Relocation algorithms implementation

[isidorostsa]

This is a starting point for the implementation of the P1144 relocate_at and uninitialized_relocate algorithms for HPX. They will later be used as base primitives for parallelized versions.

[Quuxplusone]

In P1144, this algorithm appears in <memory>, alongside std::uninitialized_fill and std::destroy and so on.
P1144R8 does not specify any feature-test macro, e.g. #define __cpp_lib_relocate 202307L; but if that would help you, I'm open to suggestions on such a macro's name, and can add it to my libc++ implementation on Godbolt.

[Quuxplusone]

It is conceivable that we have InIter=int*, FwdIter=const int*. In that case, dest won't be convertible to void*; you'll need const_cast<void*>(static_cast<const void*>(dest)) or simply (void*)dest. (Remember, we're not modifying *dest; we're bringing it into existence. So it's sane for *dest to be a const type.)

I'm fixing the same bug in my libc++ code as we speak. :)

[isidorostsa]

Thank you, hadn't thought of that.

So it makes sense to modify relocate_at to accept different input/output types?

template <typename SourceType, typename DestType>
T* relocate_at(SourceType* src, DestType* dst)

[Quuxplusone]

I do that in libc++ internally: implement relocate_at(T*, T*) in terms of __libcpp_relocate_at2(T*, U*). But I have never proposed that in P1144R0–R8, because relocate_at(T*, U*) can't ever take advantage of trivial relocatability unless T==U. (I mean, in theory, a sufficiently smart implementation could expose __is_trivially_relocatable_from(T, U); but nobody does that, and it's not at all clear what would be the syntax via which the user could "warrant" such a property themselves. See https://quuxplusone.github.io/blog/2018/07/03/trivially-constructible-from/ for more thoughts on the topic.)

Note that the "relocatable-from" relationship, if it existed, wouldn't be symmetrical:

    int *a;
    std::unique_ptr<int> b;
    std::construct_at(&b, std::move(a)); std::destroy_at(&a); // OK
    std::construct_at(&a, std::move(b)); std::destroy_at(&b); // Ill-formed

    static_assert(std::is_relocatable_from_v<std::unique_ptr<int>, int*>);
    static_assert(!std::is_relocatable_from_v<int*, std::unique_ptr<int>>);

...However, maybe you just meant "shouldn't it be possible to relocate from const into non-const?"—

    const int j = 42;
    alignas(int) char ibuf[sizeof(int)];
    int& i = *(int*)ibuf;
    std::relocate_at(&j, &i);  // P1144R8: Ill-formed, deduction failed: `const int` versus `int`

I'm much more sympathetic to that idea, but it's never yet come up in WG21 discussions. Until someone claims it's a real problem, I'd weakly prefer not to try to address it. I think addressing it will require either completely uncoupling SourceType and DestType as you suggest (which makes the API seem to promise triviality in cases where the implementation can't actually guarantee it), or doing some sort of awful constrained template like requires is_same_v<remove_cvref_t<SourceType>, remove_cvref_t<DestType>> (which makes the API harder to understand).

[Quuxplusone]

Nitpicks:

• Perhaps object_type should be in_type, for symmetry.
• The use of decay_t suggests to me that you should test what happens when InIter and/or FwdIter is a pointer-to-array, e.g. int(*)[5]. P1144R8 says that uninitialized_relocate should refuse to compile when FwdIter is a pointer-to-array (because the as-if-by expression ::new (result) T(std::move(*first)) would be ill-formed), but should work fine when InIter is a pointer-to-array (because the behavior is defined as-if-by std::destroy_at(std::addressof(*first)), not first->~T()). I'm fixing the same bug in my libc++ code as we speak. :)

[isidorostsa]

Now that you mention it I am not sure decay is needed at all.

Would the following be sufficient instead?

using in_type = typename std::remove_reference_t<decltype(*std::declval<InIter>())>;
using out_type = typename std::remove_reference_t<decltype(*std::declval<FwdIter>())>;

That way pointer-to-array types become in_type = int[N] which we can test for inside uninitialized_relocate:

template <typename InIter, typename FwdIter>
    FwdIter uninitialized_relocate(InIter first, InIter last, FwdIter dest)
    {
        static_assert(
            hpx::is_relocatable_v<
                typename detail::choose_uninitialized_relocate_impl<InIter,
                    FwdIter>::in_type>,
            "Relocated objects must be move-constructible");
        return detail::uninitialized_relocate_helper(first, last, dest);
    }

[Quuxplusone]

Would the following be sufficient instead?

Yes, I think so.

But the second half of your comment is coupled to the question above about relocatable_from: In this algorithm we do support first and dest having different value_types (again because it makes the API simpler), so you would need to static-assert on is_relocatable_from_v<out_type, in_type>.

[isidorostsa]

That's nice, could is_relocatable_from be as simple as

  constexpr bool is_relocatable_from_v =
      std::is_constructible_v<std::remove_cv_t<out_type>,
                              std::add_rvalue_reference_t<in_type>> &&
      !std::is_const_v<in_type>;

where in_type = decltype(*first), out_type = decltype(*dest) ?

[Quuxplusone]

I would say just:

constexpr bool is_relocatable_from_v =
    std::is_constructible_v<std::remove_cv_t<out_type>, in_type>;

The add_rvalue_reference_t isn't needed because all type-traits that talk about invocability ("can I call X with Y arguments?") treat Y in the same way as declval<Y>(), i.e., apply a layer of rvalue-ref-ness automatically for no reason. (This is a priori awful, but it's been this way since C++11 and will never change.)

I would expect to have is_relocatable_from_v<unique_ptr<int>, const unique_ptr<int>> == false, but is_relocatable_from_v<shared_ptr<int>, const shared_ptr<int>> == true.

[isidorostsa]

For the first part, does this weird convention apply to constructibility as well? I think this is a counterexample: https://godbolt.org/z/G36nYfeWv

For the second part, I agree with the first example, but I do not understand why is_relocatable_from_v<shared_ptr<int>, const shared_ptr<int>> == true would be correct, isn't relocating from a const object UB?

[Quuxplusone]

For the first part, does this weird convention apply to constructibility as well? I think this is a counterexample

You must have misinterpreted my meaning, because that's not a counterexample to what I meant; see https://godbolt.org/z/jrx9MMh8T . Basically the intuition is, any time a type-trait might plausibly be implemented as SFINAE on something-of(declval<Args>()...), then it literally is specified as-if-by SFINAE on something-of(declval<Args>()...), i.e., Args is interpreted as Args&&. Example: https://godbolt.org/z/43rPWTe6T

For the second part, [...] isn't relocating from a const object UB?

No, I don't see why it should be. Relocation is as-if-by construct_at(dst, std::move(*src)) (which is OK as long as you've got a copy constructor) followed by std::destroy_at(src) (which works fine on const objects). You're not allowed to change the value of a const object, but of course you're allowed to end its lifetime. If you couldn't end the lifetime of a const object then every const object would be immortal. :)

