On Mon, Mar 4, 2024 at 7:22 PM Jan Schultke via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> The link to the library is 404.
>
> The way I see it, this proposal stands or falls with necessity. Your
> Prior Art section talks about how much faster it is to have these
> functions compared to using to_chars to determine the size, but it
> doesn't talk about whether this strategy makes sense in the first
> place.
>
> You can over-allocate, as you've said in Motivation. Is
> over-allocating so costly that this approach becomes preferable? What
> is the use case here, really? What about over-allocating, performing
> all the conversions without checking for size, then re-allocating? If
> to_chars_size is half the cost of to_chars for floating-point,
> couldn't this be cheaper? After all, copying some memory shouldn't be
> that costly. This needs some benchmarks and deeper discussion.
>
> Also note that your to_chars_size function for integers is
> mathematically floor(log(value, base)) + 1, except for the case of
> zero. Floating-point to-chars_size is pretty expensive anyway, and an
> integer logarithm function (taking bases beyond int) would solve the
> case of integers while being more generally applicable. These design
> trade-offs need to be discussed.

I also feel like a better way to handle this (for floating point at
least) is to allow you to partially perform `to_chars`, and if it ran
out of room, then you can allocate more storage and continue. The
partial version can then figure out how much more room is needed and
return that (along with information needed to continue). That seems
like it would minimize performance better, as there will be many cases
where the SSO-size of a string class would be sufficient. In those
cases, computing the size is just not helpful. And if it's not, you
can resize the string, preserving the prior work, and continue where
you left off.