Artyom wrote:
I think pimpl should be used on by case basis, because it doesn't make sense in every library Boost has.
I agree, but I think that there should be policy that recommends doing that for relevant parts.
Just like today: Boost recommends using Boost.Test framework but it is up to library developer to decide whether it would use it or not.
For example: I do not expect from Boost.Function, Boost.Bind or Boost.Pheonix to separate implementation from interfaces.
However libraries like Asio, Thread, Regex, Interprocess and many others should.
I don't see any reason why, memory allocation algorithm of Interprocess should be in header libraries at all?
If something requires templates for flexibility, it should be in headers, but if it does not? Put it in source library and never recompile, especially when these parts of code huge and non-trivial!
If you look at the archives of this mailing list, you will see that there was a concerted effort to keep libraries header-only in order to avoid the myriad of problems involved in ensuring that boost libraries are compiled with ALL required settings to be compatible with the users' build targets. In my experience - which I think the archives mirror - header-only libraries are easier to incorporate into existing build procedures, and enjoy a higher adoption rate due to that fact. Promoting a specific solution of pimpl/d to the implied problem of compile times will bring along as many negatives as it tries to alleviate. Jeff