Il 30/10/25 18:02, Thiago Macieira via Std-Proposals ha scritto:
> On Thursday, 30 October 2025 08:15:33 Pacific Daylight Time Giuseppe D'Angelo
> via Std-Proposals wrote:
>> No. P2786 / trivial relocation as per the current working draft doesn't
>> grant any special features to realloc(). std::trivially_relocate is the
>> only entry point for trivial relocation.
>
> Then we won't use this in Qt.

There's multiple use cases:

* One is indeed vector reallocation, where we want to keep using
realloc() or similar. Assuming things stay as they are today, C++26
won't give us anything to satisfy this use case so we'll be stuck in
"UB that works in practice" land.

The only thing we might decide to do is to amend the detection inside
QVector, and to use realloc() not only on the types that we mark as
trivially relocatable using Qt's markup, but also to those that are
bitwise trivially relocatable as per the language.


* Another is inserting/erasing in the middle of a vector. Here we could
actually use std::trivially_relocate() instead of memmove(), as the
result is the same.



(And as a side note, we'll need to develop a Clazy plugin that adds the
new pseudo-keywords to all Qt classes that currently have our custom
markup...)

>
>> From my understanding, P3858 (likely C++29 material at this point)
>> wants to correct this by introducing a lower-level primitive than
>> std::trivially_relocate.
>
> Great, so we can rely on it in 2033-2035.
>
> Though if the current trivial relocatability is yanked, we won't get a
> replacement fix until the same time frame, so it's not a big deal for us to
> continue with our Q_DECLARE_TYPEINFO solution until then.

We'll certainly continue with Q_DECLARE_TYPEINFO for a very long time
anyhow :)

>
>> The idea is that you will be able to move object representations in
>> memory using *any* facility you like (including realloc()), but then you
>> need to call std::restart_lifetime<T>() to tell the abstract machine¹
>> that there are objects of type T at the destination whose lifetime needs
>> to be started.
>
> I'm fine with that, so long as that is an O(1) operation for an array of any
> size for *properly* trivially relocatable types.

If there's nothing to realize on the physical machine, what else could
it be?


> So long as we have this:
>
>> I'm also 99% sure that P3858 does not solve the problem of detecting
>> bitwise trivial relocability (detection that we need for things like
>> QVariant), but that's a separate can of worms...
>
> Because we either need to type-erase the operation for QVariant, or we need to
> reject allowing this type to live in QVariant's "small object optimisation"
> buffer, if the operation needs to do anything that memcpy() didn't.

That's precisely the use case for detecting bitwise trivial relocation.

My 2 c,
--
Giuseppe D'Angelo | giuseppe.dangelo_at_[hidden] | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - Trusted Software Excellence