Topic: object layout
Author: Gilbert Chang <gilbert@ia-us.com>
Date: 1998/08/11 Raw View
Does the standard have anything to say about how C++ objects are layed out in
memory, especially when virtual functions are involved?
Thanks
Gilbert
[ 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 ]
Author: clamage@Eng (Steve Clamage)
Date: 1998/08/11 Raw View
Gilbert Chang <gilbert@ia-us.com> writes:
>Does the standard have anything to say about how C++ objects are layed out in
>memory, especially when virtual functions are involved?
Hardly anything. The implementation has to tell you the size
and alignment requirements of the basic types (int, char, double,
etc). Some of this information is also deducible from the various
headers, especially <limits>, <climits>, <cfloat>.
POD-structs must be laid out the same as in C. (A "POD-struct" is
roughly a struct or union that has no C++ features that could cause
it to differ from a C struct or union.)
Between access modifiers ("private", "protected", "public")
class members must be in non-decreasing address order,
except for bitfields.
Apart from those things, layout is entirely up to the implementation,
and layout details of classes need not even be documented.
Implementations typically do document layout, and unless
constrained by a standard for the platform, different compilers
(or different releases of the same compiler) often use different
layouts.
--
Steve Clamage, stephen.clamage@sun.com
[ 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 ]
Author: "Paul D. DeRocco" <pderocco@ix.netcom.com>
Date: 1998/08/11 Raw View
Gilbert Chang wrote:
>
> Does the standard have anything to say about how C++ objects are layed
> out in memory, especially when virtual functions are involved?
Almost nothing is defined. It doesn't state where the virtual function
table pointer is, or how base classes are included, or how virtual base
classes are pointed to. It also allows data members to be non-contiguous
if there is an intervening public/protected/private specifier. About all
you can say is that consecutive non-static data members will be
consecutive (with possible alignment padding) if there is no intervening
public/protected/private specifier.
--
Ciao,
Paul
[ 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 ]
Author: smk@typhoon.cadre (Stephen M. Kafka)
Date: Mon, 12 Dec 1994 17:14:40 GMT Raw View
A question about class layout. Given the following
class a {};
class b : public a {};
It is clear that the sizeof(a) >= 1, lets say it is exactly 1 for a given implementation.
Then what would be the sizeof(b) ? Does the compiler have to carry forward the
fact that "a" has been allocated 1 byte ? So is the sizeof(b) == 2 ?
Or is it implementation defined so the sizeof(b) could be 1 or 2 ?
Here's another question.
class aa { };
class bb: public virtual aa
{
int i;
};
The sizeof(aa) is 1.
For class bb, if the compiler allocates space for the virtual base pointer and for the
member "i" does it also have to allocate space for the class aa (which again is 1).
If the sizeof(void *) == 4 and sizeof(int) == 4 then the sizeof(bb) should be 8 [the
case where no space for the base class a is actually allocated] or [depending on alignment]
12 or 16 ?
If no space is allocated for the base class, then the following could lead to problems
class aa { };
static aa sa;
class bb: public virtual aa {
public:
int i;
};
class bbb {
int i;
};
static bb lc;
main()
{
struct tst {
bb bf;
char p;
} ls;
ls.p = 'a';
cout << "ls.p before = " << ls.p << endl;
aa *ap = &ls.bf;
*ap = sa;
cout << "ls.p after = " << ls.p << '\n'; // shows that ls.p has been changed
return 0;
}
as it does with a certain compiler.