[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACb0b4mFc-raAkU2MFrwRxEWPbnHyXx_0obexyembFzFrQhBHg@mail.gmail.com>
Date: Fri, 28 Jun 2024 22:15:06 +0100
From: Jonathan Wakely <jwakely@...hat.com>
To: libc-coord@...ts.openwall.com
Cc: Florian Weimer <fweimer@...hat.com>, Jonathan Wakely <jwakely.gcc@...il.com>,
Zijun Zhao <zijunzhao@...gle.com>
Subject: Re: aligned_realloc()
On Fri, 28 Jun 2024 at 20:47, enh <enh@...gle.com> wrote:
>
> On Fri, Jun 28, 2024 at 3:41 PM Florian Weimer <fweimer@...hat.com> wrote:
> >
> > * Jonathan Wakely:
> >
> > >> This would also be helpful in the implementation of data structures such
> > >> as std::vector, where in-place resizing and moving allocations require
> > >> different execution paths.
> > >
> > > Probably not, because std::vector goes through the C++ Allocator
> > > interface, which is very unlikely to expose something like this.
> >
> > Does the default allocator have to call ::operator new(std::size_t)?
> > Is this an interposable interface, similar to malloc?
>
> https://en.cppreference.com/w/cpp/memory/allocator
>
> there have certainly been PRs suggesting adding extra functionality,
> but they don't seem to get anywhere. (iirc "why don't we have
> something relloc()-like?" has come up a few times, but i couldn't find
> the PRs in a couple of minutes' searching and gave up.)
See https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p0401r6.html
(approved for C++23) which links to a few failed realloc proposals,
and explains why they failed.
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.
