- Boost - lists.boost.org

Thread/intel-win32-8.1 failures
by Aleksey Gurtovoy 20 Sep '04

20 Sep '04

As shown in http://tinyurl.com/6ukqm, _all_ thread library tests fail on Intel 8.1 with memory access violation (!). That's especially weird because Intel 8.0 shows quite the opposite results -- it passes all the tests. Could somebody with local access to this compiler please take a look at this? -- Aleksey Gurtovoy MetaCommunications Engineering

3 6

Re: Lexical cast suggestion
by Martin Adrian 20 Sep '04

20 Sep '04

>From: Terje Slettebø <tslettebo <at> broadpark.no> >Subject: Re: Lexical cast suggestion >Newsgroups: gmane.comp.lib.boost.devel >Date: Sat, 18 Sep 2004 14:23:50 +0200 >>From: "Martin" <adrianm <at> touchdown.se> >> I have tried to use lexical_cast many times but I always run into problems >> sooner or later due to the lack of locale support. >This issue has come up with quite regular intervals. The current docs says a >little bit about this: >"Where a higher degree of control is required over conversions, >std::stringstream and std::wstringstream offer a more appropriate path." My concern is that the current implementation gives you a false sense of portability. The documentation says nothing nothing about locales. Even the test cases for lexical_cast assumes the default "C" locale. E.g. BOOST_CHECK_EQUAL("1.23", lexical_cast<std::string>(1.23)); I think there should be a big warning about using lexcial_cast for convering numbers to/from text. The only safe place I see is when the resulting string is used to create user messages. A quick scan shows that at least "program options" uses lexical_cast for other things than user messages. lexical_cast is used to validate entries and to create default values. This means that the options must be specified in the locale the application uses (which might not be the same as the computer is running). This might be intentional but it is not documented so I have no idea how program options works in my locale.

2 1

Linux regressions
by Aleksey Gurtovoy 20 Sep '04

20 Sep '04

