shap@delrey.sgi.com (Jonathan Shapiro) (01/22/90)
[Pacman's revenge...] Since G++ doesn't run on SGI machines, 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? Jon Shapiro Silicon Graphics, Inc.
rfg@ics.uci.edu (Ron Guilmette) (01/23/90)
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