Boost logo

Boost :

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 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

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