Re: [boost] [pimpl] Mini Review

Subject: Re: [boost] [pimpl] Mini Review
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2011-05-31 12:20:43

Vladimir Batov wrote:
> Artyom Beilis <artyomtnk <at> yahoo.com> writes:
>
> > a) Wrapping different implementation (not mine) with
> different interface
[snip]

This example, showing the before and after, is just what's needed in the documentation.

> > b) Improving compilation speed by hiding a real object behind
> >    a lighweight wrapper.
[snip]

This example, showing the before and after, is just what's needed in the documentation.

> > c) Not calling class "implementation" just because it only
> >    holds data memebers and not real implementations (AKA d-
> >    pointer)
> >
> >    Only to make adding new members not to change its sizeof
> >
> >    struct book {
> >    private:
> >      // data members - not functions.
> >      smart_ptr<data> d;
> >    };
> >
> >    So having pimpl<book>::implementation is misleading as it
> >    is only... discuonnected part of body - have data members.
>
> Applying Pimpl idiom to the book above is, uhm... err, ...makes
> no sense to me.

It isn't without sense entirely.  Avoiding calls to operator new until, and unless, needed, is beneficial.

> I'd suggest
>
> // Interface
> struct book : pimpl<book>::whatever { interface; }
> // Implementation
> template<> pimpl<book>::implementation : public data {}

Nah, it's just

struct book : public pimpl<book>::whatever
{
private:
   // data members - not functions.
};

Then, if and when the extra is needed, play with pimpl<book>::implementation.

> > Consider this case:
> >
> > statistics.h
> >
> >   class statistics {
> >   public:
> >     ...
> >     void add_new_value(double v);
> >     double std() const;
> >     double mean() const;
> >     ...
> >   private:
> >     // enough to handle standard deviation and mean values
> >     int N_;
> >     double sum_;
> >     double square_sum_;
> >
> >     // Place holder for future use
> >     // for statitics that can't be calculated with
> >     // only the values above.
> >     struct data;
> >     smart_ptr<data> d;
> >   };
> >
> > statistics.cpp
> >   ..
> >   void statistics::add_new_value(double v)
> >   {
> >     N_++;
> >     sum_+=v;
> >     square_sum_ += v*v;
> >   }
> >   ...
> >
> > In this case you keep a smart pointer just as place holder
> > not in use, the class is generally simple value type but
> > you want to keep it extensible.
> >
> > This class does not even require memory allocation (at this
> > point) But once when a new type of statistics is added the
> > "d" pointer would be in use.
> >
> > Is this valid use case or not?
>
> Yes, it is a valid use-case... poorly implemented.

IIUC, statistics can be extended with new, non-virtual member functions in a future release.  So long as the size is unaffected, then old and new clients can use the new version without change because the object's size is not affected.

The new version, however, must allocate and initialize the extra state and the new member functions would use that new state for their computations.

> I'd apply normal Pimpl idiom, i.e. I'd separate interface from
> the data/implementation; I'd hide the implementation and that
> includes
>      int N_;
>      double sum_;
>      double square_sum_;
>
> like
>
> template<> pimpl<statistics>::implementation
> {
>      int N_;
>      double sum_;
>      double square_sum_;
> };
>
> Then I'd extend pimpl<statistics>::implementation when my
> requirements change.

Sure, that works.  The down side is that the implementation object *must* be allocated on the free store from the start.  With Artyom's version, that only occurs *if* extra state becomes necessary.

> In fact, I already do exactly that. If I want to avoid memory
> allocation, then, I'd use a policy as Gottlob Frege
> suggested... but I'd keep design clean and simple.

Using SBO, things work very nicely but for one problem.  Artyom's version permits inline member functions that access the data members not in the implementation object.  Is that necessary?  It depends.

Nevertheless, Artyom's approach can be supported by leaving the implementation null until, and unless, it is needed.

IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.