4 ms·

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

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.
- nemetroid 3y ago
  Types that are self-referential in one way or another, e.g. a graph where nodes point to each other, or a "main object" containing subobjects which point back to the main object. There is no way to implement an efficient move for such types (it would need to adjust all pointers), so implementing move operations would be misleading. If you want to be able to pass around ownership of such a type, it needs to happen through pointer indirection. But you might want to allow a copy operation that recreates the entire structure. The proposed box<T> offers exactly the desired copy/move semantics.
  - adrian_b 3y ago
    It can be argued that any types like those described by you are wrongly designed. For a self-referential type like a graph, either a value of the graph is completely stored in a contiguous region of memory, including all nodes, when the self-references should not be pointers, but offsets from the start of the region, and a graph value can be moved or copied anywhere without problems, or else a graph value consists only of a list of pointers, which point to node contents without pointers, which are scattered through the memory. In the second case, a graph value, i.e. the list of pointers, can also be copied or moved anywhere in the memory without any problems, like you would do with any single pointer. Mixing pointers with data makes sense only for objects with embedded pointers whose purpose is to allow them to be inserted in linked links or trees, where such objects will never be copied or moved, but only created and destroyed.
  - fluoridation 3y ago
    Those sorts of types fail the second requirement. The members are not trivially copyable on their own because they contain tremendous structure that may only be discernible at the top level. A generic box pointer doesn't help you there because the problem is not implementing the copy methods of the members, but implementing the copy method of the outermost object.

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.

nemetroid 3y ago
Types that are self-referential in one way or another, e.g. a graph where nodes point to each other, or a "main object" containing subobjects which point back to the main object. There is no way to implement an efficient move for such types (it would need to adjust all pointers), so implementing move operations would be misleading. If you want to be able to pass around ownership of such a type, it needs to happen through pointer indirection. But you might want to allow a copy operation that recreates the entire structure. The proposed box<T> offers exactly the desired copy/move semantics.
- adrian_b 3y ago
  It can be argued that any types like those described by you are wrongly designed. For a self-referential type like a graph, either a value of the graph is completely stored in a contiguous region of memory, including all nodes, when the self-references should not be pointers, but offsets from the start of the region, and a graph value can be moved or copied anywhere without problems, or else a graph value consists only of a list of pointers, which point to node contents without pointers, which are scattered through the memory. In the second case, a graph value, i.e. the list of pointers, can also be copied or moved anywhere in the memory without any problems, like you would do with any single pointer. Mixing pointers with data makes sense only for objects with embedded pointers whose purpose is to allow them to be inserted in linked links or trees, where such objects will never be copied or moved, but only created and destroyed.
- fluoridation 3y ago
  Those sorts of types fail the second requirement. The members are not trivially copyable on their own because they contain tremendous structure that may only be discernible at the top level. A generic box pointer doesn't help you there because the problem is not implementing the copy methods of the members, but implementing the copy method of the outermost object.