Ok, that seems more inline with how I thought it was working.
But then again if you are over-allocating and shrinking on a per-parameter basis it's not really pre-allocation.
Not sure if that is what the OP had in mind, if he was worried about the cost of transcoding after formatting (and wanting pre-allocation) the cost of that is going to be relatively low compared to everything else.

My suggestion was aimed at being able to format the whole thing to completion with only 1 allocation or less (emphasis on less), then at that point transcoding really becomes quite significant.

-----Original Message-----
From: Thiago Macieira <thiago_at_macieira.org>
Sent: Tuesday, July 2, 2024 10:55
To: sg16_at_[hidden]; Tiago Freire <tmiguelf_at_hotmail.com>
Subject: Re: [isocpp-sg16] std::format and charN_t

On Monday 1 July 2024 23:48:59 CEST Tiago Freire wrote:
> > There's a third alternative, which is what we use in Qt: we estimate
> > the maximum possible size and request that. Once we've transcoded,
> > we tell the container how much was actually used, which truncates
> > the output to that size before continuing the formatting operation.
> Did you mean "finishing the formatting operation"? Or did you mean
> proceed to the next parameter?

I meant "the next parameter". I assume that whatever was formatting the current parameter already did so properly when writing the necessary code points to the provided buffer.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Principal Engineer - Intel DCAI Platform & System Engineering