Why should a class or struct must have no user defined constructor or destructor to ensure ROMability for const in C++?

2
votes

I was reading a reference on C++ and there I found out that in order to ensure ROMability for an object defined as const :
1.The class or struct must have no user-defined constructors
2.There can be no base classes or member objects with user defined constructors or destructors.
I am taking this in reference to bitwise const and not mutable const.
In my views ,the first one holds because the constructor or destructor modifies the const data members. So, we refrain from using user defined constructor or destructor.
But I can't get a good explaination for the second point.

3
c++constants
Define ROMability. It is not a standard term AFAIK. – Alok Save
You have to define what you mean by "ROMability"? Is it to put the code in ROM, or to put a complete object in ROM? If the latter, then the class can't contain any code that modifies the object (you can't modify ROM), but if it's only to store the code, and you create the objects in RAM then there is no such limits. – Some programmer dude
If an object is defined as const, it is a candidate to be placed in ROM , which is often an important consideration in embedded systems programming. So I am asking in this reference that to ensure this why do these points hold. – Kavish Dwivedi
The C++ standard does not define where an object will be stored it only specify's the behaviors expected from objects depending on storage specification. At best this will be specific to an implementation or a platform. – Alok Save
Simply making an object const won't assure this right? – Kavish Dwivedi

3 Answers

3
votes

A constructor / destructs would modify the object, which goes against it being stored in ROM.

If the class contains objects or inherits a constructor, that still is code that must run to construct the object (members are stored together with their parent objects). Which is not possible to do at compile-time (when ROM objects are assembled).

3
votes

As you say, the first point is necessary because objects with user-defined constructors are initialised at run-time (during the dynamic initialisation phase before running main, if they have a static lifetime), and so can't be placed in read-only memory since that initialisation must modify the object's memory.

The second point follows from the first - if a (non-static) member or base sub-object has a user-defined constructor, then that constructor must also be used to initialise the member or sub-object at runtime. Therefore, at least part of the object can't be stored in read-only memory; and so the object itself can't be.

3
votes

This looks like the definition of POD in C++03. POD means plain old data. A const global instance of that could be placed in ROM by some compiler and platform.

C++11 adds new language features that can mapped to ROMable. constexpr constructors and standard layout types, between them, may be a reasonable set of restrictions on what some compiler can put into ROM. But this will depend on the compiler's support for ROMing data.