Hiding a C++ class in a header without using the unnamed namespace

Question

I am writing a C++ header in which I define a

class A {
   // ...
};

that I would like to hide from the outside world (because it may change or even be removed in future versions of this header).

There is also a class B in the same header that has an object of class A as a member:

class B {
public:
   // ...

private:
   A a_;
};

What is a proper way of hiding class A from the outside world?

If I put the definition of A in an unnamed namespace, the compiler issues a warning, so I assume that, due to issues with internal linkage, I should do something else.

Answer 1

The right way to go about it in C++ is PIMPL idiom. Alternative solution is to put the class you want to hide into a nested namespace, which is usually called detail. But that will not make it totally private as users will still be exposed to its dependencies, and will be able to use it directly.

Answer 2

You could do an inner class:

class B
{
  class A { /* ... */ };
  A a_;
}

Answer 3

Document that this class is not part of the public API and should not be used.

In C++ you have to trusted programs that link with your library code because you have little other choice. C++ has limited "access control" features many of which can be bypassed or abused so you're better of treating your API clients with respect and building trust.

If you design your API to be easy to use correctly and hard to use unintentionally incorrectly then you will be helping your clients and it is hardly your fault if your clients abuse your interface.

Answer 4

An unnamed namespace is useless anyways, as it only protects agains multiple definitions. What you could do is either using the pImpl Idiom, as mentioned in other answers, or use a detail namespace. Works fine for Boost:

namespace detail{
  class A{
    // ...
  };
}

class B{
public:
  // ...
private
  A a_;
};

Anyone messing with stuff in a detail namespace is asking for trouble. Or maybe obscure it even more

namespace _b_impl_detail{
  // ...
};

Anyone who now touches anything inside should be shot in the foot. :)

Answer 5

Instead of class B holding an A object, have it hold an A* instead (or a shared_ptr<A>, or an unique_ptr<A>, etc.). This way class B only needs a forward declaration of class A and class A can be fully defined inside of class B's source file.

Answer 6

If A is an implementation detail of B, don't put its definition in the header at all. Instead:

class B {

   ...
   class A * myA;
};

and then put the definition of A in the B implementation (i.e. .cpp) file.

Answer 7

I'd like to add a small increment over https://stackoverflow.com/a/5780976/1525238 that helped me better solve my peculiar use case, namely where the "main" class is a template and the "helper/inner" class also has to be a template¹.

I used a nested namespace called detail, made all "helper" content private and made the "main" class a friend of the "helper" class:

template<__MAIN_TEMPLATE_PARAMS__> class Main;

namespace detail {
    template<__HELPER_TEMPLATE_PARAMS__> class Helper {

        /* All Main templates are friends */
        template<__MAIN_TEMPLATE_PARAMS__> friend class Main; 

        /* Private stuff, not reachable from the outside */
        static void privateThing(){
            ...
        }
    };
}

template<__MAIN_TEMPLATE_PARAMS__> class Main {
    void usePrivateThing(){
        detail::Helper<__DESIRED_HELPER_TEMPLATE_PARAMS__>::privateThing();
    }
};

The private stuff is static above only to make the code shorter. They may very well be tied to the Helper instance.

In retrospect, there could certainly be more elegant solutions involving less black magic, but it highly depends on the specific application. I still find the above a legit, nice use case for a friend class.

---

¹ This is because I needed to use a template helper function that required a partial specialization, which is not allowed yet in c++, for no particular reason but is technically possible with a wrapper class. Partial specialization is omitted from the above for simplicity.