TITLE: sizeof, parenthesis, and references

(Newsgroups: comp.lang.c++.moderated, 29 Oct 96)

PAYNE: Tom Payne <thp@cs.ucr.edu>

>: >The issue at hand, however, is what sizeof should yield when applied
>: >to a parenthesized reference type, an entirely different kind of
>: >entity.


CLAMAGE: Steve Clamage <clamage@taumet.Eng.Sun.COM>

>: Date: Fri, 11 Oct 1996 10:11:19 -0700
>: Subject: Re: references vs. pointers: an OOD issue
>: References: <53kgd3$1jg@netlab.cs.rpi.edu>
>
>: Why do you say that?  Parens around declarators can affect binding
>: of the elements of a declaration, and affect ambiguity of declarations.
>: But I don't find anything in the ARM or draft standard that says putting
>: parens around an entire type has any particular meaning. 


PAYNE: 

>From the draft standard, 5.3.3:
>
>  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. ...


CLAMAGE: 

I think you are reading too much into that sentence. It merely
reflects the syntax of the sizeof operator:

	'sizeof' unary-expression
	'sizeof' '(' type-id ')'

That is, finding the size of a type requires putting the type in parens.
(I view that as a glitch inherited from C. The parens should always be
required, in my view. Certainly they make the code easier to read. An
expression like
	sizeof d * e + 4 // legal without any parens
is going to send most programmers back to a syntax chart, and still
will leave doubt in the mind of the reader as to whether the author
really meant what the code says.)

I don't think the draft says anywhere that a parenthesized type means anything
different from the type without parens, except possibly for grouping. (And
of course, some constructions like sizeof or a function declaration may
require parens around a type for other reasons.)

Regarding the main topic, I believe it is entirely clear that according
to the C++ language rules and definition, a reference is not an object.

One can argue (as you have) that the definition is wrong, and a reference
should be considered an object. It seems to me that either you say a
reference is not an object, or you say it is an object with some exceptions
to the usual properties of objects. It doesn't strike me that the latter
has any advantages over the former, but reasonable people could disagree
on that point.