C++ Logo

std-proposals

Advanced search

Re: [std-proposals] std::sizeof_minus_trailing_padding

From: Jason McKesson <jmckesson_at_[hidden]>
Date: Sun, 3 Dec 2023 21:51:05 -0500
On Sun, Dec 3, 2023 at 5:26 PM Thiago Macieira via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> On Sunday, 3 December 2023 09:55:30 PST Frederick Virchanza Gotham via Std-
> Proposals wrote:
> > I didn't know about the existence of no_unique_address until a few
> > days ago, and so now I'll be more careful with 'memset' and 'memcpy'.
> > The whole idea of 'potentially-overlapping objects' is a bit mad and I
> > would imagine that a few people were hesitant to bring it into C++.
>
> You shouldn't need to be.
>
> Some other code using NUA on your own types is wrong. One should only use NUA
> for types that declare that they don't need unique addresses. There's no
> property for this, therefore using NUA on arbitrary types is wrong.

While I can understand that, I don't really agree.

The primary purpose of NUA was for *empty* types, not to slip
something into the padding bits of a non-empty type. Yes, that's a
thing it *can* do, but that's not what it's for. Remember: the feature
was added so that you could have the member equivalent of empty base
optimizations. And one of the main purposes of EBO is for types like
allocators which are frequently empty and thus should be declared NUA
when they're members.

So if "using NUA on arbitrary types is wrong", then the feature is
fundamentally broken.

Received on 2023-12-04 02:51:21