7 ms·

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, upo

by lbrandy 12y ago

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.

pcwalton 12y ago
> 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.
- crantanplum 12y ago
  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
  - dbaupp 12y ago
    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://stackoverflow.com/q/6793262/1256624 - http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html http://blog.llvm.org/2011/05/what-every-c-programmer-should-...

by lbrandy 12y ago

pcwalton 12y ago

> 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.

crantanplum 12y ago
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
- dbaupp 12y ago
  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://stackoverflow.com/q/6793262/1256624 - http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html http://blog.llvm.org/2011/05/what-every-c-programmer-should-...