We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Hi,
as I understand from this link: www.caravan.net/.../guide.html in point D1 it is not possible to put an object in ROM if that object is from a class that has been derived from another class, even though everything is const.
Isn't this a huge limitation in the embedded world with it's limited RAM?
Jef
It seems to be true for the current C166 compiler. And as far as I understand from what I read that's the official ec++ website. Maybe that's why ec++ is considered 'dead' ;-) en.wikipedia.org/.../Embedded_C++
As far as I understand this everything has to go in RAM or you have to give up every OO principle. That just removes every use for ec++ in embedded.
How often do you need to override a C++ class, and need objects of that class to be const?
An example would be an abstract "lookup" class overriden by a class having specific data. The alternative then would be to avoid the class override and implement the actual functionality directly. Or call helper functions if you need many lookup classes.
In most situations, the needs looks different in an embedded application than in a PC application. Your const objects are normally quite simple, so you may not get snagged so often by this.
A ring-buffer implemented in C++ is an example of a non-const object. A CSerial class would normally also be used to create non-const objects. Same with CTimer objects. In my experience, most classes that are overriden or having virtual methods, ... are having member data that makes it impossible to use a const object in the first place. But that may not be a general case, and more a result of how I tend to structure my programs.