inherited classes and const members
-
Also some floating types and missing declaration. Anyways,
READ_INTERVALisn't part ofButtonRTFM, so you can't use it in the initializer list. If you want to do that, you need to delegate it through the parent's constructor. E.g.class Button { public: Button(); protected: Button(TickType_t); const TickType_t READ_INTERVAL; }; Button::Button() : Button(100) { } Button::Button(TickType_t interval) : READ_INTERVAL(interval) { } class ButtonRTFM : public Button { public: ButtonRTFM(); }; ButtonRTFM::ButtonRTFM() : Button(500) { }@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) {} -
@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) {}@mzimmers said in inherited classes and const members:
Why is this wrong?
Consistency in the language and/or typing. You can only use the current class' members in the initializer list to prevent you from blowing off your toe (as opposed to shooting yourself in the foot).
In C++ even if you don't do it explicitly the base class' default constructor is going to be called for you (this is the first thing in the initializer list). Now imagine what is supposed to happen if the base class' constructor is initializing the same variable and then you overwrite it in the derived class' initializer. Is it correct, or simply an error?
Even worse, suppose the base class (being badly written) expects the derived class to init the base's own privates, because why not, it's allowed ... then you're in for a treat. In principle the base class is responsible for its resources (RAII), not the derived ones. If it were the other way around, it'd be like asking a car type to make sure there's internal consistency in the machine type it derives from, why should the "car" care? It's a "machine" already, right? So everything related to the machine type should already be available out of the box for its subtypes.
Read and abide by the Qt Code of Conduct
-
@mzimmers said in inherited classes and const members:
Why is this wrong?
Consistency in the language and/or typing. You can only use the current class' members in the initializer list to prevent you from blowing off your toe (as opposed to shooting yourself in the foot).
In C++ even if you don't do it explicitly the base class' default constructor is going to be called for you (this is the first thing in the initializer list). Now imagine what is supposed to happen if the base class' constructor is initializing the same variable and then you overwrite it in the derived class' initializer. Is it correct, or simply an error?
Even worse, suppose the base class (being badly written) expects the derived class to init the base's own privates, because why not, it's allowed ... then you're in for a treat. In principle the base class is responsible for its resources (RAII), not the derived ones. If it were the other way around, it'd be like asking a car type to make sure there's internal consistency in the machine type it derives from, why should the "car" care? It's a "machine" already, right? So everything related to the machine type should already be available out of the box for its subtypes.
@kshegunov good explanation, and it makes sense (though it's a little odd that you can't initialize a member, but you can assign to it, but...no matter).
So, what is considered best practices for a situation like this, where you want modified (yet constant) parameters in a subclass?
-
@kshegunov good explanation, and it makes sense (though it's a little odd that you can't initialize a member, but you can assign to it, but...no matter).
So, what is considered best practices for a situation like this, where you want modified (yet constant) parameters in a subclass?
@mzimmers
see @kshegunov post, 8 post prior
@kshegunov said in inherited classes and const members:class Button { public: Button(); protected: Button(TickType_t); const TickType_t READ_INTERVAL; }; Button::Button() : Button(100) { } Button::Button(TickType_t interval) : READ_INTERVAL(interval) { } class ButtonRTFM : public Button { public: ButtonRTFM(); }; ButtonRTFM::ButtonRTFM() : Button(500) { }
Be aware of the Qt Code of Conduct, when posting : https://forum.qt.io/topic/113070/qt-code-of-conduct
Q: What's that?
A: It's blue light.
Q: What does it do?
A: It turns blue. -
@mzimmers
see @kshegunov post, 8 post prior
@kshegunov said in inherited classes and const members:class Button { public: Button(); protected: Button(TickType_t); const TickType_t READ_INTERVAL; }; Button::Button() : Button(100) { } Button::Button(TickType_t interval) : READ_INTERVAL(interval) { } class ButtonRTFM : public Button { public: ButtonRTFM(); }; ButtonRTFM::ButtonRTFM() : Button(500) { }@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.
-
@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?Read and abide by the Qt Code of Conduct
-
@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.
The dystopian literature that served as a warning in my youth has become an instruction manual in my elder years.
-
@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) {}@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
-
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.
@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.
-
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.
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
setjmpandlongjmpexisted 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
virtualmethods I have seen emulated in C through function pointers ...Read and abide by the Qt Code of Conduct
-
@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.
@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.
-
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
setjmpandlongjmpexisted 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
virtualmethods I have seen emulated in C through function pointers ...@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.
The dystopian literature that served as a warning in my youth has become an instruction manual in my elder years.
-
@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.
-
@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.
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::vectorwhich 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.
-
@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.
@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?
-
@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 ?
;-) -
@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:
@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.
