February 2005 - Boost - lists.boost.org

Latest CVS: Boost.Python -> Illegal instruction
by Ralf W. Grosse-Kunstleve 05 Feb '05

05 Feb '05

I am working with the very latest boost CVS. Most Boost.Python tests fail with a segmentation fault with these compilers: gcc version 3.3 20030304 (Apple Computer, Inc. build 1493) gcc version 3.3 20030304 (Apple Computer, Inc. build 1671) gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5) gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-20) gcc version 3.4.3 # compiled from sources, running under RH WS 3 gcc version 3.4.3 # compiled from sources, running under RH 8.0 In contrast, these gcc's do *not* have any problems: gcc version 2.96 20000731 (Red Hat Linux 7.3 2.96-113) gcc version 3.2 20020903 (Red Hat Linux 8.0 3.2-7) valgrind reports no errors for gcc version 3.2 under RH 8.0, but complains about the gcc 3.4.3 compiled code on the same machine (see below). The problem appears to be independent of the Python version (problem observed with 2.2, 2.3, 2.4) and the optimizer (problem observed with -O3 and -O0). The Boost CVS from 2005-Jan-26 11:43 PDT didn't have this problem. I attach the valgrind output for one of the Boost.Python tests. Does this ring any bells? # gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-20) % valgrind --tool=memcheck /usr/bin/python $BOOST_DIST/libs/python/test/object.py running... ==19174== Memcheck, a memory error detector for x86-linux. ==19174== Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward et al. ==19174== Using valgrind-2.2.0, a program supervision framework for x86-linux. ==19174== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward et al. ==19174== For more details, rerun with: -v ==19174== disInstr: unhandled instruction bytes: 0xCD 0x5 0x90 0x55 at 0x1BE8A57D: _object* boost::python::api::object_base_initializer<boost::python::handle<_typeobject> >(boost::python::handle<_typeobject> const&) (object_core.hpp:285) ==19174== ==19174== Process terminating with default action of signal 4 (SIGILL) ==19174== Illegal operand at address 0xB0021520 ==19174== at 0x1BE8A57D: _object* boost::python::api::object_base_initializer<boost::python::handle<_typeobject> >(boost::python::handle<_typeobject> const&) (object_core.hpp:285) ==19174== by 0x1BE89B32: boost::python::api::object::object<boost::python::handle<_typeobject> >(boost::python::handle<_typeobject> const&) (object_core.hpp:310) ==19174== by 0x1BE8D921: boost::python::objects::(anonymous namespace)::new_class(char const*, unsigned, boost::python::type_info const*, char const*) (class.cpp:501) ==19174== by 0x1BE8BFCD: boost::python::objects::class_base::class_base(char const*, unsigned, boost::python::type_info const*, char const*) (class.cpp:514) ==19174== ==19174== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 47 from 1) ==19174== malloc/free: in use at exit: 714158 bytes in 8967 blocks. ==19174== malloc/free: 34052 allocs, 25085 frees, 6930352 bytes allocated. ==19174== For a detailed leak analysis, rerun with: --leak-check=yes ==19174== For counts of detected errors, rerun with: -v Illegal instruction __________________________________ Do you Yahoo!? Yahoo! Mail - Easier than ever with enhanced search. Learn more. http://info.mail.yahoo.com/mail_250

5 14

type_traits changes break Boost.Python under IRIX
by Ralf W. Grosse-Kunstleve 05 Feb '05

05 Feb '05

