Re: [boost] Pimpl Again?

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

On 05/31/2016 12:56 AM, Rob Stewart wrote:
> On May 30, 2016 1:42:39 AM EDT, Vladimir Batov <Vladimir.Batov_at_[hidden]> wrote:
>> On 2016-05-30 14:18, Gavin Lambert wrote:
>>
>>> it would be nice to get something like it into Boost.
>> Excellent.
> I, too, think that something that simplifies The Pimpl Idiom could be a good addition to Boost.

Thank you, Robert, for chiming in. Much appreciated. Maybe this time 
we'll be able to get enough momentum and to actually get something 
tangible out of it.

> Adding The Pimpl Idiom to a class means splitting the implements 
> across two class: one public and one private. Even then, the private 
> class is, normally nested in the public class so they are tightly 
> related. With your library, that split is carried further by splitting 
> the code across two distinct namespaces. That is, indeed, a style 
> issue, since the code still does the same work. Nevertheless it seems 
> wrong to write the implementation details of one's own class in the 
> (proposed) boost namespace. 

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.

> I've not given any thought to alternatives, so I can only criticize 
> your solution at present.

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.