> Assuming that the locale issue isn't a problem, can that be reused?
The to_chars patch uses C++14 features, while to_string is C++11. If
that was solved, it probably could be used.
However, as far as I know, simply using to_chars in to_string would
technically be suboptimal, because it needs thr
On 28 May 2017 at 23:29, Tim Song wrote:
> libstdc++ has a to_chars implementation already. Assuming that the
> locale issue isn't a problem, can that be reused?
Maybe, but that implementation hasn't landed yet. The patch has been circulated
but I don't see it having been committed.
libstdc++ has a to_chars implementation already. Assuming that the
locale issue isn't a problem, can that be reused?
2017-05-28 21:38 GMT+02:00 Adrian Wielgosik :
>> so a conforming program could notice the difference by either calling
>> std::setlocale.
>
> Unless I missed or misunderstood something about locale (please let me
> know if I did), I don't know of any way for locale to affect %d and
> its integer f
> so a conforming program could notice the difference by either calling
> std::setlocale.
Unless I missed or misunderstood something about locale (please let me
know if I did), I don't know of any way for locale to affect %d and
its integer friends.
2017-05-27 23:46 GMT+02:00 Adrian Wielgosik :
> Currently std::to_string takes a fairly long trip to vs(n/w)printf. The patch
> implements int-to-string formatting in header, to improve function
> performance.
The existing specification of std::to_string is specified in a way
that would make this
Currently std::to_string takes a fairly long trip to vs(n/w)printf. The patch
implements int-to-string formatting in header, to improve function performance.
Results of a benchmark on my PC:
to_string(integer) takes 85-107ns per call (depending on result string size),
out of which ~75ns is spent i