视觉类型定义到C++中的周围类型

visual Typedef to surrounding type in C++

本文关键字：类型 周围 定义 视觉 C++      更新时间：2023-10-16

有没有办法在类型声明中为声明的（包围）类型本身构建typedef而不声明类型的名称？

例：

class X
{
  public:
    typedef <fill in magic here> MyType;
  //...
};

背景：乍一看，这似乎很愚蠢。我需要这个，因为我使用宏构建数据类的编译时反射。因此，在数据类的声明中插入了一个宏，该宏需要处理它插入到的类型。到目前为止，我找到了MSVC和g ++的工作解决方案，它们都依赖于我认为实现中的缺陷。因此，它们可能无法在较新版本上运行。Clang不会"吃"这两种解决方案中的任何一种。

我目前的 MSVC 解决方案定义了一个方法，然后仅通过它的名称获取它的地址，并调用一个小助手来"返回"它的类的类型。 （Clang 和 g++ 需要方法的全名，包括它的类名）。

我当前的 g++ 解决方案定义了一个返回类型为 std::remove_reference(decltype(*this)) 的静态方法。（Clang 和 MSVC 不允许在静态上下文中this）。

我绝对更喜欢标准的符合解决方案，但目前也可以使用特殊的 clang 解决方案。

如果没有任何效果，我必须将类的名称传递给宏，但我尽量避免这种情况，因为我已经有大量使用该宏的代码。

编辑：添加有关反射如何工作的示例（这可能会澄清我需要什么）：

class X : public Y
{
  public:
    //.. constructor and such stuff...
    int a;
    double b;
    std::string c;
    CLASSHEAD(Y)
      FIELD(a)
      FIELD(b)
      FIELD(c)
    CLASSFOOT
};

CLASSHEAD是应该定义typedef的宏。它是一个VAR_ARGS宏，参数在其中接收基类。如前所述：可以给它类的名称作为它的第一个参数（导致示例中CLASSHEAD(X, Y)）。但我几乎无法想象，对于像类型定义周围类型这样"简单"的任务没有解决方案......

这并不完全符合您的规格，但我认为它非常接近：

class X
{
//Stuff...
//Use Macros to add:
struct MyType;
//Use class closing macro to insert variable between class-ending brace and semicolon      

} TYPE_VAR;
//Perhaps add random stuff to TYPE_VAR name to avoid collisions, like __FILE__
struct decltype(TYPE_VAR)::MyType
{
    typedef decltype(TYPE_VAR) V;
};

然后使用

X::MyType::V

例如，简化的 CLASSFOOT 可能如下所示：

#define CLASSFOOT /*Your classfoot here*/ } TYPE_VAR; struct decltype(TYPE_VAR)::MyType {typedef decltype(TYPE_VAR) V;
//No }; at end on purpose- this will come from the class in which you placed CLASSFOOT

这对你的目的来说足够好吗？

由于您已经在使用宏，因此可以使用此解决方案 https://stackoverflow.com/a/21143997/2173029

#define CLASS_WITH_MY_TYPE(ClassName)  
    class ClassName                   
    {                                 
       using MyType = ClassName;

然后像

CLASS_WITH_MY_TYPE(X)
public:
  struct Y
  {
    using T = MyType;
  };
};
static_assert(std::is_same<X, typename X::Y::T>::value, "");

标记为社区维基，因为@Chris提到了该链接，原始答案由@Bartek Banachewicz发布

> Nohting工作，因此在宏中使用类名是唯一有效的解决方案

相关文章：