-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
<execution>
, <numeric>
: Change improper direct-initialization to copy-initialization in C++17 numeric algorithms
#4419
<execution>
, <numeric>
: Change improper direct-initialization to copy-initialization in C++17 numeric algorithms
#4419
Conversation
<numeric>
: Change improper direct-initialization to copy-initialization in C++17 numeric algorithms<execution>
, <numeric>
: Change improper direct-initialization to copy-initialization in C++17 numeric algorithms
- s/_Implicit_construct/_Implicitly_construct - Restore some default-initialization
ec79508
to
3f811a9
Compare
This comment was marked as resolved.
This comment was marked as resolved.
|
||
template <class _Ty, class _BinaryOp, class _ArgTy> | ||
void _Implicitly_construct_in_place_by_binary_op(_Ty& _Val, _BinaryOp& _Reduce_op, _ArgTy& _Left, _ArgTy& _Right) { | ||
::new (static_cast<void*>(_STD addressof(_Val))) _Ty([&]() -> _Ty { return _Reduce_op(_Left, _Right); }()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And capturing it by reference too. Ditto below.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The point is performing implicit conversion in placement new with workaround for imperfectness of forwarding. So I guess copying should be avoided.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm fine with capturing by reference since it doesn't affect the function signature, even though it should be a reference to a _Pass_fn
.
|
||
template <class _Ty, class _BinaryOp, class _ArgTy> | ||
void _Implicitly_construct_in_place_by_binary_op(_Ty& _Val, _BinaryOp& _Reduce_op, _ArgTy& _Left, _ArgTy& _Right) { | ||
::new (static_cast<void*>(_STD addressof(_Val))) _Ty([&]() -> _Ty { return _Reduce_op(_Left, _Right); }()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm fine with capturing by reference since it doesn't affect the function signature, even though it should be a reference to a _Pass_fn
.
tests/std/tests/GH_004129_conversion_in_new_numeric_algorithms/test.cpp
Outdated
Show resolved
Hide resolved
tests/std/tests/GH_004129_conversion_in_new_numeric_algorithms/test.cpp
Outdated
Show resolved
Hide resolved
I'm mirroring this to the MSVC-internal repo - please notify me if any further changes are pushed. |
Thanks for fixing these algorithms! 🛠️ 🧮 🪄 |
Follows up #4260.
Affected algorithms:
reduce
transform_reduce
exclusive_scan
inclusive_scan
transform_exclusive_scan
transform_inclusive_scan
The standard wording only uses "convertible" (from the results of operations to the element type) in the requirements of these algorithms, so direct-initialization can be sometimes wrong.
The construction from
_Transform_op(*_First)
seems incorrect formeow
scan
algorithms as the standard doesn't seem to require this. See also #3783. Perhaps we should remove such construction later._Implicitly_construct_in_place_
meow
function templates are added for performing implicit conversion in placements new and avoiding additional move, which may be important for WG21-P2408R5.