🚀 go-pugleaf

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