[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3331500.4sosBPzcNG@tjmaciei-mobl5>
Date: Fri, 31 Oct 2025 12:15:51 -0700
From: Thiago Macieira <thiago@...ieira.org>
To: paulmck@...nel.org
Cc: Alejandro Colomar <alx@...nel.org>, Paul Eggert <eggert@...ucla.edu>,
libc-alpha@...rceware.org, musl@...ts.openwall.com,
"A. Wilcox" <AWilcox@...cox-tech.com>,
Lénárd Szolnoki <cpp@...ardszolnoki.com>,
Collin Funk <collin.funk1@...il.com>,
Arthur O'Dwyer <arthur.j.odwyer@...il.com>,
Jonathan Wakely <jwakely@...hat.com>
Subject: Re: Re: realloci(): A realloc() variant that works in-place
On Friday, 31 October 2025 11:12:10 Pacific Daylight Time Paul E. McKenney
wrote:
> In C++, presumably, only std::movable types should be passed to realloc(),
> right? In C, yes, this is a definitely an issue, but then again it has
> been since the advent of realloc().
Correct (wrong terminology, see below). That would be extremely useful, but is
half of the problem. It would still be useful to apply the resize-in-place
operation to types that cannot be realloc()ed. Like libstdc++'s std::string.
Terminology-wise, the new term is "relocatable", not "movable", because
"movable" became used for something different in C++11 (something that had a
move constructor or move-assignment operator). Then in the lead-up to C++26
with paper P1144, it became "trivially relocatable": can be moved by memcpy().
It has since become "bitwise trivially relocatable" for reasons which do not
bear elaborating in this discussion.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Principal Engineer - Intel Data Center - Platform & Sys. Eng.
Download attachment "signature.asc" of type "application/pgp-signature" (871 bytes)
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