[isidorostsa]

You must have misinterpreted ....

Yes, you are completely right, thank you for the clarification

you're allowed to end its lifetime. If you couldn't end the lifetime of a const object then every const object would be immortal

I had never thought of it that way, thanks for this too. TIL

[Quuxplusone]

I was wondering, do you think there's a standard-friendly way to achieve the same thing?

The spec's reference implementation doesn't get you the memmove codegen, but it's perfectly conforming:

std::remove_cv_t<T> t = std::move(source);
std::destroy_at(source);
return t;

There is no way to get the memmove codegen without bending some rule or other: either use my hack, or, here's an alternative direction that's been discussed:

    __attribute__((do_not_construct)) T t;
    std::relocate_at(source, std::address_of(t));
    return t;  // NRVO

But no compiler vendor has ever implemented such an attribute. (I don't even think anyone's implemented P1247 __attribute__((no_destroy)).) So unless you own your own compiler, that direction is currently a dead end. :)

[isidorostsa]

Sad to hear, does P1144 require compilers to implement a way to get the memmove codegen, or is not required as per the as-if rule?

[Quuxplusone]

does P1144 require compilers to implement a way to get the memmove codegen

Nope. This is a deliberate design decision, both

• pragmatically — I don't want vendors to have to jump through every single hoop on the first try; let them deal with performance as a quality-of-implementation issue at their leisure
• philosophically — the implementation may skip observable side effects associated with trivial relocation; but if you're relying on the implementation to skip a side effect of relocation because you know that that side effect would change the semantics of your program, well then, it sounds like your type isn't trivially relocatable after all!