Thread: CreateInstance

  1. #1
    Registered User
    Join Date
    May 2006
    Posts
    1,579

    CreateInstance

    Hello everyone,


    In the book "Inside COM", there is an interesting code segment like this,

    Code:
    IUnknown* CreateInstance()
    {
        IUnknown* pI = static_cast <IX*> (new CA);
        pI -> AddRef();
        return pI;
    }
    
    // IX an interface is derived from IUnkown, IY is an interface derived from
    // IUnknown and CA is a class directly derived from both IX and IY.
    My question is, why static_cast <IX*> to result in IUnknown*? Why not static_cast <IUnknown*> to result in IUnknown* to be more straightforward (even if I think using IX* and IUnknown* have the same effect)? Are there any reasons or advantages if we use IX* other than IUnknown*?


    thanks in advance,
    George

  2. #2
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,895
    Just how many different topics at once do you tackle? Perhaps you would be able to properly understand what you're reading if you only read one topic at a time.

    You could also simply try what happens when you cast directly to IUnknown. Keep in mind that downcasts implicit and thus the static_cast would not be necessary at all.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  3. #3
    Registered User
    Join Date
    May 2006
    Posts
    1,579
    Thanks CornedBee,


    I have written some code to reproduce this issue -- error C2594: 'initializing' : ambiguous conversions from 'Final *' to 'Base *'.

    But I am confused why there is ambiguity issue. In my knowledge, class instance is different by the data members, but common (share) in executable code.

    In my sample, IUnknown, IX and IY are all classes which do not have data members, they should share the common executable code. Could you explain in more details why compiler complaint ambiguity issue and what blocks compiler from type conversion?

    Code:
    #include <iostream>
    
    using namespace std;
    
    class Base {
    public:
    	int foo() {cout << "Base" << endl;}
    };
    
    class Derived1: public Base
    {
    public:
    	int foo() {cout << "Derived1" << endl;}
    };
    
    class Derived2: public Base
    {
    public:
    	int foo() {cout << "Derived2" << endl;}
    };
    
    class Final: public Derived1, public Derived2 {
    public:
    	int foo() {cout << "Final" << endl;}
    };
    
    int main()
    {
    	Final f;
    	Final* p = &f;
    	Base* pb = p; //error C2594: 'initializing' : ambiguous conversions from 'Final *' to 'Base *'
    	return 0;
    }
    Quote Originally Posted by CornedBee View Post
    Just how many different topics at once do you tackle? Perhaps you would be able to properly understand what you're reading if you only read one topic at a time.

    You could also simply try what happens when you cast directly to IUnknown. Keep in mind that downcasts implicit and thus the static_cast would not be necessary at all.

    regards,
    George

  4. #4
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Ireland
    Posts
    8,446
    See the Diamond of Death for an explanation of this problem.
    Originally Posted by brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

  5. #5
    Registered User
    Join Date
    May 2006
    Posts
    1,579
    Thanks Mario,


    Quote Originally Posted by Mario F. View Post
    See the Diamond of Death for an explanation of this problem.
    I have read through that before. So, Diamond pattern could also apply even if there are no data members?


    regards,
    George

  6. #6
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Quote Originally Posted by George2 View Post
    Thanks Mario,




    I have read through that before. So, Diamond pattern could also apply even if there are no data members?


    regards,
    George
    Sure, it's got nothing to do with data members, only with inherited behaviour.

    --
    Mats
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  7. #7
    Registered User
    Join Date
    May 2006
    Posts
    1,579
    Thanks Mats,


    My question is answered.

    Quote Originally Posted by matsp View Post
    Sure, it's got nothing to do with data members, only with inherited behaviour.

    --
    Mats

    regards,
    George

  8. #8
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,895
    Basically, there's two paths to reach two IUnkowns, so the compiler doesn't know which one to take unless you help it along.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  9. #9
    Registered User
    Join Date
    May 2006
    Posts
    1,579
    Thanks CornedBee,


    My question is answered.

    Quote Originally Posted by CornedBee View Post
    Basically, there's two paths to reach two IUnkowns, so the compiler doesn't know which one to take unless you help it along.

    regards,
    George

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. thread-safe singleton?
    By bling in forum C++ Programming
    Replies: 12
    Last Post: 10-01-2008, 09:49 PM
  2. COM CreateInstance method
    By George2 in forum C++ Programming
    Replies: 6
    Last Post: 02-08-2008, 07:37 AM
  3. 'Access Violation' in CreateInstance()??
    By rhinoishere in forum C++ Programming
    Replies: 4
    Last Post: 05-01-2003, 02:10 AM