On 02 May 03 02:59:15 GMT, "Oliver S." <Follow.Me@gmx.net> wrote:
>  Given the following two classes ...
>
> class A
> {
> public:
>  int  i;
>  char c;
> };
>
> class B : public A
> {
> public:
>  char c2;
> };
>
>  ... I've got a question regarding any possible size-constraints on the
> second class. With my compiler, sizeof(A) is 8 and sizeof(B) is 12. Would
> it violate any standard-requirement if a compiler takes the opportunity
> to place the data-members of a derived class within the tail-padding of
> the base-class,

No, afaik. It's up to the compiler.



      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <Xns9375F17B875CEFollowMeGmxNet@130.133.1.4>,
Follow.Me@gmx.net says...
>  > If the class has many access specifiers (eg. "private"), the compiler
>  > may re-arrange the access blocks in any order, though within each block
>  > the order is order in which you declare the variables.  For example.
>
>   Sure ? AFAIK access-specifiers themselfes do not qualify a class
> /struct as a non-POD - and rearranging the members of a POd is illegal.

Unfortunately, that's not the case -- there's nothing that says members
of a POD can't be rearranged.  Even if you have something like:

struct A {
 int x; // public by default
public: // vacuous -- already public
 int y;
public: // still vacuous
 int z;
};

The insertion of the access specifiers allows rearrangement of y and z,
even though it's a POD-struct and the access is public throughout.  The
rules about PODs (as such) do nothing to prevent this.  Oddly, x cannot
be rearranged -- but it's the rules about unions, not the rules about
PODs that prevent it.  The union rules say that if a union has a struct
as a member, then the address of the union must be the same as the
address of the first member of the struct.  As such, x has to be put
first in the struct just in case somebody somewhere defines a union that
includes an A.  There's also a rule that even if the declaration of A
isn't used in the union, if an equivalent struct is defined in a
different TU, and IT'S used in a union, then a pointer to the union can
refer to an A, and still depend on accessing it correctly -- so there's
no way for the compiler to deduce when it might be able to rearrange x
and remain conforming.

--
    Later,
    Jerry.

The universe is a figment of its own imagination.
---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <Xns9376ADD519609ukcoREMOVEfreenetrtw@195.129.110.130>,
rtw@freenet.REMOVE.co.uk says...

[ ... ]

> Perhaps but a POD class is also an aggregate, so all data fields must
> be public.

A POD Class can contain private and/or protected data, as long as it's
static.

> So as soon as you put data into a protected: or private: section
> you have a non-POD and reordering can occur (AFAICT ;-)).

$8.5.1/1 disagrees.

--
    Later,
    Jerry.

The universe is a figment of its own imagination.
---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Rob Williscroft" <rtw@freenet.REMOVE.co.uk> wrote in message news:Xns9376ADD519609ukcoREMOVEfreenetrtw@195.129.110.130...

> >   Sure ? AFAIK access-specifiers themselfes do not qualify a class
> > /struct as a non-POD - and rearranging the members of a POd is illegal.
> >
>
> Perhaps but a POD class is also an aggregate, so all data fields must
> be public.

All non-static data members must be public.

>
> So as soon as you put data into a protected: or private: section
> you have a non-POD and reordering can occur (AFAICT ;-)).

However, you can still have access specifiers.   The trivial case:

    struct x {
    public:
        int a;
    public:
        int b;
    };

