Casting to void*, result unexpected.

[He Shiming]

Hi,

I'm having a little bit of trouble regarding pointer casting in my program.
I don't understand why the following two cases produce different results.

Case 1:
IInterface *pInterface = new CImplementation ();
pInterface->Method();

Case 2:
void* pInterface = static_cast<voi d*>(new CImplementation ());
static_cast<IIn terface*>(pInte rface)->Method();

In these two cases, "IInterface " is an interface definition class, it
contains no member variables, only public pure virtual methods are defined.
"CImplementatio n" is derived from IInterface, and it implements those pure
virtual methods.

Now, if CImplementation is derived only from IInterface, the above two cases
will work the exact same way. However, when CImplementation derives from
other classes, which also contain virtual or pure virtual methods, Case 2
will fail. It'll cause a crash mainly because the ->Method() call isn't
actually calling IInterface::Met hod(), depending on the actual
inheritance, ->Method() may be pointed at a pure virtual method of another
class. Case 1 still works. Why is that? And more importantly, why is the
above two cases work differently?

Thanks,
--
He Shiming

[Alf P. Steinbach]

* He Shiming:

[unexpected result from void* casting]
...

Why is that?

Disregarding compiler-specific behavior there are only two things
you can do with a void* pointer casted from a type T: compare it wrt.
equality to another such void* pointer, and cast it back to T.

You cast to void* from a type X and then cast back to Y, and that's
Undefined Behavior even if the types X and Y are related.

Perhaps what surprises you is that static_cast can change the pointer
bitpattern (while not changing the conceptual pointer value). But if
you think about it that's how it must be. Consider:

struct A { int x; };
struct B { int y; }
struct X: A, B {};

X* pX = new X;
A* pA = static_cast<A*> ( pX );
B* pB = static_cast<B*> ( pX );

'pA' points to the beginning of the A subobject, and 'pB' points to
the beginning of the B subobject; these two pointers cannot be equal.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[He Shiming]

> Disregarding compiler-specific behavior there are only two things

you can do with a void* pointer casted from a type T: compare it wrt.
equality to another such void* pointer, and cast it back to T.
You cast to void* from a type X and then cast back to Y, and that's
Undefined Behavior even if the types X and Y are related.
I'm sorry but what does this mean? I mentioned that it only fails when
multiple inheritance is used. Then if it's an undefined behavior, why does
it work flawlessly, when single inheritance is used?

Consider:

struct A { int x; };
struct B { int y; }
struct X: A, B {};

X* pX = new X;
A* pA = static_cast<A*> ( pX );
B* pB = static_cast<B*> ( pX );

'pA' points to the beginning of the A subobject, and 'pB' points to
the beginning of the B subobject; these two pointers cannot be equal.

I got your point but this isn't what exactly I wanted.

Consider case 1 in my first post, it worked with the "IInterface " type
definition on the pointer, case 2 fails because something bad happened
during pointer re-casting. The reason why I'm trying to use void* is because
I can't store the type definition in this particular case. In the first
line, the class allocator has no idea about what type should it use.

Regarding the pointer itself. Isn't the pointer just an address? Isn't void*
capable of storing any kind of pointers? If so, why won't casting work?

Thanks,
He Shiming

[Alf P. Steinbach]

* "He Shiming" <mailbill(NOSPA M)@21cn.com.nos pam>:

Disregarding compiler-specific behavior there are only two things
you can do with a void* pointer casted from a type T: compare it wrt.
equality to another such void* pointer, and cast it back to T.
You cast to void* from a type X and then cast back to Y, and that's
Undefined Behavior even if the types X and Y are related.
I'm sorry but what does this mean? I mentioned that it only fails when
multiple inheritance is used. Then if it's an undefined behavior, why does
it work flawlessly, when single inheritance is used?

Undefined Behavior means the effect can be anything, including whatever you
think it "should" be.

Don't rely on Undefined Behavior.

Consider:

struct A { int x; };
struct B { int y; }
struct X: A, B {};

X* pX = new X;
A* pA = static_cast<A*> ( pX );
B* pB = static_cast<B*> ( pX );

'pA' points to the beginning of the A subobject, and 'pB' points to
the beginning of the B subobject; these two pointers cannot be equal.

I got your point but this isn't what exactly I wanted.

Consider case 1 in my first post, it worked with the "IInterface " type
definition on the pointer,

Case 1:
IInterface *pInterface = new CImplementation ();
pInterface->Method();

case 2
Case 2:
void* pInterface = static_cast<voi d*>(new CImplementation ());
static_cast<IIn terface*>(pInte rface)->Method();

fails because something bad happened during pointer re-casting.
Nope, it fails because it can. It _can_ fail because it's UB. However,
if the type you cast from is the as same the one you cast to it's no longer
UB and won't fail:

