Boost logo

Boost :

From: Edward Diener (eldiener_at_[hidden])
Date: 2021-01-27 17:03:42


On 1/27/2021 3:41 AM, Andrey Semashev via Boost wrote:
> 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.

Granted ! But I think that the vast majority of Boost libraries do not
deal in these issues. For the ones that do testing with different
platform/architecturs is important.


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