4 ms·

I'm not sure I see the benefit vs std::unique_ptr. In the rare case you do want to deep-copy a unique_ptr, you can always use std::make_unique() to invoke the c

I'm not sure I see the benefit vs std::unique_ptr. In the rare case you do want to deep-copy a unique_ptr, you can always use std::make_unique() to invoke the copy constructor

LegionMammal978 3y ago
That was my thought as well; even Rust requires a .clone() call to deep-copy a Box<T>, since it doesn't allow implicit copies of types without the Copy trait. (Types with that trait must effectively be "plain old data" that can be copied byte-by-byte.) So I don't see the issue with requiring an explicit copy function for std::unique_ptr<T> instead of an implicit copy constructor.
- ithkuil 3y ago
  But if you clone a struct that contains a Box<T> field then that field is also cloned (at least that's the behavior if the default derived Clone impl)
seeknotfind 3y ago
Kind of, though because the language does a lot of things for you when you use the built in copy, make_unique gets complicated when you want to use std::box inside of another structure. You would need to override the default copy constructor to get this to work. For instance, vector<box<Foo>> wouldn't be possible to implement with unique_ptr because you can't override the copy constructor for a templated type. std::box would allow you to copy it. As for why you would need to do this (over vector<Foo>), consider Foo having subclasses. Complexity breeds complexity... Regardless, I think lifetime annotations would solve far more problems than std::box. I really do like box as a suggestion as it would help clean up types, make things a bit more explicit in a few places, but there are bigger issues with C++ right now. This is a great suggestion (as is unique_resource for similar on the stack), but a relatively minor thing in the scheme of things. Still nice.
- pjmlp 3y ago
  Lifetime annotations are somehow complicated without subseting the language. It isn't as if Microsoft, Apple and Google haven't been doing it for a while. https://devblogs.microsoft.com/cppblog/high-confidence-lifetime-checks-in-visual-studio-version-17-5-preview-2/ https://devblogs.microsoft.com/cppblog/high-confidence-lifet... https://reviews.llvm.org/D15032 https://reviews.llvm.org/D15032
deleted 3y ago
[deleted]
loeg 3y ago
Yeah, this is just a unique_ptr with a copy operation.
nemetroid 3y ago
You could make a similar argument about std::unique_ptr, that you can always use new and delete to create and destroy. Which one of these (which implement the same copy/move semantics) would you prefer? struct A { box<int> thing; } struct B { std::unique_ptr<int> thing; B(std::unique_ptr<int> t) : thing(std::move(t)) {} B(const B& other) { *this = other; } B& operator=(const B& other) { if (other.thing) thing = std::make_unique<int>(*other.thing); else thing.reset(); return *this; } B(B&&) = default; B& operator=(B&&) = default; ~B() = default; }; edit: nullptr checks.
- Asooka 3y ago
  Huh, isn't struct B literally what an implementation of std::box would look like? You would need a nullptr check in the copy ctor and copy assignment operator to make it complete, but other than that, that is exactly how I would implement box. Anything that would be in std, you can implement yourself, so I would encourage people to try implementing box themselves and see how it works for them.
  - nemetroid 3y ago
    Yes, it's not too difficult (but thanks for the pointer, edited). The question was why this smart pointer would be useful at all, not just whether it belongs in the standard library. Implementing the helper class yourself is not too bad, but putting this in domain classes is a lot of cruft.
- fluoridation 3y ago
  Personally, I've never needed to copy something that was both not trivially copiable and the component parts of which were individually trivially copiable. If thing just gets initialized immediately, why do you put it in a pointer? Usually you would put it in a pointer because you need to initialize it in a specific order in the constructor relative to the other members (so presumably also in the copy constructor), or because it's a polymorphic object (so you can't just use the copy constructor of the static type). If neither of those is true, why use a pointer at all? Just make the member a simple object.

I'm not sure I see the benefit vs std::unique_ptr. In the rare case you do want to deep-copy a unique_ptr, you can always use std::make_unique() to invoke the copy constructor

LegionMammal978 3y ago

That was my thought as well; even Rust requires a .clone() call to deep-copy a Box<T>, since it doesn't allow implicit copies of types without the Copy trait. (Types with that trait must effectively be "plain old data" that can be copied byte-by-byte.) So I don't see the issue with requiring an explicit copy function for std::unique_ptr<T> instead of an implicit copy constructor.

ithkuil 3y ago
But if you clone a struct that contains a Box<T> field then that field is also cloned (at least that's the behavior if the default derived Clone impl)

seeknotfind 3y ago

Kind of, though because the language does a lot of things for you when you use the built in copy, make_unique gets complicated when you want to use std::box inside of another structure. You would need to override the default copy constructor to get this to work. For instance, vector<box<Foo>> wouldn't be possible to implement with unique_ptr because you can't override the copy constructor for a templated type. std::box would allow you to copy it. As for why you would need to do this (over vector<Foo>), consider Foo having subclasses. Complexity breeds complexity... Regardless, I think lifetime annotations would solve far more problems than std::box. I really do like box as a suggestion as it would help clean up types, make things a bit more explicit in a few places, but there are bigger issues with C++ right now. This is a great suggestion (as is unique_resource for similar on the stack), but a relatively minor thing in the scheme of things. Still nice.

pjmlp 3y ago
Lifetime annotations are somehow complicated without subseting the language. It isn't as if Microsoft, Apple and Google haven't been doing it for a while. https://devblogs.microsoft.com/cppblog/high-confidence-lifetime-checks-in-visual-studio-version-17-5-preview-2/ https://devblogs.microsoft.com/cppblog/high-confidence-lifet... https://reviews.llvm.org/D15032 https://reviews.llvm.org/D15032

deleted 3y ago

[deleted]

loeg 3y ago

Yeah, this is just a unique_ptr with a copy operation.

nemetroid 3y ago

You could make a similar argument about std::unique_ptr, that you can always use new and delete to create and destroy. Which one of these (which implement the same copy/move semantics) would you prefer? struct A { box<int> thing; } struct B { std::unique_ptr<int> thing; B(std::unique_ptr<int> t) : thing(std::move(t)) {} B(const B& other) { *this = other; } B& operator=(const B& other) { if (other.thing) thing = std::make_unique<int>(*other.thing); else thing.reset(); return *this; } B(B&&) = default; B& operator=(B&&) = default; ~B() = default; }; edit: nullptr checks.

Asooka 3y ago
Huh, isn't struct B literally what an implementation of std::box would look like? You would need a nullptr check in the copy ctor and copy assignment operator to make it complete, but other than that, that is exactly how I would implement box. Anything that would be in std, you can implement yourself, so I would encourage people to try implementing box themselves and see how it works for them.
- nemetroid 3y ago
  Yes, it's not too difficult (but thanks for the pointer, edited). The question was why this smart pointer would be useful at all, not just whether it belongs in the standard library. Implementing the helper class yourself is not too bad, but putting this in domain classes is a lot of cruft.
fluoridation 3y ago
Personally, I've never needed to copy something that was both not trivially copiable and the component parts of which were individually trivially copiable. If thing just gets initialized immediately, why do you put it in a pointer? Usually you would put it in a pointer because you need to initialize it in a specific order in the constructor relative to the other members (so presumably also in the copy constructor), or because it's a polymorphic object (so you can't just use the copy constructor of the static type). If neither of those is true, why use a pointer at all? Just make the member a simple object.