Re: [boost] Pimpl Again?

Subject: Re: [boost] Pimpl Again?
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2016-05-29 22:32:00

On 30/05/2016 13:20, Vladimir Batov wrote:
> 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; }
> }

Right.  And to users, this is going to feel like defining their types 
(at least the private members, possibly even some method 
implementations) inside the boost namespace -- and that feeling isn't 
entirely wrong.

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

I don't think it's a personal programming style issue.  I think it's a 
natural consequence of writing code in the non-global namespace.

I suppose you could consider writing code not in the global namespace as 
a personal style choice, but at least for library code (which is the 
most likely to want to use pimpl style so they can avoid ABI breakage 
with applications) this is the encouraged style.  Certainly most (all?) 
of STL and Boost is itself not in the global namespace.

So (at least in my opinion), the primary users of Pimpl will probably be 
library developers who want to write code in custom namespaces.  But 
they can't use Pimpl without breaking out of their namespace and writing 
some code in the global/boost namespace instead.  This is a code 
uglification that seems like it should be a principal objection -- if 
that doesn't count, what does?

(Some app authors will want to use Pimpl as well of course -- which has 
the same issues if the namespaces don't match.)