views:

1157

answers:

5

I have code like this:

class RetInterface {...}

class Ret1: public RetInterface {...}

class AInterface
{
  public:
     virtual boost::shared_ptr<RetInterface> get_r() const = 0;
     ...
};

class A1: public AInterface
{
  public:
     boost::shared_ptr<Ret1> get_r() const {...}
     ...
};

This code does not compile. In visual studio it raises "C2555: overriding virtual function return type differs and is not covariant". If I do not use boost::shared_ptr but return raw pointers, the code compiles (I understand this is due to covariant return types in C++). I can see the problem is because boost::shared_ptr of Ret1 is not derived from boost::shared_ptr of RetInterface. But I want to return boost::shared_ptr of Ret1 for use in other classes, else I must cast the returned value after the return.

  1. Am I doing something wrong?
  2. If not, why is the language like this - it should be extensible to handle conversion between smart pointers in this scenario? Is there a desirable workaround?
+1  A: 

You can't change return types when overloading methods in C++. A1::get_r must return a boost::shared_ptr<RetInterface>.

Mr Fooz
+1  A: 

Mr Fooz answered part 1 of your question. Part 2, it works this way because the compiler doesn't know if it will be calling AInterface::get_r or A1::get_r at compile time - it needs to know what return value it's going to get, so it insists on both methods returning the same type. This is part of the C++ specification.

For the workaround, if A1::get_r returns a pointer to RetInterface, the virtual methods in RetInterface will still work as expected, and the proper object will be deleted when the pointer is destroyed. There's no need for different return types.

Mark Ransom
+5  A: 

Firstly, this is indeed how it works in C++: the return type of a virtual function in a derived class must be the same as in the base class. There is the special exception that a function that returns a reference/pointer to some class X can be overridden by a function that returns a reference/pointer to a class that derives from X, but as you note this doesn't allow for smart pointers (such as shared_ptr), just for plain pointers.

If your interface RetInterface is sufficiently comprehensive, then you won't need to know the actual returned type in the calling code. In general it doesn't make sense anyway: the reason get_r is a virtual function in the first place is because you will be calling it through a pointer or reference to the base class AInterface, in which case you can't know what type the derived class would return. If you are calling this with an actual A1 reference, you can just create a separate get_r1 function in A1 that does what you need.

class A1: public AInterface
{
  public:
     boost::shared_ptr<RetInterface> get_r() const
     {
         return get_r1();
     }
     boost::shared_ptr<Ret1> get_r1() const {...}
     ...
};

Alternatively, you can use the visitor pattern or something like my Dynamic Double Dispatch technique to pass a callback in to the returned object which can then invoke the callback with the correct type.

Anthony Williams
A: 

maybe you could use an out parameter to get around "covariance with returned boost shared_ptrs.

 void get_r_to(boost::shared_ptr<RetInterface>& ) ...

since I suspect a caller can drop in a more refined shared_ptr type as argument.

Wim Ockerman
+1  A: 

This question was asked a long time ago, but no one gave a very good answer. See http://lists.boost.org/boost-users/2007/11/31932.php for how to actually get what you want.

All this makes me think whether the heavy machinery and constraints of shared_ptr is worth it. My current position is to avoid shared_ptr as far as possible, in favor of ptr_containers. I've to still need to try intrusive reference counters.
Amit Kumar