Re: Boost.Charconv review runs January 15th - 25th, 2024

From: Alan de Freitas (alandefreitas_at_[hidden])
Date: 2024-01-25 15:48:55

# Boost.Charconv review

## What is your evaluation of the design?

A fast replacement for std::to_chars/from_chars in C++11 is very useful.

I also like that it's a compiled library, even if it causes some temporary
inconveniences for integration.

I'm still worried about the "non-allocating" initial description in the
documentation.
It rarely allocates, but it might. Even if only in edge cases and with a
function that doesn't throw on allocation failure.
So the initial documentation sentence describing the library is misleading.

The return value on result_out_of_range is also something to think about.
After considering opinions on both sides here and elsewhere, I tend to
think we should not deviate from the standard in this case.
Deviating from the standard also seems like a headache to the author.

I don't like the name from_chars_strict though. Because it's not what the
function is doing.
The way it returns values on result_out_of_range is not a matter of being
more or less strict since it would accept and reject the same inputs.

## What is your evaluation of the implementation?

I went through the code and the implementation seems fine and organized.

I would like it if it were possible to have no malloc in there.
But if that's impossible, documenting the edge cases is also fine.

It would be good to have some fuzzing tests in the library.

## What is your evaluation of the documentation?

The documentation is small and has lots of examples.
I found the "why use Boost.Charconv over <charconv>" section very useful.

The initial description in the docs describes it only as "parsing
functions".
This seems too generic for what the library does.

One great thing about boost libraries is that their documentation is
usually goal-oriented.
The initial sections in the documentation assume the reader knows what
<charconv> is but I don't think it should assume that.
For instance, there's an initial section on "why use Boost.Charconv over
<charconv>" but no initial section on "Why use Boost.Charconv".

The "from chars" section doesn't describe the edge cases when it allocates.
It could also include examples of these edge cases so the users understand
how extreme they are.

The floating point example includes `assert(v == 1.2345);`.
I thought this kind of floating point equality comparison could fail.

The introduction of boost::charconv::limits should be somewhat interleaved
with the discussion of from/to_chars because users should already be aware
of that when copying/pasting the first examples on how to use these
functions.

The from/to_chars overview sections and the reference section are a little
too repetitive at times.
Some repetition is natural here, but it would be good to go through these
sections to make sure most of the content in each of the sections adds
independent value to the reader.

## What is your evaluation of the potential usefulness of the library?

Boost libraries might benefit from that.
Some internal functions in Boost.URL could use this library.
I believe that's the case for many other libraries because most protocols
involve numbers here and there.

It's also useful to have this feature without C++17.

The library is also faster than std::from/to_chars.

## Did you try to use the library? With what compiler? Did you have any
problems?

I ran some small tests locally and it worked fine.
I haven't tried to integrate it in any other library.

I particularly like that the project provided vcpkg and conan
packages/ports.

## How much effort did you put into your evaluation?

I read the documentation, experimented with it in a small local project,
and went through the code.

## Are you knowledgeable about the problem domain?

I understand the problem clearly, as most people probably do, but I'm not
an expert in terms of the trade-offs between all possible solutions.
In other words, I'm just a user.

## Your decision.

I recommend to ACCEPT Charconv into Boost.

## Disclaimer

I'm affiliated with the C++ Alliance.