3 ms·

Not sure I like this pointer. Copying a pointer should not be a heavyweight operation. That is pretty well established. I wish C++ had a unique_ptr without the

Not sure I like this pointer. Copying a pointer should not be a heavyweight operation. That is pretty well established. I wish C++ had a unique_ptr without the ability to be null. But that does not seem possible given that moving from a pointer must give a valid object.

entelechy 9y ago
If you don't copy the resource then you are sharing it. This means you'll have reference semantics and every instance operates on the same resource. Value_ptr implements value semantics and so it behaves like primitives.
- masklinn 9y ago
  > If you don't copy the resource then you are sharing it. I think their point is more that the copy has an arbitrary complexity, so while you think you're copying a smart pointer you're triggering a possibly huge cascade behind the scenes. > This means you'll have reference semantics and every instance operates on the same resource You could have an explicit copy operation on an otherwise move-semantic smart pointer. No sharing, and while you get the ability to copy stuff if necessary it's not potentially hidden behind every argument passing or assignation, it becomes a very deliberate operation.
beached_whale 9y ago
All the standard says is that the state is valid. It would come at a space cost I guess though.
stinos 9y ago
not_null style classes might be what you're after, e.g. https://github.com/Microsoft/GSL/blob/master/include/gsl/gsl#L74 https://github.com/Microsoft/GSL/blob/master/include/gsl/gsl.... Whan trying to store nullptr in it at runtime that will result in an exception or abort or whatever it's implemented like. Depending on the usecase, it's still better than manually checking for nullptr though. moving from a pointer must give a valid object Yes (well, actually it's state is 'valid but unspecified') but afaik performing any operations having preconditions on moved-from objects is undefined behaviour anyway so you shouldn't even be doing that. And when using not_null that would again result in an exception.
masklinn 9y ago
> Not sure I like this pointer. Copying a pointer should not be a heavyweight operation. That is pretty well established. An alternative option would be a unique_ptr subtype (or extension) which allows cloning if the wrapped type is clonable, something similar to rust's impl<T> Clone for Box<T> where T: Clone Can that be expressed without concepts?
- petters 9y ago
  Yes, but it is a bit awkward. You can can separate implementations depending on whether T has a particular member function. I need to look up how every time, though.
  - masklinn 9y ago
    > You can can separate implementations depending on whether T has a particular member function. Separate implementation, but not separate interface? The Rust bit means Box is "transparently" clonable, meaning it only implements the clone trait(/interface) if the value it wraps also does, trying to clone a Box<T> where T can not be cloned would be a compile-time error.

entelechy 9y ago

If you don't copy the resource then you are sharing it. This means you'll have reference semantics and every instance operates on the same resource. Value_ptr implements value semantics and so it behaves like primitives.

masklinn 9y ago
> If you don't copy the resource then you are sharing it. I think their point is more that the copy has an arbitrary complexity, so while you think you're copying a smart pointer you're triggering a possibly huge cascade behind the scenes. > This means you'll have reference semantics and every instance operates on the same resource You could have an explicit copy operation on an otherwise move-semantic smart pointer. No sharing, and while you get the ability to copy stuff if necessary it's not potentially hidden behind every argument passing or assignation, it becomes a very deliberate operation.

beached_whale 9y ago

All the standard says is that the state is valid. It would come at a space cost I guess though.

stinos 9y ago

not_null style classes might be what you're after, e.g. https://github.com/Microsoft/GSL/blob/master/include/gsl/gsl#L74 https://github.com/Microsoft/GSL/blob/master/include/gsl/gsl.... Whan trying to store nullptr in it at runtime that will result in an exception or abort or whatever it's implemented like. Depending on the usecase, it's still better than manually checking for nullptr though. moving from a pointer must give a valid object Yes (well, actually it's state is 'valid but unspecified') but afaik performing any operations having preconditions on moved-from objects is undefined behaviour anyway so you shouldn't even be doing that. And when using not_null that would again result in an exception.

masklinn 9y ago

> Not sure I like this pointer. Copying a pointer should not be a heavyweight operation. That is pretty well established. An alternative option would be a unique_ptr subtype (or extension) which allows cloning if the wrapped type is clonable, something similar to rust's impl<T> Clone for Box<T> where T: Clone Can that be expressed without concepts?

petters 9y ago
Yes, but it is a bit awkward. You can can separate implementations depending on whether T has a particular member function. I need to look up how every time, though.
- masklinn 9y ago
  > You can can separate implementations depending on whether T has a particular member function. Separate implementation, but not separate interface? The Rust bit means Box is "transparently" clonable, meaning it only implements the clone trait(/interface) if the value it wraps also does, trying to clone a Box<T> where T can not be cloned would be a compile-time error.