tags:

views:

134

answers:

5

In C++ for Windows, I have some object factory that is supposed to create a series of Info object by passing a pointer to the object to a Create function and returning a created object.

void CreateInfoObject(AbstractInfo** info);  // The creation function 

AbstractInfo is a base class of which we have many types of Info objects derive.

I thought I could now create an Info object as follows:

MyInfoObject* InfoObj = NULL;  // derived from AbstractInfo object
InfoFactory fc;

fc.CreateInfoObject(&InfoObj); // Now I want to get my initialized pointer back

But it says it cannot do the cast... What is wrong?

ERROR: Cannot cast from MyInfoObject**_W64 to AbstractInfo**

EDIT: The first answer mentions that the interface is horrid, cannot see who's allocating etc... How can I improve?

+8  A: 

Let's think about a possible implementation of CreateInfoObject:

void InfoFactory::CreateInfoObject(AbstractInfo** info)
{
  *info = new SuperInfo;
}

Now, SuperInfo and MyInfoObject do not have anything in common right ?

This is why, in general, the following is forbidden:

struct Base {};
struct D1: Base {};
struct D2: Base {};

int main(int argc, char* argv[])
{
  Base** base = nullptr;
  D1* d = nullptr;
  base = d;
}

As it would allow D1 to point to something unrelated.

There are several solutions:

// 1. Simple
AbstractInfo* info = nullptr;
fc.CreateInfoObject(info);

// 2. Better interface
std::unique_ptr<AbstractInfo> info = fc.CreateInfoObject();

Then, if you know with certainty that you have, in fact, a MyInfoObject you can use:

MyInfoObject* myInfo = static_cast<MyInfoObject*>(info);

or if you are unsure:

MyInfoObject* myInfo = dynamic_cast<MyInfoObject*>(info);

which will set myInfo to nullptr if ever the info did not pointed to an instance of MyInfoObject (or derived).

Bear in mind though, that your interface is really horrid. It very C-ish and it is unclear whether memory is actually allocated or not... and who is responsible for handling it if it is.

EDIT:

In good C++ style, we use RAII to both denote ownership and ensure clean-up. RAII is well-known though not very indicative, I myself prefer the newish SBRM (Scope Bound Resources Management).

The idea is that instead of using a bare pointer, which does not indicate anything about ownership (ie do you have to call delete on it ?) you should use a smart pointer, like for example unique_ptr.

You can also make use of the return parameter of the method, to avoid having a two-steps initialization process (first create the pointer, then make it point to an object). Here is a concise example:

typedef std::unique_ptr<AbstractInfo> AbstractInfoPtr;

// Note: if you know it returns a MyInfoObject
// you might as well return std::unique_ptr<MyInfoObject>
AbstractInfoPtr InfoFactory::CreateInfoObject()
{
  return AbstractInfoPtr(new MyInfoObject());
}

// Usage:
int main(int argc, char* argv[])
{
  InfoFactory factory;
  AbstractInfoPtr info = factory.CreateInfoObject();

  // do something

} // info goes out of scope, calling `delete` on its pointee

Here, there is no ambiguity in regard to the ownership.

Also, note how you better understand your question here:

  std::unique_ptr<MyInfoObject> info = factory.CreateInfoObject();

would not compile because you cannot convert a AbstractInfo* to a MyInfoObject* without using static_cast or dynamic_cast.

Matthieu M.
@Matthieu: The edit talks about your comment!
Tony
@Tony: I've edited my answer with a proposal for an alternative interface.
Matthieu M.
@Matthieu: Thanks a lot for the explanation. Now can I still do a down cast from my retrieved AbstractInfoPtr to a derived object?? Is that a good idea?
Tony
@Tony: yes and no. It's better if your design does not necessitates a downcast, however if you are stuck with a `AbstractInfoPtr` and need a more derived object, then go ahead and downcast. There is no facility (you cannot use `static_cast` directly) so you have to do it manually: 1. get the pointer and cast it, 2. if it succeeds assign it to another `unique_ptr`, 3. release it from the first. In case of a `static_cast`, you can short-cut 2. which gives: `unique_ptr<MyInfoObject> myinfo ( static_cast<MyInfoObject*>(info.release()) );`. For a `dynamic_cast`, this may fail, thus the test before.
Matthieu M.
+2  A: 

