[libcxx-commits] [PATCH] D61761: P1144 "Trivially relocatable" (1/3): is_trivially_relocatable, relocate_at, and uninitialized_relocate

Zoe Carver via Phabricator via libcxx-commits libcxx-commits at lists.llvm.org
Sun May 12 11:04:03 PDT 2019


zoecarver added inline comments.


================
Comment at: include/memory:3466
+    __source->~_Tp();
+    return _VSTD::__launder(__dest);
+}
----------------
Quuxplusone wrote:
> I'm not sure whether this `launder` is doing anything.
> Alternatively, should I assign `__dest = ::new (...` and then `return __dest`?
That seems more correct. After calling `new` the pointer should still be active, so you won't need `launder `.

I think `launder` is only necessary after `memmove` because then the pointer's lifetime is over.


================
Comment at: include/memory:3510
+    for (; __first != __last; (void)++__result, ++__first) {
+        ::new (static_cast<void*>(_VSTD::addressof(*__result))) _Dt(_VSTD::move(*__first));
+        _VSTD::destroy_at(std::addressof(*__first));
----------------
Quuxplusone wrote:
> zoecarver wrote:
> > I think this should require `_LIBCPP_STD_VER > 03`.
> libc++ supports `std::move` even in `_LIBCPP_HAS_NO_RVALUE_REFERENCES`-mode, presumably because it would be too tedious to `#ifdef` all the places where we use `std::move` (such as here).
Good to know.


================
Comment at: include/memory:3556
+        integral_constant<bool,
+            !is_volatile<_St>::value && !is_volatile<_Dt>::value &&
+            __is_same_uncvref<_St, _Dt>::value &&
----------------
Quuxplusone wrote:
> zoecarver wrote:
> > What is the reason for `is_volatile`? I don't see that in the paper (but maybe I am missing something).
> It's related to https://quuxplusone.github.io/blog/2018/07/13/trivially-copyable-corner-cases/ — if we have a range of `volatile Foo`, then the user is probably expecting us to follow the abstract machine and copy the `Foo` objects one by one, instead of byte-by-byte (possible tearing). The library doesn't technically //have// to follow the abstract machine here, but I think it's QoI to do so.
> 
> I just re-examined `std::copy` and it doesn't bother to check `is_volatile`, so I guess it would be consistent for libc++ not to check `is_volatile` here either. (That would make the QoI //consistently// low, IMHO.)
Maybe open an issue about this (in bugzilla) so that once/if P1153 is introduced it can be updated.


================
Comment at: include/memory:3464
+_Tp *__relocate_at_impl(_Tp *__source, _Tp *__dest, false_type) {
+    ::new (static_cast<void*>(__dest)) _Tp(_VSTD::move(*__dest));
+    __source->~_Tp();
----------------
Are you intentionally not doing anything with the result of `new`? Also, I am not sure you need to `static_cast` to `void*`.

Also, also, I think you want to move `__source` not `__dest` (because I am pretty sure `__dest` is where you want to relocate the new thing and `__source` is where you want to get it).


================
Comment at: include/memory:3481
+        __source, __dest,
+        typename is_trivially_relocatable<_Tp>::type()
+    );
----------------
I think this should be `is_trivially_relocatable<_Tp>()`.


Repository:
  rCXX libc++

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D61761/new/

https://reviews.llvm.org/D61761





More information about the libcxx-commits mailing list