C++ Logo

std-proposals

Advanced search

Re: [std-proposals] Replace an object -- but retain old object if new object fails to construct

From: Oliver Hunt <oliver_at_[hidden]>
Date: Wed, 29 Oct 2025 03:19:48 -0700
> On Oct 29, 2025, at 3:07 AM, Frederick Virchanza Gotham via Std-Proposals <std-proposals_at_[hidden]> wrote:
>
>
>
> On Tuesday, October 28, 2025, Giuseppe D'Angelo wrote:
>
>> The current specification allows for trivial relocation of polymorphic types, on *any* platform. Polymorphism simply isn't taken into account when deciding whether a class is trivially relocatable or not:

It disallows them on unions.

>>
>> struct PolyTR {
>> virtual void f();
>> };
>>
>> static_assert( std::is_polymorphic_v<PolyTR> );
>> static_assert( std::is_trivially_relocatable_v<PolyTR> ); // OK, everywhere
>
> We need an arm64e compiler-and-executor up on GodBolt. We need to be able to test all this stuff out.

You mean clang? You don’t need an executor to get this information.

Matt provides plenty of information about setting up your match, it is also not reasonable to randomly flag him on a standards list for a topic that is not related to CE. This was absolutely inappropriate.

> We really need this . . . before the talk on November 5th about trivial relocation.


This is nonsense.

> I'd tried setting up virtual machines and Qemu and cross-compiling and the like, but haven't got a viable arm64e compiler and executor working


I do not understand why you think you need an executor for this? Pointer authentication is not mysterious or magic.

For the topic at hand clang currently does not support trivial relocation of polymorphic types - and reports correctly that such are not. There are large numbers of NB comments demanding trivial relocation be a guaranteed bitwise copy, so it is on the fence whether such relocation is guaranteed.

—Oliver

Received on 2025-10-29 10:19:50