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;
        }

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

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

Comments

[Montre]

I'm not sure there's a direct equivalent, but friend functions might be close. (That said, I'm not entirely up-to-date with the latest C++ versions.)

[Arafangion]

I would consider using the PIMPL idiom.

[Montre]

@Arafangion That would help, but then you wouldn't get the benefit of faster compilation within the module, unless you use multiple layers of those. (Which adds yet more boilerplate. Although apparently that can be cut through: c2.com/cgi/wiki?PimplIdiom)

[Arafangion]

@millimoose: You would get faster compilation of the application or library as a whole, though, and you don't need multiple layers. Just a class Impl; std::unique_ptr<Impl> impl; in the header class would be fine.

[user978122]

"With C++/CLI one access modifier defines the access within the assembly, the other one defines the outside access. The order doesn't matter: more access is always from inside. C# internal is done with C++/CLI public private: public within the assembly, private outside of the assembly. Protected within the assembly and private outside of the assembly is not possible with C#, but it is possible with C++/CLI." weblogs.thinktecture.com/cnagel/2004/12/…

[user978122]

It appears that declaring public private is the way to go, but I can't make much sense of it. Sorry to be so daft, but could explain it to me?

[Waihon Yew]

@user978122: If you are using C++/CLI then you should explicitly mention that in the question (unfortunately I have no experience with it, so cannot suggest a good solution there). Otherwise what you quoted does not apply.

[user978122]

Hmm, it appears that C++/CLI is not what I thought it was. Nevermind my finding. I'll just swap everything to public or protected as needed.

[Sebastian Mach]

Note you can also befriend specific funtions.

[Ben Voigt]

This is completely and totally forbidden in standard C++ (see: One Definition Rule). You may get away with it in some specific environment but a better paradigm is for the public portion to be a base class of the private (complete) implementation.