Как я могу использовать ковариантные возвращаемые типы с интеллектуальными указателями?
-
10-07-2019 - |
Вопрос
У меня есть такой код, как этот:
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 {...}
...
};
Этот код не компилируется.
В Visual Studio это вызывает
C2555:переопределение виртуальной функции тип возвращаемого значения отличается и не ковариантные
Если я не использую boost::shared_ptr
но возвращая необработанные указатели, код компилируется (я понимаю, это связано с ковариантные возвращаемые типы в C++).Я вижу, что проблема в том, что boost::shared_ptr
из Ret1
не является производным от boost::shared_ptr
из RetInterface
.Но я хочу вернуться boost::shared_ptr
из Ret1
для использования в других классах, иначе я должен привести возвращаемое значение после возврата.
- Я делаю что-то не так?
- Если нет, то почему язык такой - он должен быть расширяемым для обработки преобразования между интеллектуальными указателями в этом сценарии?Есть ли желательный обходной путь?
Решение
Во-первых, это действительно так в C ++: возвращаемый тип виртуальной функции в производном классе должен быть таким же, как и в базовом классе. Существует специальное исключение, что функция, которая возвращает ссылку / указатель на некоторый класс X, может быть переопределена функцией, которая возвращает ссылку / указатель на класс, производный от X, но, как вы заметили, это не позволяет использовать умные указатели (например, shared_ptr
), просто для простых указателей.
Если ваш интерфейс RetInterface
достаточно исчерпывающий, вам не нужно знать фактический возвращаемый тип в вызывающем коде. В общем, в любом случае это не имеет смысла: причина, по которой get_r
является функцией virtual
, заключается в том, что вы будете вызывать ее через указатель или ссылку на базовый класс AInterface
, и в этом случае вы можете не знаю, какой тип будет возвращать производный класс. Если вы вызываете это с действительной ссылкой A1
, вы можете просто создать отдельную функцию get_r1
в <=>, которая делает то, что вам нужно.
class A1: public AInterface
{
public:
boost::shared_ptr<RetInterface> get_r() const
{
return get_r1();
}
boost::shared_ptr<Ret1> get_r1() const {...}
...
};
Кроме того, вы можете использовать шаблон посетителя или что-то вроде моего метода динамической двойной отправки передать обратный вызов возвращаемому объекту, который затем может вызвать обратный вызов с правильным типом.
Другие советы
Как насчет этого решения:
template<typename Derived, typename Base>
class SharedCovariant : public shared_ptr<Base>
{
public:
typedef Base BaseOf;
SharedCovariant(shared_ptr<Base> & container) :
shared_ptr<Base>(container)
{
}
shared_ptr<Derived> operator ->()
{
return boost::dynamic_pointer_cast<Derived>(*this);
}
};
например,:
struct A {};
struct B : A {};
struct Test
{
shared_ptr<A> get() {return a_; }
shared_ptr<A> a_;
};
typedef SharedCovariant<B,A> SharedBFromA;
struct TestDerived : Test
{
SharedBFromA get() { return a_; }
};
Вы не можете изменять типы возвращаемых данных (для не указательных, не ссылочных возвращаемых типов) при перегрузке методов в C ++. A1::get_r
должен вернуть boost::shared_ptr<RetInterface>
.
У Энтони Уильямса хороший ответ .
Вот моя попытка:
template<class T>
class Child : public T
{
public:
typedef T Parent;
};
template<typename _T>
class has_parent
{
private:
typedef char One;
typedef struct { char array[2]; } Two;
template<typename _C>
static One test(typename _C::Parent *);
template<typename _C>
static Two test(...);
public:
enum { value = (sizeof(test<_T>(nullptr)) == sizeof(One)) };
};
class A
{
public :
virtual void print() = 0;
};
class B : public Child<A>
{
public:
void print() override
{
printf("toto \n");
}
};
template<class T, bool hasParent = has_parent<T>::value>
class ICovariantSharedPtr;
template<class T>
class ICovariantSharedPtr<T, true> : public ICovariantSharedPtr<typename T::Parent>
{
public:
T * get() override = 0;
};
template<class T>
class ICovariantSharedPtr<T, false>
{
public:
virtual T * get() = 0;
};
template<class T>
class CovariantSharedPtr : public ICovariantSharedPtr<T>
{
public:
CovariantSharedPtr(){}
CovariantSharedPtr(std::shared_ptr<T> a_ptr) : m_ptr(std::move(a_ptr)){}
T * get() final
{
return m_ptr.get();
}
private:
std::shared_ptr<T> m_ptr;
};
И маленький пример:
class UseA
{
public:
virtual ICovariantSharedPtr<A> & GetPtr() = 0;
};
class UseB : public UseA
{
public:
CovariantSharedPtr<B> & GetPtr() final
{
return m_ptrB;
}
private:
CovariantSharedPtr<B> m_ptrB = std::make_shared<B>();
};
int _tmain(int argc, _TCHAR* argv[])
{
UseB b;
UseA & a = b;
a.GetPtr().get()->print();
}
Пояснения:
Это решение подразумевает метапрограммирование и модификацию классов, используемых в ковариантных интеллектуальных указателях. Р>
Простая структура шаблона Child
предназначена для привязки типа Parent
и наследования. Любой класс, наследующий от Child<T>
, наследует от T
и определяет has_parent
как CovariantSharedPtr<B>
. Классы, используемые в ковариантных интеллектуальных указателях, должны определять этот тип.
Класс ICovariantSharedPtr<B>
используется для определения во время компиляции, определяет ли класс тип ICovariantSharedPtr<B, has_parent<B>::value>
или нет. Эта часть не моя, я использовал тот же код, что и для определения, существует ли метод ( см. здесь )
Поскольку мы хотим ковариации с помощью умных указателей, мы хотим, чтобы наши умные указатели имитировали существующую классовую архитектуру. Проще объяснить, как это работает на примере.
Когда B
определено, оно наследуется от Child<A>
, что интерпретируется как has_parent<B>::value
. Так как ICovariantSharedPtr<B, true>
наследуется от ICovariantSharedPtr<B::Parent>
, ICovariantSharedPtr<A>
является истиной, то A
является has_parent<A>::value
и наследуется от ICovariantSharedPtr<A, false>
, что <=>. Поскольку <=> не имеет <=> определенного значения, <=> является ложным, <=> является <=> и наследуется из ничего. Р>
Суть в том, что <=> наследуется от <=>, у нас <=> наследуется от <=>. Поэтому любой метод, возвращающий указатель или ссылку на <=>, может быть перегружен методом, возвращающим то же самое на <=>.
В это сообщение в блоге (из Рауля Борхеса)
Выдержка из бита до добавления поддержки множественного наследования и абстрактных методов:
template <typename Derived, typename Base>
class clone_inherit<Derived, Base> : public Base
{
public:
std::unique_ptr<Derived> clone() const
{
return std::unique_ptr<Derived>(static_cast<Derived *>(this->clone_impl()));
}
private:
virtual clone_inherit * clone_impl() const override
{
return new Derived(*this);
}
};
class concrete: public clone_inherit<concrete, cloneable>
{
};
int main()
{
std::unique_ptr<concrete> c = std::make_unique<concrete>();
std::unique_ptr<concrete> cc = b->clone();
cloneable * p = c.get();
std::unique_ptr<clonable> pp = p->clone();
}
Я бы посоветовал прочитать статью полностью. Это просто написано и хорошо объяснено.
Мистер Фуз ответил на часть 1 вашего вопроса. Во второй части это работает так, потому что компилятор не знает, будет ли он вызывать AInterface :: get_r или A1 :: get_r во время компиляции - ему нужно знать, какое возвращаемое значение он получит, поэтому он настаивает на обоих методах. возвращая тот же тип. Это часть спецификации C ++.
Для временного решения, если A1 :: get_r возвращает указатель на RetInterface, виртуальные методы в RetInterface будут по-прежнему работать должным образом, и соответствующий объект будет удален при уничтожении указателя. Нет необходимости в различных типах возвращаемых данных.
возможно, вы могли бы использовать параметр out для обхода & ковариации с возвращенным boost shared_ptrs. Р>
void get_r_to(boost::shared_ptr<RetInterface>& ) ...
поскольку я подозреваю, что вызывающая сторона может добавить более уточненный тип shared_ptr в качестве аргумента.