4

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?

Improve this question
2
  • 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
    Commented Mar 30, 2019 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
    Commented Apr 4, 2019 at 13:36

2 Answers 2

Reset to default
6

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.

Improve this answer
-2

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.

Improve this answer
3
  • 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
    Commented Mar 29, 2019 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
    Commented Mar 29, 2019 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
    Commented Mar 29, 2019 at 22:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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