C ++相当于C#的内部

时间:2022-10-07 21:01:03

I am trying to backport some code from C# to C++ to get around an annoying problem, and what like to ask if anyone knows what the equivalent of C#'s 'internal' would be in C++.

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

Here's an example of the it in use:

这是一个使用它的例子:

internal int InternalArray__ICollection_get_Count ()
        {
            return Length;
        }

2 个解决方案

#1


18  

There is no direct equivalent of internal in C++. Apart from public/protected/private the only other access control mechanism is friend, a mechanism by which can allow specific classes access to all members of your own class.

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

It could therefore be used as an internal-like access control mechanism, with the big difference being that:

因此,它可以用作类似内部的访问控制机制,最大的区别在于:

  • you have to explicitly declare friend classes one by one
  • 你必须逐个显式地声明朋友类

  • friend classes have access to all members without exception; this is an extremely high level of access and can introduce tight coupling (which is the reason why the customary reflex reaction to friend is "do you really need that?")
  • 朋友班可以毫无例外地访问所有成员;这是一个非常高的访问水平,可以引入紧密耦合(这就是为什么对朋友的习惯性反射反应是“你真的需要吗?”)

See also When should you use 'friend' in C++?

另请参见何时在C ++中使用“朋友”?

#2


3  

If your idea is to isolate whole modules from one another, you could try keeping two sets of header files – one with the "public" methods, another with the "internal" ones. I'm not sure how to avoid duplication at this point; AFAIK a class may only be declared once in a compilation unit, and both the public and internal header need a complete definition of a class. One, admittedly very clunky way would be to have partial files like _Foo.public.h and _Foo.internal.h that only contain method declarations, and the "real" header files include one or both of those into the class declaration body:

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

Foo.public.h

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

Foo.internal.h

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

Source files would refer to the internal headers of their own module, but to the public ones of their dependencies. It should be possible to tweak the project layout and build scripts to make this reasonably transparent. (E.g. setting up the include paths to the correct directories for each module.)

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

This merely hides the "internal" members instead of implementing actual access control, and thus assumes that modules are compiled separately and treated as binary dependencies. If you handle dependencies by including them in the source tree and compiling everything at once, you need to be able to build them anyway, and the internal method declarations might still be present in the build.

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

#1


18  

There is no direct equivalent of internal in C++. Apart from public/protected/private the only other access control mechanism is friend, a mechanism by which can allow specific classes access to all members of your own class.

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

It could therefore be used as an internal-like access control mechanism, with the big difference being that:

因此,它可以用作类似内部的访问控制机制,最大的区别在于:

  • you have to explicitly declare friend classes one by one
  • 你必须逐个显式地声明朋友类

  • friend classes have access to all members without exception; this is an extremely high level of access and can introduce tight coupling (which is the reason why the customary reflex reaction to friend is "do you really need that?")
  • 朋友班可以毫无例外地访问所有成员;这是一个非常高的访问水平,可以引入紧密耦合(这就是为什么对朋友的习惯性反射反应是“你真的需要吗?”)

See also When should you use 'friend' in C++?

另请参见何时在C ++中使用“朋友”?

#2


3  

If your idea is to isolate whole modules from one another, you could try keeping two sets of header files – one with the "public" methods, another with the "internal" ones. I'm not sure how to avoid duplication at this point; AFAIK a class may only be declared once in a compilation unit, and both the public and internal header need a complete definition of a class. One, admittedly very clunky way would be to have partial files like _Foo.public.h and _Foo.internal.h that only contain method declarations, and the "real" header files include one or both of those into the class declaration body:

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

Foo.public.h

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

Foo.internal.h

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

Source files would refer to the internal headers of their own module, but to the public ones of their dependencies. It should be possible to tweak the project layout and build scripts to make this reasonably transparent. (E.g. setting up the include paths to the correct directories for each module.)

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

This merely hides the "internal" members instead of implementing actual access control, and thus assumes that modules are compiled separately and treated as binary dependencies. If you handle dependencies by including them in the source tree and compiling everything at once, you need to be able to build them anyway, and the internal method declarations might still be present in the build.

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