Great talk! 25:03, I disagree with the construction interface proposed. the empty argument version is inconsistent with the variadic version. because the former is not semantically the “limit” of zero arguments of the later. The variadic version should be a version that takes a T&& and that’s it. If an in place construction is needed an inplace_t + variadic version of the constructor should be added instead. just like std::optional does.
actually, together with what to do with swap and moved-from state, default construction is a very interesting aspect of std::indirect. The point is that, if indirect is meant to support a proper value type, these operations could support (exploit) the partially formed state for efficiency even if the original value type does not. This is basically an orthogonal feature to heap allocation but it might be worth it.
28:06 [slide 38] the part where “there’s nothing in other” (i.e. if(!other) is true) should not forget to assign “ptr = pointer{};” after calling destroy(). Also, the member variable “p_” is probably a typo and should be called “ptr”
I also think that after the first and second calls to destroy() the destroyed pointers (ptr and other.ptr respectively) should be reset and not keep pointing to destroyed memory
Surely that nasty std::argument_arg_t hack could have been at the very least hidden away by a new function attribute? Who came up with the name select_on_container_copy_construction?
Great talk!
25:03, I disagree with the construction interface proposed. the empty argument version is inconsistent with the variadic version. because the former is not semantically the “limit” of zero arguments of the later.
The variadic version should be a version that takes a T&& and that’s it.
If an in place construction is needed an inplace_t + variadic version of the constructor should be added instead. just like std::optional does.
actually, together with what to do with swap and moved-from state, default construction is a very interesting aspect of std::indirect. The point is that, if indirect is meant to support a proper value type, these operations could support (exploit) the partially formed state for efficiency even if the original value type does not. This is basically an orthogonal feature to heap allocation but it might be worth it.
Great talk, thanks! Some slight issues like function signature in Slide 39 but that’s obvious typo.
28:06 [slide 38] the part where “there’s nothing in other” (i.e. if(!other) is true) should not forget to assign “ptr = pointer{};” after calling destroy().
Also, the member variable “p_” is probably a typo and should be called “ptr”
27:05 [slide 37] the allocator extended move constructor does seem to use the allocator that’s passed to it. I assume it’s a typo
29:33 the signature of the move assignment is wrong. It should be &&, instead of const&.
I also think that after the first and second calls to destroy() the destroyed pointers (ptr and other.ptr respectively) should be reset and not keep pointing to destroyed memory
@ well, he warned it was very hard to get right!
2:32 Jonathan’s talk from 2022: ua-cam.com/video/sjLRX4WMvlU/v-deo.html
Slide 39, signature is not a move-assignemnt
Surely that nasty std::argument_arg_t hack could have been at the very least hidden away by a new function attribute? Who came up with the name select_on_container_copy_construction?