Steve Clamage (clamage@Eng.Sun.COM) wrote:

|> tony@online.tmx.com.au (Tony Cook) writes:

|> >J. Kanze (kanze@gabi-soft.fr) wrote:

|> >:  struct X { int i ; char c ; } ;
|> >:  X    x ;
|> >:  char   c[ 3 ] ;

|> >: On my system, sizeof( X ) == 8, as does sizeof( x ).  And of course,
|> >: sizeof( c ) == 3.  Curiously, however, the two variables only take up a
|> >: total of 8 bytes; in this particular case, the physical sizeof x is 5,
|> >: and not 8.  This is a perfectly legal, and frequent, implementation.)

|> >Are you sure about this?  Considering X is a POD, what if the
|> >programmer has coded:

|> > memset(&x, 0, sizeof(X));

|> >somewhere in their program?  Or does this produce undefined
|> >behaviour?

|> I think James meant that only the first 5 bytes of the struct have
|> meaningful data; the rest is padding needed for alignment. The
|> compiler must allocate sizeof(X) bytes for any type X, if only
|> because distinct objects must not overlap.

Actually, I was just writing faster than I was thinking; what I said
(and meant) is wrong.  (I even think that there was a clarification with
regards to this in the C standard.)

What I think a compiler could do is apply the as-if rule.  A conforming
program cannot compare the address of x and the address of c; if the
compiler could determine that sizeof( X ) was never used to write
unsigned char's from the address of x (or something like that), then it
could allocate them without the padding.  Given the cost of memory, and
the complexity of the analysis necessary, I don't really expect to see
any compilers doing this, though.
--
James Kanze           (+33) 88 14 49 00          email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs Bourgeois, 67000 Strasbourg, France
Conseils en informatique industrielle--
                             --Beratung in industrieller Datenverarbeitung
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

This posting follows up a posting in comp.lang.c++ dealing with the portion
of the draft standard that deals with sizeof applied to types.

In article <41nfb7$qau@druid.borland.com> Pete Becker (pete@borland.com) wrote:
 :
 : In article <41lqnl$fgb@galaxy.ucr.edu>, thp@cs.ucr.edu says...
 : >
 : >As I read 5.3.3, it seems to support my claim:
 : >
 : >  1 The sizeof operator yields the number of bytes in the object represen-
 : >  tation of its operand.  The operand is either an expression, which  is
 : >  not  evaluated, or a parenthesized type-id.  The sizeof operator shall
 : >  not be applied to an expression that has function or incomplete  type,
 : >  or  to  an  enumeration  type  before  all  its  enumerators have been
 : >  declared, or to the parenthesized name of such types, or to an  lvalue
 : >  that   designates   a   bit-field.   [Note:  sizeof(char)  is  1,  but
 : >  sizeof(bool) and sizeof(wchar_t) are implementation-defined.  10)  See
 : >  _intro.memory_  for  the  definition of byte and _basic.types_ for the
 : >  definition of object representation.  ]
 : >
 : >  2 When applied to a reference, the result is the size of the referenced
 : >  object.  ...
 : >
 : >It seems to me that (2) above is somewhat redundant in that this is
 : >the way references work under all operations, as stated elsewhere.
 : >
 : >But, in the expression sizeof(Widget&), I am applying sizeof, not to a
 : >reference, but to a parenthesized type-id for a reference type, which
 : >should yield the number of bytes in the object representation of this
 : >operand, (Widget&).
 : >
 : >This is not an inference based on internal representation but my
 : >direct reading of a portion of the standard defines a language feature
 : >that reports a feature (size) of those representations to the
 : >programmer.
 :
 : Widget& w = something;
 :
 : Are you seriously arguing that sizeof(Widget&) need not be the same as
 : sizeof(w)? Please apply a little common sense in reading the working paper. It
 : is, after all, a document written by humans to be read by humans. It is not,
 : and will not be, perfect. If it is possible to interpret something in a way
 : that is clearly absurd, and it is also pssible to interpret the same thing in
 : a way that is consistent with the rest of the paper and actually useful, do
 : the latter.
 :