x is pod.  What is the ordering of a and b?   You can also have private
member functions (provided they aren't constructors etc...) and static
data.
---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

Jerry Coffin <jcoffin@taeus.com> wrote in message
news:<MPG.192579d09bd2d950989997@news.clspco.adelphia.net>...
> In article <Xns9375F17B875CEFollowMeGmxNet@130.133.1.4>,
> Follow.Me@gmx.net says...
> >  > If the class has many access specifiers (eg. "private"), the
> >  > compiler may re-arrange the access blocks in any order, though
> >  > within each block the order is order in which you declare the
> >  > variables.  For example.

> >   Sure ? AFAIK access-specifiers themselfes do not qualify a class
> > /struct as a non-POD - and rearranging the members of a POd is
> > illegal.

> Unfortunately, that's not the case -- there's nothing that says
> members of a POD can't be rearranged.  Even if you have something
> like:

> struct A {
>  int x; // public by default
> public: // vacuous -- already public
>  int y;
> public: // still vacuous
>  int z;
> };

> The insertion of the access specifiers allows rearrangement of y and
> z, even though it's a POD-struct and the access is public throughout.
> The rules about PODs (as such) do nothing to prevent this.  Oddly, x
> cannot be rearranged -- but it's the rules about unions, not the rules
> about PODs that prevent it.  The union rules say that if a union has a
> struct as a member, then the address of the union must be the same as
> the address of the first member of the struct.  As such, x has to be
> put first in the struct just in case somebody somewhere defines a
> union that includes an A.  There's also a rule that even if the
> declaration of A isn't used in the union, if an equivalent struct is
> defined in a different TU, and IT'S used in a union, then a pointer to
> the union can refer to an A, and still depend on accessing it
> correctly -- so there's no way for the compiler to deduce when it
> might be able to rearrange x and remain conforming.

If the class is a POD, the address of the first element (converted to
void*) must compare equal to the address of the class (converted to
void*).  That pretty much means that the first declared element must be
the first element in the physical layout.  No question there.

Beyond that, my understanding of '9.5 is that the following should be
legal:

    struct A
    {
        int x ;
    public:
        int y ;
    public:
        int z ;
    } ;

    struct B
    {
        int x ;
        int y ;
        int z ;
    } ;

    union U { A a ; B b ; } u ;

    u.b = aB ;
    A a = u.a ;

if this is to work, the compiler cannot reorder A.  See also '9.2/14 --
A and B are "layout compatible".

A lot hinges on what is meant exactly by "share a common initial
sequence".  I think that A and B, above share a common intial sequence,
but I suppose that that could be argued.  On the other hand, I don't see
too many possible interpretations of "layout compatible".  And the
standard is quite clear there: "Two POD_struct types are
layout-compatible if they have the same number of members, and
corresponding members (in order) have layout-compatible types.

Given struct A, I don't see how a compiler can deduce that there is not
a struct B in any other compilation unit.  And if it cannot deduce this,
I don't think that it can reorder the members.

--
James Kanze             GABI Software
mailto:kanze@gabi-soft.fr
Conseils en informatique orientie objet/
                           Beratung in objektorientierter
Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, Til. : +33 (0)1 30 23 45
16

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ 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. ---               ]

"Francis Glassborow" <francis@robinton.demon.co.uk> wrote in message news:47wLayJWstt+Ew93@robinton.demon.co.uk...
> In article <ounta.66940$cO3.4526858@bgtnsc04-news.ops.worldnet.att.net>,
> Siemel Naran <SiemelNaran@KILL.att.net> writes
> >When our struct has multiple access specifiers
> >
> >struct MyJunk {
> >   private: char c1;
> >   private: int i; double d;
> >   private: char c2;
> >};
> >
> >the compiler may re-arrange the blocks in any order.  Thus it may rewrite
> >the struct as
>
> Even more than that, I believe the compiler is allowed to interleave
> items declared in different 'blocks'. The only requirement that I am
> aware of is that within the same block the order of the addresses of
> data members must be the same as the order of declaration.

I don't buy this.  While you could read it this way, my interpretation is
that passage is talking about allowing padding between elements within
the block (not other elements).   It certainly can't be permitted for POD's,
it would break layout compatibility.   It appears to be a defect in the standard.
---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

Oliver S. wrote:
>  > If the class has many access specifiers (eg. "private"), the compiler
>  > may re-arrange the access blocks in any order, though within each block
>  > the order is order in which you declare the variables.  For example.
>
>   Sure ? AFAIK access-specifiers themselfes do not qualify a class
> /struct as a non-POD - and rearranging the members of a POd is illegal.
>

