I am sorry I misread your email. I thought you were speaking about
std::string c-tor.
and seems I copy pasted to_string all over.

On Sun, Feb 11, 2024 at 2:56 PM Jan Schultke <janschultke_at_[hidden]>
wrote:

> > The correct form is std::to_string(std::size_t).
>
> I don't know where you got that information from. The current wording
> in https://eel.is/c++draft/string.conversions#lib:to_string defines
> overloads:
>
> > to_string(int)
> > to_string(long)
> > ...
>
> An overload exists for every standard integer type.
>
> > std::to_string(std::int128_t) - this can not be done
>
> Correct. However, the proposal includes wording changes which would permit
> it.
>
> > such big number is not "addressable"
>
> Yes it is. A std::int128_t consists of 16 8-bit bytes, so the most
> significant byte is found at offset 15. std::size_t is required to
> represent the number 15. I think you're mixing up value ranges and
> addressability here.
>
> Or perhaps you got confused by std::to_string. std::to_string(123)
> produces "123", not a string that has 123 characters.
>
> > some other thoughts - I would love to be able to print 128 bit numbers
> on the screen using standard ways (std::cout, printf etc) . also to do bit
> operations faster
>
> Yeah, that would be nice, and that's what the proposal is about :)
>
> > Year ago I tried to do the same with gcc uint128_t and the result was
> really slow.
>
> I would expect compilers to provide optimal codegen for 128-bit
> comparison nowadays. For clang, comparing two 128-bit integers with ==
> compiles to:
>
> eq(__int128, __int128):
> xor rsi, rcx
> xor rdi, rdx
> or rdi, rsi
> sete al
> ret
>