From -6782287086045787894
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: f78e5,b054a21715049ddb
X-Google-Attributes: gidf78e5,public
From: Cristian Georgescu <Cristian.Georgescu@worldnet.att.net>
Subject: Re: Placement of objects in ROM and physical object layout
Date: 1998/03/21
Message-ID: <6evde1$1j8@bgtnsc02.worldnet.att.net>#1/1
X-Deja-AN: 336162288
Content-Transfer-Encoding: 7bit
References: <87lnuqjry7.fsf@lickey.shell4.ba.best.com> <6dm38g$fhc$1@nnrp1.dejanews.com>
X-Original-Date: Fri, 20 Mar 1998 22:44:17 -0500
Content-Type: text/plain; charset=us-ascii
Organization: AT&T WorldNet Services
X-Auth: PGPMoose V1.1 PGP comp.std.c++ iQBFAgUANRM79uEDnX0m9pzZAQF1dQF/ZoeLx9f11ELZjLg+4syEgozPX9R9Ty9p zq5llEPM9VvgTOGWY4CjxEjhg/KKDjbO =gL4b
Mime-Version: 1.0
Reply-To: Cristian.Georgescu@worldnet.att.net
Newsgroups: comp.std.c++


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              ]