From 3037701608149574716 X-Google-Language: ENGLISH,ASCII X-Google-Thread: f78e5,b054a21715049ddb X-Google-Attributes: gidf78e5,public From: jkanze@otelo.ibmmail.com Subject: Re: Placement of objects in ROM and physical object layout Date: 1998/03/06 Message-ID: <6dm38g$fhc$1@nnrp1.dejanews.com>#1/1 X-Deja-AN: 331294297 Content-Transfer-Encoding: quoted-printable References: <87lnuqjry7.fsf@lickey.shell4.ba.best.com> X-Original-Date: Thu, 05 Mar 1998 05:45:59 -0600 MIME-Version: 1.0 X-MIME-Autoconverted: from 8bit to quoted-printable by ncar.UCAR.EDU id EAA01396 Content-Type: text/plain; charset=iso-8859-1 X-Http-User-Agent: Mozilla/4.03 [de] (WinNT; I) Organization: Deja News - The Leader in Internet Discussion X-Article-Creation-Date: Thu Mar 05 11:45:59 1998 GMT X-Auth: PGPMoose V1.1 PGP comp.std.c++ iQBFAgUANP9x/eEDnX0m9pzZAQEi3gF9GFf9PSJVA6hj45OcghrLuUUAmR3jIBjR iGZWNfuLijKu5JWGImoIrC+f7Rus320H =Iy0p Newsgroups: comp.std.c++ In article <87lnuqjry7.fsf@lickey.shell4.ba.best.com>, Matt Armstrong 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 ]