On Mon, Nov 10, 2014 at 8:41 AM, niXman
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/