(To comp.std.c++ only)

Where do you read that?  I know only that rearranging the
members between access specifiers is illegal.

-- James.

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Fri, 9 May 2003 20:13:26 +0000 (UTC), jdennett@acm.org (James Dennett)
wrote:

> Oliver S. wrote:
> >  > If the class has many access specifiers (eg. "private"), the compiler
> >  > may re-arrange the access blocks in any order, though within each block
> >  > the order is order in which you declare the variables.  For example.

> >   Sure ? AFAIK access-specifiers themselfes do not qualify a class
> > /struct as a non-POD - and rearranging the members of a POd is illegal.

> Where do you read that?  I know only that rearranging the
> members between access specifiers is illegal.

The original statement uses "private" which makes the point.  Private and
protected do remove aggregate, thus POD status, but public does not.
Consider:

class C {
   public : int i;
   public : float f;
   };

I think that is still a POD and reordering would not be allowed.

John

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

Oliver S. wrote in news:Xns9375F17B875CEFollowMeGmxNet@130.133.1.4:

> > If the class has many access specifiers (eg. "private"), the compiler
> > may re-arrange the access blocks in any order, though within each block
> > the order is order in which you declare the variables.  For example.
>
>   Sure ? AFAIK access-specifiers themselfes do not qualify a class
> /struct as a non-POD - and rearranging the members of a POd is illegal.
>

Perhaps but a POD class is also an aggregate, so all data fields must
be public.

So as soon as you put data into a protected: or private: section
you have a non-POD and reordering can occur (AFAICT ;-)).

Rob.
--
http://www.victim-prime.dsl.pipex.com/

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <ounta.66940$cO3.4526858@bgtnsc04-news.ops.worldnet.att.net>,
Siemel Naran <SiemelNaran@KILL.att.net> writes
>When our struct has multiple access specifiers
>
>struct MyJunk {
>   private: char c1;
>   private: int i; double d;
>   private: char c2;
>};
>
>the compiler may re-arrange the blocks in any order.  Thus it may rewrite
>the struct as

Even more than that, I believe the compiler is allowed to interleave
items declared in different 'blocks'. The only requirement that I am
aware of is that within the same block the order of the addresses of
data members must be the same as the order of declaration.


--
Francis Glassborow      ACCU
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Oliver S." <Follow.Me@gmx.net> wrote in message

>  ... I've got a question regarding any possible size-constraints on the
> second class. With my compiler, sizeof(A) is 8 and sizeof(B) is 12. Would
> it violate any standard-requirement if a compiler takes the opportunity
> to place the data-members of a derived class within the tail-padding of
> the base-class, so that the size of the derived- and the base-class are
> equal in some cases even though the derived class contains additional
> data-members ? With my example this would mean that if my compiler would
> be that smart, sizeof(A) and sizeof(B) would be 8.

To summarize the results so far, the sizeof(Derived) may equal sizeof(Base)
even if Derived adds data members.  Though in most of the implementations
I've seen so far, if the Derived class adds data members then
sizeof(Derived)>sizeof(Base), and if the Derived class adds no data members
then sizeof(Derived)==sizeof(Base) because of the empty base optimization.

There's another related point which I learned on this newsgroup.

If the class has many access specifiers (eg. "private"), the compiler may
re-arrange the access blocks in any order, though within each block the
order is order in which you declare the variables.  For example.

struct Junk { char c1; int i; double d; char c2; };

has sizeof(double)*3==24 on WinME Borland 6.

struct OptimizedJunk { char c1; char c2; int i; double d; };

has sizeof(double)*2==16 on the same platform.

When our struct has multiple access specifiers

struct MyJunk {
   private: char c1;
   private: int i; double d;
   private: char c2;
};

the compiler may re-arrange the blocks in any order.  Thus it may rewrite
the struct as

   private: char c1;
   private: char c2;
   private: int i; double d;

