Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!purdue!decwrl!labrea!polya!shap
From: shap@polya.Stanford.EDU (Jonathan S. Shapiro)
Newsgroups: gnu.g++
Subject: Re: Isn't sizeof an operator?
Message-ID: <8124@polya.Stanford.EDU>
Date: 3 Apr 89 09:24:05 GMT
References: <2352@buengc.BU.EDU> <8903202240.AA24954@yahi> <9120@claris.com> <GRUNWALD.89Mar20221129@flute.cs.uiuc.edu>
Sender: Jonathan S. Shapiro <shap@polya.Stanford.EDU>
Reply-To: shap@polya.Stanford.EDU (Jonathan S. Shapiro)
Distribution: gnu
Organization: Stanford University
Lines: 29

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