Re: [charconv] is std::from_chars practical?

From: Дмитрий Архипов (grisumbras_at_[hidden])
Date: 2024-01-26 17:17:28

пт, 26 янв. 2024 г. в 17:36, Zach Laine via Boost <boost_at_[hidden]>:
>
> I want to underline my support for this.  To me, the reason this
> submission will get the most use is that it implements the standard
> behavior.  This makes it useful for people who are using a pre-C++17
> build mode, or an implementation that does not yet provide <charconv>.
> The perf benefits are nice, but few users will be motivated by that
> alone, based on the numbers I saw.  If the std:: version sucks in some
> way, the Boost one should suck in exactly the same way, IMO, with of
> course an available non-sucky alternative.

I hold a very different position. This library implements fast
locale-unaware conversions between strings of characters and numbers.
This is often useful.
The API is based on the standard header <charconv> which is
beneficial, because it flattens the learning curve. There is also a
function that has the
exact "sucky" behaviour of the current standard from_chars.

Why one would use such a "sucky" function? Presumably, the reason is
inability to use a standard library implementation that has
<charconv>. And
so, such user aims at switching to the standard library version at the
first opportunity.

My first comment is that after you went all the way to add a physical
library dependency to your project, you've paid the cost. What would
be the benefit
of switching to the standard library equivalent that is actually
slower? You spend more effort to get slower code.

My second comment is that having compatibility between std::from_chars
and charconv::from_chars in such a case prioritises non-users over
users. That
is, people who need such strict compatibility are people who plan to
*not use the library*. People who would prefer the most useful
behaviour to be the
default are people who plan to continue using the library.