A pointer to a pointer just isn't as flexible as a pointer to an object. The compiler will strictly enforce the type without regard to the inheritance tree.

The safest way to fix this code is with a double assignment:

MyInfoObject* InfoObj = NULL;  // derived from AbstractInfo object 
AbstractInfo* temp = NULL;
InfoFactory fc; 

fc.CreateInfoObject(&temp); 
InfoObj = dynamic_cast<MyInfoObject*>(temp);
Mark Ransom
The problem would exist even if he were returning an object without using any pointers (e.g. with a method `AbstractInfo InfoFactory::CreateInfoObject();`.) He's trying to cast an abstract class to a concrete subclass thereof, which produces an ill-formed program and won't compile.
Jonathan Grynspan
@Jonathan, that problem is exactly why I use `dynamic_cast` in the answer. If the object returned isn't actually a `MyInfoObject`, the cast will fail.
Mark Ransom
@Mark: Fair enough!
Jonathan Grynspan
+3  A: 

Because CreateInfoObject() takes a pointer-to-a-pointer-to-an AbstractInfo, it's possible for the function to return an instance of AbstractInfo that is not an instance of MyInfoObject. So you could end up with a pointer to MyInfoObject that actually points to a DifferentInfoObject.

Change the MyInfoObject *InfoObj to AbstractInfo *InfoObj and it should work. Don't cast away the conversion with anything but dynamic_cast<> because you don't know for certain that CreateInfoObject() returns an instance of that subclass.

Jonathan Grynspan
+3  A: 

The compiler told you what's wrong. You cannot convert a pointer of type T* to a pointer of type U* when T and U have nothing to do with each other. Here, T=MyInfoObject*, U=AbstractInfo* and these are two distinct pointer types that don't share any inheritance relationship.

sellibitze
The problem isn't pointers. The problem is that `CreateInfoObject()` could return an instance of `AbstractInfo` that is *not* also an instance of `MyInfoObject` and the calling code has no way of ensuring that can't happen.
Jonathan Grynspan
To reinforce this answer: even though the classes MyInfoObject and AbstractInfo have an inheritance relationship, the pointer types MyInfoObject* and AbstractInfo* do not.
Mark Ransom
@Jonathan: The calling code is invalid anyways. It is invalid because T and U are not reference-related. The compiler doesn't let you do something like that unless you explicitly cast the pointers in which case you may run into the problem you're referring to.
sellibitze
@Jonathan: sellibitze is correct; this error would happen even if inheritance weren't involved. For example, `void f(void **vp); int *i; f(` is illegal, too, despite a conversion existing between `int*` and `void*`.
Steve M
I just want to mention one more thing. Converting a pointer of type Derived* to Base* may involve a pointer adjustment. That's *another* reason why Derived* and Base* are not reference-related even though Derived and Base are reference-related.
sellibitze
You're absolutely right, of course. :) I was looking at a more obvious issue with the type conversion--more obvious to me, at the least. My bad!
Jonathan Grynspan
Thinking a bit more about the problem, I think we're saying fundamentally the same thing: that the code is wrong because there's an invalid conversion between types. I only mentioned inheritance because it looked like @Tony was assuming that, because the class types *were* related, the conversion would be both valid and implicit.
Jonathan Grynspan
A: 

Consider that happens in CreateInfoObject.

Lets say there is another subclass of AbstractInfo, call Foo.

Inside CreateInfoObject we create a new Foo and assign it to *info. (Allowed upcast).

But outside we now have Foo inside a MyInfoObject** which is wrong.

Douglas Leeder