Date: Mon, 18 Dec 2023 18:24:53 -0500
On Mon, Dec 18, 2023 at 3:11 PM Frederick Virchanza Gotham via
Std-Proposals <std-proposals_at_[hidden]> wrote:
> On Mon, Dec 18, 2023 at 4:55 PM Thiago Macieira wrote:
> >
> > There shouldn't be unaligned versions. The parameters should be plain T
> > pointers.
>
> 'std::unaligned' will need to relocate an object into (and back out
> of) unaligned space, and therefore we need an void* or byte*.
>
At least in all the existing "relocation" proposals, the verb "relocate"
specifically means ending the lifetime of *an object of type T* in address
`src`, and constructing a similar-valued *object of type T* in address
`dest`. There is no such thing as "an object of type T" in space that's
misaligned for a T.
There are at least two mental models you can have of your "unaligned<T>"
thing:
(1) It's an opaque type similar to `atomic<T>` that *behaves roughly like a
T* but just happens to have an (inaccessible) object representation that
occupies less-aligned storage. This is how I initially envisioned
what Gašper and Lénárd were talking about.
(2) It's a buffer of bytes into which you can *dehydrate* an actual object
of type T and from which you can *rehydrate* an actual object of type T,
but which stores plain old bytes in between. Here you have to be really
clear about whether the type is "linear" — e.g. can you rehydrate two
copies of the object from a single buffer? — and the model in general feels
more complicated; but, on the plus side, it seems to give you two really
clear verbs for dehydration and rehydration. P1144 does not give you those
verbs at all; but, a competent performance-minded programmer will quickly
observe that if `is_trivially_relocatable_v<U>` then both *dehydrate* and
*rehydrate* can be accomplished *in practice* via memcpy (as long as the
intervening buffer is treated "linearly" in the sense above). As I said in
my previous message
<https://lists.isocpp.org/std-proposals/2023/12/8632.php>, there are some
really interesting patterns being developed in this space.
...You can have either of those mental models; and maybe others. But you
cannot have the mental model that "an object of type T" ever *exists* in
misaligned space, or that you're "*relocating*" from an object of type T
into misaligned space. That's simply physically impossible.
–Arthur
Std-Proposals <std-proposals_at_[hidden]> wrote:
> On Mon, Dec 18, 2023 at 4:55 PM Thiago Macieira wrote:
> >
> > There shouldn't be unaligned versions. The parameters should be plain T
> > pointers.
>
> 'std::unaligned' will need to relocate an object into (and back out
> of) unaligned space, and therefore we need an void* or byte*.
>
At least in all the existing "relocation" proposals, the verb "relocate"
specifically means ending the lifetime of *an object of type T* in address
`src`, and constructing a similar-valued *object of type T* in address
`dest`. There is no such thing as "an object of type T" in space that's
misaligned for a T.
There are at least two mental models you can have of your "unaligned<T>"
thing:
(1) It's an opaque type similar to `atomic<T>` that *behaves roughly like a
T* but just happens to have an (inaccessible) object representation that
occupies less-aligned storage. This is how I initially envisioned
what Gašper and Lénárd were talking about.
(2) It's a buffer of bytes into which you can *dehydrate* an actual object
of type T and from which you can *rehydrate* an actual object of type T,
but which stores plain old bytes in between. Here you have to be really
clear about whether the type is "linear" — e.g. can you rehydrate two
copies of the object from a single buffer? — and the model in general feels
more complicated; but, on the plus side, it seems to give you two really
clear verbs for dehydration and rehydration. P1144 does not give you those
verbs at all; but, a competent performance-minded programmer will quickly
observe that if `is_trivially_relocatable_v<U>` then both *dehydrate* and
*rehydrate* can be accomplished *in practice* via memcpy (as long as the
intervening buffer is treated "linearly" in the sense above). As I said in
my previous message
<https://lists.isocpp.org/std-proposals/2023/12/8632.php>, there are some
really interesting patterns being developed in this space.
...You can have either of those mental models; and maybe others. But you
cannot have the mental model that "an object of type T" ever *exists* in
misaligned space, or that you're "*relocating*" from an object of type T
into misaligned space. That's simply physically impossible.
–Arthur
Received on 2023-12-18 23:25:07