Casting from one interface to another...

re: Casting from one interface to another...

RyanBemrose — Sat, 16 Feb 2008 05:37:22 GMT

A class that "implements IFoo and IFoo2" is hopefully just inheriting IFoo2, since that necessarily requires implementing IFoo. Every IFoo2 is also an IFoo, and if you have an IFoo2*, then you can cast to IFoo* with impunity, thanks to the magic of single inheritance.

If you have an IFoo*, the only way to make it into an IFoo2* is QueryInterface(), which is, I think, the point of this post.

If there's a style question in this post, it has to do with how to do the cast. I suspect the whole reason the question came up is because the co-worker was using C-style casts, and although (IFoo2*)pFoo is wrong, the compiler will let you do it. If you try to use static_cast<IFoo2*>(pFoo), the compiler will throw an error, exactly because this is wrong.

re: Casting from one interface to another...

Gwyn — Sat, 16 Feb 2008 05:58:38 GMT

I suspect that this also has something to do with why CreateObject calls in COM take a parameter specifying the interface of the object that you want to use. In this case, GetFoo should really be something like:

HRESULT GetFoo(IUnknown **ppFoo, IID *piid)

Then, the caller could specify that they wanted an IFoo2 explicitly, and if that wasn't supported, they would get an E_NO_INTERFACE

re: Casting from one interface to another...

SvenGroot — Sat, 16 Feb 2008 06:50:51 GMT

Actually, in general given a class CFoo : IFoo2, and IFoo2 : IFoo, if you have a IFoo* that you know is actually a CFoo, it's perfectly safe to do static_cast<IFoo2*>(p). The vtable will be adjusted on the cast so it'll work fine. If you're not sure the pointer is an IFoo2 you could use a dynamic_cast which throws an exception if it isn't.

In the context of COM however, you shouldn't assume that's how the interfaces are implemented, and of course you should use QueryInterface.

Speaking of style, I hope nobody still actually prefixes their classes with a C. :P

re: Casting from one interface to another...

Jack Mathews — Sat, 16 Feb 2008 07:15:24 GMT

Based on the code you've provided, I'm afraid that your layout for the class in incorrect.

You gave us the following assumptions:

IFoo : IUnknown and IFoo2 : IFoo

Now you mentioned that CFoo implements both interfaces. However, since IFoo2 inherits from IFoo, that means that it's:

CFoo : IFoo2

Since this is a single-inheritance chain, then adjustor thunks are not necessary, so for a CFoo, IFoo and IFoo2 can (and do) share the same vtable. The one and only vtable is laid out the way that you laid out the IFoo2 vtable. The class will have one vtbl pointer at the top followed by the data for CFoo.

Because of the single inheritance, all casts can and will work just fine. Now I do agree that _depending_ on this is a bad thing, because if IFoo2 were broken out to have no inheritance from IFoo, then the class looks closer to what you've described. Since QueryInterface works no matter what, it is, all in all, the right solution in the long run. But your friend's code was in no danger of crashing.

RyanBemrose:

You're wrong. It's a perfectly valid static_cast to go from IFoo* to IFoo2*. The only time it wouldn't be a valid static_cast would be if there were multiple copies of a base class and you tried to cast to a subclass. For instance, if you had, B:A, C:A, and D:C,B, then you can't cast an A to a D, because there are two copies of A in D.

SvenGroot:

"The vtable will be adjusted on the cast so it'll work fine." - There is no vtable adjustment in this case, since there's only one vtable and the compiler knows it.

re: Casting from one interface to another...

Mark Sowul — Sat, 16 Feb 2008 07:21:42 GMT

Why not change IBar's GetFoo to return an IFoo2? (side note: I hate using foo and bar) - since IFoo2 is an IFoo and the team owns both interfaces, shouldn't that work with little issue?

(Unless other callers are doing similar casting monkey business)

re: Casting from one interface to another...

LarryOsterman — Sat, 16 Feb 2008 10:04:47 GMT

Sven: Actually lots of Windows code prefixes their classes with C - it's a legacy of the old hungarian days.

And the cast isn't safe unless the compiler can tell that it's a CFoo - otherwise it has to assume that it's a class with nothing but a vtable.

re: Casting from one interface to another...

LarryOsterman — Sat, 16 Feb 2008 10:05:47 GMT

Mark: Because that would change the interface contract for IBar, which means that IBar's interface ID would have to change.

Don't believe me? Just ask Larry.

