- Boost - lists.preview.boost.org

[tokenizer and token_iterator] request for policy or redesign
by Thorsten Ottosen 30 Sep '04

30 Sep '04

Hi John, I vaguely recall that the standard committee rejected the tokenizer proposal because of performance problems. A thing that would boost performance a lot would be to allow the user to specify a "token match type". So I have some stupid questions: 1. Why is the three template paramters not defined as template < class TokenizerFunc = char_delimiters_separator<char>, class Type = std::string class Iterator = typename range_const_iterator<Type>::type > class tokenizer ?? 2. what is the requirement exactly on the Type parameter? 3. would it not be possible to allow typedef boost::tokenizer< fun, boost::sub_range<string> > tokenizer; ? I believe this would give a huge speedup. br Thorsten

6 23

[Serialization] Remaining failures markup
by Aleksey Gurtovoy 30 Sep '04

30 Sep '04

Robert, Pending msvc-stlport issue aside, the serialization library reports show quite a few failures with other toolsets, in particular: cw-9.3 borland-5.6.4 cw-8.3 msvc vc7 I'm sure you've well aware of these; what I'd like to ask you is to comment on them in the "explicit-failures-markup.xml" in the similar way you commented on "*_warchive" tests, so that a) the library users are not scared away by all these yellow cells, and b) the release manager and everybody else besides the author have a simple way of telling whether the library is in the OK state or not. Thanks in advance, -- Aleksey Gurtovoy MetaCommunications Engineering

1 0

[Random] GCC 2.95.3 regressions
by Aleksey Gurtovoy 30 Sep '04

30 Sep '04

