Date: Sun, 16 Feb 2025 18:00:11 +0100
> There's something I'm not understanding here. Why is it more of a burden for freestanding ? implementations to support a 128-bit integer type than a class type that implements 128-bit integer arithmetic? Is it only because the type may be slow and users will complain more in the first scenario?
Because you need to implement the functionality of a fundamental type
in the compiler itself. If you get your compiler on an exotic
architecture to compile the MSVC STL or libstdc++ or whatever, you get
this feature without further work.
You also need to decide on an ABI for 128-bit integers, or any N-bit
integers if this is a fundamental type. If it's simply a class type,
and you don't care about having a fundamental type at some point, you
don't really care about this (other than not breaking ABI in the
future, but even if you did, the consequences of breaking ABI for a
single class type are lower).
Because you need to implement the functionality of a fundamental type
in the compiler itself. If you get your compiler on an exotic
architecture to compile the MSVC STL or libstdc++ or whatever, you get
this feature without further work.
You also need to decide on an ABI for 128-bit integers, or any N-bit
integers if this is a fundamental type. If it's simply a class type,
and you don't care about having a fundamental type at some point, you
don't really care about this (other than not breaking ABI in the
future, but even if you did, the consequences of breaking ABI for a
single class type are lower).
Received on 2025-02-16 17:00:27