Boost logo

Boost :

Subject: Re: [boost] [pimpl] Mini Review
From: Gregory Crosswhite (gcross_at_[hidden])
Date: 2011-05-28 22:33:15

On 5/28/11 2:55 PM, Vladimir Batov wrote:
>> Krzysztof Czainski<1czajnik<at>> writes:
>> I just wanted to add an example...
>> I think Pimpl should have the following property:
>> a)
>> struct X
>> {
>> int f();
>> private:
>> int a_;
>> };
>> b)
>> struct X : public pimpl<X>::value_semantics
>> {
>> int f();
>> };
>> The user of class X should not be able to tell the difference between a) and
>> b).
>> X x;
>> Now in this case the user can tell the difference. In b) he can do x.null(),
>> but in a) he can't. So Pimpl changes the interface. And that's what I want
>> to avoid. Pimpl or no Pimpl, the interface of X should stay the same.
> 1) I firmly believe that the insistence on no difference between a) an b) is
> misguided. You are applying a programming pattern/idiom and you reap the
> benefits of that applications.
> 2) That said I do see your desire to deny x.null() to the user. I'd be
> interested to know why you are not noticing/satisfied with the obvious solution
> struct X : pimpl<X>::value_semantics { ...}

Again, I don't see why we can't have it both ways by letting the user
mix and match what operations they want. Use virtual inheritance so
that the user can call the pimpl base constructor directly, and then use
either multiple inheritance or base class daisy-chaining to let the user
select whatever operations they want. This also creates an
infrastructure for us to add new operations such as operator[],
operator(), user-defined operators* and operator->, etc., which can
additional be mixed in to the interface.


Boost list run by bdawes at, gregod at, cpdaniel at, john at