Given that the code compiles with the latests versions of the compiler, the following (from http://tinyurl.com/58lll) is most likely to be a compiler bug, but since the test used to pass some time ago, I was wondering if anyone is interested in making it work again or simply commenting on it before I mark it green: /boost/head-regression/boost/boost/random/xor_combine.hpp: In method `uint32_t boost::random::xor_combine<boost::random::linear_feedback_shift<unsigned int,32,31,13,12,0>,0,boost::random::linear_feedback_shift<unsigned int,32,29,2,4,0>,0,0>::min() const': /boost/head-regression/boost/boost/random/xor_combine.hpp:74: instantiated from `boost::random::xor_combine<boost::random::xor_combine<boost::random::linear_feedback_shift<unsigned int,32,31,13,12,0>,0,boost::random::linear_feedback_shift<unsigned int,32,29,2,4,0>,0,0>,0,boost::random::linear_feedback_shift<unsigned int,32,28,3,17,0>,0,0>::min() const' /boost/head-regression/boost/libs/random/random_test.cpp:251: instantiated from `instantiate_urng<boost::taus88, unsigned int>(const basic_string<char,string_char_traits<char>,__default_alloc_template<true,0> > &, const boost::taus88 &, const unsigned int &)' /boost/head-regression/boost/libs/random/random_test.cpp:377: instantiated from here ... Date: 2004-09-26 06:35 set -e "/usr/local/gcc-2.95.3/bin/g++wrap" --limit-memory=600 --limit-cpu=1800 -c -Wall -ftemplate-depth-255 -g -O0 -fno-inline -I"../bin/boost/libs/random/test" -I "/boost/head-regression/boost" -o "../bin/boost/libs/random/test/random_test.test/gcc-2.95.3-linux/debug/random_test.o" "/boost/head-regression/boost/libs/random/random_test.cpp" "/usr/bin/objcopy" --set-section-flags .debug_str=contents,debug "../bin/boost/libs/random/test/random_test.test/gcc-2.95.3-linux/debug/random_test.o" Anyone? -- Aleksey Gurtovoy MetaCommunications Engineering

1 1

[Lambda] GCC 3.4.1 failures
by Aleksey Gurtovoy 30 Sep '04

30 Sep '04

Jaakko, Could you please take a look/comment on the following failure in "bind_tests_simple_f_refs" (from http://tinyurl.com/52xlg) "C:\MinGW341\bin\g++" -c -Wall -ftemplate-depth-255 -g -O0 -fno-inline -mno-cygwin -I"C:\MinGW\Bronek\boost\results\bin\boost\status" -I "C:\MinGW\Bronek\boost\boost" -o "C:\MinGW\Bronek\boost\results\bin\boost\status\bind_tests_simple_f_refs.test\mingw-3.4.1\debug\bind_tests_simple_f_refs.obj" "C:\MinGW\Bronek\boost\boost\libs/lambda/test/bind_tests_simple_f_refs.cpp" C:\MinGW\Bronek\boost\boost\libs/lambda/test/bind_tests_simple_f_refs.cpp: In function `int test_main(int, char**)': C:\MinGW\Bronek\boost\boost\libs/lambda/test/bind_tests_simple_f_refs.cpp:69: error: call of overloaded `bind(int (&)())' is ambiguous C:/MinGW/Bronek/boost/boost/boost/lambda/detail/bind_functions.hpp:48: note: candidates are: const boost::lambda::lambda_functor<boost::lambda::lambda_functor_base<boost::lambda::action<1, boost::lambda::function_action<1, T> >, typename boost::lambda::detail::bind_tuple_mapper<Result (&)(), boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, 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 (&)()) [with Result = int] C:/MinGW/Bronek/boost/boost/boost/lambda/detail/bind_functions.hpp:70: note: const boost::lambda::lambda_functor<boost::lambda::lambda_functor_base<boost::lambda::action<1, boost::lambda::function_action<1, boost::lambda::detail::unspecified> >, typename boost::lambda::detail::bind_tuple_mapper<const Arg1, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, 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&) [with Arg1 = int ()()] C:\MinGW\Bronek\boost\boost\libs/lambda/test/bind_tests_simple_f_refs.cpp:70: error: call of overloaded `bind(int (&)(int), int)' is ambiguous C:/MinGW/Bronek/boost/boost/boost/lambda/detail/bind_functions.hpp:188: note: candidates are: const boost::lambda::lambda_functor<boost::lambda::lambda_functor_base<boost::lambda::action<2, boost::lambda::function_action<2, T> >, typename boost::lambda::detail::bind_tuple_mapper<Result (&)(Par1), const Arg2, boost::tuples::null_type, boost::tuples::null_type, 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), const Arg2&) [with Result = int, Par1 = int, Arg2 = int] C:/MinGW/Bronek/boost/boost/boost/lambda/detail/bind_functions.hpp:210: note: const boost::lambda::lambda_functor<boost::lambda::lambda_functor_base<boost::lambda::action<2, boost::lambda::function_action<2, boost::lambda::detail::unspecified> >, typename boost::lambda::detail::bind_tuple_mapper<const Arg1, const Arg2, boost::tuples::null_type, boost::tuples::null_type, 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&) [with Arg1 = int ()(int), Arg2 = int] [...] ? -- Aleksey Gurtovoy MetaCommunications Engineering

2 2

Test failure with STLPort
by Robert Ramey 30 Sep '04

30 Sep '04

I've noticed that you are testing the serialization library with the toolset msvc-stlport. I've tested that here and got most of to pass - at least as well as standard msvc. I had to make some changes though and I believe that you will have to make similar ones if you want the test to pass. I had to invoke the following before running the tests. export STLPORT_PATH="c:/" export STLPORT_VERSION=4.5.3 export STLPORT_INCLUDE_DIRECTORY="c:/program files/Microsoft Visual Studio/vc98/include/stlport" my stlport install process created a special set of stlport header files in the msvc include directory. This is and altered version of the original ones. The original ones compiler ok but they have some switches set so that some inline code is not included and this makes the test builds fail at link time. The above variables communicate information to the msvc-stlport toolset on where to look for the stlport headers. Note that the documentation on msvc-stlport jam is somewhat out of date so that confuses this issue as well. Note that failures of other STLPort toolsets that depended upon vc6 may be related to this issue as well. Robert Ramey

2 3

Python/GCC 3.4.1/Linux failures
by Gottfried.Ganssauge＠HAUFE.DE 30 Sep '04

30 Sep '04

David Abrahams wrote: > Martin Wille <mw8329(a)yahoo.com.au> writes: > > > David Abrahams wrote: > >> Martin Wille writes: > >> > >>>Trying: assert abs(rewrap_value_complex_float(4+.2j) - > (4+.2j)) < .000001 > >>>Expecting: nothing > >>>Segmentation fault > >> Wild guess: This is an ODR violation. The Boost.Python library and > >> the test shared library were compiled with a different > definition of > >> std::complex. > > > > How could that have happened? > > Weird INCLUDE picked up from the environment? Sorry, after that I'm > fresh out of wild guesses ;-) > > GDB should be able to show you what's going wrong, though. > > > Note, this is not the intel compiler, > > so flags like "-cxxlib-gcc" shouldn't be a problem here. Could the > > build system use so different flags that the resulting libraries > > wouldn't be interoperable? (I know this can happen rather easily > > on other systems. However, I haven't seen that with gcc on Linux > > as long as you stick to the same compiler version). > > > > Python was compiled using gcc 3.3.4. Could this cause the problem? > > (I don't think so.) It probably can if python was linked using the C++-Compiler. Gcc-3.3 uses libstdc++.so.5 for it's standard library whereas gcc-3.4 uses libstdc++.so.6. Probably both are dynamically linked to your extension (ldd will reveal if that's the case). Cheers, Gottfried

1 0

[Filesystem] Intel 7.1/Linux failures
by Aleksey Gurtovoy 30 Sep '04

30 Sep '04

Does anyone have anything to say on this one (from http://tinyurl.com/5jnv6) Compiler output []: /boost/head-regression/boost/libs/filesystem/build/../src/operations_posix_windows.cpp(122): error: the global scope has no "readdir64" if ( (dp = ::readdir( handle )) == 0 ) ^ /boost/head-regression/boost/libs/filesystem/build/../src/operations_posix_windows.cpp(313): error: incomplete type is not allowed struct stat path_stat; ^ /boost/head-regression/boost/libs/filesystem/build/../src/operations_posix_windows.cpp(314): error: the global scope has no "stat64" if(::stat( ph.string().c_str(), &path_stat ) != 0) ^ /boost/head-regression/boost/libs/filesystem/build/../src/operations_posix_windows.cpp(339): error: incomplete type is not allowed struct stat lcl_stat; ^ [...] ? Should I mark the library as unusable in this configuration? -- Aleksey Gurtovoy MetaCommunications Engineering

3 8

Any Intel on Linux Gurus (help wanted with toolset for 8.1)?
by John Maddock 30 Sep '04

30 Sep '04

Apparently from Intel 8.1 onwards, we can no longer link C++ programs with icc as the current intel-linux toolset does: icc is now Intel's equivalent to gcc and performs a C only link, we need to use icpc to link C++ programs (and ideally to compile them as well, although icc currently still recognises C++ source and internally calls icpc). So here's the big question - does anyone have access to Intel 6 and/or 7 on Linux and do these also have icpc? If they do, then this is a no-brainer change to the toolset, but if not then we're going to have to get creative :-| Thanks, John.

2 2

ublas problem
by Matthias Troyer 30 Sep '04

30 Sep '04

Hi, I encounted a strange assertion failure in ublas: Assertion failed in file /Users/troyer/src/boost/boost/numeric/ublas/matrix_sparse.hpp at line 2603: !preserve internal logic Can anyone shed light on this? Matthias

1 0

[config] bcc configuration fix
by Tobias Schwinger 30 Sep '04

30 Sep '04

Just tripped over this (maybe still "sleeping") bug: Neither Builder 5 nor the free 5.5.1 tool chain do support member function specializations: 27a28 > # define BOOST_NO_MEMBER_FUNCTION_SPECIALIZATIONS

2 2