Noticias externas — Sat, 16 Feb 2008 10:16:51 GMT

QueryInterface isn't a particularly controversial topic (and I haven't heard any grumbling about

re: Casting from one interface to another...

Jack Mathews — Sat, 16 Feb 2008 18:56:12 GMT

"And the cast isn't safe unless the compiler can tell that it's a CFoo - otherwise it has to assume that it's a class with nothing but a vtable."

Right, but given the inheritance tree, that doesn't matter. Your friend's code was never in danger of crashing so long as the class hierarchy matches the assumptions.

I'm sorry, but this whole entry is incorrect. I mean, given this code:

---

class IFoo : public IUnknown

{

public:

virtual HRESULT FooMethod1() = 0;

virtual HRESULT FooMethod2() = 0;

};

class IFoo2 : public IFoo

{

public:

virtual HRESULT Foo2Method1() = 0;

virtual HRESULT Foo2Method2() = 0;

};

class CFoo : public IFoo2

{

public:

HRESULT STDMETHODCALLTYPE QueryInterface(const IID &,void **) { return E_NOTIMPL; }

ULONG STDMETHODCALLTYPE AddRef(void) { return 0; }

ULONG STDMETHODCALLTYPE Release(void) { return 0; }

HRESULT FooMethod1() { return E_NOTIMPL; }

HRESULT FooMethod2() { return E_NOTIMPL; }

HRESULT Foo2Method1() { return E_NOTIMPL; }

HRESULT Foo2Method2() { return E_NOTIMPL; }

private:

int mI;

};

void main()

{

CFoo foo;

printf(

"Size: %d\n"

"CFoo *: %x IFoo2 *:%x IFoo *:%x\n",

sizeof( CFoo ),

&foo, static_cast<IFoo2 *>( &foo ), static_cast< IFoo * >(&foo) );

}

---

You get this output:

Size: 8

CFoo *: 12ff28 IFoo2 *:12ff28 IFoo *:12ff28

It's clear that all casts work, all are based from the same address, and there is only one vtable.

Now, if I would have changed the class decls to:

class IFoo : public virtual IUnknown

class IFoo2 : public virtual IUnknown

class CFoo: public IFoo, public IFoo2

then you get this:

Size: 24

CFoo *: 12ff18 IFoo2 *:12ff20 IFoo *:12ff18

Which is somewhat closer to what you described, where simple casts between IFoo and IFoo2 no longer suffice.

re: Casting from one interface to another...

Jack Mathews — Sun, 17 Feb 2008 00:09:36 GMT

By the way, I'm not trying to be a jerk here. I just don't want people to get the wrong idea about how C++ casts work and how objects are laid out.

re: Casting from one interface to another...

LarryOsterman — Sun, 17 Feb 2008 03:32:54 GMT

Jack, you're not. But what happens if the class derives from IFoo and IFoo2 (I believe that it's legal).

In that case, you have a case of multiple inheritance.

re: Casting from one interface to another...

Tim Smith — Sun, 17 Feb 2008 19:31:23 GMT

Jack, if you and the compiler both know the structure of the COM object, then why are you even bothering to use COM?

For the current (and past) implementations of vtables in MSVC, what you say is correct. However, what about Borland C++ or any other language that properly supports COM? COM makes no statement as to the structure of the vtables for an object supporting multiple interfaces. It only makes a statement about each interface's vtable. Since we are working with COM, we only have available the rules COM provides us.

Your statements, while correct depend on both the implementation of the object and the compiler in order to prove something true. This is very dangerous in programming. In Larry's case, he is using the very same details (with a easily corrected technical error) to show why something is bad. That is perfectly legit.

re: Casting from one interface to another...

Tim Smith — Sun, 17 Feb 2008 19:33:25 GMT

BTW

Jack, YOU are giving people the wrong idea about how C++ casts work and how objects are laid out. They are very dangerous things to depend on.

The things that you are saying are compiler implementation details and are NOT addressed in the C++ standard.

re: Casting from one interface to another...

Jack Mathews — Mon, 18 Feb 2008 08:54:05 GMT

"Jack, you're not. But what happens if the class derives from IFoo and IFoo2 (I believe that it's legal)."

Yes, I brought that up in one of my messages.

"Jack, if you and the compiler both know the structure of the COM object, then why are you even bothering to use COM? "

I'm only speaking to the example provided, not to COM in general.

