We had the same problem: try to put some objects in ROM. The solution was
something like this:

class Obj { // possibly ROM-able class
public:
    int Id;
    int Value;

    void someFunction();
}

class ROMObjectsHolder {
    static const Obj Obj1; // object in ROM
    static const Obj Obj2; // object in ROM
    static const Obj Obj3; // object in ROM
}

and in the .cpp file:

ROMObjectsHolder::Obj1 = {1, 10};
ROMObjectsHolder::Obj2 = {2, 11};
ROMObjectsHolder::Obj3 = {3, 12};

The ideas are:
   1. Keep the Obj class simple (aggregate class):
        - no ctor: use instead initialization list {...}.
            If the class has a ctor the compiler may be tented to make a
function call.
            (An alternative would be to make the ctor inline.)
        - no base class
        - private data is fine but the compiler may complain about initializing
with curly brackets {...} an object with private parts...
        - no const members (these have to be initialized in the ctor init
list): use nested enums instead.
    2. Use static const objects.
        - The objects have to be const so that the compiler knows that he can
put them in ROM.
        - The objects have to be static so that the compiler knows that they
are to be created "before anything else". Otherwise they may be created when
the flow of control reaches the line where the object created.

This works with the GreenHils compiler that is used for ES development.

jkanze@otelo.ibmmail.com wrote:

> In article <87lnuqjry7.fsf@lickey.shell4.ba.best.com>,
>   Matt Armstrong <mattdav+matt@best.com> wrote:
> >
> > Or (from a non-embeded systems point of view), placement of objects in
> > read only memory (the code segment).
> >
> > Does the standard say anything about when an instance of a
> > class/struct can and can not be put into ROM?
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

