Why RAII rocks

[Nexus]

But they aren't for free. They still introduce overhead with tracking objects!

What do you mean exactly?

shared_ptr has big overhead, as a result of its reference counting, the dynamic deleters and thread-safety.

unique_ptr has no overhead. It is a simple wrapper around a raw pointer, with support for ownership transfer (using C++11 move semantics).

[Qix]

Overhead isn't just performance, although it is one of the more important facets of it.

There is also a memory cost. While it isn't significant, any smart pointer creates a tracking object; that is, an object (wrapper) to hold the raw pointer itself. Depending on the implementation, this may include a vtable as well (which probably isn't the case with STL or Boost).

That's grasping at straws though. Depending on what you do with the smart pointer, there is overhead. Only in its most basic use is it close to being free.

[cire]

While it isn't significant, any smart pointer creates a tracking object; that is, an object (wrapper) to hold the raw pointer itself.

#include <iostream>
#include <memory>

int main()
{
    std::unique_ptr<int[]> pointer(new int[32]) ;

    std::cout << "Size of pointer: " << sizeof(pointer)
              << "\nSize of int*: " <<  sizeof (int*) << '\n' ;
}

Output:
Size of pointer: 4
Size of int*: 4

Gee.  Where did they hide that tracking object?

[Qix]

Right there. That is still an object. The size is the same, and yes it's only holding the pointer destination; however, you can allocate memory in the heap without needing to hold the pointer. It obviously becomes useless, but I'm saying, there is always overhead. Of course, anything but a shared_ptr (to my knowledge) will only create a 4/8 byte pointer in memory.

[Laurent]

You guys talk a lot but this discussion isn't going anywhere

Let's summarize things. Qix is of course wrong (*) but he really likes the way he's doing things, and since he's not a beginner you won't convince him to change his habits.

(*) Smart pointers cause no overhead, thanks to inlining. It's just syntactic sugar and automatic behaviours that you would write anyway, the compiled code is the same. What they do, they do it better than any user code. If you don't think so please send a patch to the development team of your standard C++ library. And if you had a strong argument against them, you would already have provided a use case that demonstrates your point of view.

So please admit that your point of view is purely a personal taste, and let's stop this discussion that could make other people think that smart pointers can be bad. The only thing to say is "use them" -- if you need the features they provide, of course.

[Qix]

You guys talk a lot but this discussion isn't going anywhere

Let's summarize things. Qix is of course wrong (*) but he really likes the way he's doing things, and since he's not a beginner you won't convince him to change his habits.

(*) Smart pointers cause no overhead, thanks to inlining. It's just syntactic sugar and automatic behaviours that you would write anyway, the compiled code is the same. What they do, they do it better than any user code. If you don't think so please send a patch to the development team of your standard C++ library. And if you had a strong argument against them, you would already have provided a use case that demonstrates your point of view.

So please admit that your point of view is purely a personal taste, and let's stop this discussion that could make other people think that smart pointers can be bad. The only thing to say is "use them" -- if you need the features they provide, of course.

I never said they were bad, but instead often used incorrectly; I don't have to admit anything because I said from the start that not using them is a personal preference; lastly, I'm not wrong, just providing another point of view.

Sure, most types of smart pointers are almost free (nothing is ever free, laurent; you know this) and I even said saying smart pointers (with the slim exception of shared_ptr) are not 100% free is grasping straws to begin with. However, I can't ignore that there is some extra baggage that comes along when applied to a large scale. It goes back to the 'wonder drug' phenomena.

[Laurent]

I'm just trying to figure out where this discussion goes.

I never said they were bad, but instead often used incorrectly

I don't know if it's "often", but yes, they can be used incorrectly, like... anything else.
And someone who can write equally safe and performant code using raw pointers, is very unlikely to use them incorrectly anyway. Because it's much harder to write the same code with raw pointers.

I don't have to admit anything because I said from the start that not using them is a personal preference

So maybe it doesn't deserve such a discussion? If you know the advantages of RAII and smart pointers, but prefer to not use them, what else should be said?

I'm not wrong, just providing another point of view.

Sorry for that. I thought you were trying to prove that writing your own code based on raw pointers was better than using the standard smart pointers.

nothing is ever free, laurent; you know this

The classes we are talking about are free. And we are just waiting for more detailed and stronger arguments from you on this point

So, again, what's the point of this thread? (if you just want to continue what you were doing, then just tell me and I'll leave the discussion, I promise).

[Qix]

I wasn't the one who started this discussion.