C++ 等效于 C# 的内部

Question

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++.

Here's an example of the it in use:

internal int InternalArray__ICollection_get_Count ()
        {
            return Length;
        }

Answer 1

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.

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++?

Answer 2

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:

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. (Eg 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.

Answer 3

For anyone still interested, I think there's a macro solution. Usually when creating an API I define a "BUILDDLL" macro in the API project's settings that is used to define DLL export/import like such:

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

So I also use it to define an INTERNAL macro:

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

BUILDDLL is defined in the DLL project's settings (in VS, properties->C\\C++->preprocessor->preprocessor definitions), but not the consumer project's settings. So for the consumer, the macro is replaced with "private", but it's "public" within the DLL project. You'd use it just like any other access modifier:

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

It's not a perfect solution (you can't use it with member functions whose definitions appear in header files, for example, and there's nothing stopping the end user from overriding it), but it seems to work without error. I think it fits as one of the "good" uses for macros, and it's pretty clear for an outsider looking at the code (who is familiar with the C# keyword) what it means.