为什么std :: find在std :: shared_ptr上不起作用

Question

We came across something we can not explain at work, and even if we found a solution, i would like to know exactly why the first code was fishy.

Here a minimal code example :

#include <iostream>
#include <memory>
#include <vector>
#include <algorithm>

int main() {

    std::vector<std::shared_ptr<int>> r;

    r.push_back(std::make_shared<int>(42));
    r.push_back(std::make_shared<int>(1337));
    r.push_back(std::make_shared<int>(13));
    r.push_back(std::make_shared<int>(37));

    int* s = r.back().get();

    auto it = std::find(r.begin(),r.end(),s); // 1 - compliation error
    auto it = std::find(r.begin(),r.end(),std::shared_ptr<int>(s)); // 2 - runtime error
    auto it = std::find_if(r.begin(),r.end(),[s](std::shared_ptr<int> i){
    return i.get() == s;}
    ); // 3 -works fine

    if(it == r.end())
        cout << "oups" << endl;
    else
        cout << "found" << endl;    

    return 0;
}

So what i want to know is why the find are not working.

1. For the first one, it seems that shared_ptr do not have a comparison operator with raw pointers , can someone explain why ?
2. The second one seems to be a problem of ownership, multiple delete (when my local shared_ptr goes out of scope it delete my pointer), but what i don't understand is why the runtime error is during the find execution, the double delete should happen only on the vector destruction, any thoughts ?

I have the working solution with the find_if so what i really want is to understand why the first two are not working, not another working solution (but if you have a more elegant one, feel free to post).

Answer 1

For the first one, it seems that shared_ptr do not have a comparison operator with raw pointers, can someone explain why ?

Subjective, but I certainly don't consider it a good idea for shared pointers to be comparable to raw pointers, and I think the authors of std::shared_ptr and the standard's committee agree with that sentiment.

The second one seems to be a problem of ownership, multiple delete (when my local shared_ptr goes out of scope it delete my pointer), but what i don't understand is why the runtime error is during the find execution, the double delete should happen only on the vector destruction, any thoughts ?

s is a pointer to an int that was allocated by make_shared as part of a block, together with the reference counting information. It's implementation defined how it actually was allocated, but you can be sure it was not with a simple unadorned new expression, because that would allocate a seperate int in its own memory location. ie it was not allocated in any of these ways:

p = new int;
p = new int(value);
p = new int{value};

Then you passed s to the constructor of a new shared_ptr (the shared_ptr you passed as an argument to std::find ). Since you didn't pass a special deleter along with the pointer, the default deleter will be used. The default deleter will simply call delete on the pointer.

Since the pointer was not allocated with an unadorned new expression, calling delete on it is undefined behavior. Since the temporary shared_ptr will be destroyed at the end of the statement, and it believes it is the sole owner of the integer, delete will be called on the integer at the end of the statement. This is likely the cause of your runtime error.

Try the following, easier to reason about snippet, and you will likely run into the same problem:

auto p = std::make_shared<int>(10);
delete p.get();  // This will most likely cause the same error.
                 // It is undefined behavior though, so there
                 // are no guarantees on that.

Answer 2

The smart pointer class template std::shared_ptr<> only supports operators for comparison against other std::shared_ptr<> objects; not raw pointers. Specifically, these are supported in that case:

operator==    - Equivalence
operator!=    - Negated equivalence
operator<     - Less-than
operator<=    - Less-than or equivalent
operator>     - Greater-than
operator>=    - Greater-than or equivalent

Read here for more info

Regarding why in the first case, because it isn't just a question of value ; its a question of equivalence. A std::shared_ptr<> cannot be considered equivalent or comparable to a raw address simply because that raw address may not be held within a shared pointer. And even if the addresses are value equivalent, that doesn't mean the source of the latter came from a properly reference-counted equivalence (ie another shared pointer). Interestingly, your second example exposes what happens when you try to rig that system.

Regarding the second case, constructing a shared pointer as you are will proclaim two independent shared pointers having independent ownership of the same dynamic resource. So ask yourself, which one gets to delete it ? Um... yeah. Only when you replicate the std::shared_ptr<> itself will the reference count material shared among shared pointers holding the same datum reference be properly managed, so your code in this case is just-plain wrong .

If you want to hunt a raw address down in a collection of shared pointers, your third method is exactly how you should do it.

Edit: Why does the ownership issue in case 2 render where it does?

Ok, I did some hunting, and it turns out its a runtime-thing (at least on my implementation). I would have to check to know for sure if this behavior (of std::make_shared ) is hardened in the standard, but I doubt it). The bottom line is this. These two things:

r.push_back(new int(42));

and

r.push_back(std::make_shared<int>(42));

can do very different things. The former dynamically allocates a new int , then send its address off to the matching constructor for std::shared_ptr<iint> , which allocates its own shared reference data that manages referencing counting to the provided address. Ie there are two distinct blocks of data from separate allocations.

But the latter does something different. It allocates the object and the shared reference data in the same memory block , using placement-new for the object itself and either move-construction or copy-construction depending on what is provided/appropriate. The result is there is one memory allocation, and it holds both the reference data and the object, the latter being an offset within the allocate memory. Therefore the pointer you're sending to your shared_ptr did not come from an allocation return value.

Try the first one, and i bet you'll see you're runtime error relocate to the destruction of the vector rather then the conclusion of the find.

Answer 3

1. bool operator ==(const std::shared_ptr<T>&, const T*) doesn't exist.

2. It is a bad usage of std::shared_ptr it is like you do:

    int* p = new int(42); std::shared_ptr<int> sp1(p); std::shared_ptr<int> sp2(p); // Incorrect, should be sp2(sp1) // each sp1 and sp2 will delete p at end of scope -> double delete ...