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

Subject: [boost] Should Boost adopt pimpl/d-pointer as much as it can?
From: Artyom (artyomtnk_at_[hidden])
Date: 2010-03-20 17:49:29

Hello,

There are recently lots of discussions about current development issues.

I would like to point to one small but extremely important issue 
(from user point of view).

Boost has too many logic in header part of library, by meaning too much
I mean painfully too much.

I think that Boost should adopt as policy:

1) All implementation related code **should** be put in sources.
2) Any non-template based class should have opaque/d/pimpl pointer in its
   body.

Why? I give you a simple example: one of the pearls of Boost: Boost.Asio
is one of most painful libraries to use.

I created a simple example of echo server written with Boost.Asio
and written with a small pimpl-wrapped Boost.Asio (I had written myself
as proof of concept - that uses boost.asio in implementation):

   http://art-blog.no-ip.info/files/asio_pimpl.tar.gz

These are results of compilation times with gcc-4.3 (seconds):

       -O0    -O2   -O3   -O2+link
asio   2.56   4.65  4.96  4.75     
pimpl  0.59   0.85  0.89  0.94     
diff   *4.3   *5.5  *5.6  *5.05

And this is trivial echo server. When the code gets larger and bigger
it becomes even more painful.

For me, compilation of components based on Asio is total nightmare
because of unacceptable compilation times.

Another issue is executable size. I had took same echo sever
placed in 10 object compiled under different namespaces
once I did it with Boost.Asio and then I did it with pimpl-ed Asio.

Result (liked executable size with gcc-4.3):

Build   Size (-Os stripped)
Asio:   245K
Pimpl:  190K

----------------------------

Conclusions:
============

There are too many good libraries (Asio as good example) that
use headers too much or headers only, this terribly increases
compilation times and makes executable sizes much bigger (this
is especially relevant for embedded systems).

Should Boost wellcome pimpled libraries more? I think yes.

It would solve two problems:

1. It would give faster compilation times.
2. It would allow to provide changes easily without breaking
   compatibility (even would allow to provide backward ABI compatibility)

Dear Boosters.
What do you think about?

Artyom