Re: charconv for C++11

From: Robert Ramey (ramey_at_[hidden])
Date: 2023-05-11 19:56:56

This is the useful information I was hoping to get when I asked the 
question. Unfortunately, I had to dig a little deeper than I expected 
and have a few more questions:

On 5/11/23 11:05 AM, Peter Dimov via Boost wrote:
> Robert Ramey wrote:
> lexical_cast can convert any streamable type to any other streamable type.
> It's defined as `ss << input; ss >> output; return output;` where `ss` is
> a default-constructed `std::stringstream`.

Hmmm - cannot not an ss be associated with a local of choice via 
std::imbue?  Looking at the documentation for lexical cast I don't see 
this.  I'm not sure what the issues would be with this.

> This has a number of implications. One, the conversion is locale-dependent.
Hmmm - conversion to/from strings isn't locale dependent, how does one 
deal with string numeric formats which depend on locality - e.g. some 
countries use , while others use . as a decimal separator.

> Two, for conversion to string, you use lexical_cast<std::string>, which can
> allocate. 

There is a section in the lexical_cast docs titled "converting to string 
without dynamic memory allocation".  Actually it would never occur to me 
that one could return a string from a conversion without a dynamic 
memory allocation.  But I guess that's me.

Three, errors are signaled via exceptions (although there's
> try_lexical_convert that can avoid this.)

Right

> lexical_cast does a good job of optimizing the from_chars and to_chars
> cases when it detects it can do so, but that by definition can't be better
> than the programmer just calling the primitive operations from_chars
> and to_chars directly, as they are (a) locale-independent, (b) non-
> allocating, (c) non-throwing.
OK
> 
> In addition to all that, from/to_chars are standard C++17, so Charconv
> can be used by libraries that want to support C++11 (or 14) today, but
> at the same time want to be able to switch to the standard functions
> later when increasing the minimal supported standard to C++17.

So this is an implementation in C++11 of a library which is already 
accepted (and presumably shipping) in C++17 ?  And the only user who 
would use this is someone who has C++11 but can't upgrade to C++17? 
Doesn't seem like very many people to me.

I didn't find an documentation for this.  May I presume that it's not 
deemed necessary as C++17 is documented and this is an exact equivalent?

Note that there is another boost library, Boost.Convert, which purports 
to address short comings in lexical cast. 
https://www.boost.org/doc/libs/1_82_0/libs/convert/doc/html/index.html

Has anyone looked at or evaluated this?  Is there overlap? I actually 
never knew about this.

Robert Ramey