On Mon, Nov 10, 2014 at 8:41 AM, niXman <i.nixman@autistici.org> wrote:

niXman 2014-11-10 01:19:

Ion Gaztañaga 2014-11-10 00:44:

I don't think using std::equal will guarantees the use of memcmp. At
least, the last time I checked some major implementations didn't use
it and others only for char types. I've seen libstdc++ uses memcmp for
non-char types, maybe that could be a good example to follow.

Hmm..
std::equal()[1] uses __equal_aux()[2], which uses '__builtin_memcmp()' for:
https://gcc.gnu.org/viewcvs/gcc/trunk/libstdc%2B%2B-v3/include/bits/stl_algobase.h?view=markup#l832

[1] https://gcc.gnu.org/viewcvs/gcc/trunk/libstdc%2B%2B-v3/include/bits/stl_algobase.h?view=markup#l1047
[2] https://gcc.gnu.org/viewcvs/gcc/trunk/libstdc%2B%2B-v3/include/bits/stl_algobase.h?view=markup#l828

ping?

As said, listdc++ uses memcmp. MSVC uses it only for chars, libc++ does not use memcmp. So Boost.Container will need to implement its own optimization based on libcstd++ ideas: pointers and integers (asumming no padding or trap representation) can be memcmp-ed on all platforms Boost runs. PODs, due to float signed zero and Nan, can't be memcmp-ed.

A similar optimization could be done for lexicographical_compare, but only for unsigned chars. Unsigned integers might work in Big Endian machines. In any case, I consider this a very specific optimization that chould not be crucial.

Ion

--
Regards, niXman
___________________________________________________
Dual-target(32 & 64-bit) MinGW-W64 compilers for 32 and 64-bit Windows:
http://sourceforge.net/projects/mingw-w64/
___________________________________________________
Another online IDE: http://liveworkspace.org/