Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!usc!orion.oac.uci.edu!uci-ics!rfg
From: rfg@ics.uci.edu (Ron Guilmette)
Newsgroups: comp.lang.c++
Subject: Re: operator sizeof()
Message-ID: <25BBE1B6.13849@paris.ics.uci.edu>
Date: 23 Jan 90 04:46:46 GMT
References: <3052@odin.SGI.COM>
Reply-To: rfg@ics.uci.edu (Ron Guilmette)
Organization: UC Irvine Department of ICS
Lines: 91

In article <3052@odin.SGI.COM> shap@delrey.sgi.com (Jonathan Shapiro) writes:
>[Pacman's revenge...]
>
>Since G++ doesn't run on SGI machines,

What makes you say that it won't?  SGI makes machines with 680x0 processors
right?  I'm fairly sure that it will run on those.  Also, SGI makes machines
that have MIPS processors, right?  I know that g++ is now running on
at least one person's MIPS-based DECstation.  Perhaps all you need is some
friendly advice to get it running (and perhaps a bit of System V tweeking).

>I am posting to ask for
>verification.  At one time I seem to recall Mike was contemplating
>making sizeof() an overloaded operator in G++.  I don't remember if
>this was ever actually done.
>
>Is sizeof() a per-class overloadable operator in G++ 1.36?

I proposed making sizeof() user-definable (and overloadable) here some
time ago and was immediately thrashed with wet noodles.  I believe that
both Stroustrup and Tiemann said they thought that it was a bad idea.

Since then I have had some time to contemplate, and I now have what I hope
is a better argument in favor of this.

Consider the following:

	struct base { int i1; };

	struct derived : base { int i2; };

	base ** element_one_address (base *p)
	{
		return &p[1];
	}

	main ()
	{
		derived derived_array[10];
		base **one_address = element_one_address (derived_array);
	}

Now the question is "What should element_one_address return?"

Whenever you index relative to a pointer, there are some assumptions made,
namely (1) the pointer points into an array of things, and (b) the type
of each element of the pointed to array is the "pointed-at" type declared
for the pointer value being indexed.

In the above example, assumption (b) fails to be true and thus, the above
program will do weird (and probably undesirable) things.

In effect, we could say that the above program is "unsafe".

The problem demonstrated by the above program could be solved easily via
the following steps:

	Treat each indexing of a pointer value as if it involved an
	implicit "call" of the sizeof operator for the object pointed
	to by the pointer.

	Allow user-definable sizeof operators for classes/structs/unions.
	(Assume for simplicity that these user-definable sizeof operators
	would only come into play when the entity whose size is needed is
	an "expression", and never for typenames.

	Allow user-definable sizeof operators to be virtial.

	Have the compiler implicitly define sizeof operators for all
	classes/structs/unions that do not explicitly define their own
	(kind of like it does now for X::X(X&) and X::operator=(X&)).

	For each class which has either (a) some virtual members, or (b)
	some virtual bases, let the compiler make the implicitly generated
	sizeof operators implicitly virtual.

This last rule needs some explaining.  Basically, it would be nice to *always*
have *all* sizeof operators be virtual, but the same could be said for
destructors.  Unfortunately, if the compiler were to force them to always
be virtual (even for classes that would not otherwise contain vtable
pointers) then this could add an intolerable amount of space overhead
for even the simplest of classes.  Thus, this final rule insures that
the "virtualness" of the sizeof operator would not be forced upon classes
unless doing so would *not* created any new space overhead.

Anyway, it's an idea.

I'm now gritting my teeth in preparation for being whipped with wet noodles
again. :-)

// rfg