boost.container.vector::operator==() bug?
Hi, https://github.com/boostorg/container/blob/master/include/boost/container/ve... Explained: if ( !(1 != 1) ) Another question is, why 'memcmp()' not used for vectors of fundamental types? -- 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/
On Wed, Nov 5, 2014 at 6:46 AM, niXman
Hi,
https://github.com/boostorg/container/blob/master/include/boost/container/ve...
Explained: if ( !(1 != 1) )
"if ( !(1 != 1) )" was humor, right? I say that half seriously, because I've actually had the pleasure of dealing with code like that at times throughout my career. My own code is not without its logical concerns from time to time, but t'ain't one of these... :)
Another question is, why 'memcmp()' not used for vectors of fundamental types?
-- 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/ _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
El 05/11/2014 13:46, niXman escribió:
Hi,
https://github.com/boostorg/container/blob/master/include/boost/container/ve...
Explained: if ( !(1 != 1) )
Thanks for the bug report. Fixed in [develop e6d19fb] Fixed in bug in vector::operator==
Another question is, why 'memcmp()' not used for vectors of fundamental types?
Because nobody has provided a patch ;-) I'll add this to the to-do list. Thanks. Ion
Ion Gaztañaga 2014-11-09 23:07:
Because nobody has provided a patch ;-) I'll add this to the to-do list. Thanks.
done: https://github.com/boostorg/container/pull/18 -- 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/
El 09/11/2014 21:34, niXman escribió:
Ion Gaztañaga 2014-11-09 23:07:
Because nobody has provided a patch ;-) I'll add this to the to-do list. Thanks.
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. Best, Ion
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_algo... [1] https://gcc.gnu.org/viewcvs/gcc/trunk/libstdc%2B%2B-v3/include/bits/stl_algo... [2] https://gcc.gnu.org/viewcvs/gcc/trunk/libstdc%2B%2B-v3/include/bits/stl_algo... -- 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/
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_algo...
[1] https://gcc.gnu.org/viewcvs/gcc/trunk/libstdc%2B%2B-v3/include/bits/stl_algo... [2] https://gcc.gnu.org/viewcvs/gcc/trunk/libstdc%2B%2B-v3/include/bits/stl_algo...
ping? -- 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/
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/
Ion Gaztañaga 2014-11-10 10:52:
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.
Ok, in what namespaces/file should I implement it? -- 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/
$z$s$ak
Sent from my BlackBerry device on the Rogers Wireless Network
-----Original Message-----
From: Ion Gaztañaga
Ion Gaztañaga 2014-11-09 23:07:
Because nobody has provided a patch ;-) I'll add this to the to-do list. Thanks.
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. Best, Ion _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
participants (4)
-
Ion Gaztañaga -
Michael Powell -
niXman -
quang.trinh＠gmail.com