Are BOOST_STATIC_ASSERT() and BOOST_STATIC_CONSTANT() still necessary?

Hi everyone, I was wondering if there's still any compiler among those generally supported by Boost which requires either BOOST_STATIC_ASSERT() or BOOST_STATIC_CONSTANT(). I'd like to get rid of them for DynamicBitset. Thanks. -- Gennaro Prota <https://prota.dev>

On Wed, Sep 10, 2025 at 8:08 AM Gennaro Prota via Boost < boost@lists.boost.org> wrote:
Hi everyone,
I was wondering if there's still any compiler among those generally supported by Boost which requires either BOOST_STATIC_ASSERT() or BOOST_STATIC_CONSTANT(). I'd like to get rid of them for DynamicBitset.
2-arg static_assert is available in C++11 and up. If you want 1-arg static_assert in C++11 you need BOOST_STATIC_ASSERT. For reference, I use BOOST_STATIC_ASSERT everywhere, as my libraries support C++11. Thanks

On 9/10/2025 5:18 PM, Vinnie Falco wrote:
On Wed, Sep 10, 2025 at 8:08 AM Gennaro Prota via Boost <boost@lists.boost.org <mailto:boost@lists.boost.org>> wrote:
Hi everyone,
I was wondering if there's still any compiler among those generally supported by Boost which requires either BOOST_STATIC_ASSERT() or BOOST_STATIC_CONSTANT(). I'd like to get rid of them for DynamicBitset.
2-arg static_assert is available in C++11 and up.
If you want 1-arg static_assert in C++11 you need BOOST_STATIC_ASSERT. Ah, right :-). I forgot 1-arg static_assert is C++17 or later.
Thanks. -- Gennaro Prota <https://prota.dev>

Vinnie Falco wrote:
On Wed, Sep 10, 2025 at 8:08 AM Gennaro Prota via Boost < boost@lists.boost.org> wrote:
Hi everyone,
I was wondering if there's still any compiler among those generally supported by Boost which requires either BOOST_STATIC_ASSERT() or BOOST_STATIC_CONSTANT(). I'd like to get rid of them for DynamicBitset.
2-arg static_assert is available in C++11 and up.
If you want 1-arg static_assert in C++11 you need BOOST_STATIC_ASSERT.
For reference, I use BOOST_STATIC_ASSERT everywhere, as my libraries support C++11.
I define my own local macro and use that instead to avoid the dependency.

On Wed, Sep 10, 2025 at 8:30 AM Peter Dimov via Boost <boost@lists.boost.org> wrote:
I define my own local macro and use that instead to avoid the dependency.
I guess that's worth it if you can make your library have zero dependencies, and if not though how much is being gained? Boost.StaticAssert has just one include (and it looks more beefy than one might expect): https://github.com/boostorg/static_assert/blob/develop/include/boost/static_... Thanks

Vinnie Falco wrote:
On Wed, Sep 10, 2025 at 8:30 AM Peter Dimov via Boost <boost@lists.boost.org <mailto:boost@lists.boost.org> > wrote:
I define my own local macro and use that instead to avoid the dependency.
I guess that's worth it if you can make your library have zero dependencies, and if not though how much is being gained? Boost.StaticAssert has just one include (and it looks more beefy than one might expect):
A package/repo download is still a download, even if it contains a single header. We probably need to move that into Config at some point (and drop all the pre-11 stuff.) https://github.com/boostorg/endian/blob/c0b5c80603b8de7eeea8724c9a4f2761c3df...

On Wed, Sep 10, 2025 at 8:51 AM Peter Dimov <pdimov@gmail.com> wrote:
A package/repo download is still a download, even if it contains a single header.
Have we considered bundling the diagnostic-related things together in one repository? This could reduce the number of explicit packages. Maybe it should all go into Config? Thanks

El 10/09/2025 a las 22:17, Vinnie Falco via Boost escribió:
On Wed, Sep 10, 2025 at 8:51 AM Peter Dimov <pdimov@gmail.com> wrote:
A package/repo download is still a download, even if it contains a single header.
Have we considered bundling the diagnostic-related things together in one repository? This could reduce the number of explicit packages. Maybe it should all go into Config?
Long time ago I proposed merging Assert and StaticAssert into Config, maybe adding some workaround utilities, so I consider your proposal as a good idea ;-) Best, Ion

