Nsryjdtyk

I had 2 questions regarding the std::shared_ptr control block:

(1) Regarding size:
How can I programatically find the exact size of the control block for a std::shared_ptr?

(2) Regarding logic:
Additionally, boost::shared_ptr mentions that they are completely lock-free with respect to changes in the control block.(Starting with Boost release 1.33.0, shared_ptr uses a lock-free implementation on most common platforms.) I don't think std::shared_ptr follows the same - is this planned for any future C++ version? Doesn't this also mean that boost::shared_ptr is a better idea for multithreaded cases?

(1) Regarding size: How can I programatically find the exact size of the control block for a std::shared_ptr?

There is no way. It's not directly accessible.

(2) Regarding logic: Additionally, boost::shared_ptr mentions that they are completely lock-free with respect to changes in the control block.(Starting with Boost release 1.33.0, shared_ptr uses a lock-free implementation on most common platforms.) I don't think std::shared_ptr follows the same - is this planned for any future C++ version? Doesn't this also mean that boost::shared_ptr is a better idea for multithreaded cases?

Absolutely not. Lock-free implementations are not always better than implementations that use locks. Having an additional constraint, at best, doesn't make the implementation worse but it cannot possibly make the implementation better.

Consider two equally competent programmers each doing their best to implement shared_ptr. One must produce a lock-free implementation. The other is completely free to use their best judgment. There is simply no way the one that must produce a lock-free implementation can produce a better implementation all other things being equal. At best, a lock-free implementation is best and they'll both produce one. At worse, on this platform a lock-free implementation has huge disadvantages and one implementer must use one. Yuck.

The control block is not exposed. In implementations I have read it is dynamic in size to store the deleter contiguously (and/or, in the case of make shared, the object itself).

In general it contains at least 3 pointer-size fields - weak, strong count, and deleter invoker.

At least one implementation relies on RTTI; others do not.

Operations on the count use atomic operations in the implementations I have read; note that C++ does not require atomic operatins to all be lock free (I believe a platform that doesn't have pointer-size lock-free operations can be a conforming C++ platform).

Their state is are consistent with each other and themselves, but no attempt to make them consistent with object state occurs. This is why using raw shared ptrs as copy on write pImpls may be error prone on some platforms.

(1)
Of course it is best to check implementation, however you still may make some checks from your program.

Control block is allocated dynamically, so to determine its size you may overload new operator.

Then what you may also check is if std::make_shared provides you with some optimization of control block size.
In proper implementation I would expect that this will make two allocations (objectA and control block):

std::shared_ptr<A> i(new A());

However this will make only one allocation (and then objectA initialized with placement new):

auto a = std::make_shared<A>();

Consider following example:

#include <iostream>

#include <memory>



void * operator new(size_t size) 

{ 

    std::cout << "Requested allocation: " << size << std::endl; 

    void * p = malloc(size); 

    return p; 

} 



class A {};



class B

{

    int a[8];

};



int main()

{

  std::cout << "Sizeof int: " << sizeof(int) << ", A(empty): " << sizeof(A) << ", B(8 ints): " << sizeof(B) << std::endl;

  {

      std::cout << "Just new:" << std::endl;

      std::cout << "- int:" << std::endl;

      std::shared_ptr<int> i(new int());

      std::cout << "- A(empty):" << std::endl;

      std::shared_ptr<A> a(new A());

      std::cout << "- B(8 ints):" << std::endl;

      std::shared_ptr<B> b(new B());

  }

  {

      std::cout << "Make shared:" << std::endl;

      std::cout << "- int:" << std::endl;

      auto i = std::make_shared<int>();

      std::cout << "- A(empty):" << std::endl;

      auto a = std::make_shared<A>();

      std::cout << "- B(8 ints):" << std::endl;

      auto b = std::make_shared<B>();

  }

}

The output I received (of course it is hw architecture and compiler specific):

Sizeof int: 4, A(empty): 1, B(8 ints): 32

Just new:

- int:

Requested allocation: 4

Requested allocation: 24

First allocation for int - 4 bytes, next one for control block - 24 bytes.

- A(empty):

Requested allocation: 1

Requested allocation: 24

- B(8 ints):

Requested allocation: 32

Requested allocation: 24

Looks that control block is (most probably) 24 bytes.

Here is why to use make_shared:

Make shared:

- int:

Requested allocation: 24

Only one allocation, int + control block = 24 bytes, less then before.

- A(empty):

Requested allocation: 24

- B(8 ints):

Requested allocation: 48

Here one could expect 56 (32+24), but it looks that implementation is optimized. If you use make_shared - pointer to actual object is not needed in control block and its size is only 16 bytes.

Other possibility to check the size of control block is to:

std::cout<< sizeof(std::enable_shared_from_this<int>);

In my case:

16

So I would say that the size of control block in my case is 16-24 bytes, depending on how it was created.