Re: [boost] Pimpl Again?

Subject: Re: [boost] Pimpl Again?
From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2016-06-06 04:45:21

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?

Also, I remember that last time the library promoted the use of shared
ownership (altering the state of one object immediately alters the states
of other objects). The examples from the new dos still seem to imply that.
Is it necessary? If for some reason I need the shared ownership I could
implement it atop of Pimpl classes using a shared_ptr.

But I might be wrong about my understanding of the library. I am really
missing the introduction, that would outline the scope of the problems you
are addressing, some high level design decisions, and the intended usage.

For now, the initial example encourages me to use shared semantics, and I
feel it is encouraging me to do the wrong thing.

Regards,
&rzej

2016-05-28 7:41 GMT+02:00 Vladimir Batov <Vladimir.Batov_at_[hidden]>:

> Don't laugh but it is only fairly recently at work that I managed to move
> all our supported platforms to C++11. So, then, I started moving our code
> to C++11 (what a delight!) and stumbled upon my old pimpl which is used
> quite a bit around my workplace for all its good properties... :-)
>
> Now C++11-ed piml turned out to be very small and very basic. So basic it
> felt it did not have the right to exist. Still, it encapsulates and
> enforces the "proper" pimpl properties and behavior, reduces implementation
> minutia and offers a recognizable deployment pattern (helps other people
> reading the code).
>
> Over the years IMO the technique has been proven as legitimate and useful,
> a basic but important building block... rather than a curiosity item.
> Unfortunately, despite many articles and a few Sutter's GotWs about it
> there is nothing ready-to-go like std::unique_ptr.
>
> I feel that pimpl and its deployment pattern need to be codified,
> described, "standardized" and in our toolboxes to stop/avoid everyone
> re-inventing the pimpl and making the same mistakes. IMO Boost is best
> positioned for that.
>
> Do you think we might review what I've got and/or maybe collectively come
> up with something better... It's no MPL or Hana but as std::unique_ptr it's
> one of the first "little things" I personally reach out for in my everyday
> work. IMO having pimpl in Boost would save quite a few hours of frustration
> for many.
>
> Thoughts? No pressure. I am easy either way. :-)
>
> https://github.com/yet-another-user/pimpl
>
> Docs are freshened up but still somewhat out of date. Apologies.
>
>
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>