shared_ptr VS. intrusive_ptr?

[TriKri]

What I understand, intrusive_ptr provides better performnce than shared_ptr, but requires the type being refered to provide its own counting mechanism. I can understand that intrusive_ptr is fast and works good, if the object itself can provide that. But how does shared_ptr work? How does it know how many references there is to the same object? Or when deleted, when to delete the object being refered to? If the object being refered to cannot store the number of references, where is it sored?

[souldog]

The reference count is stored in the shared_ptr object. You can look at the source code http://www.boost.org/doc/libs/1_35_0...shared_ptr.hpp

[souldog]

I think I understand your real question.

if I do the following then a crash will result

class foo;
foo* f = new foo;
shared_ptr ptr_1(f);
shared_ptr ptr_2(f);

with shared pointer, multiple shared pointers must come from an original shared_ptr

the following code is ok

class foo;
foo* f = new foo;
shared_ptr ptr_1(f);
shared_ptr ptr_2 = ptr_1;

[_uj]

where is it sored?

In a counter allocated on the heap.

That's the reason why intrusive smart pointers are faster. They don't allocate a counter. It's supplied by the object.

[TriKri]

What's the heap? Can the program allocate from the heap?

[Graham]

You're asking about pointers and you don't know what the heap is? It's where the object that you're pointing to is allocated.

Incidentally, don't get hung up on "efficiency". I'll lay good odds that you couldn't tell the difference between the two in a real situation. The difference between them has been alluded to by souldog - intrusive reference pointers to a single object can be created independently of each other, whereas shared pointers to a single object all have to be created by copying from a single original.

[_uj]

What's the heap? Can the program allocate from the heap?

The heap is a memory where objects you allocate using the new keyword are stored.

I suggest you start by using the shared smart pointer, either the one supplied by Boost or the one from any TR1 implementation. The latter is a candidate for being included in the C++ standard library. Note that no intrusive smart pointer is suggested for inclusion. It's generally best sticking to the standard, unless you're an expert knowing exactly what you want.

[souldog]

I thought the shared_ptr being included in TR1 is just the boost shared_ptr.
Am I wrong about that?

[_uj]

I thought the shared_ptr being included in TR1 is just the boost shared_ptr.
Am I wrong about that?

Features aren't just included as is. For example the Boost shared_ptr makes some promises about its multithreading behavior. I doubt the C++ standard will maintain that.

[TriKri]

Features aren't just included as is. For example the Boost shared_ptr makes some promises about its multithreading behavior. I doubt the C++ standard will maintain that.

Multithreading behavior? Now I'm lost...

[_uj]

Multithreading behavior? Now I'm lost...

http://www.boost.org/doc/libs/1_35_0...m#ThreadSafety

[TriKri]

Features aren't just included as is. For example the Boost shared_ptr makes some promises about its multithreading behavior. I doubt the C++ standard will maintain that.

I don't see how the C++ standard would not be able to maintain the multithreading behavior. Isn't that pretty basic?

[laserlight]

I don't see how the C++ standard would not be able to maintain the multithreading behavior. Isn't that pretty basic?

I think that what _uj meant is the next edition of the C++ Standard might not guarantee such behaviour.

[souldog]

I don't see how the C++ standard would not be able to maintain the multithreading behavior. Isn't that pretty basic?

Threading is one of those features which is too OS dependent.

[TriKri]

I think that what _uj meant is the next edition of the C++ Standard might not guarantee such behaviour.

I know, but I mean, what could go wrong? How do you construct a class which does not guarantee the behavior? I can't imagine any.