Question

我正在尝试将一些代码从C＃反向移植到C ++以解决一个恼人的问题，并且想知道是否有人知道C＃的'内部'的等价物将在C ++中。

以下是使用它的示例：

internal int InternalArray__ICollection_get_Count ()
        {
            return Length;
        }

Answer 1

C ++中没有internal的直接等价物。除了public / protected / private之外，唯一的其他访问控制机制是friend，这是一种允许特定类访问所有的机制你自己班的成员。

因此它可以用作类似internal的访问控制机制，其中最大的区别在于：

您必须逐个明确声明friend个类
friend类可以毫无例外地访问所有成员;这是一个非常高的访问水平，可以引入紧密耦合（这就是为什么对friend的习惯反射反应是“你真的需要吗？”）

另见When should you use 'friend' in C++?

Answer 2

如果您的想法是将整个模块彼此隔离，您可以尝试保留两组头文件 - 一个使用“公共”方法，另一个使用“内部”方法。我不确定如何在这一点上避免重复; AFAIK类只能在编译单元中声明一次，公共标题和内部标题都需要完整的类定义。其中一个非常笨重的方法是让_Foo.public.h和_Foo.internal.h等部分文件只包含方法声明，而“真正的”头文件包含一个或两个进入类声明体的文件： / p>

Foo.public.h

class Foo {
    #include "_foo.public.h"
}

Foo.internal.h

class Foo {
    #include "_foo.internal.h"
}

源文件将引用其自己模块的内部标头，但是引用其依赖项的公共标头。应该可以调整项目布局并构建脚本以使其合理透明。（例如，为每个模块设置正确目录的包含路径。）

这仅仅隐藏了“内部”成员，而不是实现实际的访问控制，因此假设模块是单独编译的，并被视为二进制依赖项。如果通过将依赖项包含在源代码树中并一次编译所有内容来处理依赖项，则需要能够构建它们，并且内部方法声明可能仍然存在于构建中。

Answer 3

对于仍然感兴趣的任何人，我认为有一个宏解决方案。通常在创建 API 时，我会在 API 项目的设置中定义一个“BUILDDLL”宏，用于定义 DLL 导出/导入，如下所示：

#ifdef BUILDDLL
    #define DLL __declspec(dllexport)
#else
    #define DLL __declspec(dllimport)
#endif

所以我也用它来定义一个内部宏：

#ifdef BUILDDLL
    #define INTERNAL public
#else
    #define INTERNAL private
#endif

BUILDDLL 在 DLL 项目的设置中定义（在 VS 中，属性->C\C++->预处理器->预处理器定义），而不是使用者项目的设置。因此，对于使用者，宏被替换为“私有”，但它在 DLL 项目中是“公共的”。您可以像使用任何其他访问修饰符一样使用它：

class DLL Foo
{
public:
    int public_thing;
INTERNAL:
    int internal_thing;
};

这不是一个完美的解决方案（例如，您不能将它与定义出现在头文件中的成员函数一起使用，并且没有什么可以阻止最终用户覆盖它），但它似乎可以正常工作。我认为它适合作为宏的“好”用途之一，对于查看代码的局外人（熟悉 C# 关键字的人）来说，它的含义非常清楚。

C ++相当于C＃的内部

3 个答案:

Foo.public.h

Foo.internal.h