"COM makes no statement as to the structure of the vtables for an object supporting multiple interfaces."

Yes, but this Larry's friend's group does. I'm only speaking to the example, where the people authoring the component set out specific guidelines. Mind you, I don't agree with them either as it violates what COM is designed for, but that doesn't justify confusing people about how vc++ generates a vtable.

In fact, that's really what I'm trying to point out here, that vtables are not generated this way for this single inheritance case in VC++ (or really any compiler).

"Jack, YOU are giving people the wrong idea about how C++ casts work and how objects are laid out. They are very dangerous things to depend on.

Am I?

For one, Larry's post spoke to an implementation defined way of vtable generation, and I corrected it. The source material had nothing to do with the standard, so neither does my rebuttal.

for another, my casting rules are absolutely correct. Given a defined class hierarchy, you can cast from any point to any other point unless more than one copy of the class is in the hierarchy. If you cast to a derived class knowing full well that you ARE that derived class, the cast will give you a valid pointer.

re: Casting from one interface to another...

LarryOsterman — Mon, 18 Feb 2008 10:38:47 GMT

To be fair: As far as I know, given what I stated in the post, Jack is totally right. On Monday, I'm going to talk a bit about how the standard requires that a compiler handle multiple inheritance (it turns out that much of this vtable behavior is actually required by the standard). As I said however, if the implementor of the class had chosen to implement both IFoo and IFoo2, my co-worker would have been up a creek - that's way too fragile to trust.

re: Casting from one interface to another...

Ulric — Tue, 19 Feb 2008 02:53:14 GMT

I'm with Jack Mathews

My first reaction to the blog was "what?" This up-cast to IFoo2 works perfectly in this simple example, and there is no reason why it could crash. C++ insures this.

So this is here entirely a question of style. You shouldn't mix C++ casting with COM, trying to go around QueryInterface. The programmers I've seen doing this were usually driven by misguided beliefs about performance -- which happens a lot.

re: Casting from one interface to another...

meh — Tue, 19 Feb 2008 12:19:16 GMT

At the very beginning of the post it says "Someone had defined two COM interfaces". COM, not C++.

re: Casting from one interface to another...

Bob — Wed, 20 Feb 2008 02:44:03 GMT

Just because you can do something doesn't mean you should.

Even if God Almighty tells you the layout of the vtables, doing the cast in a way that depends on that detail creates coupling that is entirely unnecessary.

C++ can ensure anything it wants - but what it can not ensure is that the IBar implementor will never change the way that the interfaces are being implemented. Even if there's only one person who owns all the relevant code, then you still need to remember (or leave a comment) explaining that the IBar implementation can't ever change because it would break a client module. I'm at a loss to understand why people consider that to be a good thing.

I don't care how much you know about the compiler internals - I don't ever want to work with some of the people posting here (like Jack and Ulric) and would have no choice but to resort to physical violence if anyone tried to mutilate my code with such unnecessary assumptions about compiler implementation.

re: Casting from one interface to another...

Sys64738 — Wed, 20 Feb 2008 13:32:09 GMT

Hi Larry,

could you please - in other(s) blog post(s) - write about coding conventions you use in Microsoft?

I'm very interested, and you have a good teaching style!

About prefixing classes with C or interfaces with I... what's wrong with that? So you can read a name and immediately know that it is a class (C) or an interface (I). What is the alternative: Foo (class) and FooInterface (interface) ?

Thanks,

re: Casting from one interface to another...

LarryOsterman — Wed, 20 Feb 2008 18:12:12 GMT

Sys64738: http://blogs.msdn.com/larryosterman/archive/2004/11/30/272437.aspx

Search for "Larry Osterman" "What Does Style Look Like" and you'll find a series of posts I did a few years ago on coding styles.

There is no "microsoft" coding style - each team has its own style (sometimes each developer on the team has their own style).

re: Casting from one interface to another...

Sys64738 — Thu, 21 Feb 2008 12:34:07 GMT

Thank you! This is what I looked for.

re: Casting from one interface to another...

Sys64738 — Thu, 21 Feb 2008 14:08:44 GMT

Wow! Your "What Does Style Look Like" series is *great*.

Also some comments are very rich of insight!