The recent changes to the type_traits library break our Boost.Python builds under IRIX, using the old MIPSpro 7.3.1 compiler. This compiler is based on EDG 238. The problem is illustrated by this simple piece of code: template <class T> struct is_signed_helper { static const bool value = (static_cast<T>(-1) < 0); }; % CC -n32 -mips4 -LANG:std -c foo.cpp cc-3314 CC: ERROR File = foo.cpp, Line = 4 The expression must have arithmetic, enum, or pointer type. static const bool value = (static_cast<T>(-1) < 0); ^ 1 error detected in the compilation of "foo.cpp". I tried several ideas for a workaround. The only one that worked in the end is the patch attached to this message. I know it is not pretty, but it has no effect on compilers other than EDG 238. I'd be happy to try other ideas, but all of Boost.Python compiles and runs with the patch. Unless someone else needs a more general fix (that works for user-defined types) I doubt the old compiler is worth more effort. Is the attached patch acceptable as a workaround? Cheers, Ralf Index: is_signed.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/type_traits/is_signed.hpp,v retrieving revision 1.1 diff -u -r1.1 is_signed.hpp --- is_signed.hpp 30 Jan 2005 15:47:45 -0000 1.1 +++ is_signed.hpp 2 Feb 2005 06:42:43 -0000 @@ -21,12 +21,35 @@ namespace detail{ +#if !(defined(__EDG_VERSION__) && __EDG_VERSION__ == 238) + template <class T> struct is_signed_helper { BOOST_STATIC_CONSTANT(bool, value = (static_cast<T>(-1) < 0)); }; +#else + +template <class T> +struct is_signed_helper; + +template <> struct is_signed_helper<char> { BOOST_STATIC_CONSTANT(bool, value = false); }; +template <> struct is_signed_helper<signed char> { BOOST_STATIC_CONSTANT(bool, value = true); }; +template <> struct is_signed_helper<unsigned char> { BOOST_STATIC_CONSTANT(bool, value = false); }; +template <> struct is_signed_helper<short> { BOOST_STATIC_CONSTANT(bool, value = true); }; +template <> struct is_signed_helper<unsigned short> { BOOST_STATIC_CONSTANT(bool, value = false); }; +template <> struct is_signed_helper<int> { BOOST_STATIC_CONSTANT(bool, value = true); }; +template <> struct is_signed_helper<unsigned int> { BOOST_STATIC_CONSTANT(bool, value = false); }; +template <> struct is_signed_helper<long> { BOOST_STATIC_CONSTANT(bool, value = true); }; +template <> struct is_signed_helper<unsigned long> { BOOST_STATIC_CONSTANT(bool, value = false); }; +template <> struct is_signed_helper<long long> { BOOST_STATIC_CONSTANT(bool, value = true); }; +template <> struct is_signed_helper<unsigned long long> { BOOST_STATIC_CONSTANT(bool, value = false); }; +template <> struct is_signed_helper<float> { BOOST_STATIC_CONSTANT(bool, value = true); }; +template <> struct is_signed_helper<double> { BOOST_STATIC_CONSTANT(bool, value = true); }; + +#endif + template <bool integral_type> struct is_signed_select_helper { Index: is_unsigned.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/type_traits/is_unsigned.hpp,v retrieving revision 1.1 diff -u -r1.1 is_unsigned.hpp --- is_unsigned.hpp 30 Jan 2005 15:47:45 -0000 1.1 +++ is_unsigned.hpp 2 Feb 2005 06:42:43 -0000 @@ -21,12 +21,35 @@ namespace detail{ +#if !(defined(__EDG_VERSION__) && __EDG_VERSION__ == 238) + template <class T> struct is_unsigned_helper { BOOST_STATIC_CONSTANT(bool, value = (static_cast<T>(-1) > 0)); }; +#else + +template <class T> +struct is_unsigned_helper; + +template <> struct is_unsigned_helper<char> { BOOST_STATIC_CONSTANT(bool, value = true); }; +template <> struct is_unsigned_helper<signed char> { BOOST_STATIC_CONSTANT(bool, value = false); }; +template <> struct is_unsigned_helper<unsigned char> { BOOST_STATIC_CONSTANT(bool, value = true); }; +template <> struct is_unsigned_helper<short> { BOOST_STATIC_CONSTANT(bool, value = false); }; +template <> struct is_unsigned_helper<unsigned short> { BOOST_STATIC_CONSTANT(bool, value = true); }; +template <> struct is_unsigned_helper<int> { BOOST_STATIC_CONSTANT(bool, value = false); }; +template <> struct is_unsigned_helper<unsigned int> { BOOST_STATIC_CONSTANT(bool, value = true); }; +template <> struct is_unsigned_helper<long> { BOOST_STATIC_CONSTANT(bool, value = false); }; +template <> struct is_unsigned_helper<unsigned long> { BOOST_STATIC_CONSTANT(bool, value = true); }; +template <> struct is_unsigned_helper<long long> { BOOST_STATIC_CONSTANT(bool, value = false); }; +template <> struct is_unsigned_helper<unsigned long long> { BOOST_STATIC_CONSTANT(bool, value = true); }; +template <> struct is_unsigned_helper<float> { BOOST_STATIC_CONSTANT(bool, value = false); }; +template <> struct is_unsigned_helper<double> { BOOST_STATIC_CONSTANT(bool, value = false); }; + +#endif + template <bool integral_type> struct is_unsigned_select_helper { __________________________________ Do you Yahoo!? Meet the all-new My Yahoo! - Try it today! http://my.yahoo.com

