正确使用std :: unique_ptr和std :: weak_ptr

Question

How do I correctly use std::unique_ptr and std::weak_ptr in this case?

struct B;
struct A
{
    B* b;
    float f;

    A(float f, B* parent)
        : f(f), b(parent)
    {}
};

struct B
{
    A a;

    B(float f)
        : a(f, this)
    {}
};

I want to create a B with auto anB = std::unique_ptr<B>(new B(3.0f)) . My guess would be that A should have a std::weak_ptr<B> b instead of the raw pointer, but to create the std::weak_ptr I need a std::shared_ptr of B ...
Should A just keep its raw pointer in this case?

Answer 1

The information provided is not enough information to solve the lifetime management problem.

You have provided some structure layouts. You have not described how the data in the structures is going to be used, nor anything much about their lifetimes.

Structure layouts does not determine lifetime , except a sane structure layout is going to be a function of the data lifetime problem.

What you have done is said "I have some red paint I want to paint a room with. What house should I buy?" Structure layout is useful to solve lifetime issues, and paint is useful to paint rooms in houses, but providing a structure layout does not tell you what smart pointers to use, and the color of house paint doesn't tell you what house to buy.

You need to think about what the lifetime of the various objects will be, and try to make that as simple as possible, and then use the smart pointers that make that management easy.

Answer 2

As A doesn't have ownership of B , a raw (non owning) pointer is ok. (but its lifetime should be longer than A ).

So currently, you have problem with default copy constructor/assignment of B/A which may make A points to old B .

For the weak_ptr , indeed, B should go in a shared_ptr instead of unique_ptr , and to allow same signature, it should inherit from std::enable_share_from_this ...

Answer 3

From our conversation in the comments it seems to me that separating concerns might be in order.

An A is an attribute of a B. There needs to be a canonical store of Bs (that controls lifetime) and there needs to be an index (non-owning) of Bs ordered by some attribute of the B (in this case, one of the As).

This argues for two vectors (or some other appropriate container), one containing Bs and the other containing sorted references to Bs.

You can of course wrap the container and index into another object to provide encapsulation (I have not done this in the trivial example below):

#include <vector>
#include <algorithm>
#include <memory>
#include <functional>

// define the attribute
struct A
{
    float f;

    A(float f)
        : f(f)
    {}
};

// define the object    
struct B
{
    A a1;
    A a2;

    // no back-pointers
    B(float f, float f2)
        : a1(f)
          , a2(f2)
    {}
};


int main()
{
  using b_vec_type = std::vector<B>;

  // build the canonical store      
  b_vec_type bs = { B { 1, 2}, B { 5, 4 }, B { 3, 4 } };

  using a1_index_type = std::vector<std::reference_wrapper<B>>;

  // build the index
  a1_index_type index(bs.begin(), bs.end());

  // sort the index by the attribute we want      
  std::sort(index.begin(), index.end(), 
            [](const B& l, const B& r) {
              return l.a1.f < r.a1.f;
            });

  // now use the index:

  for (const auto& e : index)
  {
    // do something with the Bs, ordered by B::a1
    // e will be of type std::reference_wrapper<B>, which has
    // a conversion operator to B& already defined.
  }


  return 0;
}