[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