Bikineev
Bikineev

Reputation: 1777

ABI in pimpl idiom with unique_ptr

My goal is to provide abi compatibility for my new library. I look toward the using of unique_ptr instead of raw pointers. But I'm afraid that if I update standard library, I may break abi. Is it true? Is there any guaranty of abi-stability for unique_ptrs in future stdlib releases?

Upvotes: 3

Views: 825

Answers (2)

Daniel Heilper
Daniel Heilper

Reputation: 1250

The problem rise when you use a custom deleter. unique_ptr (unlike shared_ptr) destructor requires knowing a complete type of the object. So you need to specify the deleter in the data member declaration:

class Foo {
private:
   std::unique_ptr <FooImpl> _pimpl;
};

When instantiating the pimpl you are constrained to using the default deleter. If you want a custom deleter, you need to specify it in the declaration

class Foo {
private:
   std::unique_ptr <FooImpl,  std::function <void (FooImpl*&)> > _pimpl;
};

However, you can't have the option to be flexible whether you want the unique_ptr d'tor to call the default delete or a custom deleter. The more flexible option is the second version, but if you choose to keep with the default behavior, then you must instantiate the unique_ptr with a specific deleter that is equivalent to the default delete.

IMO, this is a significant drawback for unique_ptr to be used for pimpl idiom.

Upvotes: 1

Nicola Musatti
Nicola Musatti

Reputation: 18218

As you can see from this blog post the problem is known and it is being addressed. As things stand now I'm afraid the best you can do is check with your compiler supplier whether they provide any guarantee (e.g. not to break ABI in minor releases).

Upvotes: 2

Related Questions