On Thu, Sep 11, 2025 at 3:25 PM Ion Gaztañaga via Boost < boost@lists.boost.org> wrote:
Long time ago I proposed merging Assert and StaticAssert into Config, maybe adding some workaround utilities, so I consider your proposal as a good idea ;-)
Are you proposing: #include <boost/config/assert.hpp> #include <boost/config/static_assert.hpp> and that these would be in the same Git repository? Thanks

El 12/09/2025 a las 0:38, Vinnie Falco escribió:
On Thu, Sep 11, 2025 at 3:25 PM Ion Gaztañaga via Boost <boost@lists.boost.org <mailto:boost@lists.boost.org>> wrote:
Long time ago I proposed merging Assert and StaticAssert into Config, maybe adding some workaround utilities, so I consider your proposal as a good idea ;-)
Are you proposing:
#include <boost/config/assert.hpp> #include <boost/config/static_assert.hpp>
and that these would be in the same Git repository?
Thanks
Yeah. But we should also maintain old paths <(boost/assert.hpp> <boost/current_function.hpp>, <boost/assert/source_location.hpp> and <boost/static_asset.hpp>) to avoid breaking code. Best, Ion PS: In the future boost/assert could support hardening modes for boost libraries (something similar to https://libcxx.llvm.org/Hardening.html)

Am 10.09.2025 um 17:19 schrieb Vinnie Falco via Boost:
On Wed, Sep 10, 2025 at 8:08 AM Gennaro Prota via Boost < boost@lists.boost.org> wrote:
BOOST_STATIC_CONSTANT
This macro sounds ancient. I've never seen it before, or used it. Probably safe to remove :) Rarely used? I find it in just 711 out of 58'459 files in Boost 1.89
What's really bugging me is the use of BOOST_CONSTEXPR_OR_CONST at namespace scope in header files. You can easily end up in TU-local entities which are deprecated in traditional compilations, and outright forbidden in modules / header units. I have replaced them with BOOST_INLINE_CONSTEXPR in some libraries to get an actually usable module Boost. Dani -- PGP/GPG: 2CCB 3ECB 0954 5CD3 B0DB 6AA0 BA03 56A1 2C4638C5

On Wed, Sep 10, 2025 at 8:46 AM Daniela Engert <dani@ngrt.de> wrote:
What's really bugging me is the use of BOOST_CONSTEXPR_OR_CONST at namespace scope in header files.
Should we get pull requests opened to all the libraries that use BOOST_CONSTEXPR_OR_CONST to replace them with BOOST_INLINE_CONSTEXPR? Thanks

Am 10.09.2025 um 17:48 schrieb Vinnie Falco:
On Wed, Sep 10, 2025 at 8:46 AM Daniela Engert <dani@ngrt.de> wrote:
What's really bugging me is the use of BOOST_CONSTEXPR_OR_CONST at namespace scope in header files.
Should we get pull requests opened to all the libraries that use BOOST_CONSTEXPR_OR_CONST to replace them with BOOST_INLINE_CONSTEXPR?
May be. For *my* in-house distribution of 1.89, I have given - Boost.Accumulators - Boost.Container - Boost.Move - Boost.Parameter this kind of treatment, or had to handle entities in anonymous namespaces with the same effect. I didn't look into all libraries, only the ones that we use in our company. Hence, I have only 71 libraries in my module 'Boost'. Dani -- PGP/GPG: 2CCB 3ECB 0954 5CD3 B0DB 6AA0 BA03 56A1 2C4638C5

Daniela Engert wrote:
What's really bugging me is the use of BOOST_CONSTEXPR_OR_CONST at namespace scope in header files. You can easily end up in TU-local entities which are deprecated in traditional compilations, and outright forbidden in modules / header units. I have replaced them with BOOST_INLINE_CONSTEXPR in some libraries to get an actually usable module Boost.
There was no good way to have a namespace scope constant before C++17, so it's not that surprising that every library written before that is technically broken.
participants (5)
-
Daniela Engert
-
Gennaro Prota
-
Ion Gaztañaga
-
Peter Dimov
-
Vinnie Falco