Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am working on a library which had several headers that are meant to only be used by the library itself. I also have a few classes and functions in headers that I do not want the client to use. For instance, I have a header that contains debugging functions, but they should not be used outside of the library as it could cause problems.

Should this code be hidden from the client? If so, how?

share|improve this question
up vote 1 down vote accepted

A common way to handle this is public and private headers.

Given that some things must appear in a header file, either for physical implementation reasons, or for performance/inlining reasons, you need to split somehow.

Have your public header include the private header; and add comment(s) nearby that this is an implementatinn detail and subject to change.

Of course, you still need to ship the headers, and they will be visible to your end user, but they would use those internals at their own risk.

share|improve this answer

Should this code be hidden from the client? If so, how?

Off course. You do it by not providing the headers. That is, you just provide the shared libraries, and the headers declaring classes your client should use.

share|improve this answer

Yes, you can do this in C++ by using the PIMPL idiom. If you use this idiom you only need to let the client see a header defining a simple wrapper class, which has a pointer to the real class as its data member. Because you are using a pointer, you would only need to forward declare the real implementation class in the header of the wrapper class. The header of the real implementation class only needs to be included in the .cpp file of the wrapper, so the client will never see it.

Having said that, using PIMPL adds complexity to your code. Now, if you need a new public member function, you would have to add it in two places. Also, you would have to go through more levels of call stack when you debug. You should really think long and hard whether hiding some functions from your client is worth this extra work.

P.S. The PIMPL idiom has another important use. It lets you break dependencies between components, which reduces coupling making your code easier to modify, and it can also significantly reduce the build time.

share|improve this answer

If there is any functionality which should not be reached by the client, it should be well hidden from them.

If you are going to distribute your library, without any debug symbols, you might consider taking the debug functionality out of your distribution as well, instead of encapsulating them.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.