Re: [boost] A Pimpl variant

Subject: Re: [boost] A Pimpl variant
From: Vicente Botet Escriba (vicente.botet_at_[hidden])
Date: 2010-04-02 03:38:24

Gottlob Frege wrote:
> 
> On Thu, Apr 1, 2010 at 4:13 PM, vicente.botet <vicente.botet_at_[hidden]>
> wrote:
>> Hi,
>>
>> I don't know if this is the correct ML to talk about this subject, but as
>> there was recently a discussion about wether Boost should or not use
>> Pimpl, I have decided to post this here.
>>
>> In http://www.gotw.ca/publications/mill05.htm H. Sutter
> 
>> My experience is that I add more private member functions than private
>> member data. I have explored a different variant
>> 5. Â  Â  Â  Â  Put all private funtion and static data (but not instance
>> data) into XImpl. XImpl needs only to store the back pointer.
>>
>> Â While this approach doesn't encapsulates all the private members has
>> some advantages:
>> * The XImpl class has no inherent instance data, so  no space overhead
>> * The class doesn't needs to store any XImpl pointer as there is no data
>> to maintain, so no need to allocate/deallocate it.
>> * Reduce the performance overhead of the Pimpl idiom.
>>
>> The drawbacks are:
>> * Need to include the headers needed for the private instance data.
>> * There is yet a minimal performance overhead on the construction of the
>> temporary XImpl class and the derreference of the back pointer.
>>
> 
> I must be missing something.  In '5' what is left of Pimpl that is
> worthwhile?  ie I think I understand the usual benefits of Pimpl -
> data hiding, changing instance data without changing the h file and
> forcing client compiles, etc.  Aren't all these benefits lost?  What's
> left.
> Alternatively, how is 5 better than a normal C++ class with no Pimpl?
> Is this an April Fool's thing? :-)
> 
> 
No, this is not a April Fool. :(

5 can not be considered really a Pimpl as there is not pointer as such. As I
said even if no instance data hiding is provided by this variant it provides
function hiding. I have used it to implement the Methods for state pattern
on which there are a lot of internal function for each transition between
states. A  change in the implementation of the FSM means adding removing
transition which means modifying the class interface. The variant I purpose
avoid changing the header file in this case.

Gottlob Frege wrote:
> 
> 
> 
> By the way, although Herb Sutter warns against it in that same
> article, I've experimented with a 'Reckless' Pimpl that stores the
> data (typelessly) in the class:
> 
> class C {
>    struct impl; // forward declare
>    RecklessPimpl<impl, 24> pimpl;
> };
> 
> so RecklessPimpl becomes the storage for struct impl.  Since the size
> is not known, you supply it (eg 24).
> 
> Now, there are obvious dangers to this, and Herb's article lists them.
>  Surprisingly, I think I've managed to work around them all.
> 
> ie
> - once in the cpp implementation file for class C, you can check that
> the size is OK:
>    static_assert(sizeof(impl) == sizeof(Pimpl));  // or can use <=
> - alignment can also be assured
> 

How? Does you RecklessPimpl class have an alignment parameter?

Gottlob Frege wrote:
> 
> - the constructor for RecklessPimpl can properly construct impl with
> inplace new
> - etc
> 
> All this can be automatic in the template of RecklessPimpl, thus it
> isn't really so reckless after all.
> 
> The resulting Pimpl is like a smart pointer in that calls to the impl
> look like pointer calls:  pimpl->function(); etc.
> 
> Of course if sizeof(impl) is increased too much, the h file needs to
> change and clients need to recompile, but it still minimizes the
> effects of changes, and hides private implementation details.
> 
> My main use was to avoid things like windows.h, which tends to screw
> up code if it is only included _sometimes_  (ie it is more of an all
> or nothing thing!).  Like so:
> 
>    struct CRITICAL_SECTION; // forward declared instead of #include
> <windows.h>
> 
>    RecklessPimpl<CRITICAL_SECTION, 32> csPimpl;
> 
> Which worked well because the sizeof(CRITICAL_SECTION) didn't change.
> 
> If anyone was really interested, I could probably submit it to boost
> when I find a bit more time (post-BoostCon).
> Tony
> 
> 

Waiting for a proper Boost submission maybe you can share with us, which of
the warnings H. Sutter  signal against RecklessPimpl do you solve with your
implementation (alignment been the most important issue to me). 

Could you share also your implementation.

Best,
Vicente
-- 
View this message in context: http://old.nabble.com/A-Pimpl-variant-tp28113118p28116567.html
Sent from the Boost - Dev mailing list archive at Nabble.com.