- Boost - lists.boost.org

[mpl][doc]range-c.html size<r>::type -> size<r>::value
by Larry Evans 06 Feb '05

06 Feb '05

Shouldn't size<r>::type in the table be size<r>::value? The examples following the table do show the use of value.

1 1

[boost.assign] RFC on small updates
by Thorsten Ottosen 06 Feb '05

06 Feb '05

Hi All, For the next revision of boost.assign I have planned the following changes: 1. all arguments are passed by const reference 2. support for boost.graph 3. list_of()'s type has begin() and end() member functions. These will now return a mutable iterator even though they are const. (to allow better use of anonymous arrays) 4. a new super-efficient version of list_of() which can be used whenever efficiency matters and when references needs to be forwarded. For example: template< class Range > typename Range::const_iterator max_element( const Range& r ) { return std::max_element( r.begin(), r.end() ); } ... int a=1,b=5,c=3,d=4,e=2,f=9,g=0,h=7; ... int& max = *max_element( list_of<8,int&>(a)(b)(c)(d)(e)(f)(g)(h) ); BOOST_CHECK_EQUAL( max, f ); max = 8; BOOST_CHECK_EQUAL( f, 8 ); The question is if we should allow list_of<5,T> where T is not a reference or if we should require a reference argument (for the sake of efficiency). Thanks for your feedback -Thorsten -- Thorsten Ottosen ---------------------------- Dezide Aps -- Intelligent Customer Support: www.dezide.com Aalborg University --- Decision Support Systems: http://www.cs.aau.dk/index2.php?content=Research/bss C++ Boost: www.boost.org C++ Standard: http://www.open-std.org/JTC1/SC22/WG21/

2 2

A Refcounting Handle Class that supports CrossCasts
by Tommy Nordgren 06 Feb '05

06 Feb '05

I have developed a nonintrusive Reference Counting Handle class that supports crosscasts. The limitaions are that both source and target parameter types must have virtual methods, and that currently it don't supports access from multiple threads, Do the esteemed members of this list think that such a class would be a useful addition to the library?? "Home is not where you are born, but where your heart finds peace" - Tommy Nordgren, "The dying old crone"

2 1

Profiler Library Proposal
by christopher diggins 06 Feb '05

06 Feb '05

I have posted preliminary documentation and source code for a proposal for the boost profiler library at http://www.cdiggins.com/profiler/ . The code has been successfully compiled on Visual C++ 7.1 but not tested yet. There have been some updates to the code as a result of the suggestions made so far. Any further comments are appreciated. Christopher Diggins Object Oriented Template Library (OOTL) http://www.ootl.org

2 1

[boost.tr1?] request for a hash<> implementation
by Joaquín Mª López Muñoz 05 Feb '05

05 Feb '05

Hi, There are several Boost-related projects underway around the theme of unordered containers (in my case, I'm pretty much on the verge of releasing a preview of hashed indices for Boost.MultiIndex.) All these projects have the common need of a hash<> implementation being available, preferrably promoted to a public namespace rather than as an implementation detail. Although Boost.TR1's purpose is not to implement new features but rather wrap them to achieve std::tr1-compliance, I think it'd be very useful if some tr1-hash implementation could be added to Boost. For the record, I'm currently using Jeremy Maitin-Shepard and Daniel James' implementation in Sanbox files/unordered.tar.gz. I think it is a rather solid implementation, taking care of compilers witohut PTS such as MSVC++ 6.0/7.0. As for the location, my pereference would be boost/functional/hash.hpp. Boost.TR1 could embrace this later in boost/tr1/functional.hpp. Could this be done? Maybe as a separate activity from Boost.TR1? Am I entitled to do it myself as part of the upgrade of my library, even though this would be adding a new library in disguise? As it happens, I think I'll be able to release hashed indices in time for Boost 1.33, but this detail can be a showstopper :( Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 3

Two alined_storage classes in the CVS
by JOAQUIN LOPEZ MU?Z 05 Feb '05

05 Feb '05

With the recent addition of TR1 aligned_storage to Boost.TT, there's a nasty collision with a class named exactly the same and living in boost/aligned_storage.hpp (this class is a spin-off from Boost.Variant, IIRC.) I think this has been discussed some months ago, but with no resolution to the best of my knowledge. Apart from the symbol clash, these two classes do not provide the same functionality, so I guess it'd be sensible to rename the older aligned_storage to something else. Ideas? Joaquín M López Muñoz Telefónica, Invstigación y Desarrollo

10 14

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