Date: Thu, 14 Mar 2024 12:29:21 -0400
On Thu, Mar 14, 2024 at 11:45 AM Ville Voutilainen <
ville.voutilainen_at_[hidden]> wrote:
> On Thu, 14 Mar 2024 at 17:11, Arthur O'Dwyer via SG14 <
> sg14_at_[hidden]> wrote:
> > On Thu, Mar 14, 2024 at 11:09 AM Jake Fevold (BLOOMBERG/ 919 3RD A) via
> SG14 <sg14_at_[hidden]> wrote:
> >> Just wanted to point out that the trivial relocation presented in P2786
> is strongly preferred by BDE (sometimes called BSL) over the form in P1144.
> >
> > That's not true; BSL actually uses the form presented in P1144 table
> §2.1. I have several blog posts on the topic; see particularly
> https://quuxplusone.github.io/blog/2024/01/02/bsl-vector-erase/ which
> presents an example directly taken from bsl::vector.
> >
> > I'm happy to talk about this further; you can find me on the cpplang
> Slack. :)
>
> Is there a concise summary of the differences between these proposals?
>
Yes! From "How my papers did at Issaquah"
<https://quuxplusone.github.io/blog/2023/02/17/issaquah-status/#trivial-relocatability>
:
The major places where P2786R0 disagreed with P1144 are:
-
<https://quuxplusone.github.io/blog/2023/02/17/issaquah-status/#whether-std-swap-can-be-implemen>
Whether std::swap can be implemented as “relocate A into a temporary;
relocate B into A; relocate the temporary into B,” or whether it *must* be
implemented in terms of assignment — and what “assignment” means for
trivial types anyway. Vendors already optimize copy_n
<https://godbolt.org/z/8nMoo6Tes> in a way detectable by the user; the
question is if we should permit vendors to optimize swap
<https://godbolt.org/z/Y5YMndM56> in the same way. P1144 says
“optimize,” P2786 says “don’t.”
-
<https://quuxplusone.github.io/blog/2023/02/17/issaquah-status/#whether-vector-insert-can-use-re>
Whether vector::insert can use relocation to “make a window” that is
then filled with the new data (as in Folly’s fbvector
<https://github.com/facebook/folly/blob/1d4690d0a3/folly/FBVector.h#L1273-L1292>),
or whether it *must* be implemented in terms of assignment. P1144 says
“optimize,” P2786 says “don’t.” See “Should assignment affect
is_trivially_relocatable?”
<https://quuxplusone.github.io/blog/2024/01/02/bsl-vector-erase/>
(2024-01-02).
-
<https://quuxplusone.github.io/blog/2023/02/17/issaquah-status/#whether-a-type-containing-a-data>Whether
a type containing a data member of type
boost::interprocess::offset_ptr<T> may be explicitly warranted as
[[trivially_relocatable]] (Godbolt <https://godbolt.org/z/hz56dqq4Y>).
P1144 says “optimize,” P2786 says “don’t.”
And there are also two verbose summaries...
(1) P2814R1 "Comparing P1144 with P2786"
<https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2814r1.pdf> (15
pages)
(2) My own post-Issaquah blog series, one post per major difference:
- "How my papers did at Issaquah"
<https://quuxplusone.github.io/blog/2023/02/17/issaquah-status/#trivial-relocatability>
(executive summary)
- "Trivial relocation, std::swap, and a $2000 prize"
<https://quuxplusone.github.io/blog/2023/02/24/trivial-swap-x-prize/> (Can
we swap trivially relocatable types trivially, via mutual relocation? P1144
and Abseil say yes; P2786 says no.)
- "STL algorithms for relocation"
<https://quuxplusone.github.io/blog/2023/03/03/relocate-algorithm-design/>
(Should the library provide a generic algorithm
`std::uninitialized_relocate` matching `std::uninitialized_move` and
`std::uninitialized_destroy`, or should it provide P2786's novel API? HPX,
Parlay, and AMC implement P1144's API; Qt implements a hybrid; nobody
implements P2786.)
- "Should the compiler sometimes reject a [[trivially_relocatable]]
warrant?"
<https://quuxplusone.github.io/blog/2023/03/10/sharp-knife-dull-knife/>
(Sharp knife / dull knife. My P1144 reference implementation implements
P1144 of course, and anecdotally I've found it to be the simplest and
safest approach in my complete P1144-ification of libc++ and libstdc++ which
is available on Godbolt <https://godbolt.org/z/eoz7913Ta>. No other
implementations of the warrant side currently exist for comparison.)
–Arthur
ville.voutilainen_at_[hidden]> wrote:
> On Thu, 14 Mar 2024 at 17:11, Arthur O'Dwyer via SG14 <
> sg14_at_[hidden]> wrote:
> > On Thu, Mar 14, 2024 at 11:09 AM Jake Fevold (BLOOMBERG/ 919 3RD A) via
> SG14 <sg14_at_[hidden]> wrote:
> >> Just wanted to point out that the trivial relocation presented in P2786
> is strongly preferred by BDE (sometimes called BSL) over the form in P1144.
> >
> > That's not true; BSL actually uses the form presented in P1144 table
> §2.1. I have several blog posts on the topic; see particularly
> https://quuxplusone.github.io/blog/2024/01/02/bsl-vector-erase/ which
> presents an example directly taken from bsl::vector.
> >
> > I'm happy to talk about this further; you can find me on the cpplang
> Slack. :)
>
> Is there a concise summary of the differences between these proposals?
>
Yes! From "How my papers did at Issaquah"
<https://quuxplusone.github.io/blog/2023/02/17/issaquah-status/#trivial-relocatability>
:
The major places where P2786R0 disagreed with P1144 are:
-
<https://quuxplusone.github.io/blog/2023/02/17/issaquah-status/#whether-std-swap-can-be-implemen>
Whether std::swap can be implemented as “relocate A into a temporary;
relocate B into A; relocate the temporary into B,” or whether it *must* be
implemented in terms of assignment — and what “assignment” means for
trivial types anyway. Vendors already optimize copy_n
<https://godbolt.org/z/8nMoo6Tes> in a way detectable by the user; the
question is if we should permit vendors to optimize swap
<https://godbolt.org/z/Y5YMndM56> in the same way. P1144 says
“optimize,” P2786 says “don’t.”
-
<https://quuxplusone.github.io/blog/2023/02/17/issaquah-status/#whether-vector-insert-can-use-re>
Whether vector::insert can use relocation to “make a window” that is
then filled with the new data (as in Folly’s fbvector
<https://github.com/facebook/folly/blob/1d4690d0a3/folly/FBVector.h#L1273-L1292>),
or whether it *must* be implemented in terms of assignment. P1144 says
“optimize,” P2786 says “don’t.” See “Should assignment affect
is_trivially_relocatable?”
<https://quuxplusone.github.io/blog/2024/01/02/bsl-vector-erase/>
(2024-01-02).
-
<https://quuxplusone.github.io/blog/2023/02/17/issaquah-status/#whether-a-type-containing-a-data>Whether
a type containing a data member of type
boost::interprocess::offset_ptr<T> may be explicitly warranted as
[[trivially_relocatable]] (Godbolt <https://godbolt.org/z/hz56dqq4Y>).
P1144 says “optimize,” P2786 says “don’t.”
And there are also two verbose summaries...
(1) P2814R1 "Comparing P1144 with P2786"
<https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2814r1.pdf> (15
pages)
(2) My own post-Issaquah blog series, one post per major difference:
- "How my papers did at Issaquah"
<https://quuxplusone.github.io/blog/2023/02/17/issaquah-status/#trivial-relocatability>
(executive summary)
- "Trivial relocation, std::swap, and a $2000 prize"
<https://quuxplusone.github.io/blog/2023/02/24/trivial-swap-x-prize/> (Can
we swap trivially relocatable types trivially, via mutual relocation? P1144
and Abseil say yes; P2786 says no.)
- "STL algorithms for relocation"
<https://quuxplusone.github.io/blog/2023/03/03/relocate-algorithm-design/>
(Should the library provide a generic algorithm
`std::uninitialized_relocate` matching `std::uninitialized_move` and
`std::uninitialized_destroy`, or should it provide P2786's novel API? HPX,
Parlay, and AMC implement P1144's API; Qt implements a hybrid; nobody
implements P2786.)
- "Should the compiler sometimes reject a [[trivially_relocatable]]
warrant?"
<https://quuxplusone.github.io/blog/2023/03/10/sharp-knife-dull-knife/>
(Sharp knife / dull knife. My P1144 reference implementation implements
P1144 of course, and anecdotally I've found it to be the simplest and
safest approach in my complete P1144-ification of libc++ and libstdc++ which
is available on Godbolt <https://godbolt.org/z/eoz7913Ta>. No other
implementations of the warrant side currently exist for comparison.)
–Arthur
Received on 2024-03-14 16:29:35