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) {}@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.