Upon reading in a C++ book that it is often more efficient to pass
parameters by reference (because references are often smaller than
their referrentss), an experienced C programmer decides to determine
at what referrent size this effect becomes true.  Knowing, as all C
progrmmers do, that the sizeof operator "yields the number of bytes in
the object representation of its operand", which may be an expression
or the parenthesized name of a type, he immediately runs the program:

   #include <iostream.h>
   int main() { cout << sizeof(Widget&) << endl; }

The result, 17, he finds oddly coincidental; it's the same prime value
as sizeof(Widget).

"How strange!"

He tries some other types with the even stranger result that in all
cases sizeof(T&) is equal to sizeof(T).

"Astonishing!!  So much for the book's claim that references are more
compact than their referrents.  But I wonder why these representations
vary in size this way."


Now, let's apply some common sense.  We can blame the victim,
insisting that he has failed to "apply a little common sense" and has
interpreted the C++ semantics of sizeof "in a way that is clearly
absurd."  Or, we can design the language in a way that minimizes the
astonishment factor by preserving the well-known semantics of sizeof.

There are two issues at hand:

  * What does the present wording say is the semantics of sizeof
    as it applies to parenthesized names of types?

  * What should be the semantics of sizeof as applied to
    parenthesized names of types?

IMHO, logic, common sense, and good taste in language design all point
to a strict interpretation of the present wording.

Specifically, I find nothing in the present wording that would support
an interpretation that sizeof(T&) == sizeof(T).  Also, I find nothing
convincing about the argument that, because applying sizeof to a
reference expression, applying sizeof to a reference type must yield
the size of the referrent type.  It's similar to the non-sequitur that
brains can't think because neurons can't think.  There is no reason to
believe that properties of the components (in this case references)
can or must be shared by an ensemble (in this case a reference type).


Tom Payne (thp@cs.ucr.edu)
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

J. Kanze (kanze@gabi-soft.fr) wrote:
: (Concerning the last, consider the following:

:  struct X { int i ; char c ; } ;
:  X    x ;
:  char   c[ 3 ] ;

: On my system, sizeof( X ) == 8, as does sizeof( x ).  And of course,
: sizeof( c ) == 3.  Curiously, however, the two variables only take up a
: total of 8 bytes; in this particular case, the physical sizeof x is 5,
: and not 8.  This is a perfectly legal, and frequent, implementation.)

Are you sure about this?  Considering X is a POD, what if the
programmer has coded:

 memset(&x, 0, sizeof(X));

somewhere in their program?  Or does this produce undefined
behaviour?
--
        Tony Cook - tony@online.tmx.com.au
                    100237.3425@compuserve.com

[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

tony@online.tmx.com.au (Tony Cook) writes:

>J. Kanze (kanze@gabi-soft.fr) wrote:

>:  struct X { int i ; char c ; } ;
>:  X    x ;
>:  char   c[ 3 ] ;

>: On my system, sizeof( X ) == 8, as does sizeof( x ).  And of course,
>: sizeof( c ) == 3.  Curiously, however, the two variables only take up a
>: total of 8 bytes; in this particular case, the physical sizeof x is 5,
>: and not 8.  This is a perfectly legal, and frequent, implementation.)

>Are you sure about this?  Considering X is a POD, what if the
>programmer has coded:

> memset(&x, 0, sizeof(X));

>somewhere in their program?  Or does this produce undefined
>behaviour?

I think James meant that only the first 5 bytes of the struct have
meaningful data; the rest is padding needed for alignment. The
compiler must allocate sizeof(X) bytes for any type X, if only
because distinct objects must not overlap.

--
Steve Clamage, stephen.clamage@eng.sun.com

---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]