[Boost-users] Avoiding reinventing the wheel for a public api with binary compatibility in mind

Subject: [Boost-users] Avoiding reinventing the wheel for a public api with binary compatibility in mind
From: Geoff Hilton (geoff.hilton_at_[hidden])
Date: 2009-11-04 20:16:34

I'm writing a public api for a product which will be bundled as a 
precompiled dll or binary and one of my goals is binary compatibility 
(if not across major versions, at least across minor). I'd like to 
implement the pimpl idiom and reference counting for the handle classes 
as appropriate, but I'm worried about all the typical stuff (exception 
safety, memory leaks, etc) and I'd rather not reinvent the wheel.

eg.
template<typename T>
class MyClass {
public:
T foo();
private:
boost::shared_ptr<MyClassImpl<T> > impl;
};

Using boost::shared_ptr would be great, but this means clients of my 
code would have to have the same version of boost installed that we use, 
and I imagine this could cause conflicts in the event that they happen 
to use boost (and a different version of it). I'd rather not include 
more code dependencies than I absolutely have to, especially if they may 
prove problematic in the future. What do I do? I know I'm not the first 
in this situation. How often have others opted for this dependency as 
opposed to furnishing their own alternative that would avoid additional 
dependencies (at the expense of the benefit of time-tested code)?