Re: [boost] Pimpl Again?

Subject: Re: [boost] Pimpl Again?
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2016-05-30 19:45:05

On 31/05/2016 09:37, Vladimir Batov wrote:
> Yes, I hear you. And, yes, from a certain angle that might seem wrong...
> On the other hand, from a certain angle anything might seem wrong... :-)
> Is it a serious design flaw? I personally do not think so. More so, I
> personally see it from a different angle. Namely, I read the code below
> as "Book is declared as a pimpl; then I define the implementation of
> that pimpl-Book". Seems sensible and even natural:
>
> struct Book : public pimpl<Book>::shared {};
>
> template<> pimpl<Book>::implementation {};
>
> So, when it is simply read (rather than mechanically dissected) it does
> not seem that wrong at all... to me :-)
>
> The "boost::" prefix may or may not be explicitly present... It is up to
> coder's preferences and style.

The trouble is that the syntax you've written above is not legal C++. 
In order to provide the implementation of the impl class (assuming that 
pimpl is in the boost namespace), it *must* be done thusly:

// close any other namespace blocks first
namespace boost
{
     template<> struct pimpl<other::ns::Book>::implementation
     {
         ...
     };
}

In particular it is *not* legal to use a boost:: prefix (or even to 
leave it unprefixed in the presence of a "using namespace boost") -- you 
have to put it in a namespace block.  Otherwise you are declaring a new 
type in a different namespace, not specialising the existing template.

This is the part that makes it feel like you're actually implementing 
your class (or at least its private members, anyway) in the boost 
namespace, and that feels wrong (unless you're a boost library author of 
course).

(You're probably going to say that feelings are style decisions again, 
which is true -- but it's still important.)

> Thank you for mentioning it. I'll hijack your prop to re-iterate that I
> very much hope we all can keep the discussion *constructive* and
> ultimately moving forward. That IMO means picking the best available
> solution... and "no solution" is not one of the choices. I am sure we'll
> never get anything that everyone likes. However, a solution is immensely
> better than no solution. IMO it's important that we get *something*
> in... The seed that the library will grow, mature, improve from. We have
> plenty of libs that went through several incompatible changes... It did
> not make them worse. It made them better. I am not sure if all those
> improvements (for everyone's benefits) were possible if those libs did
> not have the visibility, exposure and scrutiny which come with the Boost
> tag.

I agree -- but using template specialisation or not is a fundamental 
design decision.  It's not possible to incrementally improve it later, 
only to tear it out and replace it with something different.  My point 
is that if we can figure out what that something different should be, 
then now is the best time to make that change, before it gets users 
whose code would break from changes.

Exactly what that change would look like, I'm not sure; I'm hoping that 
others will provide feedback and suggestions on this point.

One possibility is that the template specialisation could just be for a 
traits type that provides a typedef for the "real" implementation class. 
  Not sure whether that really improves anything though; it might just 
make it more wordy.