Boost logo

Boost :

From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2021-01-27 08:41:53


On 1/27/21 7:38 AM, Edward Diener via Boost wrote:
> On 1/25/2021 6:08 PM, Gavin Lambert via Boost wrote:
>> On 26/01/2021 10:53 am, Edward Diener wrote:
>>> Please name the Boost low level libraries which have specific code
>>> aimed at the platform/architecture combination. I am not talking
>>> about code for just Mac or Linux or Solaris or Windows but code that
>>> actually does something different when run on Intel or ARM or AArch64
>>> etc. I still imagine that if such Boost libraries exist there are
>>> still very, very few Boost libraries with dependence on such code. I
>>> am not arguing that testing on non-Intel is in any way wrong but
>>> simply that very, very few libraries should be impacted by different
>>> architectures in any way.
>>
>> Boost.Atomic (and consequently Boost.Lockfree too) is the obvious one
>> (that Niall already hinted at), but parts of Boost.Thread also apply.
>>
>> Add to that list other low-level libraries such as Boost.Endian,
>> Boost.Coroutine[2], and Boost.Fiber as well.
>>
>> There are also some surprise gotchas in other libraries that do their
>> own spinlocks or pointer-packing, such as Boost.SmartPtr and likely
>> others.
>>
>> Meanwhile other libraries like Boost.Serialization (and consumers of
>> same) also make their own assumptions about things like endianness and
>> type structure, which may not matter too much in isolation but becomes
>> very important if you're intending to use it as a portable network or
>> disk format.
>
> I think then it is important for the libraries in which some of the code
> is tailored to a platform/architecture to test on other
> platform/architectures than Intel, but for the large number of Boost
> libraries which have no direct dependencies on a platform/architecture I
> do not see that it is of much importance. Simply because library XXX
> uses Boost.SmartPtr does not mean that testing on ARM is going to show
> anything of use for library XXX, which testing Boost.SmartPtr on ARM
> would not itself show.

Memory ordering correctness cannot be tested in the low level libraries,
it must be tested at the place of use, i.e. in the downstream libraries.

Assumptions about alignment, endianness and overflow semantics and FP
specifics are also not limited to lower level libraries and tend to crop
up at any level.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk