🚀 go-pugleaf

clamage@Eng.sun.com (Steve Clamage) wrote [but much edited by me]:
>In article 1e7a@mule1.mindspring.com, abell@mindspring.com (Andrew Bell) writes:
>>About casting operators]
>[[Are you asking] can you define
>a conversion operator from a user-defined class to a predefined type

No, I'd want to go the other way.  In the case of "pure wrapper"
classes (as I defined in my earlier post), one might want an automatic
cast from the original to the wrapper.  In my case, I have created a
class to wrap around an OS-defined struct, to give it access safety
(the particular class contains a type specifier and a union) and
smarter access as well as constructors.

I'd like to have a casting operator that would allow me to convert the
original struct to the pure wrapper automatically.  (but you can't
always get what you want...)  A constructor works differently than a
casting operator; in this case, it would force the creation of an an
(algorithmically) unnecessary duplicate object.  Admittedly, it's only
relevant for pure wrapper classes, but is that such a rare concept?

It's always seemed a little odd to me that you can add operators to a
class outside the class structure, even when they might modify the
object (such as ostream operator<<...), but not non-virtual functions.
It is, after all, this restriction against defining member functions
externally that leads to my need for pure wrapper classes (and my
desire for casting support to them) in the first place.

I can do what I need with dangerous casts
	PureWrapperClass &wrapper = (PureWrapperClass &)
		baseStruct;
but it isn't obvious without lots of hunting that this is in fact
safe.  Also, sometimes I might not want to allow the conversion (throw
an exception in the conversion operator),, which this approach doesn't
allow.

>I assume you mean a class like
>	class Short { short val; };
>with non-virtual member functions added. You can't assume the size and
>alignment of the class will be the same as its only data member, and no,
>the standard provides no special support for this special case.

Seems like if you only have one data member and no virtual functions,
there's no reason to arbitrarily restrict it to a greater alignment
level, save maybe to make compiler programmer's lives (and maybe
debugger programmer's lives) trivially easier.   (For that matter, is
there really a good reason to make it more restrictive than the most
restrictive member element regardless of the number of elements?  I
suppose there's making the bitwise copy constructors a little more
efficient, though that doesn't hold for the single member case.)

>>4) With RTTI, a derived class that doesn't change any virtual member
>>funcs or add any properties to a base class still evaluates to a
>>different object type, correct?
>Yes. The typeids of two types compare equal if and only if they are
>the same type. Base and derived classes are not ever the same type.

Fair enough, although in this case RTTI forces the creation of an
additional vtable that wouldn't normally be necessary.  Since the
general criterion for RTTI support in a class in the first place is
the existence of any virtual functions (and thus a vtable), it doesn't
seem like it would be too unreasonable to make classes with identical
vtables evaluate to the same thing.  Adding an operator to a class
(externally) doesn't change its identity; should a non-virtual member
function do so?

Andrew Bell
abell@mindspring.com
 



[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]