[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3de20b82-ce6f-4114-a65a-0129be5e75dc@paulmck-laptop>
Date: Fri, 31 Oct 2025 12:49:28 -0700
From: "Paul E. McKenney" <paulmck@...nel.org>
To: Thiago Macieira <thiago@...ieira.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 Fri, Oct 31, 2025 at 12:15:51PM -0700, Thiago Macieira wrote:
> 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.
I stand corrected, thank you!
Thanx, Paul
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.