thereby reducing the size of the struct.  The fact that in the derived-only
members of a class may be placed before the base-only members seems to be an
instance of this re-ordering rule.  However Borland 6 and most other
compilers do not do this optimization.

--
+++++++++++
Siemel Naran
---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

Siemel Naran wrote:

> "Oliver S." <Follow.Me@gmx.net> wrote in message
>
>  >  That's what I also *believe* and furthermore I believe that this
>  >  should
>  > be ok even with virtual base-classes, but sometimes there are
>  > constraints the standard makes which have reasons that aren't
>  > obvious; f.e. a compi- ler isn't allowed to give a size of zero
>  > with an empty structure !
>
> You can take the address of an empty structure.  If the empty
> structure had
> size zero what would the address point to?  I guess it could point to
> junk, but they didn't want them, I guess for aesthetic reasons among
> others.

Not only. In an array, every object must have a distinct address.
---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Francis Glassborow" <francis@robinton.demon.co.uk> wrote in message

> The compiler could use the padding after c. Unless someone can quote
> otherwise from the standard, I think that derived data members can even
> be interleaved with base class members if appropriate padding bytes are
> available.

Yes, this is correct.  The derived only part of the class can be placed
before the base part.

--
+++++++++++
Siemel Naran
---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Oliver S." <Follow.Me@gmx.net> wrote in message

 >  That's what I also *believe* and furthermore I believe that this should
 > be ok even with virtual base-classes, but sometimes there are constraints
 > the standard makes which have reasons that aren't obvious; f.e. a compi-
 > ler isn't allowed to give a size of zero with an empty structure !

You can take the address of an empty structure.  If the empty structure had
size zero what would the address point to?  I guess it could point to junk,
but they didn't want them, I guess for aesthetic reasons among others.

--
+++++++++++
Siemel Naran



      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Oliver S." <Follow.Me@gmx.net> skrev i meddelandet
news:Xns936FD0E3E1D0FollowMeGmxNet@130.133.1.4...
 > > I believe that compilers are completely free to use padding in base
 > > classes for derived class data members providing only that the
 > > requirements for ordering of data members are applied.
 >
 >  That's what I also *believe* and furthermore I believe that this should
 > be ok even with virtual base-classes, but sometimes there are constraints
 > the standard makes which have reasons that aren't obvious; f.e. a compi-
 > ler isn't allowed to give a size of zero with an empty structure !

Yes, that is because sizeof() also gves the distance between elements in an
array. Each element is different, so it has to have a different address.
Element n in an array a is at address a + n *sizeof(type), therefore
sizeof(type) cannot be 0.


Bo Persson
bop2@telia.com



      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <Xns936FD1C2A20E6FollowMeGmxNet@130.133.1.4>, Oliver S.
<Follow.Me@gmx.net> writes
> > I don't know, but I'd be surprised if the standard addresses such
> > issues as tail padding other than allowing implementers to have it.
>
>  I don't expect any statements on tail padding in the standard;
>I'm just asking if there would be any standard-violations if a derived
>class with additional data-members has the same size like the base-class.

No, the standard has nothing to say on this issue.


--
Francis Glassborow      ACCU
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

[other cross-posted newsgroups removed]

Oliver S. wrote:
>  Given the following two classes ...
>
> class A
> {
> public:
>  int  i;
>  char c;
> };
>
> class B : public A
> {
> public:
>  char c2;
> };
>
>  ... I've got a question regarding any possible size-constraints on the
> second class. With my compiler, sizeof(A) is 8 and sizeof(B) is 12. Would
> it violate any standard-requirement if a compiler takes the opportunity
> to place the data-members of a derived class within the tail-padding of
> the base-class, so that the size of the derived- and the base-class are
> equal in some cases even though the derived class contains additional
> data-members ? With my example this would mean that if my compiler would
> be that smart, sizeof(A) and sizeof(B) would be 8.

