What about memory leaks?

[shadowmouse]

That's a nice bit of reductio ad absurdum there. Waiting until someone makes mistakes by not using smart pointers doesn't mean that everyone who didn't use them made mistakes. It means it is possible and therefore you might make a mistake by not using them. If you want examples of try-catch with memory management look at this http://www.bromeon.ch/articles/raii.html Also, in my experience smart pointers can act exactly as normal pointers and when you're using unique_ptr they have no overhead so I can see no reason not to use them except disliking change. And yes, unique_ptr<int> isn't of type int, but neither is int*. Both use the same operators to access the data they point to but unique_ptr has other functions which can be useful. You can even access the underlying pointer directly if you want to.

[Jabberwocky]

That's a nice bit of reductio ad absurdum there.

I think your reductio ad absurdum is a strawman. 
Heh, actually I get why you're saying that, but it's really this simple.

Rosme said this:

I can't do anything but wait until you have an issue with your pointers.

...obviously implying issues was either likely or practically inevitable.

My response refuted this - that it is neither likely nor practically inevitable.

I'm pretty sure that's all either of us meant.

Waiting until someone makes mistakes by not using smart pointers doesn't mean that everyone who didn't use them made mistakes. It means it is possible and therefore you might make a mistake by not using them.

You can't write a line of C++ code without possibly making a mistake.  Of course mistakes can be made.  All C++ programmers have a toolbox and mental process to address this.  Mine is different than yours.  That doesn't make me incorrect.

shadowmouse, the rest of your post mostly repeats arguments that have already been made, and already responded to.  (I don't blame you for that, it's getting to be a long thread.)  We did give some reasons for not using smart pointers - there's more to it than disliking change.  We did give some reasons why those exception/memory leak examples are not a real issue.  But you'll have to critique that stuff if you want to cover some new ground here, instead of just talking in circles.

Either way, thanks for chiming in!

[shadowmouse]

Morko did ask for examples of code involving exceptions so the main point of my post was the link. But I'd still say that waiting until you have a problem means it only really because benficial if you have a problem, which may or may not happen.

EDIT: Also,

Every C program must be a horrible leaking mess right?

is reductio ad absurdum because it was never said that all programs with smart pointers have mistakes in them and the extrapolation that because smart pointers can stop issues, not having them means there must be issues is illogical.

[Jesper Juhl]

I expected there would be more resistance to storing a secondary raw pointer to a unique pointer (edit - sounds like Jesper would be against this approach).  It's not really "unique" then.  But agree in this case it would work.

I wouldn't be opposed to obtaining a raw pointer to a unique_ptr (or rather; a raw pointer to what the unique_ptr points to), not even to passing it around, as long as it is clear that the raw pointer is not owning the resource pointed to, but merely inspecting/using it. It's all about ownership semantics.

[Mörkö]

Every C program must be a horrible leaking mess right?

is reductio ad absurdum because it was never said that all programs with smart pointers have mistakes in them and the extrapolation that because smart pointers can stop issues, not having them means there must be issues is illogical.

That line was a joke, not a serious argument, which is why it should seem absurd if you take it seriously.

And yes, unique_ptr<int> isn't of type int, but neither is int*. Both use the same operators to access the data they point to but unique_ptr has other functions which can be useful. You can even access the underlying pointer directly if you want to.

That's all true, but the argument here is that it does not merely represent the address of he object, but also brings in a whole bunch of new rules that the programmer must reason about. And also, it changes the memory management mechanism in a way which some of us find undesirable.

[Nexus]

There's so much half-knowledge and plain wrong statements in this thread. "Unique pointers have overhead", "using manual memory management is a matter of taste", "exceptions are not a real issue" and so on. Please stop spreading myths. Beginners read this and are misled all the time, contributing to the main reason why most C++ code is still terrible in 2015.

A while ago I compiled a pretty exhaustive list of arguments for RAII. You can read the article here:
www.bromeon.ch/articles/raii.html

[ChronicRat]

Thanks, Nexus, great "debriefing".