C++ Logo


Advanced search

Re: Next SG14 meeting on April 10th - Low Latency Financial Systems

From: Arthur O'Dwyer <arthur.j.odwyer_at_[hidden]>
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"

The major places where P2786R0 disagreed with P1144 are:


   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.”

   Whether vector::insert can use relocation to “make a window” that is
   then filled with the new data (as in Folly’s fbvector
   or whether it *must* be implemented in terms of assignment. P1144 says
   “optimize,” P2786 says “don’t.” See “Should assignment affect

   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

(2) My own post-Issaquah blog series, one post per major difference:
- "How my papers did at Issaquah"
(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"
(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]]
(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.)


Received on 2024-03-14 16:29:35