31–40 of 130 posts
Earlier quoted context omitted.
X86 has also had saturation arithmetic since MMX was introduced.
You should never rely on the underlying CPU architecture's behavior on integer overflow when you write C or C++. It is undefined and not unspecified or implementation defined.
> The built-in integer types in C++ (int, unsigned, long long, etc.) are mostly unusable because of the lax requirements on bounds. This must be some new definition of the word 'unusable.'
On a different platform, these "friendly" types can be larger, typically 2 or 4 times larger which can be devastating for performance, or smaller, leading to overflow. They are only "usable" if you restrict yourself on one version, of one compiler, on one hardware platform.
At this point, when I see libraries like this all I can think is ”oh good, my compile times aren’t long enough, lets make EVERY INTEGER a template”. Also, while I can reasonably beliveve that most of the overhead goes away at -O2 or -O3, this has to just trash performance for debug builds, which is not unimportant.
To me the implementation seems to be a good solution given that you don't want to change the core language.
At this point, when I see libraries like this all I can think is ”oh good, my compile times aren’t long enough, lets make EVERY INTEGER a template”. Also, while I can reasonably beliveve that most of the overhead goes away at -O2 or -O3, this has to just trash performance for debug builds, which is not unimportant.
Welcome to engineering tradeoffs.
> The built-in integer types in C++ (int, unsigned, long long, etc.) are mostly unusable because of the lax requirements on bounds. This must be some new definition of the word 'unusable.'
On a different platform, these "friendly" types can be larger, typically 2 or 4 times larger which can be devastating for performance, or smaller, leading to overflow. They are only "usable" if you restrict yourself on one version, of one compiler, on one hardware platform.
At this point, when I see libraries like this all I can think is ”oh good, my compile times aren’t long enough, lets make EVERY INTEGER a template”. Also, while I can reasonably beliveve that most of the overhead goes away at -O2 or -O3, this has to just trash performance for debug builds, which is not unimportant.
Also, what do you mean by "this has to just trash performance for debug builds". Do you mean runtime performance?
Earlier quoted context omitted.
On a different platform, these "friendly" types can be larger, typically 2 or 4 times larger which can be devastating for performance, or smaller, leading to overflow. They are only "usable" if you restrict yourself on one version, of one compiler, on one hardware platform.
Does C++ not have int32_t and the like from C?
Earlier quoted context omitted.
On a different platform, these "friendly" types can be larger, typically 2 or 4 times larger which can be devastating for performance, or smaller, leading to overflow. They are only "usable" if you restrict yourself on one version, of one compiler, on one hardware platform.
Does C++ not have int32_t and the like from C?
Earlier quoted context omitted.
Does C++ not have int32_t and the like from C?
It does. I personally stick to those exclusively except for for loop index variables.
typedef Int int32_t;