[static_string] Removing support for BOOST_STATIC_STRING_STANDALONE?
Hi, while discussing a PR on GitHub (<https://github.com/boostorg/static_string/pull/67>), we ran into the question of whether BOOST_STATIC_STRING_STANDALONE should still be supported. What's your take on it? Personally, I lean toward minimizing conditional compilation wherever possible. Also, the macro is used to avoid dependencies which are easily avoided anyway, so why not avoiding them unconditionally and have "standalone mode" as the only option? -- Gennaro Prota <https://prota.dev>
On Wed, Oct 8, 2025 at 9:50 AM Gennaro Prota via Boost < boost@lists.boost.org> wrote:
BOOST_STATIC_STRING_STANDALONE
The documentation says:
In standalone mode, C++17 is required but no libraries except for the standard library are needed.
I'd be curious to know who is using this mode, before we go about removing or changing it. Thanks
On Wed, Oct 8, 2025 at 10:34 PM Vinnie Falco via Boost <boost@lists.boost.org> wrote:
On Wed, Oct 8, 2025 at 9:50 AM Gennaro Prota via Boost < boost@lists.boost.org> wrote:
BOOST_STATIC_STRING_STANDALONE
The documentation says:
In standalone mode, C++17 is required but no libraries except for the standard library are needed.
I'd be curious to know who is using this mode, before we go about removing or changing it.
We are using this mode in our projects which we currently build with GCC 14.2 and C++23. The main/only reason is that we use std::string_view throughout the projects since C++17 and we don't want to convert to boost::string_view where the boost::static_string is used. Maybe there is another way to achieve the same but this was the one that we found in the past and we just stick to it.
Thanks _______________________________________________ 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/KEDA5MZY...
We are using this mode in our projects which we currently build with GCC 14.2 and C++23. The main/only reason is that we use std::string_view throughout the projects since C++17 and we don't want to convert to boost::string_view where the boost::static_string is used.
One of our boost::string_views support conversion from std::string_view. So if that was used in the interface of static_string then you can then pass std::string_view without caring that it is actually converted to a boost string_view (optimized out by the compiler later on) I guess your use case would be covered by that?
|On Thu, Oct 9, 2025 at 2:15 PM Alexander Grund via Boost <boost@lists.boost.org> wrote:
We are using this mode in our projects which we currently build with GCC 14.2 and C++23. The main/only reason is that we use std::string_view throughout the projects since C++17 and we don't want to convert to boost::string_view where the boost::static_string is used.
One of our boost::string_views support conversion from std::string_view.
So if that was used in the interface of static_string then you can then pass std::string_view without caring that it is actually converted to a boost string_view (optimized out by the compiler later on) I guess your use case would be covered by that?
Yes, this will be sufficient for our usage. I'mt not sure how we missed this at the time. Thank you.
_______________________________________________ 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/ANLNXV3Y...
On 8 Oct 2025 19:49, Gennaro Prota via Boost wrote:
Hi,
while discussing a PR on GitHub (<https://github.com/boostorg/ static_string/pull/67>), we ran into the question of whether BOOST_STATIC_STRING_STANDALONE should still be supported. What's your take on it? Personally, I lean toward minimizing conditional compilation wherever possible. Also, the macro is used to avoid dependencies which are easily avoided anyway, so why not avoiding them unconditionally and have "standalone mode" as the only option?
How much does BOOST_STATIC_STRING_STANDALONE actually save, in terms of dependencies? Is it possible to achieve the same effect (or close to it) automatically, if the code is compiled in C++17 mode? FWIW, I'm not a user of static_string, but I wouldn't have a problem with removing the standalone mode. Especially if most of it was automatically achieved by default in C++17 mode.
On Wed, Oct 8, 2025 at 1:08 PM Andrey Semashev via Boost < boost@lists.boost.org> wrote:
How much does BOOST_STATIC_STRING_STANDALONE actually save, in terms of dependencies?
Also a good question, thanks. I believe we have this information on the website now? Looking at the landing page for the library ( https://www.boost.org/library/latest/static_string/) the listed dependencies are: Assert Config Container Hash Core Static Assert ThrowException Utility (and I think this includes the transitive dependencies as well?) Thanks
participants (5)
-
Alexander Grund -
Andrey Semashev -
Gennaro Prota -
Pavel Vazharov -
Vinnie Falco