How are you going to represent 0.3 using a non fixed point integer? And if you do, use fixed point, you suddenly have other just as common numbers you cant represent. You really think NaN is a better is a less intuitive result than what whatint64(1)/int64(0) gives? You really think the latter wont result in a bug as well?
gettimeofday is deprecated as of 2008. So even using it is a bug. Using it more than a few times per seconds is almost certainly a bug. The function also uses an ambiguous representation, but and as the docs dont specify, I would have to check the code to se if it relies on microseconds being less than 10^6, and even if I check this for standard glibc, I would not trust other implementations to do the same. However, as we can assume that the pseudo integer type used does not need to use have multiple codes for basic numbers, its easy to se that the range is just under 52 bits. gettimeofday is so old that they didn't even expect that emulated int64 was available.
That is, if they used a double instead, it would perfectly cover the same range, require much less code, while simultaneously been easier to get right, support all standard operations you would expect, behave more intuitively in many cases, and be faster on most platforms, though as you say, perhaps slightly slower on soft float platforms. Though I woudnt be so sure, almost every project notices float performance, almost no project notices gettimeofday performance.
The ABI would break by changing the type regardless, numeric types should never be used without explicitly specifying precision, and no, the burden is primarily on compilers. With float128 as a core language feature as it should be, noting that while it should be IEEE... compliant, it may be emulated, the burden on the distros would be small, and likely net beneficial as timestamps is one of those things that cause very rare and hard to replicate bugs absolutely everywhere.
>How are you going to represent 0.3 using a non fixed point integer?
I won't try to. The alternative to your proposal is fixed point integer.
>if you do, use fixed point, you suddenly have other just as common numbers you cant represent.. You really think NaN is a better is a less intuitive result than what whatint64(1)/int64(0) gives?
I think it's less of a problem than float. Most programmers (myself included) don't understand all the nuances of floating point.
>gettimeofday is deprecated as of 2008
The reason I mentioned it is because I recall it turned out to be a problem when porting/emulating Linux apps under Windows, since the equivalent Windows call used to be way more expensive. Apparently it was a significant problem since the call was in wide use. I don't recall any widespread effort to remove gettimeofday (or equivalents), so I suspect it's still is in use?
>With float128 as a core language feature as it should be
Unfortunately it isn't a core language feature - e.g. it can have 80bit precision on some x86s/software combinations. Now, that's worth fixing regardless.
Its not standards compliant for C++17 to use the 80bit precision version if I remember correctly. So it is in the languages, the language is just badly supported.
gettimeofday is deprecated as of 2008. So even using it is a bug. Using it more than a few times per seconds is almost certainly a bug. The function also uses an ambiguous representation, but and as the docs dont specify, I would have to check the code to se if it relies on microseconds being less than 10^6, and even if I check this for standard glibc, I would not trust other implementations to do the same. However, as we can assume that the pseudo integer type used does not need to use have multiple codes for basic numbers, its easy to se that the range is just under 52 bits. gettimeofday is so old that they didn't even expect that emulated int64 was available. That is, if they used a double instead, it would perfectly cover the same range, require much less code, while simultaneously been easier to get right, support all standard operations you would expect, behave more intuitively in many cases, and be faster on most platforms, though as you say, perhaps slightly slower on soft float platforms. Though I woudnt be so sure, almost every project notices float performance, almost no project notices gettimeofday performance.
The ABI would break by changing the type regardless, numeric types should never be used without explicitly specifying precision, and no, the burden is primarily on compilers. With float128 as a core language feature as it should be, noting that while it should be IEEE... compliant, it may be emulated, the burden on the distros would be small, and likely net beneficial as timestamps is one of those things that cause very rare and hard to replicate bugs absolutely everywhere.