msvc::no_unique_address

According to https://devblogs.microsoft.com/cppblog/msvc-cpp20-and-the-std-cpp20-switch/#c20-no_unique_address , MSVC ignores [[no_unique_address]], but some versions provide [[msvc::no_unique_address]] and actually act on it (this has also been added to compatible compilers like clang-18+).
Would it make sense for BOOST_ATTRIBUTE_NO_UNIQUE_ADDRESS to expand to this attribute under the right conditions?

Sorry to be 2 years late to this party!

I'm not sure about this: doesn't the ABI breakages make this problematic?

Changing the ABI is the whole point of this attribute, it should be up to the user to decide if they want it or not, and if they use the macro, it means they want the different ABI. The user may be another boost library, that itself has users who may not be aware of this, so indeed it can cause problems I guess, but the existing BOOST_ATTRIBUTE_NO_UNIQUE_ADDRESS already causes binary incompatibility between the last version of gcc before the attribute was implemented and the next one.
Still, your choice, there is some sense in following Microsoft's choice of ~~penalizing their own users until they switch to a better compiler~~ favoring ABI compatibility at all cost (other compilers aren't much better there, ABI compatibility is killing C++).

FWIW, under msvc-14.2, this attribute works under C++14 and C++17, but causes a warning

C:\drone\boost-root\boost/unordered/detail/opt_storage.hpp(18): warning C4848: support for attribute 'msvc::no_unique_address' in C++17 and earlier is a vendor extension

which is a problem for /WX builds.

It's not clear whether the right course of action here is for every use to disable the warning (as we'll probably end up doing in Unordered), or not enable the attribute for msvc-14.2 under the earlier language modes.

msvc-14.3 doesn't seem to warn.

IMHO the warning should be disabled here in Boost.Config, even if that can't be guarded with warning(push)/warning(pop) (which it can't)

This is a general warning, it's not specific to msvc::no_unique_address, and shouldn't be disabled globally.

There seem to be a lot of uses of BOOST_ATTRIBUTE_NO_UNIQUE_ADDRESS, so the most reasonable fix would probably be to not use msvc::no_unique_address on msvc-14.2.

Update: it's also a problem under msvc-14.3, but only up to and including version 1942 (https://godbolt.org/z/bYGKdaoG5). It's fixed in 1943 (https://godbolt.org/z/b3b3dTq8x).

#557

On second thought, updating msvc-14.3 silently changing the layout of classes using BOOST_ATTRIBUTE_NO_UNIQUE_ADDRESS might be problematic. We do this for different compiler versions (which is why we mangle the toolset name into the library name), but doing it within the same compiler version might be a bit too much.

So the options here are

Always use [[msvc::no_unique_address]] on msvc-14.3 and live with the warning if it's not updated enough;
Never use [[msvc::no_unique_address]] on msvc-14.3;
Only use [[msvc::no_unique_address]] on msvc-14.2 and msvc-14.3 when C++20 or later.

Option 3 seems reasonable, the rationale is that this is a C++20 feature, so if someone is using [[no_unique_address]] in their code, then the layout should be expected to change in C++20 or later anyway (this had better be documented!). I can see this may be problematic in some instances though, so I'm happy to go with whatever the consensus is.

Option 3 seems the most reasonable to me, too.

3a: only use [[msvc::no_unique_address]] under C++20 or later regardless of compiler version (Only use [[msvc::no_unique_address]] on C++20 or later. Refs #499. #558)
3b: use it under C++20 or later for msvc-14.2 and 14.3, use it for all C++ standards for msvc-14.5

3a seems more regular to me (it's what all non-MSVC compilers would do), which is why I made the PR with it.

msvc::no_unique_address is a vendor extension (it is in the name), limiting it to the case where the standard no_unique_address is supposed to exist (but is still a dummy AFAIK) sounds sad to me, especially since I haven't seen any sign that MS ever intends to change the default from C++14. But it is your (collective) choice.
For non-MSVC compilers, Boost.Config uses __has_cpp_attribute (or __has_attribute) to determine if it can use the attribute, and happily uses it in C++98 mode if the compiler lets it.

The warning is particularly dumb. Gcc didn't take me up on my offer to implement -Wwarning (Warning: warnings are enabled, meant to be included in -Weverything), but maybe I should suggest the same to Microsoft.

Is there some tacit expectation in the industry that Clang for Windows should produce binaries that are ABI-compatible with VS?

There is, yes. Clang for Windows is ABI compatible with MSVC. That's presumably why it follows the MSVC behavior with respect to [[no_unique_address]].

Hey: https://godbolt.org/z/qjK4a9116

Ah very good point.

Why does the version check use _MSC_FULL_VER by the way?

Why does the version check use _MSC_FULL_VER by the way?

Documented in the Microsoft link provided at #553 (https://devblogs.microsoft.com/cppblog/msvc-cpp20-and-the-std-cpp20-switch/#c20-no_unique_address).

OK, I'll do a PR for 3d later today. :-)

#559

This should hopefully be the last iteration and should address everyone's concerns.

The exact same #if block should then be added to Clang.

Any further comments from anyone? Are we all happy with #559?

I didn't know you could do that with __pragma's, but if it works I'm happy ;)

That's actually the purpose of __pragma.

Feel free to merge at your earliest convenience. :-)

Done!

The Clang pull request is here: #560

Enable [[msvc::no_unique_address]] attribute.

Disable C4848 around [[msvc::no_unique_address]]; only use it on msvc…

Navigation Menu

Repository navigation

msvc::no_unique_address #499

3 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

msvc::no_unique_address #499

Description

Activity

jzmaddock commented on Jul 12, 2026

mglisse commented on Jul 12, 2026

pdimov commented on Sep 12, 2026

joaquintides commented on Sep 12, 2026

pdimov commented on Sep 12, 2026

pdimov commented on Sep 12, 2026

pdimov commented on Sep 12, 2026

pdimov commented on Sep 12, 2026

pdimov commented on Sep 13, 2026

jzmaddock commented on Sep 13, 2026

joaquintides commented on Sep 13, 2026

pdimov commented on Sep 13, 2026

mglisse commented on Sep 13, 2026

3 remaining items

joaquintides commented on Sep 14, 2026

pdimov commented on Sep 14, 2026

joaquintides commented on Sep 14, 2026

pdimov commented on Sep 14, 2026

pdimov commented on Sep 14, 2026

joaquintides commented on Sep 14, 2026

pdimov commented on Sep 14, 2026

pdimov commented on Sep 14, 2026

pdimov commented on Sep 15, 2026

jzmaddock commented on Sep 18, 2026

pdimov commented on Sep 18, 2026

jzmaddock commented on Sep 18, 2026

pdimov commented on Sep 28, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions