[static_string] Desired behavior of to_static_[w]string() for floating point values
Hi everyone, I'd like to gather your input on the desired behavior of to_static_string() and to_static_wstring() when formatting floating point values. Currently, both functions mimic std::to_string() / std::to_wstring() as long as the result fits within the static string's capacity. If not, they fall back to scientific notation. However, C++26 introduces a breaking change: std::to_string() and std::to_wstring() will behave as if implemented via std::format() rather than s[w]printf(). For example, std::to_string( 0.1 ) will yield "0.1" instead of "0.100000". Given this shift, what behavior would you prefer for to_static_[w]string()? a) Match std::to_[w]string() and adopt the new behavior when compiling under C++26. b) Preserve the legacy behavior with fixed precision (6 digits) across all standard versions. c) Always behave as if using std::format(), even in pre-C++26 builds (breaking change). d) Other. Please let me know what you think. Thanks. -- Gennaro Prota <https://prota.dev>
Am 07.10.25 um 10:15 schrieb Gennaro Prota via Boost:
Given this shift, what behavior would you prefer for to_static_[w]string()?
a) Match std::to_[w]string() and adopt the new behavior when compiling under C++26.
b) Preserve the legacy behavior with fixed precision (6 digits) across all standard versions.
c) Always behave as if using std::format(), even in pre-C++26 builds (breaking change).
I'd go with option a) I think for users it is reasonable to expect `std::to_string(value) == boost::to_static_string(value)` holds, even though it can cause confusion when changing standard modes. However this allows to (gradually) use boost::static_string as a drop-in for std::string without causing breakages
Gennaro Prota wrote:
Hi everyone,
I'd like to gather your input on the desired behavior of to_static_string() and to_static_wstring() when formatting floating point values.
Currently, both functions mimic std::to_string() / std::to_wstring() as long as the result fits within the static string's capacity. If not, they fall back to scientific notation.
However, C++26 introduces a breaking change: std::to_string() and std::to_wstring() will behave as if implemented via std::format() rather than s[w]printf(). For example, std::to_string( 0.1 ) will yield "0.1" instead of "0.100000".
Given this shift, what behavior would you prefer for to_static_[w]string()?
a) Match std::to_[w]string() and adopt the new behavior when compiling under C++26.
b) Preserve the legacy behavior with fixed precision (6 digits) across all standard versions.
c) Always behave as if using std::format(), even in pre-C++26 builds (breaking change).
d) Other.
Please let me know what you think.
c)
I favour option c. I implemented my own static_string class which is also usable on ancient compilers. This is my comment for the to_fc_string function: // Conversion double/float => fc_string is not completely standard. // Before C++20 this is defined as using %f which requires more than // 300 bytes to store // C++20 makes this more reasonable so do not rely to much on the // exact result of this conversion for very small or large values // Please note that the standard formats a float as a double. // We currently save space and only store significant digits of both // types. If I remember correctly this will not always give the exact same result as C++20, but is it good enough. And the actual implementation is basically sprintf(res,"%0.17g",value) for double. /Peter On Tue, Oct 7, 2025 at 10:16 AM Gennaro Prota via Boost < boost@lists.boost.org> wrote:
Hi everyone,
I'd like to gather your input on the desired behavior of to_static_string() and to_static_wstring() when formatting floating point values.
Currently, both functions mimic std::to_string() / std::to_wstring() as long as the result fits within the static string's capacity. If not, they fall back to scientific notation.
However, C++26 introduces a breaking change: std::to_string() and std::to_wstring() will behave as if implemented via std::format() rather than s[w]printf(). For example, std::to_string( 0.1 ) will yield "0.1" instead of "0.100000".
Given this shift, what behavior would you prefer for to_static_[w]string()?
a) Match std::to_[w]string() and adopt the new behavior when compiling under C++26.
b) Preserve the legacy behavior with fixed precision (6 digits) across all standard versions.
c) Always behave as if using std::format(), even in pre-C++26 builds (breaking change).
d) Other.
Please let me know what you think.
Thanks.
-- Gennaro Prota <https://prota.dev>
_______________________________________________ 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/LMTGWPUG...
On October 7, 2025 11:15:36 AM Gennaro Prota via Boost <boost@lists.boost.org> wrote:
Hi everyone,
I'd like to gather your input on the desired behavior of to_static_string() and to_static_wstring() when formatting floating point values.
Currently, both functions mimic std::to_string() / std::to_wstring() as long as the result fits within the static string's capacity. If not, they fall back to scientific notation.
However, C++26 introduces a breaking change: std::to_string() and std::to_wstring() will behave as if implemented via std::format() rather than s[w]printf(). For example, std::to_string( 0.1 ) will yield "0.1" instead of "0.100000".
Given this shift, what behavior would you prefer for to_static_[w]string()?
a) Match std::to_[w]string() and adopt the new behavior when compiling under C++26.
b) Preserve the legacy behavior with fixed precision (6 digits) across all standard versions.
c) Always behave as if using std::format(), even in pre-C++26 builds (breaking change).
d) Other.
Please let me know what you think.
Any to_(whatever_)string functions should produce the same result, regardless of the standard version. Otherwise, you'd be laying landmines to users. Better break users once than keep them breaking themselves all the time. So option c.
On Tue, Oct 7, 2025, at 5:19 PM, Andrey Semashev via Boost wrote:
Please let me know what you think.
Any to_(whatever_)string functions should produce the same result, regardless of the standard version. Otherwise, you'd be laying landmines to users. Better break users once than keep them breaking themselves all the time. So option c.
Hmm. Did I get this right? Because I completely agree with reasoning, however, that means I expected you to strongly assert option a. - Note that option c means that `to_static_string` may NOT produce the same as `to_string`. - Also, indeed: better to break users *once*. Meaning, when they switch to c++26 compilation (it seems this breakage cannot be avoided since it's part of standard specification?) Seth
On October 7, 2025 7:28:27 PM Seth <bugs@sehe.nl> wrote:
On Tue, Oct 7, 2025, at 5:19 PM, Andrey Semashev via Boost wrote:
Please let me know what you think.
Any to_(whatever_)string functions should produce the same result, regardless of the standard version. Otherwise, you'd be laying landmines to users. Better break users once than keep them breaking themselves all the time. So option c.
Hmm. Did I get this right? Because I completely agree with reasoning, however, that means I expected you to strongly assert option a.
- Note that option c means that `to_static_string` may NOT produce the same as `to_string`. - Also, indeed: better to break users *once*. Meaning, when they switch to c++26 compilation (it seems this breakage cannot be avoided since it's part of standard specification?)
No. My opinion is to_string and to_static_string should return the same string, at any supported C++ version. Option a doesn't qualify the second part.
On October 7, 2025 8:39:16 PM Andrey Semashev <andrey.semashev@gmail.com> wrote:
On October 7, 2025 7:28:27 PM Seth <bugs@sehe.nl> wrote:
On Tue, Oct 7, 2025, at 5:19 PM, Andrey Semashev via Boost wrote:
Please let me know what you think.
Any to_(whatever_)string functions should produce the same result, regardless of the standard version. Otherwise, you'd be laying landmines to users. Better break users once than keep them breaking themselves all the time. So option c.
Hmm. Did I get this right? Because I completely agree with reasoning, however, that means I expected you to strongly assert option a.
- Note that option c means that `to_static_string` may NOT produce the same as `to_string`. - Also, indeed: better to break users *once*. Meaning, when they switch to c++26 compilation (it seems this breakage cannot be avoided since it's part of standard specification?)
No. My opinion is to_string and to_static_string should return the same string, at any supported C++ version. Option a doesn't qualify the second part.
"at any supported C++ version" here means that for a given input the produced output string should be the same at any supported C++ version.
participants (6)
-
Alexander Grund -
Andrey Semashev -
Gennaro Prota -
Peter Dimov -
Peter Koch Larsen -
Seth