Re: [boost] Pimpl Again?

Subject: Re: [boost] Pimpl Again?
From: Vladimir Batov (Vladimir.Batov_at_[hidden])
Date: 2016-05-30 20:42:00

On 05/31/2016 09:45 AM, Gavin Lambert wrote:
> 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).

OK. Clearly in my code it is not in the boost namespace for obvious 
reasons... Now, we can over-dramatize things indefinitely but what 
ultimately matters to me is if the thing works for me. If you insist 
that the world will end if pimpl is not in the boost namespace, then 
I'll probably disagree. For those who'll go shirtless unless a shirt has 
the Gucci tag or it must be inside the boost namespace I do the 
following (just tested with gcc-4.8):

template<class user_type>
struct pimpl // It's outside boost! We all gonna die.
{
}

namespace boost
{
     // Hmm, we might probably survive after all.
     template<class user_type> using pimpl = ::pimpl<user_type>;
}

// Look, ma! It all is in the boost namespace. It feels so good.
struct Base : public boost::pimpl<Base>::shared { ... };

template<>
struct boost::pimpl<Book>::implementation {...};

>
>> 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. 

I personally love those "I agree -- but". If "we agree", we move 
forward. If "we agree but", we stay where we were and keep arguing. That 
is, it's essentially "I disagree", isn't? :-)

 From my experience "template specialisation" is essential to create a 
*unique type*.

> It's not possible to incrementally improve it later, only to tear it 
> out and replace it with something different. 

If it has to be "tear and replace", so be it. People did that for Boost 
libs and the Standard. We all adjusted and moved on.

> 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.

I hear you. Not to be rude but I am still waiting for "that something 
different" to consider. Without it it's a one-way endless and unfair 
game -- you have all the fun criticizing, I sweat trying to make you happy.

As for the "best time", then I feel you tend to over-dramatize 
unnecessarily. If we offer something to wide audience (as part of 
Boost), that wider audience will evaluate the design with everything 
else following. If that means the current-design acceptance, good. If 
that means coming up with something better, even better. Seems like 
win-win for everyone. Don't you agree?