Re: stroustrup, void*, and reinterpret_cast
Dilip wrote:
kanze wrote:
It sends the wrong message to the reader.
When I see a reinterpret_cast in code, I immediately assume
that there is something very delicate and implementation
dependant going on. When I see a static_cast, I suppose
that while you are subverting the type system somewhat, it
is within more reasonable bounds, and is portable---I don't
have to pay particular attention to it when porting to
another system, for example.
There is a specific scenario that I have never been clear
about in all these years w.r.t reinterpret_casts.
In MSFT's COM-land, there is an API called CoCreateInstance --
its last parameter is of type void**. This API is used to get
a pointer to the interface (abstract class to be precise) you
are interested in. So people always do something like this:
struct IUnknown
{
virtual void QueryInterface(REFIID riid, void** ppv) = 0;
virtual void AddRef() = 0;
virtual void Release() = 0;
};
struct ISomeInterface : public IUnknown
{
virtual void DoIt() = 0;
};
ISomeInterface* isi;
CoCreateInstance(......,...., reinterpret_cast<void**>(&isi));
Internally a lot of hocus-pocus happens and the API ends up
calling an implementation of a standard IUnknown method called
QueryInterface that returns a pointer to ISomeInterface like
so:
class SomeInterfaceImpl : public ISomeInterface
{
void QueryInterface(REFIID riid, void** ppv)
{
*ppv = static_cast<ISomeInterface*>(this);
If the lvalue which *ppv designates does not have the type
void*, this is undefined behavior. You've lied to the compiler,
and the compiler has the right to punish you for it.
I am aware of implementations where a void* would be larger than
an ISomeInterface*. On such an implementation, Assuming that
ppv was initialized (indirectly) with the reinterpret_cast in
your call above, this line will write not just isi, but also
some bytes behind it. More generally, it will convert the
ISomeInterface* results of the cast to a void*, doing whatever
conversion is relevant for your machine, and then write the
results, as a void*, starting at the address of isi. If (as is
usually the case), void* and ISomeInterface* have the same size
and representation, everything will work fine; if they don't,
you're screwed.
About the only way to write this line in a way that is
guaranteed to work according to the C++ standard would be to
declare the parameter of CoCreateInstance to be a void* (which
eliminates the need of a cast when calling it), and then write:
*static_cast< ISomeInterface** >( ppv ) = this ;
here. Given the current interface, you need two pointers:
void * visi ;
ISomeInterface* isi ;
You then pass &visi to CoCreateInstance, and the above line is
valid. Later, when you want to use isi, you must static_cast
visi to ISomeInterface* and assign it to isi.
reinterpret_cast<IUnknown*>(*ppv)->AddRef();
Same problem as above. Except that this will actually fail,
even on a PC, if multiple inheritance is involved. Even
assuming that all pointers have the same representation (which
the interface seems to do), the only valid reinterpret_cast of
*ppv is to the type of pointer that was actually stored there,
in this case, an ISomeInterface*.
}
// remaining implementations elided for clarity
};
Have the proper casts been used in the above code? Can you
explain why reinterpret_cast is needed in places where its
been used?
What does Microsoft say about it? There are definitly
architectures where this reinterpret_cast will NOT work, and
where it will get you into deep trouble. But what it actually
does is somewhere between implementation defined and undefined
behavior. If Microsoft says that it will work in this case,
then they are defining a legal extension to the language. If
you're using COM, you're using extensions to the language
anyway, and your code won't work on a lot of platforms.
Anything regarding the use of COM is Microsoft's call, not that
of the C++ standard. (The use of such techniques probably means
that COM cannot be implemented on a platform where void* and
SomeClass* have different representations. But presumably, that
is a limitation that Microsoft is willing to take.)
--
James Kanze GABI Software
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France, +33 (0)1 30 23 00 34
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]