C++ equivalent of C#'s internal

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