On 26/01/2021 9:44 am, Edward Diener wrote:
My main thought is that, while you are correct about not testing on something other than Intel x64, from the programmers viewpoint he is writing code in C++ and not for a particular platform/architecture. At the most he may be writing code with attention to a compiler or OS, but hardly ever does a particular CPU itself come into play unless lower level assembly code, tailored to a CPU, comes into play. So realistically the programmer does not care about a CPU at all. Even if a test were to fail on some other platform/architecture, where it normally passes on Intel x64, what would a programmer do about it ? Probably very little. Maybe, at the very most, report a problem to the compiler running on that platform/architecture that their is something wrong somewhere. But for the vast, vast majority of times such a problem would hardly indicate anything wrong with the code itself. I offer all this up as a possibly valid reason why testing a Boost library on some other platform/architecture, other than the usual Intel x64 on Mac/Linux/Windows, is not going to be a big priority for any Boost library developer/maintainer.
This isn't really a good way of thinking. Despite C/C++ supposedly being portable languages, the truth is that each platform and compiler have their own quirks -- mostly stemming from implementation-defined parts of the language, including such fundamental things as the sizes of primitive types and overall endianness, along with some higher-level concepts such as whether certain operations are lock-free or not, etc. (And even, in theory, whether two's complement encoding is used; although I'm not aware of any modern platforms at least where that's not the case, they certainly did exist in the history of the language.) While a library author perhaps doesn't have to care about such differences quite as much as an application author does (as the implementation-defined differences are more significant in the multi-threading arena, and libraries usually stay out of that space), they're not something that can be ignored entirely. It is absolutely possible to write code that works perfectly on Intel x64 but is utterly broken on other architectures (or worse: mostly works except for some corner cases, or works but with pathologic performance), and that is the fault of the code, not of the compiler or platform. But even outside of that, it is a useful exercise to run code through multiple compilers, as each have a different suite of warnings, and trying to get code to compile warning-clean in most compilers can lead to an overall improvement in quality (although not always).