[gnu.g++] Isn't sizeof an operator?

mdt@yahi.stanford.edu (Michael Tiemann) (03/21/89)

   In article <123@riunite.ACA.MCC.COM> rfg@riunite.UUCP (Ron Guilmette) writes:
   ["why isn't sizeof declarable as an operator?"]

   Because it's a compiler directive, not a C-language operator.  The
   result of sizeof (something) is an integer _constant_.  If you try to
   take the size of something that has a varying size, you will get only
   the size of that thing at compile time.

   If you're creating varying-sized data elements, you should keep track of
   their sizes yourself.

				   --Blair
				     "But I don't know why you would..."

It also takes a TYPE as an argument instead of an EXPRESSION.

Michael

hearn@claris.com (Bob Hearn) (03/21/89)

In article <8903202240.AA24954@yahi> tiemann@lurch.stanford.edu writes:
>
>   In article <123@riunite.ACA.MCC.COM> rfg@riunite.UUCP (Ron Guilmette) writes:
>   ["why isn't sizeof declarable as an operator?"]
>
>   Because it's a compiler directive, not a C-language operator.  The
>   result of sizeof (something) is an integer _constant_.  If you try to
>   take the size of something that has a varying size, you will get only
>   the size of that thing at compile time.
>
>   If you're creating varying-sized data elements, you should keep track of
>   their sizes yourself.
>
>				   --Blair
>				     "But I don't know why you would..."
>
>It also takes a TYPE as an argument instead of an EXPRESSION.
>
>Michael

You are 100% incorrect.  Remember that the topic of discussion here is
C++, not C!  sizeof is certainly an operator.  And it can take a type
or an expression as an argument.  See Stroustrup, pp. 257-258.  It is,
however, resolved at compile time.  Presumably, it can't be overloaded
for this very reason; it is syntactically an operator, but it is not
treated the same as other operators.  It may be overloadable in the 
future; C++ is still an evolving language, and recently -> was added
to the list of overloadable operators.  However, it would be much nicer
if it used the dynamic rather than static information where appropriate,
like class/structure element dereferencing!!  Are you listening, Bjarne???

Unfortunately, for now, there seems to be no alternative but to keep track
of the sizes yourself.  Not very helpful, I know, but at least correct. :-)

Bob Hearn
hearn@claris.com

grunwald@flute.cs.uiuc.edu (03/21/89)

In article <9120@claris.com> hearn@claris.com (Bob Hearn) writes:

	....

   to the list of overloadable operators.  However, it would be much nicer
   if it used the dynamic rather than static information where appropriate,
   like class/structure element dereferencing!!  Are you listening, Bjarne???

   Unfortunately, for now, there seems to be no alternative but to keep track
   of the sizes yourself.  Not very helpful, I know, but at least correct. :-)

   Bob Hearn
   hearn@claris.com

And how should it do this? By sticking an extra field into every variable
structured item? How would this field be maintained?

Asking the compiler to keep this information is ``against the spirit of C++''.
You can do a much better job of it, and in those cases where you *don't*
want that information (i.e. usually), you don't pay for it.

What's wrong with having you base class have define `sizeOf' or something
and using that as a virtual function to determine size of things, as
OOPS & Libg++ do?



--
Dirk Grunwald
Univ. of Illinois
grunwald@flute.cs.uiuc.edu

shap@polya.Stanford.EDU (Jonathan S. Shapiro) (04/03/89)

In article <GRUNWALD.89Mar20221129@flute.cs.uiuc.edu> grunwald@flute.cs.uiuc.edu writes:

[Context: implementing overloaded sizeof]
>
>And how should it do this? By sticking an extra field into every variable
>structured item? How would this field be maintained?

I don't advocate doing it, but here is how it might be done:

sizeof(type) behaves as it does now.

sizeof(expr) evaluates the expression, and if the result type is a
class that overloads sizeof(), calls the overloaded sizeof operation.
If the result type is not a class that overloads the expression, it
returns the size of the result type.  In both cases it forces the
expression evaluation.

The problem is that these are telling me two different things.  The
purpose of sizeof() is to tell me how much space to allocate for a
type.  If we really need this functionality, we should contemplate
introducing obsize(), that operates the way I described sizeof(expr).
Introducing obsize(expr) makes sense in the face of the recent
extensions to New() in the language.

For my own purposes, I introduce a virtual size() function on the
objects that need to do the bookkeeping.  This solves the problem
without requiring me to introduce a new language feature.

Jon