2 5

More on Serialization Link Issue
by Jared McIntyre 05 Feb '05

05 Feb '05

I've continue to play around with this for a few days. The problem revolves around std::wstring. I can serialize just about anything, with the exception of a std::wstring, using the library. Am I required to use the wide version of the archives to do std::wstring? If so, is there some mechanism by which a compiler error can be triggered if you try to use a std::wstring with a non wide version of an archive? As a side note, I've tried to incorporate the wide version of the library and use that, but I'm running into a different batch of link errors: error LNK2019: unresolved external symbol "public: __thiscall boost::archive::xml_wiarchive_impl<class boost::archive::xml_wiarchive>::xml_wiarchive_impl<class boost::archive::xml_wiarchive>(class std::basic_istream<unsigned short,struct std::char_traits<unsigned short> > &,unsigned int)" error LNK2019: unresolved external symbol "public: __thiscall boost::archive::xml_woarchive_impl<class boost::archive::xml_woarchive>::xml_woarchive_impl<class boost::archive::xml_woarchive>(class std::basic_ostream<unsigned short,struct std::char_traits<unsigned short> > &,unsigned int)" error LNK2019: unresolved external symbol "public: __thiscall boost::archive::basic_text_oprimitive<class std::basic_ostream<unsigned short,struct std::char_traits<unsigned short> > >::~basic_text_oprimitive<class std::basic_ostream<unsigned short,struct std::char_traits<unsigned short> > >(void)" (??1?$basic_text_oprimitive@V?$basic_ostream@GU?$char_traits@G@std@@@std@@@archive@boost@@QAE@XZ) referenced in function "public: virtual __thiscall boost::archive::xml_woarchive_impl<class boost::archive::xml_woarchive>::~xml_woarchive_impl<class boost::archive::xml_woarchive>(void)" Any thoughts? I actually still get the same errors caused by the use of std::wstring as well. Jared

2 2

Complex type failure with boost::lexical_cast
by Preston A. Elder 04 Feb '05

04 Feb '05

Hi, check out this code: #include <boost/lexical_cast.hpp> #include <iostream> struct my_type { int a; int b; }; template<typename C, typename T> std::basic_istream<C,T> &operator>>(std::basic_istream<C,T> &is, my_type &mt) { is >> mt.a >> mt.b; return is; } int main() { std::string input = "1 2"; my_type mt; try { mt = boost::lexical_cast<my_type>(s); std::cout << "TEST 1: " << mt.a << " " << mt.b << std::endl; } catch (boost::bad_lexical_cast &) { std::cout << "TEST 1 FAILED" << std::endl; } input = "3 4"; std::stringstream ss; ss << s; ss >> mt >> std::ws; if (ss.eof()) std::cout << "TEST 2: " << mt.a << " " << mt.b << std::endl; else std::cout << "TEST 1 FAILED" << std::endl; return 0; } The output I get is: TEST 1 FAILED TEST 2: 3 4 My investigation has shown that this occurs because boost::lexical_cast calls stream.unsetf(std::ios::skipws); My question is, why does it do this - as this specifically stops lexical_cast from working with complex types. So could this be an option, or completely disabled, or made an option (somehow) to lexical_cast? I understand some logic to not skipping whitespace, however I believe its use is limited - especially since there is a specialization for std::string and std::wstring already which does not even use operator>>. As a side note, yes, I could change my operator>>, however the sample operator>> above is typical for an operator>> for a complex class, almost always they assume that skipws is turned on, and don't bother checking. -- PreZ :) Founder. The Neuromancy Society (http://www.neuromancy.net)

