Use low-level contiguous_sequence optimisations where appropriate

[tcbrindle]

Currently we optimise output_to() for contiguous_sequences of trivial types to use std::memmove.

There are more places where we could use equivalent low-level optimisations, including

• [ ] fill() (using memset())
• [ ] equal() (using memcmp())
• [ ] compare() (using memcmp())
• [ ] find() (using memchr())
• [x] search() (using memmem() where available)

See also the equivalent bug for Nanorange with more information about when these optimisations can be used.

[DeveloperPaul123]

I've started work on this in #103

[DeveloperPaul123]

@tcbrindle I have a question while working on equal()

There is this test case:

 // Different but comparable element types
{
    int arr1[] = {1, 2, 3, 4, 5};
    float arr2[] = {1.f, 2.f, 3.f, 4.f, 5.f};

    STATIC_CHECK(flux::equal(arr1, arr2));
}

It seems that the intension is to compare values and accept them as equal. If we want to optimize with std::memcmp, does it seem reasonable to require the the values of the 2 sequences be of the same type? Currently, using the std::memcmp optimization causes the above test to fail (where it previously passed).

[tcbrindle]

@DeveloperPaul123 Not only is it reasonable, it's essential: a memcmp optimisation of equal must require that both sequences have the same type, among other conditions.

[DeveloperPaul123]

@tcbrindle Currently, std::memmem is a GNU extension. Is it desirable to use this on platforms that's it's available on? Currently C++ extensions are explicitly turned off via CMake

[tcbrindle]

@DeveloperPaul123 Thinking about it some more, I think it's probably better to not use memmem for now and stick with portable standard library facilities... we can look at platform/vendor-specific optimisations later if/when they're needed.

[tcbrindle]

Added in #103, thanks @DeveloperPaul123!