Why do C++ libraries and frameworks never use smart pointers?c++


There can be many reasons. To list few of them:

  1. Smart pointers became part of standard just recently. Till then they were part of other libraries
  2. Their primary use is to avoid memory leaks; many libraries don't have their own memory management; Generally they provide utilities and APIs
  3. They are implemented as wrapper, since they are actually objects and not pointers. Which has additional time/space cost, compared to raw pointers; The users of the libraries may not want to have such overheads

Edit: Using smart pointers is a completely developer's choice. It depends on various factors.

  1. In performance critical systems, you may not want to use smart pointers which generates overhead

  2. The project which needs the backward compatibility, you may not want to use the smart pointers which has C++11 specific features

Edit2 There is a string of several downvotes in the span of 24 hours because of below passage. I fail to understand why the answer is downvoted even though below is just an add-on suggestion and not an answer.
However, C++ always facilitates you to have the options open. :) e.g.

template<typename T>
struct Pointer {
#ifdef <Cpp11>
  typedef std::unique_ptr<T> type;
  typedef T* type;

And in your code use it as:

Pointer<int>::type p;

For those who say that a smart pointer and a raw pointer are different, I agree with that. The code above was just an idea where one can write a code which is interchangeable just with a #define, this is not compulsion;

For example, T* has to be deleted explicitly but a smart pointer does not. We can have a templated Destroy() to handle that.

template<typename T>
void Destroy (T* p)
  delete p;
template<typename T>
void Destroy (std::unique_ptr<T> p)
  // do nothing

and use it as:


In the same way, for a raw pointer we can copy it directly and for smart pointer we can use special operation.

Pointer<X>::type p = new X;
Pointer<X>::type p2(Assign(p));

Where Assign() is as:

template<typename T>
T* Assign (T *p)
  return p;
template<typename T>
... Assign (SmartPointer<T> &p)
  // use move sematics or whateve appropriate


I read in a few articles that raw pointers should almost never be used. Instead they should always be wrapped inside smart pointers, whether it's scoped or shared pointers.

However, I noticed that frameworks like Qt, wxWidgets and libraries like Boost never return nor expect smart pointers, as if they were not using them at all. Instead, they return or expect raw pointers. Is there any reason for that? Should I stay away from smart pointers when I write a public API, and why?

Just wondering why smart pointers are recommended when many major projects seem to avoid them.

Is C++11 (C++0x) a complete super set of C++03?

Is there any feature/facility which is a valid C++03 but not working in C++11 ?

There are few incompabilities :

  • export template is removed (not deprecated, really removed)
  • you can't use auto as storage specifier anymore
  • there are new reserved words : alignof, char16_t, char32_t, constexpr, decltype, noexcept, nullptr, static_assert and thread_local

also, for future versions :

  • std::auto_ptr is deprecated
  • throw specifications are deprecated

Maybe I'm missing others, but if your code uses those, you'll have to fix it.

Almost all C++2003 features still are the same or are more precisely specified for compiler implementations in C++2011.

Returning pointers to heap objects without smart pointers

One idea is to return a reference:

class PacketMedium {
   IPacket &receivePacket();
   IPacketImpl1 impl1;
   IPacketImpl2 impl2;

The receivePacket should be implemented in the following way:

IPacket &receivePacket() {
  int data = receiveint();
  if (data==0) { // impl1
      float data = receivefloat();
      impl1.data = data;
      return impl1;
  } else { // impl2
      std::string data = receivestr();
      impl2.str = data;
      return impl2;

Note that there will be some ground rules when using the reference:

  1. Calling receivePacket() twice is dangerous. The 2nd call to it might erase existing data.
  2. The data you receive should be immediately used. Storing IPackets for longer time is dangerous.

To fix these problems, you could implement new function to IPacket interface:

virtual IPacket *clone() const=0;

Another solution is "handles". Instead of unique_ptr<IPacket> reveivePacket() you could wrap the unique_ptr to a type like this:

struct IPacketHandle { int id; };
IPacketHandle receivePacket();

But then where is packets stored? It would be inside std::vector<IPacket*> vec, but it's internal to your code. Then dovec.push_back(new IPacketImpl1); handle.id = vec.size()-1;. Note that deleting items from the vector might be more complicated/should replace the object with NULL pointer.

But wait, now you lost IPacket interface's read/write functions. Need to add them again:

void read_packet(IPacketHandle h, ...) { vec[h.id]->read(...); }
void write_packet(IPacketHandle h, ...) { vec[h.id]->write(...); }

(I've used this solution successfully in a library, and it gives nice functional programming interface similar to haskell's standard library, where there is no memory management for library users at all) (also the location of std::vector needs to be consiudered carefully, so that global variables dont need to be used)