In your example sharing the tail-padding would be illegal but if A were non-POD it would be legal.  When A is POD the following is allowed and must not destroy the derived class member, c2, of 'b':

 A a;
 B b;
 memcpy((A*)&b, &a, sizeof(A));

The IA-64 ABI mandates the reuse of tail-padding in non-POD base classes.  <http://www.codesourcery.com/cxx-abi/abi.html>

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <Xns936EAFF1A8FE8FollowMeGmxNet@130.133.1.4>, Oliver S.
<Follow.Me@gmx.net> writes
> Given the following two classes ...
>
>class A
>{
>public:
>       int  i;
>       char c;
>};
>
>class B : public A
>{
>public:
>       char c2;
>};
>
> ... I've got a question regarding any possible size-constraints on the
>second class. With my compiler, sizeof(A) is 8 and sizeof(B) is 12. Would
>it violate any standard-requirement if a compiler takes the opportunity
>to place the data-members of a derived class within the tail-padding of
>the base-class, so that the size of the derived- and the base-class are
>equal in some cases even though the derived class contains additional
>data-members ? With my example this would mean that if my compiler would
>be that smart, sizeof(A) and sizeof(B) would be 8.

I believe that compilers are completely free to use padding in base
classes for derived class data members providing only that the
requirements for ordering of data members are applied.

I think this means that even were you to define

class A {
        char c;
        int i;
//
..
};

The compiler could use the padding after c. Unless someone can quote
otherwise from the standard, I think that derived data members can even
be interleaved with base class members if appropriate padding bytes are
available.


--
Francis Glassborow      ACCU
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ 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. ---               ]

Oliver S. <Follow.Me@gmx.net> wrote in message
news:Xns936EAFF1A8FE8FollowMeGmxNet@130.133.1.4...
> Given the following two classes ...
>
> class A
> {
> public:
> int  i;
> char c;
> };
>
> class B : public A
> {
> public:
> char c2;
> };
>
>  ... I've got a question regarding any possible size-constraints on the
> second class. With my compiler, sizeof(A) is 8 and sizeof(B) is 12. Would
> it violate any standard-requirement if a compiler takes the opportunity
> to place the data-members of a derived class within the tail-padding of
> the base-class, so that the size of the derived- and the base-class are
> equal in some cases even though the derived class contains additional
> data-members ? With my example this would mean that if my compiler would
> be that smart, sizeof(A) and sizeof(B) would be 8.
>

It might be necessary for alignment reasons to do it one particular way, but
that is
platform specific. From the standard, there is nothing to avoid packing the
members
in the way you want.

Packing members for minimum size often comes at a speed penalty; good
implementations
should offer you a way to prefer a different strategy.

Simon Bone
---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

Oliver S. <Follow.Me@gmx.net> wrote in message
news:Xns936EAFF1A8FE8FollowMeGmxNet@130.133.1.4...
> Given the following two classes ...
>
> class A
> {
> public:
> int  i;
> char c;
> };
>
> class B : public A
> {
> public:
> char c2;
> };
>
>  ... I've got a question regarding any possible size-constraints on the
> second class. With my compiler, sizeof(A) is 8 and sizeof(B) is 12. Would
> it violate any standard-requirement if a compiler takes the opportunity
> to place the data-members of a derived class within the tail-padding of
> the base-class,

I don't know, but I'd be surprised if the standard addresses such issues as
tail padding other than allowing implementers to have it. You would expect
that any object-layout model that allows all language features to work would
be allowed, and I can't think of any feature that wouldn't work in this
case.

> so that the size of the derived- and the base-class are
> equal in some cases even though the derived class contains additional
> data-members ? With my example this would mean that if my compiler would
> be that smart, sizeof(A) and sizeof(B) would be 8.

I don't see why that should be a problem. You are already likely to have
have equal sizes if the derived class adds no data members. You shouldn't
assume anything about relative sizes of objects of different classes anyway,
so I don't see how equal sizes could matter.

However, I could be completely wrong.

David
---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]