- Boost - lists.boost.org

RE: Boost.Test and mingw (Was: [boost] [1.32 release] Intel 8.0/M ingw regression results)
by Rob Lievaart 22 Jul '04

22 Jul '04

Hi, Hi Volodya, There are some lines in test_tools.cpp to work around this but are defined only for GCC 3.3 and I am using 3.2 :-( There was a discussion on this isssue (I think) 2 days ago: http://lists.boost.org/MailArchives/boost/msg67745.php Where Gennadiy says he wil fix it. But that has not made it into cvs yet. This is the cause of a lot of errors in the report. I "hacked" around it locally by also testing for GCC 3.2 and that clears up a lot of the problems. I could post a diff for what I changed locally, but it is not a nice solution. I simply changed the == sign in the test for minor version to <= . The test discussed in the mail is better I guess. Kind regards, Rob Lievaart. Vladimir Prus wrote: > > Aleksey Gurtovoy wrote: > > Stefan Slapeta's Intel 8.0 and Rob Lievaart's Mingw/gcc 3.2.3 results > > are now available in the Boost-wide summary reports: > > > > http://www.boost.org/regression-logs/developer/summary.html > > It shows that Boost.Test fails to build at mingw, with this error: > > Z:/regression/boost/libs/test/src/test_tools.cpp: In function `bool > > boost::test_tools::tt_detail::equal_and_continue_impl(const wchar_t*, const > > wchar_t*, boost::wrap_stringstream&, boost::unit_test::basic_cstring<const > > char>, unsigned int, boost::unit_test::log_level)': > > Z:/regression/boost/libs/test/src/test_tools.cpp:190: `wcscmp' undeclared in > > namespace `std' > > Any ideas how to fix this?

3 2

Problems with program_options using GCC 3.4 on FreeBSD
by Jonathan Wakely 22 Jul '04

22 Jul '04

Hi Boosters, I've just tried building the program_options library, using GCC 3.4.1 on FreeBSD 4.8 and hit a couple of compilation errors. One error is caused by the platform, one by the compiler's stdlib. The first problem is line 116 in libs/program_options/src/utf8_codecvt_facet.cpp gcc-C++-action bin/boost/libs/program_options/build/libboost_program_options.a/gcc/debug/utf8_codecvt_facet.o /data/development/jw/src/extcvs/boost/libs/program_options/build/../src/utf8_codecvt_facet.cpp: In member function `virtual std::codecvt_base::result boost::program_options::detail::utf8_codecvt_facet_wchar_t::do_out(mbstate_t&, const wchar_t*, const wchar_t*, const wchar_t*&, char*, char*, char*&) const': /data/development/jw/src/extcvs/boost/libs/program_options/build/../src/utf8_codecvt_facet.cpp:116: error: `WCHAR_MAX' undeclared (first use this function) /data/development/jw/src/extcvs/boost/libs/program_options/build/../src/utf8_codecvt_facet.cpp:116: error: (Each undeclared identifier is reported only once for each function it appears in.) WCHAR_MAX is not defined by FreeBSD's wchar.h. Can boost::numeric_limits<wchar_t> be used instead? The second problem is visible because I built GCC with concept-checks enabled, which means the STL containers use a version of Boost's concept checks. This reveals that boost/program_options/options_description.hpp uses an incomplete type on line 232: gcc-C++-action bin/boost/libs/program_options/build/libboost_program_options.a/gcc/debug/options_description.o In file included from /data/development/jw/src/extcvs/boost/libs/program_options/build/../src/options_description.cpp:9: /data/development/jw/gcc/3.4/bin/../lib/gcc/i386-unknown-freebsd4.8/3.4.1/../../../../include/c++/3.4.1/bits/boost_concept_check.h: In instantiation of `__gnu_cxx::_SGIAssignableConcept<boost::program_options::options_description>': /data/development/jw/gcc/3.4/bin/../lib/gcc/i386-unknown-freebsd4.8/3.4.1/../../../../include/c++/3.4.1/bits/stl_vector.h:144: instantiated from `std::vector<boost::program_options::options_description, std::allocator<boost::program_options::options_description> >' /data/development/jw/src/extcvs/boost/boost/program_options/options_description.hpp:232: instantiated from here /data/development/jw/gcc/3.4/bin/../lib/gcc/i386-unknown-freebsd4.8/3.4.1/../../../../include/c++/3.4.1/bits/boost_concept_check.h:216: error: `__gnu_cxx::_SGIAssignableConcept<_Tp>::__a' has incomplete type /data/development/jw/src/extcvs/boost/boost/program_options/options_description.hpp:142: error: forward declaration of `class boost::program_options::options_description' This error can be reproduced by compiling with -D_GLIBCXX_CONCEPT_CHECKS, or -D_GLIBCXX_DEBUG. Both the concept-checks and debug mode will reject std::vector< incomplete type >. jon -- "Nothing is true. Everything is permissible." - Hassan i Sabbah

3 9

Latest Boost.Threads regression results on meta-como-win32-4.3.3-vc7
by Michael Glassford 22 Jul '04

22 Jul '04

The Boost.Threads regression results for meta-como-win32-4.3.3-vc7 at http://boost.sourceforge.net/regression-logs/developer/thread.html all fail because: <quote> "C:\Users\Administrator\boost\main\boost\boost/config/requires_threads.hpp", line 29: catastrophic error #35: #error directive: "Threading support unavaliable: it has been explicitly disabled with BOOST_DISABLE_THREADS" # error "Threading support unavaliable: it has been explicitly disabled with BOOST_DISABLE_THREADS" </quote> The reason BOOST_DISABLE_THREADS is defined is because -DBOOST_DISABLE_WIN32 being passed on the command line. Does anyone know whether this option is on the command line on purpose, or should I consider it a configuration error for that toolset? Mike

3 2

Re: [boost] Problems with program_options using GCC 3.4 on FreeBSD
by Robert Ramey 22 Jul '04

22 Jul '04

Jonathan Wakely wrote: >> Any chance we might convince you to run the whole test suite on the >> platform? I would be curious as to the results for the serialization >> library here. >Sure, but .. >I'm not able to compile it yet - more patches will be coming shortly. >The problems mostly stem from the fact that FreeBSD 4.x doesn't support >std::wstring, std::wstreambuf etc. >e.g. >libs/serialization/src/basic_text_wiprimitive.cpp should test >BOOST_NO_STD_WSTREAMBUF before using std::wistream >The wchar.h header is present, but incomplete, so GCC on FreeBSD doesn't >define the _GLIBCXX_USE_WCHAR_T macro, disabling all wchar_t support in >the C++ library. The serialization library is set up as two libraries. Serialization.lib and wserialization.lib. If there isn't proper support for wide chars, the later fails to build and the tests that depend upon fail to pass. This is what happens when I test gcc on cygwin. So the fact that there is no wide char support on a particular platform should be no problem as far as the serialization library is concerned. Of course in such environments wide char use has to be avoided. Robert Ramey

2 1

[1.32 release] Intel 8.0/Mingw regression results
by Aleksey Gurtovoy 22 Jul '04

22 Jul '04

Stefan Slapeta's Intel 8.0 and Rob Lievaart's Mingw/gcc 3.2.3 results are now available in the Boost-wide summary reports: http://www.boost.org/regression-logs/developer/summary.html -- Aleksey Gurtovoy MetaCommunications Engineering

4 4

RE: [boost] Re: Regression results
by Rob Lievaart 22 Jul '04

22 Jul '04

Hi Alekey, I am currently running your script, for tests with mingw (gcc 3.2.3) So you should see these results appearing as well, sometime today (machine is not that fast). I'll watch the output of the upload and if it fails I'll try the new script. After a quick glance at the bjam.log (still growing) I noticed that python was not setup correctly, so those tests are not run. I'll try to correct that for the next run. And in boost tests there is a problem with wcscmp not being declared in std, that causes a lot of tests to fail, but I thought I read on the list that a fix for that was submitted ?!? Well, lets see if the upload works. Kind regards, Rob Lievaart. -----Original Message----- From: Aleksey Gurtovoy [mailto:agurtovoy@meta-comm.com] Sent: 21 July, 2004 1:35 PM To: boost(a)lists.boost.org Subject: Re: [boost] Re: Regression results for Intel 8 online Stefan Slapeta writes: > The regressions are finished and should appear in the metacomm result > tables after the next update there. Stefan, It seems that the logs didn't get uploaded. Could you please run the attached 'regression.py' with the 'upload' command, e.g. python regression.py upload --runner=<your runner id> ?

2 1

Como --windows experiment failed
by Jeff Garland 22 Jul '04

22 Jul '04

Based on the regression report it looks like --windows isn't accepted: The core of it is Command-line error #571: invalid option: --windows 1 catastrophic error detected in this compilation. Compilation terminated. Details at: http://www.boost.org/regression-logs/output/metacomm-bin-boost-libs-date_ti… or http://tinyurl.com/45z6v Thanks guys -- you will need to back out the change when you get a chance. Looks like it's time to mark the dll case as failing for Comeau. Jeff

2 1

[Range] partial_workaround failure on Linux
by Jeff Garland 22 Jul '04

22 Jul '04

One of the few remaining failures on Mandrake is a range library failure that's been there for the better part of a week. Looks like it might be easy to solve... Jeff URL: http://boost.sourceforge.net/regression-logs/cs-LinuxMandrake-links.html#ra… or http://tinyurl.com/6xwh9 Small tease: range - workaround_test - gcc Compiler output: In file included from /boost_regression1/boost/boost/range/detail/common.hpp:23, from /boost_regression1/boost/boost/range/detail/iterator.hpp:14, from /boost_regression1/boost/boost/range/iterator.hpp:21, from ../libs/range/test/partial_workaround.cpp:13: /boost_regression1/boost/boost/mpl/if.hpp:141: error: namespace `algo_' undeclared /boost_regression1/boost/boost/mpl/if.hpp:143: error: `void_' was not declared in this scope /boost_regression1/boost/boost/mpl/if.hpp:143: error: `void_' was not declared in this scope ... set -e "g++" -c -Wall -ftemplate-depth-100 -g -O0 -fno-inline -I"../bin/boost/libs/range/test" -I "/home/jeff/devTools/boost_regression1/boost" -o "../bin/boost/libs/range/test/workaround_test.test/gcc/debug/partial_workaround.o" "../libs/range/test/partial_workaround.cpp" "/usr/bin/objcopy" --set-section-flags .debug_str=contents,debug "../bin/boost/libs/range/test/workaround_test.test/gcc/debug/partial_workaround.o"

2 1

Proposal for String Algorithms Library [CODE]
by zaufi＠sendmail.ru 22 Jul '04

22 Jul '04

---------- Forwarded Message ---------- Subject: Proposal for String Algorithms Library Date: Thursday 22 July 2004 09:43 From: zaufi(a)sendmail.ru To: boost(a)lists.boost.org hi boosters I would like to propose one more algorithm to SAL -- squeeze. It removes leading/trailing spaces and duplicate spaces between words. So sample string " This is \n\n a test \n" become "This is\na test". I use this function with XML/HTML related code to 'normalize' content... Hope this will help to smbd else ;) Have fun! ------------------------------------------------------- Oops. Forget to paste code... ;) <squeeze.cc> std::string squeeze(const std::string& str) { std::string out; // bool is_start_of_line = true; char last_space = 0; for (std::string::const_iterator i = str.begin(); i != str.end(); ++i) { if (std::isspace(*i)) last_space = int(!is_start_of_line) * (int(*i == '\n') * '\n' + int((*i != '\n') & (last_space != '\n')) * ' ' + int(last_space == '\n') * last_space); else { if (last_space) { out.push_back(last_space); last_space = 0; } out.push_back(*i); is_start_of_line = false; } } return out; } </squeeze.cc>

1 0

typeof: lvalue preserving
by Vertleyb 22 Jul '04

22 Jul '04

One more addition to the typeof library is a macro, that, unlike BOOST_TYPEOF(), which removes top-level consts and references, attempts to be closer to the decltype, by preserving lvalue-ness of its argument: BOOST_TYPEOF_PRESERVE_LVALUE(expr) I do admit that the name is quite clumzy :( It is directly based on the rules of binding a reference. The following table outlines which types are returned: Expression lvalue? typeof_preserve_lvalue(expression) ---------- ------- ------ int n; lvalue int& const int m; lvalue const int& int& rn = n; lvalue int& const int& rm; lvalue const int& int foo1(); int const int foo2(); const int& (unfortunately, in both VC7.1 and GCC 3.3) int& foo3(); lvalue int& const int& foo4(); lvalue const int& int(21) int 21 int The BOOST_AUTO remains based on the BOOST_TYPEOF. The references, in the same way as proposed in http://www.osl.iu.edu/~jajarvi/publications/papers/decltype_n1478.pdf, should be specified explicitly: int& foo(); BOOST_AUTO(v, foo()); // auto v = foo(); BOOST_AUTO(&r, foo()); // auto& r = foo(); BOOST_AUTO(const& cr, foo()); // auto const& cr = foo(); See http://groups.yahoo.com/group/boost/files/typeof.zip (or Spirit repository, TYPEOF_DEV branch). As always any comments are welcome. Thanks, Arkadiy

1 0