27

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;
        }
user978122
  • 5,531
  • 7
  • 33
  • 41
  • I'm not sure there's a direct equivalent, but [`friend` functions](http://www.cplusplus.com/doc/tutorial/inheritance/) might be close. (That said, I'm not entirely up-to-date with the latest C++ versions.) – millimoose Dec 05 '12 at 11:57
  • 1
    I would consider using the PIMPL idiom. – Arafangion Dec 05 '12 at 12:37
  • @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: http://c2.com/cgi/wiki?PimplIdiom) – millimoose Dec 05 '12 at 13:40
  • @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; in the header class would be fine. – Arafangion Dec 05 '12 at 23:31

3 Answers3

30

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

Community
  • 1
  • 1
Jon
  • 428,835
  • 81
  • 738
  • 806
  • "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." http://weblogs.thinktecture.com/cnagel/2004/12/access-modifiers-ccli-vs-c-vs-vb.html – user978122 Dec 05 '12 at 13:19
  • 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? – user978122 Dec 05 '12 at 13:19
  • 1
    @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. – Jon Dec 05 '12 at 13:29
  • 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. – user978122 Dec 06 '12 at 07:49
  • Note you can also befriend specific funtions. – Sebastian Mach Feb 23 '16 at 11:08
5

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.

millimoose
  • 39,073
  • 9
  • 82
  • 134
  • 1
    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. – Ben Voigt May 12 '21 at 20:05
0

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.

Birdaclysm
  • 1
  • 1