c++ - 检查 C++ 成员函数是否存在，可能 protected

Question

我正在尝试检测一个类是否具有特定功能(特别是 shared_from_this() ，它继承自 std::enable_shared_from_this<Some Unknown Class> )。为了让事情变得更复杂，我需要知道它是否有这个功能，即使它是从远处的基类继承的，或者是使用 protected 访问继承的。

我查看了其他问题，例如 this one ，但提供的方法不适用于检测 protected 成员函数。

我目前使用的方法如下:

template <class T>
struct shared_from_this_wrapper : public T
{
  template <class U>
  static auto check( U const & t ) -> decltype( t.shared_from_this(), std::true_type() );

  static auto check( ... ) -> decltype( std::false_type() );
};

template<class T>
struct has_shared_from_this : decltype(shared_from_this_wrapper<T>::check(std::declval<shared_from_this_wrapper<T>>()))
{ };

我当前解决方案的缺陷是它不适用于声明为 final 的类。 .所以我在寻找一个满足的成员函数测试解决方案:

1. 适用于声明为 final 的类
2. 使用 protected 成员函数
3. 使用继承
4. 不需要知道函数的返回类型
5. 在 gcc、clang 和 MSVC 2013 下编译(最后一个可能会限制过于花哨的 SFINAE)

编辑:我有一个可行的解决方案，但需要与帮助程序类成为 friend ，这也不是一个理想的解决方案，但目前可能是一种解决方法(因为它满足所有要求):

struct access
{
  template <class T>
  static auto shared_from_this( T const & t ) -> decltype( t.shared_from_this() );
};

template <class U>
static auto check( U const & t ) -> decltype( access::shared_from_this(t), std::true_type() );

static auto check( ... ) -> decltype( std::false_type() );

template<class T>
struct has_shared_from_this2 : decltype(check(std::declval<T>()))
{ };

struct A : std::enable_shared_from_this<A> {};
struct B : protected A { friend class access; };    

另一个编辑:类的示例以及类型特征检查是否存在类似 shared_from_this 的内容应该返回:

struct A : std::enable_shared_from_this<A> {}; // should return true
struct B final : protected A {}; // should return true
struct C : A {}; // should return true
struct D {}; // should return false

我应该提到，我检测这个函数是否存在的最终目标是确定它的返回类型，以便找出 std::enable_shared_from_this 的类型。被模板化了。继承自 std::enable_shared_from_this<T>给你std::shared_ptr<T> shared_from_this() , 和 T最终是我需要弄清楚的。这对于正确序列化从 std::enable_shared_from_this 继承的类型是必要的。 .

编辑第 3 部分:编辑:

这是为序列化库 cereal 完成的。因此，我对用户想要如何设计他们的类(class)的控制为零。我希望能够序列化派生自 std::enable_shared_from_this 的任何用户类型，其中包括将他们的类声明为 final 或在某处使用 protected 继承的用户。任何需要干预被检查的实际类型的解决方案都不是有效的解决方案。

Answer 1

我对如何实现您要求的事情提出了一些想法，并得出了完全不同的结论。

手头的问题很有趣:如何检查一个类是否实现了隐藏接口(interface)。不幸的是，这个问题与 liskov 替换原则相矛盾。面向对象的核心原则之一。

这部分是由于 std::shared_ptr 的类型结构。 . shared_ptr不反射(reflect)其参数类型的继承关系。给定一个类 T和一个类(class)U , 其中 class T : public U {};持有 shared_ptr<T> : public shared_ptr<U> {}; 没有!

您的实现在接口(interface)级别存在一个基本缺陷。如果您在编译时查看函数是否存在，然后提取类型，您将只能反序列化使用共享指针的数据结构。

此外，如果 std::shared_ptr不推荐使用，或者您想使用其他方式来获取内存(std::allocator 接口(interface)？一些区域/池分配)，您必须调整您的接口(interface)。

我个人的意见是创建某种工厂接口(interface)并在反序列化器中的某处注册。

第二个是有一个暴露隐式模板接口(interface)的工厂类(并使用 CRTP 将接口(interface)专门用于用户需要。即:

template <class ActualType, 
          class IfType=ActualType,
          class Allocator=default::allocator<ActualType>>
class Deserializable {
  static IfType alloc(ActualType &&t) {
    Allocator a; // choose  another interface as your please.
    return a.allocate(t); /* implement me */
  }
private:
};

class MyClass
 : public InterfaceClass,
   public Deserializable<MyClass,InterfaceClass> {
  /* your stuff here */
};

• 这为您的模板类提供了合理数量的抽象。
• 您图书馆的用户知道他想要什么作为返回。如果他选择分配 std::shared_ptr 以外的其他内容他可以做到(通过创建自己的Allocator)
• 用户无需实现任何东西，只需指定类型(并实际将它们传递给您，因此无需再猜测)。

您可以将其解释为一个策略类(不是严格意义上的 Andrei Alexandrescu)。 序列化库要求分配策略。用户可以决定如何实现此策略。在这种情况下，如何分配反序列化对象和类型的选择可能不同。因为分配器有一个默认实现并且是一个模板参数，如果需要，另一个选择会传递给用户。

为了了解这种方法的威力，欢迎您查看 boost::operator 的代码它使用这种技术在编译时指定算术运算符的返回类型和参数。

注意

对于那些也在查看这篇文章以寻求原始问题答案的人，我建议使用 this approach .但是它要求成员是公共(public)的，因为它会检查给定名称的成员函数指针。