void* pInterface = static_cast<IIn terface*>( new CImplementation () );
static_cast<IIn terface*>( pInterface )->Method();

Not that I recommend such things.

Don't use void*.

The reason why I'm trying to use void* is because
I can't store the type definition in this particular case.
If you can cast the pointer back from void*, then you know the type and
don't have to use void* in the first place.

Simple.

In the first
line, the class allocator has no idea about what type should it use.
?

Regarding the pointer itself. Isn't the pointer just an address?
In general no, but for most pointers, yes.

Isn't void* capable of storing any kind of pointers?
No, but it's capable of storing the kind you're using here.

If so, why won't casting work?

Because you're casting from a type X and back to a different type Y.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[He Shiming]

I'm not sure if you are aware of this. But in Microsoft COM APIs, there is
this CoCreateInstanc e function that does use void* pointer casting. The
function definition went like this:

STDAPI CoCreateInstanc e(
REFCLSID rclsid,
LPUNKNOWN pUnkOuter,
DWORD dwClsContext,
REFIID riid,
LPVOID * ppv
);

When we use this function, we write something like this:
CComPtr<Interfa ce> spInterface;
CoCreateInstanc e(blahblahblah. ..., (void**) &spInteface) ;

CComPtr is a smart pointer, there is no void* operators defined in it. And
as you can see here, we do cast such pointers. It's pretty much what I'm
trying to do. You can see it initiates the class object to void*, and in the
smart pointer, in order to use it, it'll re-cast it back. If
CoCreateInstanc e produces a void* pointer, as you said should have undefined
behavior, and may or may not work. How are we going to use COM interfaces
correctly?

Sorry for being Microsoft-specific, but it certainly explains that it should
work.

--
He Shiming

"Alf P. Steinbach" <al***@start.no > wrote in message
news:42******** ********@news.i ndividual.net.. .

Not that I recommend such things.

Don't use void*.
If you can cast the pointer back from void*, then you know the type and
don't have to use void* in the first place.

Simple.

In the first
line, the class allocator has no idea about what type should it use.

?

Regarding the pointer itself. Isn't the pointer just an address?

In general no, but for most pointers, yes.

Isn't void* capable of storing any kind of pointers?

No, but it's capable of storing the kind you're using here.

If so, why won't casting work?

Because you're casting from a type X and back to a different type Y.

[Alf P. Steinbach]

* He Shiming:

[top-posting]
Please don't top-post in this group. See the FAQ. Corrected.
* He Shiming: * Alf P. Steinbach:

* He Shiming:

..., why won't casting work?
Because you're casting from a type X and back to a different type Y.

I'm not sure if you are aware of this. But in Microsoft COM APIs, there is
this CoCreateInstanc e function that does use void* pointer casting. The
function definition went like this:

STDAPI CoCreateInstanc e(
REFCLSID rclsid,
LPUNKNOWN pUnkOuter,
DWORD dwClsContext,
REFIID riid,
LPVOID * ppv
);

So? Ask for a pointer to the correct interface type. When the pointer
originates from type IWhatever* you can safely cast it to IWhatever*
(if you're unsure about how to specify types vis-a-vis the Microsoft
COM API, please ask about that in a Microsoft-specific group, not here).

But better, don't use void* pointers yourself.

Have I mentioned that?

...
Sorry for being Microsoft-specific, but it certainly explains that it should
work.

The example bears no relation to your "non-working" example. In that example
you casted from a type X to void*, and then back to a different type Y.
That's not the case in the example you're now giving.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[He Shiming]

>* He Shiming:

[top-posting]
Please don't top-post in this group. See the FAQ. Corrected.

I don't even know how to "top-post". And how can you correct that? Just
because your Forte hates my Outlook Express doesn't justify my top-posting.


So? Ask for a pointer to the correct interface type. When the pointer
originates from type IWhatever* you can safely cast it to IWhatever*
(if you're unsure about how to specify types vis-a-vis the Microsoft
COM API, please ask about that in a Microsoft-specific group, not here).

I said sorry for being Microsoft-specific already. But if you have no idea
about how CoCreateInstanc e works, you have no idea about what I'm doing
either. FYI, CoCreateInstanc e works pretty much (although not exactly) the
same way as my Case 2 example.

"When the pointer originates from type IWhatever* you can safely cast it to
IWhatever*" <-- Well, how did you come up with that? Previously, you said
that as type B is different, one can't cast from type A to B, and then cast
from B back to A. And now you are saying that we can?

Well, given the fact the Case 2 doesn't work as expected, and I do need to
cast the specialized pointer to something general, then later cast it back.
How would you recommend a solution, or your are saying that there's no
solution at all?

