Re: [boost] Review Request: impl_ptr (pimpl)

Subject: Re: [boost] Review Request: impl_ptr (pimpl)
From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2017-08-21 12:38:08

2017-08-15 2:51 GMT+02:00 Vladimir Batov via Boost <boost_at_[hidden]>:

> After much procrastination I would like to request a formal review for the
> pimpl library... once and for all :-) (given it's been through a few
> almost-reviews and discussions)... to get some kind of a resolution one way
> or the other. :-)
>
> The code and the docs are at https://github.com/yet-another-user/pimpl <
> https://github.com/yet-another-user/pimpl>.
>

I find it disturbing that the first example describes using shared_ptr-s
and defensive null checks. Boost has always been promoting the STL-like
value-semantic style of programming, and this usage of shared_ptr's looks
counter to the trend.

When I am defining type Book -- unless I have to hide implementation, I
will just put the members directly in order to achieve value semantics, in
particular, I want to guarantee the following property:

Book b1 {"title", "author"};
Book b2 = b1;
Book b3 = b1;
modify(b1);
assert (b2 == b3);
assert (b2 != b1);

The shared_ptr does no seem to guarantee the last assertion. Also, there
are these additional members testing if pimpl is null, which appear
suspicious to me. How can it be null? Do I have to implement the default
constructor now? Does this also mean than in my types that I want to
pimpl-ize I cannot use operator bool for my own business-logic-related
purpose, because it is already taken by the implementation of boost::pimpl?

There may be good use cases for flyweight-like implementation, but it
should not necessarily be the first example we see in the docs.

Regards,
&rzej;