A clarification for developers monitoring regression reports: a significant number of Linux regressions showing up in the current reports (http://www.meta-comm.com/engineering/boost-regression/developer/summary.html) is NOT a result of some recent checkin. Most of these failures were there for some time, but weren't highlighted as regressions because the report generation tools didn't have the data for this platform to compare against. This was fixed yesterday. Similarly, new regressions for "cw-8.3" toolset are only a result of updating the old toolset name ("cwpro83") in the 1.30.2 results. I hope we can take care of these new issues quickly, although "gcc-2.95.3-stlport-4.5.3-linux" in particular doesn't look that good. Is it still a widely-used configuration? -- Aleksey Gurtovoy MetaCommunications Engineering

4 6

[Function] GCC 3.4.1 failure
by Aleksey Gurtovoy 20 Sep '04

20 Sep '04

Doug, Could you please take a look at this one (from http://tinyurl.com/7yyu5) "C:\MinGW341\bin\g++" -c -Wall -ftemplate-depth-255 -g -O0 -fno-inline -mno-cygwin -I"C:\MinGW\Bronek\boost\results\bin\boost\libs\function\test" -I "C:\MinGW\Bronek\boost\boost" -o "C:\MinGW\Bronek\boost\results\bin\boost\libs\function\test\lambda_test.test\mingw-3.4.1\debug\lambda_test.obj" "C:\MinGW\Bronek\boost\boost\libs/function/test/lambda_test.cpp" C:\MinGW\Bronek\boost\boost\libs/function/test/lambda_test.cpp: In function `int test_main(int, char**)': C:\MinGW\Bronek\boost\boost\libs/function/test/lambda_test.cpp:30: error: call of overloaded `bind(unsigned int (&)(int, bool, double), int, const boost::lambda::lambda_functor<boost::lambda::placeholder<1> >&, const boost::lambda::lambda_functor<boost::lambda::placeholder<2> >&)' is ambiguous C:/MinGW/Bronek/boost/boost/boost/lambda/detail/bind_functions.hpp:500: note: candidates are: const boost::lambda::lambda_functor<boost::lambda::lambda_functor_base<boost::lambda::action<4, boost::lambda::function_action<4, T> >, typename boost::lambda::detail::bind_tuple_mapper<Result (&)(Par1, Par2, Par3), const Arg2, const Arg3, const Arg4, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type>::type> > boost::lambda::bind(Result (&)(Par1, Par2, Par3), const Arg2&, const Arg3&, const Arg4&) [with Result = unsigned int, Par1 = int, Par2 = bool, Par3 = double, Arg2 = int, Arg3 = boost::lambda::lambda_functor<boost::lambda::placeholder<1> >, Arg4 = boost::lambda::lambda_functor<boost::lambda::placeholder<2> >] C:/MinGW/Bronek/boost/boost/boost/lambda/detail/bind_functions.hpp:528: note: const boost::lambda::lambda_functor<boost::lambda::lambda_functor_base<boost::lambda::action<4, boost::lambda::function_action<4, boost::lambda::detail::unspecified> >, typename boost::lambda::detail::bind_tuple_mapper<const Arg1, const Arg2, const Arg3, const Arg4, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type>::type> > boost::lambda::bind(const Arg1&, const Arg2&, const Arg3&, const Arg4&) [with Arg1 = unsigned int ()(int, bool, double), Arg2 = int, Arg3 = boost::lambda::lambda_functor<boost::lambda::placeholder<1> >, Arg4 = boost::lambda::lambda_functor<boost::lambda::placeholder<2> >] ? -- Aleksey Gurtovoy MetaCommunications Engineering

2 2

Python/indirect_traits_test fails on all platforms
by Aleksey Gurtovoy 20 Sep '04

20 Sep '04

For instance (from http://tinyurl.com/5qne8) call "c:\Programme\Metrowerks\Codewarrior\Other Metrowerks Tools\Command Line Tools\cwenv.bat" -quiet mwcc -c -lang c++ -maxerrors 5 -warn on -maxwarnings 20 -nowraplines -g -O0 -inline off -cwd include -warn nounusedexpr,nounused -runtime dmd -DNOMINMAX -RTTI on -iso_templates on "-IC:\boost_regression\results\bin\boost\libs\python\test" -I- "-IC:\boost_regression\boost" -o "C:\boost_regression\results\bin\boost\libs\python\test\indirect_traits_test.test\cw-9.3\debug\threading-multi\indirect_traits_test.obj" "..\libs\python\test\indirect_traits_test.cpp" ### mwcc Compiler: # File: ..\libs\python\test\indirect_traits_test.cpp # ----------------------------------------------------- # 15: using namespace boost::python::detail; # Error: ^^^^^^ # undefined identifier 'detail' ### mwcc Compiler: # 19: ((is_reference_to_function<int (&)()>::value) ? ((void) 0) : __msl_assertion_failed("is_ref; # Error: ^ # undefined identifier 'is_reference_to_function' ### mwcc Compiler: # 20: ((!is_reference_to_function<int (*)()>::value) ? ((void) 0) : __msl_assertion_failed("!is_re; # Error: ^ # undefined identifier 'is_reference_to_function' ### mwcc Compiler: # 21: ((!is_reference_to_function<int&>::value) ? ((void) 0) : __msl_assertion_failed("!is_referen; # Error: ^ # undefined identifier 'is_reference_to_function' ### mwcc Compiler: # 24: ((!is_pointer_to_function<int (&)()>::value) ? ((void) 0) : __msl_assertion_failed("!is_po; # Error: ^ # undefined identifier 'is_pointer_to_function' # Too many errors printed, aborting program User break, cancelled... -- Aleksey Gurtovoy MetaCommunications Engineering

2 1

[all/build] Build change that affects testers...
by Rene Rivera 19 Sep '04

19 Sep '04

All, Some time ago the following problem surfaced: Robert Ramey wrote: > Almost all the tests for the serialization system fail to link with the > following message: > > ### mwld Linker Error: > # Undefined symbol: '_errno' > # referenced from 'void > boost::unit_test::hrf_report_formatter::report_assertions_stat(class > std::basic_ostream<char, struct std::char_traits<char> > &, unsigned int, > unsigned long, unsigned long, unsigned long) > (?report_assertions_stat@hrf_report_formatter@unit_test@boost@@UAEXAAV?$basi > c_ostream@DU?$char_traits@D@std@@@std@@IKKK@Z)' in unit_test_result.obj > (libboost_test_exec_monitor.lib) > ### mwld Linker Error: > # Undefined symbol: '_errno' > # referenced from 'void > boost::unit_test::hrf_report_formatter::report_sub_test_cases_stat(class > std::basic_ostream<char, struct std::char_traits<char> > &, unsigned int, > unsigned long, unsigned long) > (?report_sub_test_cases_stat@hrf_report_formatter@unit_test@boost@@UAEXAAV?$ > basic_ostream@DU?$char_traits@D@std@@@std@@IKK@Z)' in unit_test_result.obj > (libboost_test_exec_monitor.lib) > > Errors caused tool to abort. > > To me, this suggests some issue regarding libboost_test_exec_monitor.lib . > > Anyone care to comment? I spent most of yesterday and today trying to figure this problem out. What it boiled down to was the "errno" use in the std::log10 function. But that wasn't the real problem... The reason it gives the above error is that when building certain tests like serialization and threads the library was using the multi-threaded runtime while the Boost.Test was using single-threaded runtime. Which needles to say is a very bad thing of the build system to do. Much time later I managed to track down the problem in the build system and fix. Now, the *important* part... This change will affect all platforms that use multiple runtimes. As far as I know this includes all Win32 compilers. So don't be surprised if the next run of regression tests take a long time and more disk space, because different variants of things will get compiled now. And if you are really paranoid about testing, you might be advised to delete the "bin/boost" build directory to start fresh. Enjoy -- the corrected functionality ;-) PS. I'm starting a fresh run of the CW-8.3/release tests now. Which should show a large number of fixed failures. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq

4 6

old regression results question
by Reece Dunn 19 Sep '04

19 Sep '04

On the regression summary page (http://www.meta-comm.com/engineering/boost-regression/developer/summary.html) there are several instances where a toolset is duplicated (win32+cw-8.3, win32+vcX.X). I was wondering if it was possible to display only the most recent results for the toolset in that instance. This would help to see where the regressions are and shorten the width of the table. Regards, Reece _________________________________________________________________ Stay in touch with absent friends - get MSN Messenger http://www.msn.co.uk/messenger

3 3

Re: [boost] Where are they now? (needed license permissions)
by JOAQUIN LOPEZ MU?Z 19 Sep '04

19 Sep '04

----- Mensaje original ----- De: John Maddock <john(a)johnmaddock.co.uk> Fecha: Jueves, Septiembre 16, 2004 2:20 pm Asunto: [boost] Where are they now? (needed license permissions) > Here are the people we still need to contact, in order to move the > rest of > Boost over to the BSL, if anyone has a more up to date email > address for > these folks than the ones shown here, please let me know, as at > present > they're not responding :-( > > Joaquín M López Muñoz joaquin(a)tid.es Hi John, this is Joaquín. I'm afraid my name appears in the list due to the occurrence of the SGI text in some of my files which are, otherwise, under the BSL license. This thread will probably refresh your mind, as we already discussed the issue: http://lists.boost.org/MailArchives/boost/msg69520.php I case you still need my permission in the blanket tile (which I don't think it's the case) please tell me so. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

stlport.jam patch
by Aleksey Gurtovoy 19 Sep '04

19 Sep '04

I just commited the following patch to "stlport.jam": =================================================================== RCS file: /cvsroot/boost/boost/tools/build/v1/stlport.jam,v retrieving revision 1.7 diff -r1.7 stlport.jam 103,104c103,106 < flags $(CURR_TOOLSET) FINDLIBS <stlport-iostream>on/<runtime-build>debug : $(STLPORT_LIB_BASE_NAME)_stldebug ; < flags $(CURR_TOOLSET) FINDLIBS <stlport-iostream>on/<runtime-build>release : $(STLPORT_LIB_BASE_NAME) ; --- > flags $(CURR_TOOLSET) FINDLIBS <stlport-iostream>on/<runtime-build>debug/<runtime-link>static : $(STLPORT_LIB_BASE_NAME)_stldebug_static ; > flags $(CURR_TOOLSET) FINDLIBS <stlport-iostream>on/<runtime-build>debug/<runtime-link>dynamic : $(STLPORT_LIB_BASE_NAME)_stldebug ; > flags $(CURR_TOOLSET) FINDLIBS <stlport-iostream>on/<runtime-build>release/<runtime-link>static : $(STLPORT_LIB_BASE_NAME)_static ; > flags $(CURR_TOOLSET) FINDLIBS <stlport-iostream>on/<runtime-build>release/<runtime-link>dynamic : $(STLPORT_LIB_BASE_NAME) ; That should take care of a number of failures with all STLPort-based toolsets; for instance, like this one -- http://tinyurl.com/5djsj. -- Aleksey Gurtovoy MetaCommunications Engineering

1 0

Avoiding warning on the do{...}while(0) macro implementation trick
by Ivan Vecerina 19 Sep '04

19 Sep '04

I've noticed discussions about this a couple of years ago. For assert-style macros that include multiple statements, a common idiom is to enclose the statements in a do{...}while(0) dummy loop. This makes the macro behave like a single statement. A problem with some compilers (notably VC7.x) is that this triggers a warning (C4127: conditional expression is constant). The workaround adopted by boost is to automatically disable this warning -- which however can be legitimate and useful in user code. I think I have found a better 'always-false' condition which does not trigger a warning, and works at least in VC7.1: do{ }while(__LINE__==-1) Do you see a problem with this approach? Could this approach be used to stop disabling warning 4127 when boost is compiled? Do other compilers have similar warnings and workarounds? Should a boost macro that expands to a warning-free always-false (or always-true) compile-time constant be considered? This would also allow statements such as BOOST_ASSERT(BOOST_FALSE), while(BOOST_TRUE), or do{...}while(BOOST_FALSE) to compile without warning... Regards, Ivan -- http://ivan.vecerina.com/contact/?subject=NG_POST <- email contact form

2 1