Thanks,
He Shiming

[He Shiming]

You know, I got it worked.

It's as simple as this:

void* pInterface = static_cast<voi d*>(static_cast <IInterface*>(n ew
CImplementation ());

That's right, casting twice. And it also proved my point, that void* should
work, the pointer is only an address.

--
He Shiming

[Alf P. Steinbach]

* "He Shiming" <mailbill(NOSPA M)@21cn.com.nos pam>:

* He Shiming:

[top-posting]
Please don't top-post in this group. See the FAQ. Corrected.

I don't even know how to "top-post". And how can you correct that? Just
because your Forte hates my Outlook Express doesn't justify my top-posting.

See the FAQ.

So? Ask for a pointer to the correct interface type. When the pointer
originates from type IWhatever* you can safely cast it to IWhatever*
(if you're unsure about how to specify types vis-a-vis the Microsoft
COM API, please ask about that in a Microsoft-specific group, not here).

I said sorry for being Microsoft-specific already. But if you have no idea
about how CoCreateInstanc e works, you have no idea about what I'm doing
either. FYI, CoCreateInstanc e works pretty much (although not exactly) the
same way as my Case 2 example.

Case 2:
void* pInterface = static_cast<voi d*>(new CImplementation ());
static_cast<IIn terface*>(pInte rface)->Method();

That's _very_ different from the OS API function: this case 2 code casts from
a type X = CImplementation * to void*, and then from void* to a different type
Y = IInterface*.

Is that unclear somehow?

Or do you believe that the OS API mentioned above does exactly that?

It doesn't: it gives you a pointer casted from the type you specify, to void*,
so simply specify the type you'll cast it back to.

"When the pointer originates from type IWhatever* you can safely cast it to
IWhatever*" <-- Well, how did you come up with that? Previously, you said
that as type B is different, one can't cast from type A to B, and then cast
from B back to A.
No, I didn't write that: I told you you get UB if you cast from A* to void*
and from that void* to B*, when A and B are different types.

And now you are saying that we can?
No, not that either.

I suggest you read the earlier postings again, with attention to detail.

Well, given the fact the Case 2 doesn't work as expected, and I do need to
cast the specialized pointer to something general, then later cast it back.
How would you recommend a solution, or your are saying that there's no
solution at all?

See above.

And the earlier replies in this thread.

The implication of those replies: figure out how to use that smart pointer
class you're using so as to avoid having void* pointers around... ;-)

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[He Shiming]

Okay my bad.

--
He Shiming
"Alf P. Steinbach" <al***@start.no > wrote in message
news:42******** ********@news.i ndividual.net.. .

* "He Shiming" <mailbill(NOSPA M)@21cn.com.nos pam>:

>* He Shiming:
>> [top-posting]
>
> Please don't top-post in this group. See the FAQ. Corrected.

I don't even know how to "top-post". And how can you correct that? Just
because your Forte hates my Outlook Express doesn't justify my
top-posting.

See the FAQ.

> So? Ask for a pointer to the correct interface type. When the pointer
> originates from type IWhatever* you can safely cast it to IWhatever*
> (if you're unsure about how to specify types vis-a-vis the Microsoft
> COM API, please ask about that in a Microsoft-specific group, not
> here).
>

I said sorry for being Microsoft-specific already. But if you have no
idea
about how CoCreateInstanc e works, you have no idea about what I'm doing
either. FYI, CoCreateInstanc e works pretty much (although not exactly)
the
same way as my Case 2 example.

Case 2:
void* pInterface = static_cast<voi d*>(new CImplementation ());
static_cast<IIn terface*>(pInte rface)->Method();

That's _very_ different from the OS API function: this case 2 code casts
from
a type X = CImplementation * to void*, and then from void* to a different
type
Y = IInterface*.

Is that unclear somehow?

Or do you believe that the OS API mentioned above does exactly that?

It doesn't: it gives you a pointer casted from the type you specify, to
void*,
so simply specify the type you'll cast it back to.

"When the pointer originates from type IWhatever* you can safely cast it
to
IWhatever*" <-- Well, how did you come up with that? Previously, you said
that as type B is different, one can't cast from type A to B, and then
cast
from B back to A.

No, I didn't write that: I told you you get UB if you cast from A* to
void*
and from that void* to B*, when A and B are different types.

And now you are saying that we can?

No, not that either.

I suggest you read the earlier postings again, with attention to detail.

Well, given the fact the Case 2 doesn't work as expected, and I do need
to
cast the specialized pointer to something general, then later cast it
back.
How would you recommend a solution, or your are saying that there's no
solution at all?

See above.

And the earlier replies in this thread.

The implication of those replies: figure out how to use that smart pointer
class you're using so as to avoid having void* pointers around... ;-)

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?