jkanze@otelo.ibmmail.com wrote:
>
> In article <87lnuqjry7.fsf@lickey.shell4.ba.best.com>,
>   Matt Armstrong <mattdav+matt@best.com> wrote:
> >
> > Or (from a non-embeded systems point of view), placement of objects in
> > read only memory (the code segment).
> >
> > Does the standard say anything about when an instance of a
> > class/struct can and can not be put into ROM?
>
> Not really.  A const object CAN be put into ROM, unless it contains
> mutable members, but need not be.
>
> Note that an object is not const within its constructors or destructor.
> This will typically mean that the compiler won't let you put any object
> with non-trivial constructors or destructors in ROM, although in theory,
> it could probably do so under the as if rule.  (I'm thinking of things
> like "complex const i( 0.0 , -1.0 ) ;" Under the as if rule, the compiler
> doen't need to call the actual constructor; it could use static
> initialization, because--supposing the normal constructor--there is no
> way a conforming program could tell.  I don't know of a compiler that
> does this, however.)
>
> As a general rule, I wouldn't count on being to put anything other than
> plain old data in ROM.
>
> > The answer becomes
> > important in embeded systems when you want hardware guarantees that an
> > object won't be modified or you just don't want a const object taking
> > up RAM.
>
> This is very implementation dependent--many compilers (at least under
> UNIX) don't offer any way of putting objects in write protected memory.
> I would expect that a compiler designed for an embedded processor would
> have some sort of facilities, but what they are and how to use them
> will depend on the implementation.
>
> > In other words, what can force a compiler to put a "const SomeObject"
> > into RAM (writable memory).  With today's compilers, what things
> > should I avoid if I want to make sure an object gets into read only
> > memory.
> >
> > Also, does the standard draw a line where you can no longer assume a
> > class' memory layout is identical to the equivalent C-style struct?
>
> Yes.  As soon as you use an access specifier, inherit, or have a virtual
> function.  I think (but I wouldn't swear it) that you can have member
> functions, constructors and destructors, without loosing the layout
> compatibility.
>
> What I would generally do in such cases, just to be sure, is to declare
> a C style struct, then inherit from it for the added functionality.
>
> > My guess is that as soon as you add inheritance or virtual functions
> > the compiler is free to add any implementation specific instance data
> > it wants -- but I'm wondering if the standard has a more definite
> > answer.
>
> The standard only guarantees ordering for member variables declared without
> an intervening access specifier.

Is this also true if the access specifier re-states the current state?
That is, does

class X
{
public:
  char a;
  int b;
  char c;
};

guarantee the order of a, b, c and

class Y
{
  public: char a;
  public: int b;
  public: char c;
};

not do so?

If that's true, this would give an interesting optimizing guideline:
If you are not interested in the exact order (and usually you
aren't), then restate the access specifier for each member variable.

(With alignment restrictions for int == sizeof int == 4, you would
have in the first case the layout (_ stands for padding bytes)
a___bbbbc___ (giving sizeof X == 12), while the second could be
optimized by a good compiler to ac__bbbb (giving sizeof Y == 8).
If ints are only two-byte aligned, you'd even need no padding at all
for Y!
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <34FFC8D2.72B391A8@physik.tu-muenchen.de>,
  Christopher Eltschka <celtschk@physik.tu-muenchen.de> wrote:
>
> jkanze@otelo.ibmmail.com wrote:

> > The standard only guarantees ordering for member variables declared
without
> > an intervening access specifier.
>
> Is this also true if the access specifier re-states the current state?
> That is, does
>
> class X
> {
> public:
>   char a;
>   int b;
>   char c;
> };
>
> guarantee the order of a, b, c and
>
> class Y
> {
>   public: char a;
>   public: int b;
>   public: char c;
> };
>
> not do so?

As I understand it, yes.

> If that's true, this would give an interesting optimizing guideline:
> If you are not interested in the exact order (and usually you
> aren't), then restate the access specifier for each member variable.
>
> (With alignment restrictions for int =3D=3D sizeof int =3D=3D 4, you wo=
uld
> have in the first case the layout (_ stands for padding bytes)
> a___bbbbc___ (giving sizeof X =3D=3D 12), while the second could be
> optimized by a good compiler to ac__bbbb (giving sizeof Y =3D=3D 8).
> If ints are only two-byte aligned, you'd even need no padding at all
> for Y!

Well, I've yet to see a compiler that actually rearranges the order
even when it is allowed.  So don't expect much optimization with this
with current compilers.

--
James Kanze    +33 (0)1 39 23 84 71    mailto: kanze@gabi-soft.fr
        +49 (0)69 66 45 33 10    mailto: jkanze@otelo.ibmmail.com
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orient=E9e objet --
              -- Beratung in objektorientierter Datenverarbeitung

-----=3D=3D Posted via Deja News, The Leader in Internet Discussion =3D=3D=
-----
http://www.dejanews.com/   Now offering spam-free web-based newsreading
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Or (from a non-embeded systems point of view), placement of objects in
read only memory (the code segment).

Does the standard say anything about when an instance of a
class/struct can and can not be put into ROM?  The answer becomes
important in embeded systems when you want hardware guarantees that an
object won't be modified or you just don't want a const object taking
up RAM.

In other words, what can force a compiler to put a "const SomeObject"
into RAM (writable memory).  With today's compilers, what things
should I avoid if I want to make sure an object gets into read only
memory.

Also, does the standard draw a line where you can no longer assume a
class' memory layout is identical to the equivalent C-style struct?
My guess is that as soon as you add inheritance or virtual functions
the compiler is free to add any implementation specific instance data
it wants -- but I'm wondering if the standard has a more definite
answer.

Thanks!
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <87lnuqjry7.fsf@lickey.shell4.ba.best.com>,
  Matt Armstrong <mattdav+matt@best.com> wrote:
>
> Or (from a non-embeded systems point of view), placement of objects in
> read only memory (the code segment).
>
> Does the standard say anything about when an instance of a
> class/struct can and can not be put into ROM?

Not really.  A const object CAN be put into ROM, unless it contains
mutable members, but need not be.

Note that an object is not const within its constructors or destructor.
This will typically mean that the compiler won't let you put any object
with non-trivial constructors or destructors in ROM, although in theory,
it could probably do so under the as if rule.  (I'm thinking of things
like "complex const i( 0.0 , -1.0 ) ;" Under the as if rule, the compiler
doen't need to call the actual constructor; it could use static
initialization, because--supposing the normal constructor--there is no
way a conforming program could tell.  I don't know of a compiler that
does this, however.)

As a general rule, I wouldn't count on being to put anything other than
plain old data in ROM.

> The answer becomes
> important in embeded systems when you want hardware guarantees that an
> object won't be modified or you just don't want a const object taking
> up RAM.

This is very implementation dependent--many compilers (at least under
UNIX) don't offer any way of putting objects in write protected memory.
I would expect that a compiler designed for an embedded processor would
have some sort of facilities, but what they are and how to use them
will depend on the implementation.

> In other words, what can force a compiler to put a "const SomeObject"
> into RAM (writable memory).  With today's compilers, what things
> should I avoid if I want to make sure an object gets into read only
> memory.
>
> Also, does the standard draw a line where you can no longer assume a
> class' memory layout is identical to the equivalent C-style struct?

Yes.  As soon as you use an access specifier, inherit, or have a virtual
function.  I think (but I wouldn't swear it) that you can have member
functions, constructors and destructors, without loosing the layout
compatibility.

What I would generally do in such cases, just to be sure, is to declare
a C style struct, then inherit from it for the added functionality.

> My guess is that as soon as you add inheritance or virtual functions
> the compiler is free to add any implementation specific instance data
> it wants -- but I'm wondering if the standard has a more definite
> answer.

The standard only guarantees ordering for member variables declared witho=
ut
an intervening access specifier.

--
James Kanze    +33 (0)1 39 23 84 71    mailto: kanze@gabi-soft.fr
        +49 (0)69 66 45 33 10    mailto: jkanze@otelo.ibmmail.com
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orient=E9e objet --
              -- Beratung in objektorientierter Datenverarbeitung


-----=3D=3D Posted via Deja News, The Leader in Internet Discussion =3D=3D=
-----
http://www.dejanews.com/   Now offering spam-free web-based newsreading
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]