[libcxx-commits] [PATCH] D118329: [libc++] Optimize algorithms on uninitialized memory for trivial types.

Hui via Phabricator via libcxx-commits libcxx-commits at lists.llvm.org
Mon Aug 8 11:00:18 PDT 2022


huixie90 added inline comments.
Herald added a project: All.


================
Comment at: libcxx/include/__memory/construct_at.h:80
+_ForwardIterator __destroy(_ForwardIterator __first, _ForwardIterator __last,
+        __enable_if_t<!is_trivially_destructible<__iter_value_type<_ForwardIterator> >::value>* = nullptr) {
     for (; __first != __last; ++__first)
----------------
Why is `value_type` used? 
` _VSTD::__destroy_at(_VSTD::addressof(*__first));` does not have any `value_type` involved


================
Comment at: libcxx/include/__memory/uninitialized_algorithms.h:299
 _ForwardIterator __uninitialized_default_construct(_ForwardIterator __first, _Sentinel __last) {
+    if constexpr (is_trivially_default_constructible_v<_ValueType> && is_trivially_destructible_v<_ValueType>) {
+        if constexpr (is_assignable<_ForwardIterator, _Sentinel>::value) {
----------------
why `is_trivially_destructible_v` is needed? IIUC, we are not destroying anything since the memory [__first, __last) does not have any objects yet thus no destructors are required


================
Comment at: libcxx/include/__memory/uninitialized_algorithms.h:300-308
+        if constexpr (is_assignable<_ForwardIterator, _Sentinel>::value) {
+          return __last;
+
+        } else {
+          while (__first != __last) {
+            ++__first;
+          }
----------------
This looks like the implementation of `ranges::next(__first, __last)` but I guess it is hard to reuse because this algorithm is c++17?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D118329



More information about the libcxx-commits mailing list