On 06.06.2016 10:45, Andrzej Krzemienski wrote:
Hi Vladimir, I am following the discussion about Pimpl here, and it seems to me I understand the idea less and less.
My impression is (but I might be wrong here) that people use Pimp for slightly different things and that one solution might not suit all the needs. Let me list two use cases that I consider significantly different:
1a. I am selling my own complicated library, and I want to make sure users will never see the source code. I can afford to add some run-time penalty because this is a high-level library and the cost of additional indirection is negligible compared to what the library is doing.
1b. I am a programmer and I use a third party library called LIB1 but I wrap it into a class C because I do not want the users of class C to have any knowledge of LIB1, because next month I want to replace library LIB1 with another library LIB2, and I want to do it seamlessly, without forcing the users of C to recompile anything. Again, the cost of additional indirection is negligible, because what LIB1 and LIB2 do is orders of magnitude more expensive.
2. I want to apply Pimpl to every second class in my program because my code is not performance-critical and I would rather have fast compile-times than fast run-times. A valid trade-off for non-critical parts of the program.
The question is, which of the two (or any other) use cases does your library address?
Personally, when I have used pimpl, it has always been for another use case entirely: 3. I want a class to have value semantics, but use a copy-on-write implementation behind the scenes. This is mostly for objects that get copied around a lot. I don't particularly care about implementation hiding or compile times. I care about memory usage and raw performance. Pimpl gives me that for copy operations, at the cost of an extra level of redirection on other operations. -- Rainer Deyke (rainerd@eldwood.com)