🚀 go-pugleaf

Andrew Bell (abell@mindspring.com) wrote:
| 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.

You do realise that you aren't guaranteed the behaviour that you obviously
want in Standard C++, don't you ?

A simple version of your scenario, in code, is :

	struct SOMETHING {	// Arbitrary O/S API POD-struct
		int i ;
		char buf[9] ;
	} ;

	struct Something : public SOMETHING {
		Something() : i(7) { buf[0] = '\000' ; }
	} ;

What you want is to be able to substitute `Something' wherever your O/S
API requires a `SOMETHING'.

Unfortunately, Standard C++ doesn't guarantee that the address of a base
class subobject is the same as the address of the complete object.  In other
words, casting from `Something *' to `SOMETHING *' might involve an offset
calculation.  This isn't particularly difficult or bothersome when calling
the O/S API, since the compiler will handle passing a `Something *' to an 
O/S API function that expects a `SOMETHING *'.  

However, if an O/S API function _returns_ a `SOMETHING *', then assigning
the result into a `Something *' is not only wrong (Standard C++ will
require you to use a cast) but dangerous.  The danger lies in the fact that
the C++ implementation may require extra housekeeping information in a
`Something' (because it is a derived class, because it has function
members, or for some other reason), which simply won't be in the
`SOMETHING' object the address of which was returned to you by the O/S API.

The flaw in your original message was assuming that not having virtual
function members is the only requirement for being a POD-struct.  If you
look at [dcl.init.aggregate] and [class] you will find that there is quite
a long list of prohibitions on POD-structs, including not having base
classes.

You can tell that I've trod this road as well, can't you ?  (-:

| (but you can't always get what you want...)

Exactly.
---
[ 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                             ]