[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <57A4AE10-546F-402D-A04E-3EC323A86AC5@gmail.com>
Date: Fri, 21 Feb 2025 21:56:24 -0800
From: comex <comexk@...il.com>
To: Bart Van Assche <bvanassche@....org>
Cc: David Laight <david.laight.linux@...il.com>,
Laurent Pinchart <laurent.pinchart@...asonboard.com>,
Jan Engelhardt <ej@...i.de>,
"H. Peter Anvin" <hpa@...or.com>,
Greg KH <gregkh@...uxfoundation.org>,
Boqun Feng <boqun.feng@...il.com>,
Miguel Ojeda <miguel.ojeda.sandonis@...il.com>,
Christoph Hellwig <hch@...radead.org>,
rust-for-linux <rust-for-linux@...r.kernel.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
David Airlie <airlied@...il.com>,
linux-kernel@...r.kernel.org,
ksummit@...ts.linux.dev
Subject: Re: C aggregate passing (Rust kernel policy)
> On Feb 21, 2025, at 2:13 PM, Bart Van Assche <bvanassche@....org> wrote:
>
> Initially, early implementations of std::string may have used CoW or reference counting techniques.
More accurately, you can’t have one without the other. std::string is mutable, so reference counting requires copy-on-write (and of course copy-on-write wouldn’t make sense without multiple references).
> Notably, the C++11 standard explicitly banned CoW for std::string in order to avoid its pitfalls.
> [ ... ]
The C++11 spec doesn’t explicitly say ‘thou shalt not copy-on-write’, but it requires std::string's operator[] to be O(1), which effectively bans it because copying is O(n).
Which forced libstdc++ to break their ABI, since they were using copy-on-write before.
Powered by blists - more mailing lists