通过shared_ptr共享类内存

Question

I want to share object memory between different objects (eg Reader/Writer access same memory pool). It works quit good but I have a problem with sharing one shared_ptr.

struct A {
  A() {}

  A(const A &other) {
    i = other.i;
  }

  std::shared_ptr<int> i;
};

struct B : public A {
  B(const A &other) : A(other) {}
};

I would like to get the second example to work, but it throws an exception. Because the variable i is not initialized and the shared_ptr does not get copied (he is empty).

{ // don´t throw
    A a;
    a.i = std::make_shared<int>(10);

    B b(a);
    *b.i = 11;

    printf("%d\n", *a.i);
}  
{ // throw
    A a;
    B b(a);

    b.i = std::make_shared<int>(10);
    printf("%d\n", *a.i);
}

Only B should init variable i.

One solution would be following, but do I really need an other wrapper class?

struct A {
  A() : i(std::make_shared<std::vector<std::shared_ptr<int>>>()) {}

  A(const A &other) {
    i = other.i;
  }

  std::shared_ptr<std::vector<std::shared_ptr<int>>> i;
};

struct B : public A {
  B(const A &other) : A(other) {}
};

int main(int argc, char *argv[]) {

  { // throw
    A a;
    B b(a);

    b.i->emplace_back(std::make_shared<int>(10));
    printf("%d\n", *a.i->at(0));
  }
}

Another example would be just to use raw pointer but I want to ask you, how it could work with a shared_ptr.

The type int is just an example. It could also be an heavy class without default constructor.

Answer 1

Your first scenario

Your code throws, because:

• when you create a , ai is an empty shared_ptr
• then you create b with a constructor copying a . So bi is then an empty shared_ptr
• then you assign a shared pointer to a newly created object to bi . But this doesn't change the ai pointer, which is still empty.
• finally you try to dereference ai . But as ai is empty, ie has a usage count of 0 and no valid pointer, it's undefined behaviour (probably a segfault will happen).

Improvement of first scenario:

You could easily avoid this pitfall by defining the default constructor of A:

    A() : i(std::make_shared<int>(0)) {}

a and b would then point to the same shared object, and you wouldn't experience the segfault.

But this approach doesn't of course prevent that someone reassigns bi to another shared pointer. That's the problem with the struct : you give the key to the house and it's up to you to clean the mess.

An improved variant could be a completely encapsulated class, where i would be protected and functions or operator give access to i. I choose a way where I overload assignment form int and converion to int, to allow an intuitive usage, but this is a matter of taste:

class A {
public:
    A() : i(std::make_shared<int>(0)) {}
    A(const A &other) { i = other.i; }
    operator int() { return *i; }   // you can use A when you could use an int
    A& operator= (int x) {
        *i = x;
        return *this;
    }
    // todo:  copy assigment:  take the pointer or take the value ? 
protected:
    std::shared_ptr<int> i;
};
struct B : public A {
    B(const A &other) : A(other) {}
    B& operator= (int x) {
        *i = x;
        return *this;
    }
    // todo:  copy assigment:  take the pointer or take the value ? 
}; 

The usage of this class would then be:

{ // don´t throw
    A a;
    a = 10;
    B b(a);
    b = 11;
    printf("%d\n", (int)a);
}
{ // don't throw either
    A a;
    B b(a);
    a = 1; 
    cout << a <<endl; 
    cout << b << endl;
    b = 10; 
    printf("%d\n", (int)a);  // to make sure that only the int value is passed
}   

Your second scenario

In this scenario, you've changed to use a shared pointer to a vector of shared pointer.

I can see no problem with this code and I've experienced no throwing: see online demo

Your other thoughts

You can of course work with raw pointers, provided they've been properly allocated with new.

int *pi = new int(1); 
shared_ptr<int> spi(pi); 

But attention: once you do this, the shared_ptr has ownership. THis means that the shared_ptr becomes responsible for the destruction of the object.

If you would reuse this raw pointer in another shared_ptr (or worse: if it was obtained from a shared_ptr), your compiler would'nt complain, but you'd get undefined behaviour at runtime, because when the the second shared_ptr would try to destroy an object that was already destroyed by the first shared_ptr (shared_ptr won't be aware of existance of other shared_ptr if constructed from a raw pointer).