Reputation: 1777
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
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
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