Should I use PIMPL everywhere? [closed]

Question

My current project involves writing a C++ API and I have decided to use the PIMPL idiom.

Should I use the PIMPL idiom everywhere in my project, for example I need to create a custom class that inherits from std::exception, should I design this class with PIMPL idiom in mind or can I just write as a public implementation?

It feels wrong to assume that just because I'm using the PIMPL idiom that every class I create should be designed around it. Are there any exceptions where PIMPL should not be used?

Tabular

Well I hope it shouldn't be used everywhere, because that's where I don't use it. – Haye

I thought the main motivation for PIMPL was to reduce compile times by not forcing recompiling implemrntations every time the interface for a class changes - if this is not a problem then there's no need to use it everywhere – Fidole

Answer 1

If you are writing API/library the question is what is the main advantage for the users of your API and even what IDE and tools they will be using working with your API. The key points for using PIMPL are:

• You want to really hide implementation from users (you have great amount of private methods and fields and very simple public interface).
• You want to abstract them from platform-dependent code.
• You want to reduce their build time.

You shouldn't use PIMPL when virtual calls or any sort of indirection cost your users too much in operation time of their programs:

• Sequences of repeated small functions calls (and you can't remove it from API level).
• Creating and deleting huge amount of small objects (and you can't remove it from API level).

Forwardlooking

Answer 2

PIMPL has costs.

Therefore it's only a good idea where you really need it, e.g. to contain use of a C header that uses C++ keywords as names, or that e.g. defines a zillion macros.

Some (including Herb) advocate or at least don't argue against using PIMPL purely for reduced build times, but other measures such as throwing hardware at the problem can be less costly.

Hiedihiemal