Boost logo

Boost :

From: Gavin Lambert (boost_at_[hidden])
Date: 2021-01-25 21:04:19

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).

Boost list run by bdawes at, gregod at, cpdaniel at, john at