Hacker News Reader

Comment by justinsb | Hacker News Reader

C++11 introduces unique_ptr, which has a lot of the same safety characteristics. Rust's syntax does seem much nicer, though.

View on HN

> C++11 introduces unique_ptr, which has a lot of the same safety characteristics.

Sure, other than not actually being safe (UB resulting from use after move of unique_ptr being an obvious one; there are many others).

Good point! Safe if used very carefully, perhaps - like most of C++.

Raw pointers are safe if used very carefully... :)

For those who might have been wondering, "UB" means "undefined behavior".

Right. C++ used to have auto_ptr, which did roughly the same thing, but didn't quite get it right. Transferring ownership was always iffy. There were, I think, three standardized versions of auto_ptr, all bad. Now there's unique_ptr, which is supposed to be better.

The lesson of C++ is that you can't bolt on safety by using templates to paper over the underlying mess. The mold always seeps through the wallpaper. The usual problem is that at some point you need raw pointers to call some API. If you can get raw pointers, the abstraction has to have a leak.

What part of that is undefined? When you move the pointer, the original becomes null..

> What part of that is undefined? When you move the pointer, the original becomes null..

Nope, the argument is "valid but unspecified" not necessarily null. And http://en.cppreference.com/w/cpp/utility/move specifically has this as an example of UB:

    std::vector<std::string> v;
    std::string str = "example";
    v.push_back(std::move(str)); // str is now valid but unspecified
    str[0]; // undefined behavior: operator[](size_t n) has a precondition size() > n

There's an other fun UB because std::move doesn't check for aliasing, so self-assignment:

    v = std::move(v);

is also an UB.

And of course even if it were null., pcwalton talks about use after null. Deref'ing a null pointer (to use it) is still an UB.

OP is correct. You've quoted the general language around move semantics but unique_ptr itself has a stronger gaurantee.

From 20.7.1

  Additionally, u can, upon request, transfer ownership to
  another unique pointer u2. Upon completion of such a
  transfer, the following postconditions hold:

  — u.p is equal to nullptr,

unique_ptr isn't what's unsafe here. Null pointers are. The difference, admittedly, is mostly semantic. There is nothing undefined about using a unique_ptr after moving unless you use the internal pointer in undefined ways.

> There is nothing undefined about using a unique_ptr after moving unless you use the internal pointer in undefined ways.

If you dereference (i.e. use) a moved unique pointer you get undefined behavior.

When talking about "using a pointer" most people mean dereferencing it, not for example comparing against null. It may be somewhat imprecise language, but it's what security people mean when they talk about "use after free", for example.

This is definitely outside the scope of my knowledge, but if you dereference a null pointer, won't you get an illegal memory access?

Undefined behavior, at least colloquially, is about dereferencing a pointer to memory that may or may not be accessed and may or may not work/crash-the-program. That's what makes it undefined and an absolute disaster to track down.

I'm pretty sure that if you try to deference memory address zero the OS will bark at you.

Again, it's not my area of expertise, so please correct me if I'm wrong

Dereferencing null is not guaranteed to do any particular behaviour; on many systems, getting the machine to actually dereference 0 will give a segfault/illegal memory access, but the compiler optimises assuming this never happens, and so can break a program that accidentally "relies" on it.

e.g.

- http://stackoverflow.com/q/6793262/1256624

- http://blog.llvm.org/2011/05/what-every-c-programmer-should-...

Dereferencing a null pointer (i.e. use) is undefined behavior.

Reply on news.ycombinator.com