(BTW: I was also happy to read that you don't like C++ templates and operator overloading very much; I have the same opinion, I believe that C++ templates must be used cum grano salis [latin].)

Thanks

re: Casting from one interface to another...

Igor Levicki — Sat, 23 Feb 2008 04:44:35 GMT

No wonder why today's code is so awfull with all those interfaces, factories and so many unknowns.

re: Casting from one interface to another...

Igor Levicki — Mon, 25 Feb 2008 05:56:37 GMT

Larry, about your coding style, I disagree on two things:

1. TABs are not hard, and SPACEs are not soft. It is vice versa.

Rationale:

In any decent editor TAB can be configured to an arbitrary number of SPACEs. However, arbitrary number of SPACEs cannot be converted automatically to the proper number of TABs in most editors. Therefore, by using SPACEs you are actually hard-coding indentation.

2. if/else and braces

Most developers write functions like this:

void func(void)

{

// code goes here

}

if you write if like this:

if (condition)

{

// do something

}

It resembles function which is confusing. Some people even dare to leave out the space between "if" and "(" (I really hate that).

Rationale:

if and else are language keywords and not functions. Functions cannot be nested in C. Do not write them such that they resemble functions. Write like this:

if (condition) {

// do something

} else {

// do something else

}

Of course, I am not trying to force you to change your style, just to consider another point of view.

My style is based upon Linux Kernel coding style and when I get unreadable code from someone here is what I do with it:

indent.exe -kr -i8 -ts8 -sob -l80 -ss -ncs %1

(hint: there is indent.exe for Windows too)

re: Casting from one interface to another...

LarryOsterman — Mon, 25 Feb 2008 08:52:21 GMT

Igor, that's exactly why you use spaces, not tabs - because it hard codes indentation.

Your alternative is that every developer has to have their editors configured identically. And not every editor can be easily configured to always insert tabs. If you use spaces, your indentation is always consistent, regardless of the settings of your editor.

You're right that the if (x) { doesn't resemble function entries. But it DOES make it more obvious when you forget an opening brace (and the style requires that there always be an opening brace).

And I NEVER gratuitously reformat someone else's code, regardless of how unreadable it is. Instead, I change my style to match the coding style of the module in which it lives. It's more important that the code in the module all look the same than that the code match your personal style.

re: Casting from one interface to another...

Igor Levicki — Mon, 25 Feb 2008 21:52:08 GMT

Larry,

Two things:

1. I can't recall an editor (save notepad perhaps) where you can't set TAB size.

2. If you accidentally delete a space somewhere and do not notice it immediately the indentation gets screwed later.

3. TAB is consistent -- it is 8 characters by default. Linux Kernel Coding style warns against more than 3 levels of indentation and I think that warning has solid base. Code can always be written without deep nesting. Take a look at this example:

if (condition) {

if (condition2) {

if (condition3) {

// do something here

}

It can be written like this:

if (!condition) {

// goto or return

}

if (!condition2) {

// goto or return

}

if (!condition3) {

// goto or return

}

// do something here

In my opinion that is easier to follow than nested code.

I reformat code given to me which no one else has to see again. I do not reformat for others, in that case I reformat for myself, edit and merge.

re: Casting from one interface to another...

Ulric — Tue, 26 Feb 2008 01:26:51 GMT

Bob,

>I don't care how much you know about the compiler internals -

>I don't ever want to work with some of the people posting

>here (like Jack and Ulric) and would have no choice but to

>resort to physical violence

Bob, it has nothing to do with hackery and relying or relying on shaky compiler internals. It has to do with logic. Computer Science is about facts and logic, not about fear and belief.

You could be the kind of person that would pepper the code base with "casts" because your 'not sure' what the compiler would do. And you'd be hiding bugs and causing headaches for the team. Some people don't understand what are the facts and rules and see it as all magic and chance, and copy/paste recipes. What if the compile didn't follow the C++ standard, heh? Where do you draw the line at what's 'internal'?

I had a work term student tell me once that he wasn't sure that items in an array, or rows of arrays, were contiguous in memory.

I write, port and refact, c++ code between VC++, gcc on linux. It's the largest application you can image (300 dlls on windows) I'm pretty clear about portable, safe and correct code.

From my side, reading "if he was lucky, his code would crash" pushed my "failed logic" button...

The behavior is not uncertain or random...

It's a style issue. I am not recommending doing this at all and would never permit it. The way I understood the article, it was arguing that it wasn't strictly a style issue. But inside the parameters of the question, it's all about style. Don't fight the COM, man. I don't think anyone here suggests that.

The more you do refactoring, you get to ask question that others may feel you shouldn't ask. It's always very enjoyable to find the solutions and the explanations.

re: Casting from one interface to another...

Norman Diamond — Wed, 27 Feb 2008 03:13:41 GMT

> It can be written like this:

> if (!condition) {

> // goto or return

> }

> if (!condition2) {

> // goto or return

> }

> if (!condition3) {

> // goto or return

> }

> // do something here

> In my opinion that is easier to follow than nested code.

In other words: absence-of-goto considered harmful.

Code indented by spaces can be a nuisance to edit.

Code indented by tabs can be a nuisance to edit.

</temporary digression into facts>

Therefore we should do what VC++ 2005 does, insert spaces sometimes and insert tabs sometimes. Or do what vim does, insert tabs even if the preceding line had spaces.

> I do not reformat for others, in that case I reformat for myself, edit and merge.

When you're done, do you reformat back to the original coder's style?

re: Casting from one interface to another...

Norman Diamond — Wed, 27 Feb 2008 03:17:42 GMT

"I had a work term student tell me once that he wasn't sure that items in an array, or rows of arrays, were contiguous in memory."

Unfortunately your student has powerful forces on her/his side. For 20 years the C and C++ standards have been working very hard to cloud up this particular issue.

(Or if your student meant padding to align each item or row then your student was right all along. But I think you didn't mean that because it would be too obvious ^_^)

re: Casting from one interface to another...

*null — Wed, 27 Feb 2008 09:13:17 GMT

http://www.sellsbrothers.com/fun/#re_re_Do_Not_Mix_Cpp_Cast_and_COM

re: Casting from one interface to another...

Igor Levicki — Thu, 28 Feb 2008 06:30:43 GMT

>>Code indented by spaces can be a nuisance to edit.<<

This is true, there are still some editors which do not understand the concept that n spaces = 1 tab. Therefore you have to delete and add spaces one by one.

>>Code indented by tabs can be a nuisance to edit.<<

Can you give an example?

>>When you're done, do you reformat back to the original coder's style?<<

I said I merge -- that means I just apply my coding changes to the original source file without applying my style.

re: Casting from one interface to another...

Igor Levicki — Thu, 28 Feb 2008 06:42:01 GMT

Oh there is one more thing which is part of the coding style but people don't discuss it often -- functions which return BOOL. They write such a function like this:

BOOL IsReadable(BYTE *mem)

{

// test if readable

return TRUE;

}

And then they call it like this:

if (!IsReadable(mem)) {

// goto or return

}

Then in order to avoid writing !IsReadable() which is awkward the write nested ifs:

if (IsReadable(mem)) {

if (condition2) {

if (condition3) {

// do something

}

Instead of doing it like this:

BOOL NotReadable(BYTE *mem)

{

// test if NOT readable

return TRUE;

}

And calling it like this:

if (NotReadable(mem)) {

// goto or return

}

It avoids double negations, nesting ifs, and it is much easier to read.

re: Casting from one interface to another...

Norman Diamond — Thu, 28 Feb 2008 10:04:55 GMT

"Code indented by tabs can be a nuisance to edit."

'Can you give an example?'

Probably not the kind of example you want.

The usual case is a VC++ source file because Visual Studio usually inserts spaces to indent lines in other languages. Sometimes I use vim instead of Visual Studio to edit a single source file. Sometimes I use vim at the same time as Visual Studio because I can do some repetitive edit faster in vim than in Visual Studio (maybe less than others could do with emacs or with Visual Studio macros or add-ins, but still sometimes the tradeoff tilts me towards vim). If parts of an expression or function header or whatever were lined up in Visual Studio then they're not lined up any more in vim.

A less common case is C# or VB, for exactly the opposite reason. vim likes to indent using tabs even if the adjacent lines have spaces. Then the results come out wrong in Visual Studio.

Now, one might think that if one only uses Visual Studio then this problem won't occur. But it still did, I have a VC++ source file that has some lines indented using spaces and some indented using tabs. I don't know how it happened in this one.

For one project I used Wordpad to edit .rc files in a Unicode encoding, I think UTF-16.

re: Casting from one interface to another...

chrisg — Thu, 10 Apr 2008 05:25:01 GMT

this problem would be avoided if IBar::GetFoo() used the REFIID/void** pattern to return the object that implements IFoo or IFoo2 (or IFoo3 for that matter).

this of course has a downside, you can't read the method signature and know what types to expect.

to mitigate that put a comment above the method that lists the interfaces you can expect to request.