- Boost - lists.boost.org

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

Concept_check.hpp question
by Aleksey Gurtovoy 19 Sep '04

19 Sep '04

Is there a good reason for the following #ifdef in "concept_check.hpp": template <class Concept> inline void function_requires(mpl::identity<Concept>* = 0) { #if !defined(NDEBUG) void (Concept::*x)() = BOOST_FPTR Concept::constraints; ignore_unused_variable_warning(x); #endif } ? It causes "concept_check_fail_expected" test to fail if compiled in "release mode"; see http://tinyurl.com/6u286. Any objections to removing it? -- Aleksey Gurtovoy MetaCommunications Engineering

1 0

Re:[boost] Re: [static_assert] Regression with gcc 3.4.2?
by Robert Ramey 19 Sep '04

19 Sep '04

"David B. Held" <dheld(a)codelogicconsulting.com> wrote in message news:cihmvu$3ik$1@sea.gmane.org... > #include <boost/static_assert.hpp> > > template <typename T> > struct foo > { > void bar(void) > { > BOOST_STATIC_ASSERT(false); > } > }; I use .... BOOST_STATIC_ASSERT(sizeof(T) == 0); .... Robert Ramey

2 1

RE: [boost] Re: [Output Formatter]: Cascading Style Sheets (CSS)proposal
by Robert Ramey 19 Sep '04

19 Sep '04

Reece Dunn wrote: >I agree that Boost.Spirit, Boost.Serialization and my library overlap to >certain degrees. >IOW, CSS would be unnecessary complication for Output Formatter at this >stage. I like it this way:simple to understand and use. Formatting options >are reasonably limited. >This is the direction I am currently taking. Possibly, at some point in the >future, this library could become the output complement to Spirit (allowing >advanced code generation), as well as Spirit simplifying the binding of data >to the parser. But then again, I don't know how feasible that would be. Personally, I don't see much overlap at all between, serialization, io streams, spirit and output formatting. I see them a more complementary. Of course serialization uses streams so might work with io streams library. Serialization uses spirit to implement xml archives and it is possible someone might want to make an "annotated" archive and so want to exploit output formatting facilities. But in general these are orthogonal functions that can be composed at will. So I would be careful about making the output formatter library bigger. Bigger isn't necessarily better. I think its better if it focuses on doing one thing better than any other library does it and presents a minimal interface so that can be easily composed with related but different concepts. Robert Ramey

1 0

[static_assert] Regression with gcc 3.4.2?
by David B. Held 18 Sep '04

18 Sep '04

#include <boost/static_assert.hpp> template <typename T> struct foo { void bar(void) { BOOST_STATIC_ASSERT(false); } }; int main(void) { } --------------------------------------------------------------------- toot.cpp: In member function `void foo<T>::bar()': toot.cpp:8: error: invalid application of `sizeof' to incomplete type `boost::STATIC_ASSERTION_FAILURE< false>' --------------------------------------------------------------------- Is gcc wrong, or am I missing something really obvious? This used to work. And yes, I have the latest boost CVS snapshot. Dave

2 4