[prev in list] [next in list] [prev in thread] [next in thread] 

List:       boost
Subject:    [boost] Re: Guidelines to support Boost components and their std alternatives
From:       Alexander Grund via Boost <boost () lists ! boost ! org>
Date:       2025-09-11 6:50:39
Message-ID: 25192e21-32b8-4962-a94d-b5b249d18724 () tu-dresden ! de
[Download RAW message or body]

[Attachment #2 (text/plain)]


Am 10.09.25 um 20:34 schrieb Matt Gruenke via Boost:
> Дмитрий Архипов Wrote:
>
>> чт, 4 сент. 2025 г. в 20:16, Matt Gruenke via Boost<boost@lists.boost.org>:
>>> I don't know about any official policy on the matter, but I and others
>>> have previously gotten burned by having it be a compile-time check at
>>> the point of inclusion.  I feel strongly that the proper solution is to
>>> rely on Boost Config, so that everything compiling against a build of
>>> Boost will compile in the same way and thereby avoid any ODR violations.
>> This doesn't solve the issue, it just pushes the problem to link time.
> I think it's reasonable to expect people to compile, link, and run against the
> same build of Boost.
You could still have an independently compiled Boost with C++11, a 
dependency using Boost compiled with C++14 and your own library using 
C++17 causing potentially 3 different "contents" of the Boost headers.
I'm fine with a link-time error as the alternative would be an 
ODR-violation so detecting it at compile/linktime is better.
>> E.g. you build Boost in a configuration that doesn't have std::optional,
>> then you link to it in a configuration that does. This is actually
>> trivially done by accident (e.g. you build Boost with a compiler that
>> defaults to C++14, then you use it with C++17 enabled).
> This illustrates perfectly why it should not be a compile-time check, at
> the point of inclusion.  The Boost Config headers are generated when
> boost, itself, is compiled.  When a precompiled build of boost is installed,
> the config headers come with it.
The config headers are not generated (yet). They are kept as-is during 
installation and just contain a set of macros to enable disable stuff 
based on current compiler and flags.
Or are you proposing that Boost config headers *should* be generated?
>> The least surprising way to do this is to ask users to explicitly
>> enable standard equivalents.
> This fundamentally doesn't work, when the header you're including is
> also included and used by code in one or more of the non- header-only
> boost libraries you're linking against.  That's how you get ODR violations.
Or by code of dependencies. Even header-only dependencies could cause 
issues when you define BOOST_X=1 but one of the dependencies headers 
defines BOOST_X=2 and you might have different TU where one does include 
that dependency header and one that does not.
> The definition of types must be consistent by all code which includes
> them and might be linked into the same executable or library.  That's why
> Boost.Config is the correct solution to this problem, to the extent it's not
> simply a hard-wired requirement of the library.
What is meant by the last sentence?
> Peter Dimov avoids the problem by essentially doing away with any choice.
> That also works, so long as everyone can agree on the minimum version
> requirement.
"minimum version" of what? E.g. you'd actually need to agree on a 
specific C++ version and use that for the whole compilation including 
Boost and potentially other dependencies using Boost.

["smime.p7s" (application/pkcs7-signature)]

_______________________________________________
Boost mailing list -- boost@lists.boost.org
To unsubscribe send an email to boost-leave@lists.boost.org
https://lists.boost.org/mailman3/lists/boost.lists.boost.org/
Archived at: https://lists.boost.org/archives/list/boost@lists.boost.org/message/LK6BFIMMAREFJR5HYZAVQV52CYG542OH/ \


--===============7098694196415590901==--



[prev in list] [next in list] [prev in thread] [next in thread]