Re: [boost] Pimpl Again?

Subject: Re: [boost] Pimpl Again?
From: Vladimir Batov (Vladimir.Batov_at_[hidden])
Date: 2016-05-29 21:20:49

On 05/30/2016 11:02 AM, Gavin Lambert wrote:
> On 30/05/2016 12:29, Vladimir Batov wrote:
>> Again, I feel you are rushing things. Adapting doccs and putting it
>> into Boost namespace are minor issues to be addressed in due course.
>
> It would be minor if your entire design wasn't based around template 
> specialisation.  Since it is, however, it becomes a major 
> consideration since it directly impacts the primary API of the library.
>
>> On 05/30/2016 10:08 AM, Gavin Lambert wrote:
>>> (Though even being in the global namespace doesn't avoid this
>>> clunkiness, if the user classes are themselves in a non-global
>>> namespace.)
>>
>> That's something I do not understand. I have plenty of classes like:
>>
>> template<> struct pimpl<chart::panel::leg>::implementation.
>
> This can't exist inside a "namespace chart { namespace panel {" block.

You are right. It can't be inside a "namespace chart { namespace panel 
{" block... and I personally never expected it to be. After all that's a 
specialization of (assume Boost)

namespace boost
{
     template<typename user_type> pimpl { struct implementation; }
}

> If you have the convention that these blocks span the file, it means 
> you either have to put such specialisations at the top or bottom of 
> the file outside the namespace block (which may break locality) or you 
> have to close the namespace blocks and reopen them later (which is ugly).
>
> (Imagine the case where you want to define some detail classes that 
> only exist in the implementation *first*, then the pimpl definition, 
> then the public interface.  The first and last should be in the local 
> namespace [or child thereof]; the second can't be.  And they have to 
> be defined in that order due to the dependencies.)
>
> Granted implementation files don't *have* to have namespace blocks -- 
> they can use using directives or explicit naming instead; but the 
> latter is ugly and the former risks accidentally defining global 
> symbols, so it's generally safer to use namespace blocks instead.

Yes, I understand. You have your personal programming style and you feel 
the suggested pimpl does not fit that style as well as you'd like it to. 
I respect that. But I do not see it as a principal objection... is it a 
principal objection?