C++ Logo

std-proposals

Advanced search

Re: [std-proposals] Add [[no_unique_address]] attribute to std::pair

From: connor horman <chorman64_at_[hidden]>
Date: Fri, 25 Aug 2023 12:52:06 -0400
Could it be implementation-defined/unspecified whether the fields of
`std::pair` and `std::tuple` are `[[no_unique_address]`?
That would allow existing implementations to keep the definitions as-is,
and new implementations (or ones that are willing to break abi) can add the
attribute in. I'm not sure that is allowed as-is in the standard.

On Fri, 25 Aug 2023 at 12:30, Barry Revzin via Std-Proposals <
std-proposals_at_[hidden]> wrote:

>
>
> On Fri, Aug 25, 2023, 10:08 AM Hewill Kang via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
>> Hi all experts,
>>
>> boost::compressed_pair is widely used as a replacement for std::pair in
>> order to save storage when one of the data members is an empty class.
>>
>> The __compressed_pair helper class, which is similar to
>> boost::compressed_pair, is also widely used in libc++.
>>
>> I wonder if we could get this compression optimization at almost no cost
>> if add the C++ [[no_unique_address]] attribute to the members of
>> std::pair:
>>
>> namespace std {
>> template<class T1, class T2>
>> struct pair {
>> using first_type = T1;
>> using second_type = T2;
>>
>> [[no_unique_address]] T1 first; // <- here
>> [[no_unique_address]] T2 second; // <- here
>> };
>> }
>>
>> This looks reasonable to me, and almost achieves the equivalent of
>> boost::compressed_pair.
>>
>> What do you guys think about this? This seems like a great enhancement to
>> me. Or does this kind of practice bring certain issues?
>>
>> Comments are very welcome.
>>
>> Hewill
>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
>
> std::pair and std: tuple aren't even trivially copyable when they could be
> due to ABI. This would be even worse.
>
> Sorry,
>
> Barry
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>

Received on 2023-08-25 16:52:19