Date: Fri, 15 Dec 2023 17:23:11 -0300
On Friday, 15 December 2023 11:15:04 -03 Frederick Virchanza Gotham via Std-
Proposals wrote:
> I'm telling you, we can write a very versatile 'std::unaligned' that will
> work with any type that is "is_trivially_relocatable_v<T> ||
> is_nontrivially_relocatable_v<T>".
But you're not saying why we should have that in the first place. Sure you can
do it. Is it a good idea?
If the type isn't trivially relocatable (implying it has some dependency on
its own address), doing the relocation from unaligned memory to the stack in
order to destroy sounds like a bad idea. Better not to support it in the first
place.
I'm not sold on non-trivially-destructible unaligneds in the first place. What
are the use-cases for them? How often are they needed? And why weren't those
types coded with unaligned members instead of forcing the user to unalign the
entire object?
Proposals wrote:
> I'm telling you, we can write a very versatile 'std::unaligned' that will
> work with any type that is "is_trivially_relocatable_v<T> ||
> is_nontrivially_relocatable_v<T>".
But you're not saying why we should have that in the first place. Sure you can
do it. Is it a good idea?
If the type isn't trivially relocatable (implying it has some dependency on
its own address), doing the relocation from unaligned memory to the stack in
order to destroy sounds like a bad idea. Better not to support it in the first
place.
I'm not sold on non-trivially-destructible unaligneds in the first place. What
are the use-cases for them? How often are they needed? And why weren't those
types coded with unaligned members instead of forcing the user to unalign the
entire object?
-- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel DCAI Cloud Engineering
Received on 2023-12-15 20:23:17