Unsolved inherited classes and const members
-
@J.Hilk I recognize kshegunov's suggestion as the correct answer, assuming I was going to stubbornly insist on trying to implement this as I originally described. What I meant to ask was, should I be taking a different approach to this problem? Perhaps multiple true const definitions outside the class, and the subclasses have their own members instead of re-using the base class'? Just thinking out loud here.
-
@mzimmers said in inherited classes and const members:
What I meant to ask was, should I be taking a different approach to this problem?
Perhaps, but let me rephrase your question as it sounds to me (warning metaphor following):
I want to drive a nail, how heavy a hammer do I need?
The obvious answer would be: "Well, depends on the nail". That is to say, what's your context?
From what we've discussed so far we have a dummy class with a constant - nothing more than a means to an end. So what's your end goal? Where, how are you going to use it and why you need that constant? -
@kshegunov fair enough. I'm working on an embedded application. The host device originally called for a push button (a real button, not a QPushButton). Now it is being modified to have 2 buttons. For each button, I need to poll a GPIO, perform debouncing, and report when a valid press has occurred.
Except for a few arguments for the debouncing algorithm, the software for the buttons will be identical. So, I thought that for each button type, I'd just pass in some values at construction and leave it at that. Those values don't have to be constants, but that was my original thinking before I realized that it wasn't entirely straightforward.
-
Have you no one there on site to preach about how evil it is to use c++ for embedded applications? non-deterministic memory management with a high probability of long term memory fragmentation, the overhead of exceptions and/or the c++ runtime?
the term "embedded" has become so ambiguous in recent years. LOL
To me, embedded usually mean hard RTOS, with extremely tight deterministic requirements for things like memory managment and interupt handling...not exactly the typical Qt use case.
and yeah, for non-critical embedded systems I like coding in c++ too, if they'll let me. :^)
PS - yell and scream until they implement the debounce in hardware. It's just a couple freaking caps and it will work flawlessly.
-
@mzimmers said in inherited classes and const members:
@kshegunov thanks for the example. I'm starting to think it was a bad idea to re-use names of consts - makes for more complex code, and could be very confusing to keep straight.
I guess I still don't entirely understand inheritance. Why is this wrong?
class Base { protected: int i; }; class Derived : public Base { public: Derived(); }; Derived::Derived() : i (1) {}
see this -> StackOverflow
-
@Kent-Dorfman you did know that Reagan's out of office, right? You sound like you're almost as much of a dinosaur as I am.
In seriousness, I don't disagree with your definition of embedded systems, though it is a bit limiting in the age of IoT. I think Qt is a fine platform for many embedded applications, provided that the product designer doesn't get too stingy with the hardware resources.
In my case, this app is headless, so I'm not using the Qt libraries...just Creator as an editor and code browser. Better than anything else I've found so far.
-
The host device originally called for a push button (a real button, not a QPushButton). Now it is being modified to have 2 buttons. For each button, I need to poll a GPIO, perform debouncing, and report when a valid press has occurred.
You could use a private anonymous enum for that, e.g.:
class Something { private: enum { Whatever = 300 }; };
I don't see any real gain in having it as a member though, probably a static for each class (basically a scoped global constant) would be more practical, e.g.:
class Something { private: static const int whatever; };
and don't forget to define it in the source (or use direct initialization if your compiler supports it):
static const int Something::whatever = 200;
@Kent-Dorfman said in inherited classes and const members:
non-deterministic memory management
What's non-deterministic about it?
with a high probability of long term memory fragmentation
I don't see how memory fragmentation has anything to do with c++. Heap allocations are calls into the kernel, they're not managed directly.
the overhead of exceptions
Exceptions can be disabled, and
setjmp
andlongjmp
existed for pretty much as long as computers have.and/or the c++ runtime?
What would be that exactly? Constructors, destructors, operators? All of this existed before and continue to do so in C, they're just free functions. Hell even
virtual
methods I have seen emulated in C through function pointers ... -
@mzimmers said in inherited classes and const members:
@Kent-Dorfman you did know that Reagan's out of office, right? You sound like you're almost as much of a dinosaur as I am.
In seriousness, I don't disagree with your definition of embedded systems, though it is a bit limiting in the age of IoT. I think Qt is a fine platform for many embedded applications, provided that the product designer doesn't get too stingy with the hardware resources.
In my case, this app is headless, so I'm not using the Qt libraries...just Creator as an editor and code browser. Better than anything else I've found so far.
Guilty as charged
first computer: Trash80-model 1 and an S100 CPM system
first school computer use: DEC pdp-8 (via model33 teletype) and pdp-11 via la120 decwriter
first president voted for: You guessed it, although I'm still more of a William F Buckley type.
First embedded: PIC uC to interface with C64 computers in college.
...and as opinionated as you will find anywherePS - I don't like IoT from an ethics position, so I pretend it doesn't exist.
-
@kshegunov said in inherited classes and const members:
@Kent-Dorfman said in inherited classes and const members:
non-deterministic memory management
What's non-deterministic about it?
with a high probability of long term memory fragmentation
I don't see how memory fragmentation has anything to do with c++. Heap allocations are calls into the kernel, they're not managed directly.
the overhead of exceptions
Exceptions can be disabled, and setjmp and longjmp existed for pretty much as long as computers have.
and/or the c++ runtime?
What would be that exactly? Constructors, destructors, operators? All of this existed before and continue to do so in C, they're just free functions. Hell even virtual methods I have seen emulated in C through function pointers ...
re - embedded systems
there are very strict rules for embedded systems development of mission critical 24/7 devices in certain venues. Unless a memory manager is specifically designed for deterministic performance it is usually discouraged to use heap memory in those embedded designs. The work-around is static initialization of all needed memory resources at application startup. Unless you override the default <new> in c++ it will most certainly use an allocation srategy that is "space efficiency" weighted and non-deterministic management time. since the STL classes weigh heavily on heap memory allocation this makes c++ in general less suited for highly critical embedded applications. Same goes for the overhead of the c++ runtime. This has been a "best practice" in the embedded domain for many years. I myself, prefer to take it in context and believe that sometimes the benefits of OO programming outweigh the potential problems...if the designed is savvy enough to understand and avoid the pitfalls, and the applications is NOT highly critical: missile control systems, life support devices, etc.
Anyway, not worth debating. Professional embedded shops whos products are regulated will understand and abide by these practices. IoT, consumer electronics, etc...not so much.
-
@Kent-Dorfman good points made. As you noted earlier, the characteristics of embedded systems has definitely changed over the last couple decades. This is probably because 20-30 years ago, the components were so expensive, and the systems so difficult to build and test, they were only used in really important areas (military, aerospace, medical) that demanded the highly rigorous programming standards you cite. Today's wifi-enabled mood rings...not so much.
My product falls somewhere in between: while intended for professional applications, certainly isn't mission critical, truly real time or any of that. So, for me, the benefits of OOP definitely outweigh any perceived drawbacks. And, I'd venture that this is true of the great majority of what are now termed "embedded systems."
They're not the same. We're not the same.
-
This doesn't address any of my points.
Firstly, c++ has stack, so you don't want to use the heap, then don't use it.
Secondly, initialize all on application load is a dumb presumption, sorry, but it is. RAII as a principle exists to prevent that nonsense; so every self-contained unit, i.e. a class, acquires and releases resources (not only memory) consistently, not if or when the programmer remembers to do so. The exception mechanism you dread unwinds the stack for this very reason - to allow all acquired resources to be released, in comparison C's quick escape is just primitive - a non-local goto; great fun with that one. And I say again, if you don't want to pay for exception handling, disable them. As a matter of fact Qt is a no-exception library, it does not throw.
Thirdly, and I'm now sounding like a broken record I imagine, the heap is not managed by the c++ language, its compiler, nor by the STL. The heap manager is in the kernel, you want a different one, get a different kernel or if you're feeling adventurous write your own.
Fourthly, the STL is a library. Don't want it? Don't use it! Write your own version of the
std::vector
which does exactly what you want if that's necessary.I mean, I will be the first to admit that c++ has some really serious faults, that it can be quirky and has some rules that are borderline schizo, but the things you cite are not in that list.
-
@Kent-Dorfman
Briefly:first school computer use: DEC pdp-8 (via model33 teletype) and pdp-11 via la120 decwriter
Excellent --- someone must actually be older than me! :)
first president voted for: You guessed it....
Eisenhower?
-
@JonB said in inherited classes and const members:
first president voted for: You guessed it....
Eisenhower?
My guess is Roosevelt, the only remaining question is, 1st, 2nd, 3rd or 4th term ?
;-) -
@JonB said in inherited classes and const members:
@Kent-Dorfman
Briefly:first school computer use: DEC pdp-8 (via model33 teletype) and pdp-11 via la120 decwriter
Excellent --- someone must actually be older than me! :)
first president voted for: You guessed it....
Eisenhower?
Nah. the one who quoted the term "evil empire" to defer communism/socialism for another 30 years, while at the same time breaking organized labor in the US, and who looked cool as a muppet dressed as superman.