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 is dated very early in 1998 - is it still true?
Is it true of the actual compiler & version that you're using?
As Andy notes, I'm not sure if it is true.
The important thing is how clever the compiler and linker is at anaylyzing all potential writes to the object.
A user-defined constructor would normally make changes to the object. An inherrited class may call a base class where the constructor does make changes. An object with virtual methods may be overriden by an alternative implementation that does change fields in the object.
The problem here is that the constructors and destructor for an object are not const, and only if the compiler/linker can prove that no non-const methods can be called on the object will it be safe to place the object in ROM.
I don't think there is a standard that forbids placing a const object in ROM if the tools can prove that it is safe. The general case is that the compiler can't.
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.