March 2006 - Boost - lists.preview.boost.org

[optional] from_optional
by Vaclav Vesely 16 Mar '06

16 Mar '06

Hi, There is common need of getting value from optional with possibility to define default value in case of the optional is uninitialized. I suggest two alternatives: optional<int> o; int i = o.get(123); // meber function get with additional parameter int j = from_optional(o, 123); // free function Both alternatives can be implemented simultaneously. What do you think about it? Regards, Vaclav

2 1

[ANN] xpressive 1.0 in CVS and File Vault
by Eric Niebler 16 Mar '06

16 Mar '06

I'm pleased to announce the availability of xpressive 1.0. This is the code that is currently in Boost CVS and will be part of Boost v1.34. It is also available as a separate download in the File Vault, and it works with Boost v1.32 and higher. xpressive is a regular expression template library that allows regexes to be strings or expression templates, and to nest and call each other recursively. Its interface is similar to TR1.Regex. Download: http://tinyurl.com/gjzap Documentation: http://tinyurl.com/882t8 -- Eric Niebler Boost Consulting www.boost-consulting.com

1 0

HP-UX aCC or boost problem?
by Ralf W. Grosse-Kunstleve 16 Mar '06

16 Mar '06

While trying to port Boost.Python to HP-UX using the native "aCC" compiler I ran into this issue: void foo() { enum udt_builtin_mixture_enum { builtin_to_builtin ,builtin_to_udt ,udt_to_builtin ,udt_to_udt } ; udt_builtin_mixture_enum value1 = builtin_to_builtin; // this works udt_builtin_mixture_enum value2 = 0; // this doesn't } % aCC -AA -c enum_init.cpp "enum_init.cpp", line 11: error #2144: a value of type "int" cannot be used to initialize an entity of type "udt_builtin_mixture_enum" udt_builtin_mixture_enum value2 = 0; ^ 1 error detected in the compilation of "enum_init.cpp". Is the compiler correct in rejecting the initialization with 0? Thanks! Cheers, Ralf P.S.: aCC: HP aC++/ANSI C B3910B A.06.01 [Jan 05 2005] __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

4 12

[test] compile error on floating point comparison
by Vladimir Prus 16 Mar '06

16 Mar '06

The last test results on msvc (RudbekAssociates, as well as huber-V2), have a failure in math library that seems to be caused by Boost.Test. See: http://tinyurl.com/hon2m Seems like "max" and "min" are defined as macros. Per max/min guidelines (http://boost.org/more/lib_guide.htm) I've fixed this with attached patch, and comitted it as obvious. Hope this will fix the issue. - Volodya

2 1

[Boost-bugs] [ boost-Bugs-1451470 ] 64 bit compile warning/error for boost::format
by SourceForge.net 16 Mar '06

16 Mar '06

Bugs item #1451470, was opened at 2006-03-16 09:25 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1451470&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: 64 bit compile warning/error for boost::format Initial Comment: We are using MS Visual Studio 2005. Compiling for 64 bit Windos. We are compiling with warning level 4 and warnings == error. We're using boost 1.33.1 and STLPort 5.0.0 boost::format generates a possible loss of data conversion warning when compiling alt_sstream_impl.hpp -Lee lee.eggebroten(a)atlassolutions.com ++++++++++++++++++++++++++++++++++++++++++++ 1>c:\External\boost_1_33_1\boost/format/alt_sstream_impl.hpp(110) : error C2220: warning treated as error - no 'object' file generated 1> c:\External\boost_1_33_1\boost/format/alt_sstream_impl.hpp(96) : while compiling class template member function 'stlp_std::fpos<_StateT> boost::io::basic_altstringbuf<Ch,Tr,Alloc>::seekoff(__int64,stlp_std::ios_base::seekdir,stlp_std::ios_base::openmode)' 1> with 1> [ 1> _StateT=mbstate_t, 1> Ch=char, 1> Tr=stlp_std::char_traits<char>, 1> Alloc=stlp_std::allocator<char> 1> ] 1> c:\External\boost_1_33_1\boost/format/format_class.hpp(136) : see reference to class template instantiation 'boost::io::basic_altstringbuf<Ch,Tr,Alloc>' being compiled 1> with 1> [ 1> Ch=char, 1> Tr=stlp_std::char_traits<char>, 1> Alloc=stlp_std::allocator<char> 1> ] 1> ..\PVMTrace.cpp(120) : see reference to class template instantiation 'boost::basic_format<Ch>' being compiled 1> with 1> [ 1> Ch=char 1> ] 1>c:\External\boost_1_33_1\boost/format/alt_sstream_impl.hpp(110) : warning C4244: 'argument' : conversion from '__int64' to 'int', possible loss of data 1>c:\External\boost_1_33_1\boost/format/alt_sstream_impl.hpp(128) : warning C4244: 'argument' : conversion from '__int64' to 'int', possible loss of data 1>c:\External\boost_1_33_1\boost/format/feed_args.hpp(53) : warning C4244: 'argument' : conversion from 'stlp_std::streamsize' to 'stlp_std::basic_string<_CharT,_Traits,_Alloc>::size_type', possible loss of data 1> with 1> [ 1> _CharT=char, 1> _Traits=stlp_std::char_traits<char>, 1> _Alloc=stlp_std::allocator<char> 1> ] 1> c:\External\boost_1_33_1\boost/format/feed_args.hpp(161) : see reference to function template instantiation 'void boost::io::detail::mk_str<char,stlp_std::char_traits<char>,stlp_std::allocator<_Tp>>(stlp_std::basic_string<_CharT,_Traits,_Alloc> &,const Ch *,stlp_std::basic_string<_CharT,_Traits,_Alloc>::size_type,stlp_std::streamsize,const Ch,stlp_std::ios_base::fmtflags,const Ch,bool)' being compiled 1> with 1> [ 1> _Tp=char, 1> _CharT=char, 1> _Traits=stlp_std::char_traits<char>, 1> _Alloc=stlp_std::allocator<char>, 1> Ch=char 1> ] 1> c:\External\boost_1_33_1\boost/format/feed_args.hpp(242) : see reference to function template instantiation 'void boost::io::detail::put<Ch,Tr,Alloc,T>(T,const boost::io::detail::format_item<Ch,Tr,Alloc> &,stlp_std::basic_string<_CharT,_Traits,_Alloc> &,boost::io::basic_altstringbuf<Ch,Tr,Alloc> &,boost::io::detail::locale_t *)' being compiled 1> with 1> [ 1> Ch=char, 1> Tr=stlp_std::char_traits<char>, 1> Alloc=stlp_std::allocator<char>, 1> T=const stlp_std::string &, 1> _CharT=char, 1> _Traits=stlp_std::char_traits<char>, 1> _Alloc=stlp_std::allocator<char> 1> ] 1> c:\External\boost_1_33_1\boost/format/feed_args.hpp(251) : see reference to function template instantiation 'void boost::io::detail::distribute<Ch,Tr,Alloc,T>(boost::basic_format<Ch> &,T)' being compiled 1> with 1> [ 1> Ch=char, 1> Tr=stlp_std::char_traits<char>, 1> Alloc=stlp_std::allocator<char>, 1> T=const stlp_std::string & 1> ] 1> c:\External\boost_1_33_1\boost/format/format_class.hpp(64) : see reference to function template instantiation 'boost::basic_format<Ch> &boost::io::detail::feed<char,Tr,Alloc,const T&>(boost::basic_format<Ch> &,const stlp_std::basic_string<_CharT,_Traits,_Alloc>)' being compiled 1> with 1> [ 1> Ch=char, 1> Tr=stlp_std::char_traits<char>, 1> Alloc=stlp_std::allocator<char>, 1> T=stlp_std::string, 1> _CharT=char, 1> _Traits=stlp_std::char_traits<char>, 1> _Alloc=stlp_std::allocator<char> 1> ] 1> ..\PVMTrace.cpp(121) : see reference to function template instantiation 'boost::basic_format<Ch> &boost::basic_format<Ch>::operator %<stlp_std::string>(const T &)' being compiled 1> with 1> [ 1> Ch=char, 1> T=stlp_std::string 1> ] 1>c:\External\boost_1_33_1\boost/format/feed_args.hpp(62) : warning C4244: 'argument' : conversion from 'stlp_std::streamsize' to 'stlp_std::basic_string<_CharT,_Traits,_Alloc>::size_type', possible loss of data 1> with 1> [ 1> _CharT=char, 1> _Traits=stlp_std::char_traits<char>, 1> _Alloc=stlp_std::allocator<char> 1> ] 1>c:\External\boost_1_33_1\boost/format/feed_args.hpp(66) : warning C4244: 'argument' : conversion from 'stlp_std::streamsize' to 'stlp_std::basic_string<_CharT,_Traits,_Alloc>::size_type', possible loss of data 1> with 1> [ 1> _CharT=char, 1> _Traits=stlp_std::char_traits<char>, 1> _Alloc=stlp_std::allocator<char> 1> ] 1>Build Time 0:02 1>Build log was saved at "file://c:\Ad Serving\main\pvm\pvm_core\Release_Win32\BuildLog.htm" 1>pvm_core - 1 error(s), 5 warning(s) ========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ========== ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1451470&group_… ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Compiler Status > General Info
by David Abrahams 16 Mar '06

16 Mar '06

This link on our home page seems to point to information that is utterly out-of-date. Can we kill it, please? -- Dave Abrahams Boost Consulting www.boost-consulting.com

1 0

[serialization][tru64cxx] assertion failed at extended_type_info.cpp
by JOAQUIN LOPEZ MU?Z 16 Mar '06

16 Mar '06

Hello, As of recently, the serialization test of Boost.MultiIndex has begun failing in Compaq C++ for Tru64, the behavior being a failed asertion at tkmap::insert(): http://tinyurl.com/kfqfs The test used to work, but has hundergone a significant change that I've got the hunch might be related to its currently failing: previously all serialization tests were performed in a single translation unit named test_serialization.cpp, while now the code has been split (for reasons irrelevant to this discussion) into two files test_serialization1.cpp and test_serialization2.cpp. Does this ring some bell? I've scanned the net for more info, the only thing I found is a reference to the same assertion at: http://lists.boost.org/boost-users/2006/02/17253.php but there's no conclusive answer in that thread, alas. Any help much appreciated, thank you in advance, Joaquín M López Muñoz Telefónica, Investigtación y Desarrollo

4 12

distance operation (24.3.4)
by Zara 16 Mar '06

16 Mar '06

[This message has been crossposted to boost developers list, it has been done on purpose, as it affects both communities] [Sorry if it comes up twice on Boost] I have detected that the standard declares "distance" template at 24.3.4, as taking two "InputIterator" as parameters. IMHO, the parameters shoudl be "const InputIterator" as they should not be changed by that function. In fact, the version I have seen of STLPORT does implement it like that ("const InputIterator") violating the standard, while DINKUMWARE respects the standard defintion. This has given me some problems when trying to use BOOST libraries with BDS 2006 (which comes with Dinkumware library). The function "size" in boost::iterator_range is declared "const", so that when it calls "std::distance", it will do so with "const IteratorT" parameters. With STLPORT, there will be no problem, as the undelying iterato_traits do not change. But in the case of DINKUMWARE, the underlying iterator_traits change. This is specially evident when IteratorT is [const] char *, which is a valid random access iterator. "size" will call "std::distance" with "[const] char * const" parameters, which are non-valid random iterators. I feel that DINKUMWARE is right in following the standard, but STLPORT is right in following common sense. I suggest making both points of view meet: a standard with common sense, that declares "distance" as operating over "const InputIterator". Best regards, Zara

5 12

Re: [boost] distance operation (24.3.4)
by Martin Bonner 16 Mar '06

16 Mar '06

----Original Message---- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of John Maddock Sent: 16 March 2006 10:24 To: boost(a)lists.boost.org Subject: Re: [boost] distance operation (24.3.4) >> const char * is not a random access iterator because it is not an >> output iterator, therfore not a forward iterator, therefore not a >> bidirectional iterator and therefore not a random access iterator - >> 24.1 >> >> The iterator categories are defined in 24.1, iterator traits is >> simply an aid to deducing that category for a given iterator. As it >> happens, you have found a defect in the standard, that >> itetarator_traits< const T * > reports the wrong category. Of >> course my preferred fix would be to find a better category >> definition so that 24.3.1.2 was correct <g> > > Hold your horses here: surely const char* most certainly *is* a random > access iterator, albeit an immutable one. I don't see anything in > 24.1 that > requires OutputIterator semantics for anything except, well output > iterators :-) > > Waiting to be shot down in flames yours, John. Section 24.1, paragraph 3 says: "Forward iterators satisfy all the requirements of the ... output iterators" On the other hand, paragraph 4 says "A forward ... iterator can ... be ... constant". "Constant iterators do not satisfy the requirements for output iterators". I think there is a clear defect in the standard here. > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost -- Martin Bonner Martin.Bonner(a)Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 203894

1 0

[mpl] multiset_test failure
by Vladimir Prus 16 Mar '06

16 Mar '06

Hello! The multiset_test of Boost.MPL fails on every platform being tested. Example error is: http://tinyurl.com/gdx38 Can somebody look into this? Thanks, Volodya

2 1