My 2c: In foo.h, instead of class foo { class pimpl pimpl * p_; public: foo(); ~foo(); void do_something(); }; It's better to do it the C way: simply leave foo incomplete: struct foo; foo * create_foo(); void destroy_foo( foo * ); void do_something( foo * ); The above is much improved using shared_ptr: struct foo; shared_ptr<foo> create_foo(); void do_something( foo * ); Emil On Fri, May 27, 2016 at 10:41 PM, Vladimir Batov < Vladimir.Batov@constrainttec.com> wrote:
Don't laugh but it is only fairly recently at work that I managed to move all our supported platforms to C++11. So, then, I started moving our code to C++11 (what a delight!) and stumbled upon my old pimpl which is used quite a bit around my workplace for all its good properties... :-)
Now C++11-ed piml turned out to be very small and very basic. So basic it felt it did not have the right to exist. Still, it encapsulates and enforces the "proper" pimpl properties and behavior, reduces implementation minutia and offers a recognizable deployment pattern (helps other people reading the code).
Over the years IMO the technique has been proven as legitimate and useful, a basic but important building block... rather than a curiosity item. Unfortunately, despite many articles and a few Sutter's GotWs about it there is nothing ready-to-go like std::unique_ptr.
I feel that pimpl and its deployment pattern need to be codified, described, "standardized" and in our toolboxes to stop/avoid everyone re-inventing the pimpl and making the same mistakes. IMO Boost is best positioned for that.
Do you think we might review what I've got and/or maybe collectively come up with something better... It's no MPL or Hana but as std::unique_ptr it's one of the first "little things" I personally reach out for in my everyday work. IMO having pimpl in Boost would save quite a few hours of frustration for many.
Thoughts? No pressure. I am easy either way. :-)