5 11

Broken Links on Boost.org
by Brian Braatz 04 Feb '05

04 Feb '05

http://lists.boost.org/mailman/listinfo.cgi/boost-users This is what I see in my web browser (IE \ Windows XP) " Boost is a repository of free, portable, peer-reviewed C++ libraries. It acts as a proving ground for new libraries, particularly those which work well with the ISO C++ Standard Library. The main web site is <a href="http://www.boost.org">http://www.boost.org</a> This list is for discussion of issues related to using these libraries. Before subscribing, please read our discussion policy at <a href="http://www.boost.org/more/discussion_policy.htm">http://www.boost. org/more/discussion_policy.htm</a> If your interest is in library submission, development, or review, please subscribe to <a href="http://lists.boost.org/mailman/listinfo.cgi/boost">the Boost developer list</a>. " Notice the : Before subscribing, please read our discussion policy at <a href="http://www.boost.org/more/discussion_policy.htm">http://www.boost. org/more/discussion_policy.htm</a>

2 1

[Test] BOOST_TEST removed?
by Doug Gregor 04 Feb '05

04 Feb '05

BOOST_TEST has been used for testing Boost since the dawn of time, but it's just been removed from CVS, breaking a whole lot of test cases both in Boost and elsewhere. Some warning would have been nice. Not removing it would have been nicer. Doug

11 26

[iostreams] MAP_FILE not available on some platforms
by Caleb Epstein 04 Feb '05

04 Feb '05

The iostreams module mapped_file.cpp fails to compile on (at least) Solaris because it makes use of the mmap flag MAP_FILE which does not exist on that platform. I think this should be protected in an #ifdef MAP_FILE block or similar. http://tinyurl.com/4gv9p -- Caleb Epstein caleb dot epstein at gmail dot com

3 2

Bug in Boost.Thread?
by John Eddy 04 Feb '05

04 Feb '05

I noticed a potential hazard in exceptions.cpp of the thread library. The method: const char* thread_exception::message() const returns the c_str of a string with local scope. This is a problem at least in VC 7 .NET 2003. The error can be exposed by the following code. try { throw boost::lock_error(1); } catch(boost::lock_error& e) { cerr << e.message(); } Thanks, John

2 2

[boost.range] RFC on small updates
by Thorsten Ottosen 04 Feb '05

04 Feb '05

Hi All, I have planned to add a few extra convenience function to iterator_range and sub_range. Some people have said the classes could have been a little easier to use. The changes I suggest are the following: iterator_range: -------------- value_type& front() const; value_type& back() const; value_type& operator[]( size_type ) const; value_type& at( size_type ) const; void advance( size_type ); void narrow( size_type left, size_type right ); iterator_range& operator++(); value_type& operator*() const; sub_range: ---------- the same, but now constness is propagated freestanding: ------------ iterator_range make_sub_range( range&, size_type left, size_type right = 0 ); iterator_range make_super_range( range&, size_type left, size_type right = 0 ); iterator_range make_range( range&, difference_type left, difference_type right = 0 ); Comments? -Thorsten

6 18

atomic_count on MSVC/Win32, Tim Fenders optimization
by Hauptmann Peter 04 Feb '05

04 Feb '05

Hi, I noticed that boost/detail/atomic_count.hpp uses the intrinsic verisons of _InterlockedIncrement, _InterlockedDecrement only for Win64 builds. is there a reason? it is documented for VC 2003 without target platform restrictions (and it's "known to work" on VC6, too). thanks peter __________________________________ Do you Yahoo!? Yahoo! Mail - 250MB free storage. Do more. Manage less. http://info.mail.yahoo.com/mail_250

2 1