Re: [boost] Should Boost adopt pimpl/d-pointer as much as it can?

Subject: Re: [boost] Should Boost adopt pimpl/d-pointer as much as it can?
From: Artyom (artyomtnk_at_[hidden])
Date: 2010-03-26 10:48:13

> 
> > 2) Any non-template based class should have
> opaque/d/pimpl pointer in its
> >   body.
> 
> I would most strongly disagree. The reason is, of course,
> efficiency. 

Ok, let it make more clear. If you want Boost to be ever stable
library as Qt, GLib, STL you need this. This would allow to extend
the class in future without breaking ABI.

I do not suggest moving every member to pimpl, I suggest to have it
in order to add new members when you need.

See this example in CppCMS class http::cookie:

Header: 

class CPPCMS_API cookie {
public:
        std::string name() const;
        std::string value() const;
....
        void name(std::string n);
        void value(std::string v);
...
        cookie();
        ~cookie();
        cookie(cookie const &);
        cookie const &operator=(cookie const &);
private:
        // for future use
        struct data;
        util::copy_ptr<data> d;

        // real members
        std::string name_;
        std::string value_;
        ...
};


And in implementation struct data is defined as struct data{};
and it is not even allocated when class created.

But, if I do want to add a new member without breaking any 
binary compatibility I can! This is very important.

So you do not have to use pimpl by default everywhere. But you 
need an option to have it.


> 
> Did you perhaps try to just move non-templated
> implementation into .cpps,
> without pimpling?
> 

No I didn't it would be too hard, ASIO is very templetized implementation,
Most of classes I implemented as template specialization (to make it
look like ASIO).

> When using precompiled headers (which is always ;) I do not
> notice any compile
> time performance hit 

You can take a look on this list and find many pros and cons against
precompiled headers. From my experience it is better to reduce size
of includes then use such headers.

Also may compilers do not support them or even not support them properly.
For exampple I had issues with GCC perecompiled headers when was using
Boost.Asio with 4.1 or even newer versions.


> 
> Hmm...this is strange...as if your compiler and linker are
> seriously 'broken' or
> 'weak' at throwing out unwanted things/merging same
> functions...If gcc has a
> 'link time code generation' option try using it...

In fact most of linkers I used do not have such thing. I mean they
know to throw unused functions but not merge two functions implemented
in different objects. If MSVC has good for him.

> 
> Qt uses pimpling for just about everything, the result (not
> nearly only because
> of that of course)

Ohhh I'm really glad you mentioned Qt... Qt is one of the finest libraries
I had used. It is totally different from Boost in they behavior.

One of the greatest things about Qt... I may compile executable for Linux
and just give it... It would run on other Linux that have Qt... I can
upgrade Qt for years and my program would run without recompilation.

Why? Qt provides stable ABI. This is one of greatest features it has!

Have you tried to distribute a compiled software liked with Boost? It is
impossible! Because Boost releases new version every few month and they
are not compatible even at API (not talking about ABI) level.

I wish Boost would learn something from Qt...

> it has grown to an unbelievably
> humongous bloated monster
> that compiles (for hours) to a size of several server OS
> kernels...

Just to mention. Have you tryed to compile full Boost? It compiles 
for hours. But forget.
What Qt brings you? GUI, Threading, Networking, XML, Webkit HTML Engine
SQL, OpenGL, and more... 2/3 of this even does not exist in Boost.


Artyom