Exactly as the name says, should smart pointers be exposed in a C++ library API?

I've used quite a few C++ libraries and haven't ran into exposed smart pointers yet. Given that it's very common to hear "only use smart pointers", should developers expose smart pointers in their APIs?

  • 1
    If your lib is deployed in source code and compiled as part of a project which uses it (including the same compiler & run time libs), exposing smart pointers is ok. If, however, the lib should be deployed as a precompiled binary and reused by a different toolset, you will probably need a public "extern C" API wrapper - and I am pretty sure that's getting hard to work with smart pointers (correct me if I am wrong). – Doc Brown Mar 30 '19 at 8:30
  • Most APIs should be "extern C", but if you must have a C++ API then no reason not to use smart pointers from the (shared) standard library. – david.pfx Apr 4 '19 at 13:36

There are basically two aspects of this. Smart pointers exist to define ownership of some resource. So the first question is, should your API be exposing the outside world directly to ownership issues?

That all depends on what your API is doing. If your API is allocating memory, it makes sense to wrap that in an explicit smart pointer. If your API is providing objects that internally use smart pointers to manage resources, that's a different matter. The outside world doesn't need to see the smart pointer itself.

The other issue is one of ABI. For DLL/SO-based libraries, putting any standard library type (or any type not in your library's control) into the API exposed by the library has substantial implications. Such a library can only be used by code using the exact same standard library implementation which was used to build the library. Standard library version changes can break things. Most standard library implementations will announce when an ABI break happens, but it still represents something not entirely under your control.

Coupled with this is the fact that smart pointer types tend to be header-only, so the various specific information about the type would be compiled into the DLL/SO as well as the program consuming the library. Slight differences in implementation can break things.

There's a school of thought that basically says that DLL/SO APIs should not expose any standard library type directly (with a few exceptions, like initializer_list). Now this doesn't stop you from writing your own smart pointer types and using them in your APIs.


Smart pointers are a (the) way of clarifying responsibility for cleaning up memory after use. If you think of, e.g. the factory pattern, correctly handling ownership of the created objects is difficult or needs additional documentation if smart pointers are not used.

Thus: Yes, smart pointers do have a valid place in C++ library APIs.

  • 1
    This would be a better answer if you clarified what you mean by "clarifying responsibility." Does using a smart pointer confer responsibility to the API or to the caller of the API, and how would it confer such responsibility? Given the absence of such pointers in C++ libraries (if the OP's assertion is correct), I am skeptical of your claim that such pointers are essential. – Robert Harvey Mar 29 '19 at 20:59
  • 2
    @RobertHarvey: There is no need for such clarification; a C++ programmer knows how smart pointers work, and understands the implications behind a function which returns one. It's not something that needs to be explained to someone who knows what "smart pointers" do or mean. And since the OP didn't ask about that, we can reasonably assume they know what we're talking about. – Nicol Bolas Mar 29 '19 at 21:07
  • 1
    @NicolBolas: If it were as clear as you claim, there would be no need for the question in the first place. – Robert Harvey Mar 29 '19 at 22:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.