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