May 2004 - Boost - lists.boost.org

[prereview request][fsm]
by Andreas Huber 07 Jun '04

07 Jun '04

Dear Boosters I think boost::fsm has finally reached a state that is worthy of a formal review. The .zip can be found here: http://boost-sandbox.sf.net/fsm.zip The docs are also available online: http://boost-sandbox.sf.net/libs/fsm As always: Feedback is highly welcome. Regards, Andreas

20 187

[spirit] rule<> and copying
by Thorsten Ottosen 07 Jun '04

07 Jun '04

Hi, I've been using spirit for some config-file parsing. I have some questions: 1. why can we not copy a rule<> ? 2. if we shouldn't copy a rule, why is copying not disabled? It has been a source of errors in my code that I forgot & on my return value. br Thorsten

8 23

Re: [Boost-announce] Formal Review Tribool
by Haim Cohen 05 Jun '04

05 Jun '04

Hi, I am happy to contribute my review for the tribool library. I am a software engineer developing EDA (Electronic Design Automation) software, so I think I can contribute my 2 cents to the review of tribool, as I think EDA tools will benefit from this library. I did not compile the library. I have made a quick reading of this library, but an in-depth study of this problem domain before. First of all, my first comment is about the library's name, as well as the class name. In logic circuit simulation, there are 4 values : 0, 1, x ( which is tribool referred to as undetermine ), and z ( represents high impedance - or disconnection, and sometime referred to as "tri state" ). So, I think users will find it quite confusing when they see the 'tri' in the library's name. Since the library implements a logic value which has some value that is unknown, I would suggest 'unknown bool' or 'x bool'. Now to the interface. I think that a macro which enables renaming of the x value should not be supplied. This will make people's code less standard. Same as we all know what 'true' and 'false' mean, we should adopt a unique name for 'unknown yet quite determined logic value'. I think the default 'undetermine' name is not a good name. My suggestions : logic_x, x_value, x_logic, unknwon_bool . I also think the default tribool constructor should create a tribool object which is 'undetermine'. (Not false, as in the documentation) Besides the above, I think the interface of the class is good and succinct. Some point for thought : Users might want arrays of tribools, with all the support of bitwise operations. Is this should be a part of tribool as well ? I do not know. Now I will refer to the implementation. In real-life problems, programs might make a heavy usage of the tribool class for simulations of logic circuits. A logic circuit (at least the combinatoric part) is a DAG where nodes are logic gates, and directed archs are wires. This graph might be the result of a synthesis process, where a high level language for hardware description (e.g Verilog) is compiled into this DAG. Note : This is a very general and simple description of the process. Life are much more difficult. So, outputs will be calculated by performing lexicographic order of the DAG, and calculating from inputs to outputs. I am telling this, to convince that performance is *very* important here. With a quick look at the implementation code, I think that calculating the value using branches (if else) will not result with good performance. Calculations with true/false values only is fast - CPU vendors dedicate special hardware for this, so calculation can be made in one machine cycle. Even bitwise calculation (up to some word width) is done in one machine cycle. Compilers are making use of this, and (hopefully) compiles boolean and bitwise operators to the appropriate instruction. Unfortunately, I did not see any CPU which supports built in true/false/X arithmetic. And even if there are such CPUs available, we will not be able to use it, since boost libraries should be portable. So, it is very tempting to think - how can we implement efficient true/false/X arithmetic using the existing boolean arithmetic ? One tempting idea is to represent true/false/X with some integers, and use bitwise arithmetic to get the right results. It seems there are no such integer values. I think I even managed to proof this. Since there is already a library implementing 4 values logic (0,1,x,z) - which is SystemC - I took a quick look on how they do it with their 4-states logic data type called sc_logic. They use an approach which I think should be also used in tribool. It seems that they maintain lookup tables for each operation: AND, OR, NOT, XOR (!=) and XNOR (==). As the internal representation of tribool is enumerated type, we can use the integer value of this enumerated type to access the lookup tables (primitive 2D fixed-size and fixed-values arrays) and get the result of the calculation. This will be much faster since most CPUs has a special addressing mode for accessing arrays. So, I suggest to change implementation to use class-static fixed array to perform calculations. I know that the spirit of Boost is portability and not performance, but since what is suggested here is actually very similar to a primitive data type which might be heavily used in applications, I think it is important to consider performance as well. I hope this review would be found useful. Haim -- _____________________________________________________ Haim Cohen Software Engineer haim.cohen(a)analog.com / haimcohen2002(a)hotmail.com Analog Devices Israel (972) - 9 - 9715 406

4 4

Formal Review Tribool
by Thomas Witt 05 Jun '04

05 Jun '04

The review of Douglas Gregor's Tribool library begins now and runs through Saturday, May 29. Here is a short introduction to the library: The 3-state boolean library contains a single class, boost::logic::tribool, along with support functions and operator overloads that implement 3-state boolean logic. The tribool class acts like the built-in bool type, but for 3-state boolean logic. The three states are true, false, and indeterminate, where the first two states are equivalent to those of the C++ bool type and the last state represents an unknown boolean value (that may be true or false, we don't know). When reviewing the library, please remember to include: * What is your evaluation of the design? * What is your evaluation of the implementation? * What is your evaluation of the documentation? * What is your evaluation of the potential usefulness of the library? * Did you try to use the library? With what compiler? Did you have any problems? * How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? * Are you knowledgeable about the problem domain? And finally, every review should answer this question: * Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. The library is available in the Boost files area as tribool-20031026.tgz Thank you, Thomas Witt -- Thomas Witt witt(a)acm.org

6 6

FSM idea injetion
by Alexander Nasonov 05 Jun '04

05 Jun '04

Although my idea is supposed to solve multimethod support for dynamic_any it might be useful in FSM library. What I'm trying to build in last two weeks is some sort of typelists for overloaded function set. Each function is identified by overload_id<N> class with unique N. For example: struct read_number_transitions { // Signatures has the form NewState (OldState, Char) Positive operator()(overload_id<0>, StartState, Plus) const; Negative operator()(overload_id<1>, StartState, Minus) const; Positive operator()(overload_id<2>, StartState, Digit) const; Positive operator()(overload_id<3>, Positive, Digit) const; Negative operator()(overload_id<4>, Negative, Digit) const; static std::size_t const max_overload_id = 4; }; This approach has advantage over typelists in some cases because things are right in their places. In the example, every transition, on one hand, is represented by a call operator (this is natural, because transition is a function that takes old state and a char and returns a new state); on the other hand, argument types and return type (a signature) can be retrieved from the call operator. The retrieval is a bit problematic but I'm working on this. The problem is a lack of typeof in C++. If it were available you could write: template<int N, class C, class R, class T> mpl::identity<R(T)> tester(R (C::*)(overload_id<N>, T) const); typedef typeof(tester<0>(&read_number_transitions::operator()))::type sig0; Without typeof you know signature R(T) only inside tester<0>. This means in particular, that, in order to accumulate all signatures you have to call tester<N> recursively: call tester<0> => Positive(StartState, Plus) call tester<1> => Negative(StartState, Minus) call tester<2> => Positive (StartState, Digit) call tester<3> => Positive (Positive, Digit) call tester<4> => Negative (Negative, Digit) For other compile-time algorithms we need something similar. Even worse, often we need chain of algorithms, for example: find a first occurrence of StartState as a first argument, get a return type from that signature, find that type among first arguments and so on. We have to go deeper and deeper. In my stress tests I use 1000 functions. Can you imagine a call stack as deep as 1000 multiplied by a length of algorithms chain? Fortunately, sometimes it's possible to make it plain. 1. Predicates have boolean result, therefore, we can use sizeof/yes_type/no_type to calculate their result: template<class Predicate, int N, class C, class R, class T> typename yes_type_if< Predicate::template apply<R(T)>::type // mpl::apply style >::type tester(R (C::*)(overload_id<N>, T) const); // Example bool const result = sizeof( tester<is_same<Positive(Positive,Digit), _1>, 3>(&read_number_transitions) ) == sizeof(yes_type); I already implemented several variants of *contains* algorithm. You can take a look at g++ 3.4.0 performance here: http://cpp-experiment.sourceforge.net/overloads_contains.png This is a performance plot (in seconds) of various strategies for *contains* algorithm which is applied to a function set of length 1000. Worst case takes 80+ seconds to compile for *one-at-once linear* basic strategy while optimized strategy completes its job in 12 seconds. It's really fast. I doubt that typelist of length 1000 can ever exist without compiler panic ;-) Similar work can be done for find/find_if // returns bool contains<read_number_transitions, Negative(Negative,Digit)>::value; // returns index of Negative(Negative,Digit) find<read_number_transitions, Negative(Negative,Digit)>::value; // returns -1 because int isn't even a signature find_if<read_number_transitions,is_same<int, _1> >::value; 2. Pair comparisons. It's not yet done. The sizeof trick can be modified slightly: template<class Predicate, int N, int M, class C, class R1, class R2, class T1, class T2> typename yes_type_if< Predicate::template apply<R1(T1), R2(T2)>::type >::type tester( R1 (C::*)(overload_id<N>, T1) const, R2 (C::*)(overload_id<M>, T2) const ); Suppose, you have this cool type: typedef is_base_and_derived< function_arg<1, _1>, // first argument of signature _1 function_arg<1, _2> // first argument of signature _2 > cool; Then you can check whether a first argument of overload N is a base of a first argument of overload M: bool const result = sizeof( tester<cool,N,M>(&read_number_transitions, &read_number_transitions) ) == 1; -- Alexander Nasonov

2 3

[iterator + lambda] transform_iterator and lambda expression
by Vladimir Prus 04 Jun '04

04 Jun '04

I'm again trying to use FP in C++, and having problems. What I wanted to do was: for_each(predecesor(v, g), /* BLL expression */ ); where predecessor(..) returns a pair of 'transform_iterator' instances. The simplest example which illustrates the problem is: struct functor { typedef int result_type; int operator()(int i) const { return i+1; }; }; transform_iterator<functor, vector<int>::iterator> it(v.begin()); (cout << _1)(*it); This does not compile, because operator* of transform_iterator return rvalue which can't be bound to non-const reference that operator() of the lambda expression accepts. Of all workarounds suggsted on BLL docs, only break_const is applicable to my case (I want to pass non-const references to the lambda, so const_parameters won't do), and break_const is scary. It looks like a serious problem with using FP, so I wonder what can be done. Maybe, transform_iterator should have yet another template parameter telling if it should store a value internally, and return reference (i.e. lvalue) in that case? It need not be enabled by default, but functions like my 'predecessor' above would make use of that extra template parameter. - Volodya

4 8

Re: [boost] Re: static sized strings
by Reece Dunn 03 Jun '04

03 Jun '04

Rob Stewart wrote: >From: "Reece Dunn" <msclrhd(a)hotmail.com> > > Rob Stewart wrote: > > >From: "Reece Dunn" <msclrhd(a)hotmail.com> > > > > John Nagle wrote: > > [snip] > > I think you misunderstand what I am trying to say. See my comments >below. > >Actually, I think you misunderstood my points. ok. > > [1] You need to specify the size of the buffer. You cannot declare an >object > > of type fixed_string_base (as it is abstract), you can only have >references > > and pointers to it so you can operate on variable-capacity strings. > >Ah, but you missed that I was declaring a fixed_string_base, >where string capacity is not known. I was relying on >make_fixed_string() to deduce the array length and create an >appropriate fixed_string for it. I didn't miss it, just misunderstood what you intended. > > [2] This is the point that we are discussing. Should this line be: > > > > fixed_string< LENGTH > t; > > > > as will work with the current sandbox implementation (my suggestion #2), >or > > should it be: > > > > fixed_string< LENGTH + 1 > t; > >And that's exactly my point. It should be the former as shown by >my equivalencies. > > > Different programmers favour the different semantics, so I ask: why not > > parameterise it, providing a default behaviour. > >I'm not so sure they do and I'm not sure you need to allow for >it. If you do, I suspect you'll encourage off-by-one mistakes. >Granted, those mistakes won't result in overruns, but they will >be annoying. Furthermore that will result in different >fixed_string types; will you provide for conversions among them? >(That is, for example, from a fixed_string that adds one to the >capacity to one that doesn't?) It is the former in the implementation I have, but if you have char data[ 100 ]; // manipulate and use the data buffer in this example, the buffer is 100 characters, but only 99 are writable, with the 100th being a null character (assuming this is a C-style string). Using the current implementation, this would lead to fixed_string< 100 > data; having an extra character. This would transfer to the other model. > > >(I know there is no make_fixed_string() -- yet -- but such a > > >facility would be appropriate.) > > > > Er... the fixed_string constructors! When you declare the object, you >should > > know the size of the buffer you are using, e.g.: > > > > fixed_string< 100 > data; > >The problem is that you don't know the length of the string. >That is, with this code: > > char s[] = "1234"; > >s is a fixed size array of char with five elements. The >programmer didn't have to write: > > char s[5] = "1234"; > >Instead, the compiler figured out the length. > >That's what I'm trying to provide an equivalence for: > > fixed_string_base & s = make_fixed_string("1234"); > >With that approach, the client doesn't need to precompute the >length of the literal and can rely on the compiler (and template >magic) to deduce it and use it to create a fixed_string<5>. > >I've shown returning by value (with the temporary bound to the >reference s), but it could return a smart pointer just as well. Your original example didn't have fixed_string_base as a reference. It should be easy to implement a make_fixed_string function. > > >I think this clearer reveals that fixed_string's size parameter > ^^^^^^^ >That should have been "clearly." > > > >should specify the number of characters. Remember, one can use > > >boost::array to manage a fixed size, non-string buffer. If > > >buffer overrun protection is insufficient in boost::array, that > > >should be fixed (or a new class should be added to Boost). Thus, > > >fixed_string can ignore that usage. I am not disputing this. The question is, is the null terminator counted as a character. For the example you show, it is, but for buffers (see the example above) it isn't. I haven't got a conversion between the two models because I am only implementing the one model at the moment, but conversion would be automatic because the functions that take strings as arguments take fixed_string_base & arguments, so they should be usable regardless, consider: boost::fixed_string< 20 > str1( "This is a long string!" ); boost::fixed_string< 10 > str2; str2.assign( str1 ); This will work (cutting the string short in str2) even though the strings are of different capacities. Regards, Reece _________________________________________________________________ Express yourself with cool emoticons - download MSN Messenger today! http://www.msn.co.uk/messenger

3 5

thread, line endings
by Janusz Piwowarski 02 Jun '04

02 Jun '04

Hello In files: libs/thread/src/mutex.cpp libs/thread/src/recursive_mutex.cpp libs/thread/src/mutex.inl boost/thread/mutex.hpp boost/thread/recursive_mutex.hpp there is CR+CR+LF used as line separator. Also, in recursive_mutex constructor if defined(BOOST_HAS_WINTHREADS) m_critical_section should be initialized before m_count (it's compiler warning) Regards, Janusz

3 4

Test failure for basic_cstring_test
by Martin Wille 02 Jun '04

02 Jun '04

Hello, basic_cstring_test fails on gcc-3.2.3 in a way that causes the test post processing to fail, too. The basic_cstring_test related lines from the log file are appended to this message. The full log for gcc-3.2.3-linux can be found at http://tinyurl.com/34ltq Regression log post processing fails with this message: **** exception(205): std::exception: boost::filesystem::path: invalid name "basic_cstring_test.o(.gnu.linkonce.t._Z17constructors_testIhEvPT_+0x757):.." in path: "bin/boost/libs/test/test/basic_cstring_test.test/gcc-3.2.3-linux/debug/basic_cstring_test.o(.gnu.linkonce.t._Z17constructors_testIhEvPT_+0x757):../libs/test/test" ******** errors detected; see standard output for details ******** Regards, m gcc-C++-action ../bin/boost/libs/test/test/basic_cstring_test.test/gcc-3.2.3-linux/debug/basic_cstring_test.o /boost/head-regression/boost/boost/test/test_tools.hpp: In function `bool boost::test_tools::detail::equal_and_continue_impl(const Left&, const Right&, boost::wrap_stringstream&, boost::unit_test::basic_cstring<const char>, unsigned int, boost::unit_test::log_level, unsigned int) [with Left = size_t, Right = int]': ../libs/test/test/basic_cstring_test.cpp:82: instantiated from `void constructors_test(CharT*) [with CharT = wchar_t]' ../libs/test/test/basic_cstring_test.cpp:124: instantiated from `static void meta_constructors_test::execute(T*) [with T = wchar_t]' /boost/head-regression/boost/boost/test/test_case_template.hpp:60: instantiated from `void boost::unit_test::detail::test_case_template_instance<TestCaseTemplate, TestType>::do_run() [with TestCaseTemplate = meta_constructors_test, TestType = wchar_t]' /boost/head-regression/boost/boost/utility/value_init.hpp:49: instantiated from here /boost/head-regression/boost/boost/test/test_tools.hpp:430: warning: comparison between signed and unsigned integer expressions gcc-Link-action ../bin/boost/libs/test/test/basic_cstring_test.test/gcc-3.2.3-linux/debug/basic_cstring_test ../bin/boost/libs/test/test/basic_cstring_test.test/gcc-3.2.3-linux/debug/basic_cstring_test.o(.gnu.linkonce.t._Z17constructors_testIhEvPT_+0x657): In function `void find_test<char const>(char const*)': ../libs/test/test/basic_cstring_test.cpp:470: undefined reference to `std::char_traits<unsigned char>::compare(unsigned char const*, unsigned char const*, unsigned)' ../bin/boost/libs/test/test/basic_cstring_test.test/gcc-3.2.3-linux/debug/basic_cstring_test.o(.gnu.linkonce.t._Z17constructors_testIhEvPT_+0x757):../libs/test/test/basic_cstring_test.cpp:368: undefined reference to `std::char_traits<unsigned char>::length(unsigned char const*)' ../bin/boost/libs/test/test/basic_cstring_test.test/gcc-3.2.3-linux/debug/basic_cstring_test.o(.gnu.linkonce.t._Z17constructors_testIhEvPT_+0x8ac):../libs/test/test/basic_cstring_test.cpp:432: undefined reference to `std::char_traits<unsigned char>::compare(unsigned char const*, unsigned char const*, unsigned)' ../bin/boost/libs/test/test/basic_cstring_test.test/gcc-3.2.3-linux/debug/basic_cstring_test.o(.gnu.linkonce.t._Z17constructors_testIhEvPT_+0xa1a):../libs/test/test/basic_cstring_test.cpp:433: undefined reference to `std::char_traits<unsigned char>::compare(unsigned char const*, unsigned char const*, unsigned)' ../bin/boost/libs/test/test/basic_cstring_test.test/gcc-3.2.3-linux/debug/basic_cstring_test.o(.gnu.linkonce.t._Z17constructors_testIhEvPT_+0xb93):../libs/test/test/basic_cstring_test.cpp:480: undefined reference to `std::char_traits<unsigned char>::compare(unsigned char const*, unsigned char const*, unsigned)' ../bin/boost/libs/test/test/basic_cstring_test.test/gcc-3.2.3-linux/debug/basic_cstring_test.o(.gnu.linkonce.t._Z16data_access_testIhEvPT_+0xb8): In function `void data_access_test<unsigned char>(unsigned char*)': /boost/head-regression/boost/boost/test/detail/basic_cstring/basic_cstring.hpp:539: undefined reference to `std::char_traits<unsigned char>::compare(unsigned char const*, unsigned char const*, unsigned)' ../bin/boost/libs/test/test/basic_cstring_test.test/gcc-3.2.3-linux/debug/basic_cstring_test.o(.gnu.linkonce.t._Z16data_access_testIhEvPT_+0x1e7): In function `void data_access_test<unsigned char>(unsigned char*)': /boost/head-regression/boost/boost/test/test_tools.hpp:446: undefined reference to `std::char_traits<unsigned char>::compare(unsigned char const*, unsigned char const*, unsigned)' ../bin/boost/libs/test/test/basic_cstring_test.test/gcc-3.2.3-linux/debug/basic_cstring_test.o(.gnu.linkonce.t._Z14asignment_testIhEvPT_+0xea):/usr/local/gcc-3.2.3/include/c++/3.2.3/bits/basic_string.tcc:155: more undefined references to `std::char_traits<unsigned char>::compare(unsigned char const*, unsigned char const*, unsigned)' follow ../bin/boost/libs/test/test/basic_cstring_test.test/gcc-3.2.3-linux/debug/basic_cstring_test.o(.gnu.linkonce.t._Z17constructors_testIKhEvPT_+0x757): In function `void find_test<char const>(char const*)': ../libs/test/test/basic_cstring_test.cpp:368: undefined reference to `std::char_traits<unsigned char>::length(unsigned char const*)' ../bin/boost/libs/test/test/basic_cstring_test.test/gcc-3.2.3-linux/debug/basic_cstring_test.o(.gnu.linkonce.t._Z17constructors_testIKhEvPT_+0x8ac):../libs/test/test/basic_cstring_test.cpp:432: undefined reference to `std::char_traits<unsigned char>::compare(unsigned char const*, unsigned char const*, unsigned)' ../bin/boost/libs/test/test/basic_cstring_test.test/gcc-3.2.3-linux/debug/basic_cstring_test.o(.gnu.linkonce.t._Z17constructors_testIKhEvPT_+0xa1a):../libs/test/test/basic_cstring_test.cpp:433: undefined reference to `std::char_traits<unsigned char>::compare(unsigned char const*, unsigned char const*, unsigned)' ../bin/boost/libs/test/test/basic_cstring_test.test/gcc-3.2.3-linux/debug/basic_cstring_test.o(.gnu.linkonce.t._Z17constructors_testIKhEvPT_+0xb93):../libs/test/test/basic_cstring_test.cpp:480: undefined reference to `std::char_traits<unsigned char>::compare(unsigned char const*, unsigned char const*, unsigned)' ../bin/boost/libs/test/test/basic_cstring_test.test/gcc-3.2.3-linux/debug/basic_cstring_test.o(.gnu.linkonce.t._Z23constructors_const_testIKhEvPT_+0x114): In function `void constructors_const_test<unsigned char const>(unsigned char const*)': ../libs/test/test/basic_cstring_test.cpp:195: undefined reference to `std::char_traits<unsigned char>::compare(unsigned char const*, unsigned char const*, unsigned)' ../bin/boost/libs/test/test/basic_cstring_test.test/gcc-3.2.3-linux/debug/basic_cstring_test.o(.gnu.linkonce.t._Z20asignment_const_testIKhEvPT_+0x11f): In function `void asignment_const_test<unsigned char const>(unsigned char const*)': /usr/local/gcc-3.2.3/include/c++/3.2.3/bits/basic_string.tcc:160: undefined reference to `std::char_traits<unsigned char>::compare(unsigned char const*, unsigned char const*, unsigned)' ../bin/boost/libs/test/test/basic_cstring_test.test/gcc-3.2.3-linux/debug/basic_cstring_test.o(.gnu.linkonce.t._Z20asignment_const_testIKhEvPT_+0x258):../libs/test/test/basic_cstring_test.cpp:353: more undefined references to `std::char_traits<unsigned char>::compare(unsigned char const*, unsigned char const*, unsigned)' follow ../bin/boost/libs/test/test/basic_cstring_test.test/gcc-3.2.3-linux/debug/basic_cstring_test.o(.gnu.linkonce.t._ZN5boost9unit_test13basic_cstringIhEC1EPh+0x37): In function `boost::unit_test::basic_cstring<unsigned char>::basic_cstring[in-charge](unsigned char*)': /boost/head-regression/boost/boost/detail/shared_count.hpp:150: undefined reference to `std::char_traits<unsigned char>::length(unsigned char const*)' ../bin/boost/libs/test/test/basic_cstring_test.test/gcc-3.2.3-linux/debug/basic_cstring_test.o(.gnu.linkonce.t._ZN5boost9unit_testltIhEEbRKNS0_13basic_cstringIT_EES6_+0x7c): In function `bool boost::unit_test::operator< <unsigned char>(boost::unit_test::basic_cstring<unsigned char> const&, boost::unit_test::basic_cstring<unsigned char> const&)': /boost/head-regression/boost/boost/test/detail/basic_cstring/compare.hpp:51: undefined reference to `std::char_traits<unsigned char>::compare(unsigned char const*, unsigned char const*, unsigned)' ../bin/boost/libs/test/test/basic_cstring_test.test/gcc-3.2.3-linux/debug/basic_cstring_test.o(.gnu.linkonce.t._ZNK5boost9unit_test13basic_cstringIhE4findES2_+0xab): In function `boost::unit_test::basic_cstring<unsigned char>::find(boost::unit_test::basic_cstring<unsigned char>) const': ../libs/test/test/basic_cstring_test.cpp:329: undefined reference to `std::char_traits<unsigned char>::compare(unsigned char const*, unsigned char const*, unsigned)' ../bin/boost/libs/test/test/basic_cstring_test.test/gcc-3.2.3-linux/debug/basic_cstring_test.o(.gnu.linkonce.t._ZN5boost9unit_test13basic_cstringIhE10trim_rightES2_+0x8d): In function `boost::unit_test::basic_cstring<unsigned char>::trim_right(boost::unit_test::basic_cstring<unsigned char>)': ../libs/test/test/basic_cstring_test.cpp:260: undefined reference to `std::char_traits<unsigned char>::find(unsigned char const*, unsigned, unsigned char const&)' ../bin/boost/libs/test/test/basic_cstring_test.test/gcc-3.2.3-linux/debug/basic_cstring_test.o(.gnu.linkonce.t._ZN5boost9unit_test13basic_cstringIhE9trim_leftES2_+0x8b): In function `boost::unit_test::basic_cstring<unsigned char>::trim_left(boost::unit_test::basic_cstring<unsigned char>)': /boost/head-regression/boost/boost/detail/shared_count.hpp:345: undefined reference to `std::char_traits<unsigned char>::find(unsigned char const*, unsigned, unsigned char const&)' ../bin/boost/libs/test/test/basic_cstring_test.test/gcc-3.2.3-linux/debug/basic_cstring_test.o(.gnu.linkonce.t._ZNK5boost9unit_test13basic_cstringIhE5rfindES2_+0xab): In function `boost::unit_test::basic_cstring<unsigned char>::rfind(boost::unit_test::basic_cstring<unsigned char>) const': ../libs/test/test/basic_cstring_test.cpp:329: undefined reference to `std::char_traits<unsigned char>::compare(unsigned char const*, unsigned char const*, unsigned)' ../bin/boost/libs/test/test/basic_cstring_test.test/gcc-3.2.3-linux/debug/basic_cstring_test.o(.gnu.linkonce.t._ZN5boost9unit_test13basic_cstringIKhEC1EPS2_+0x37): In function `boost::unit_test::basic_cstring<unsigned char const>::basic_cstring[in-charge](unsigned char const*)': /boost/head-regression/boost/boost/detail/shared_count.hpp:150: undefined reference to `std::char_traits<unsigned char>::length(unsigned char const*)' ../bin/boost/libs/test/test/basic_cstring_test.test/gcc-3.2.3-linux/debug/basic_cstring_test.o(.gnu.linkonce.t._ZNSbIhSt11char_traitsIhESaIhEEC1EPKhRKS1_+0x13): In function `std::basic_string<unsigned char, std::char_traits<unsigned char>, std::allocator<unsigned char> >::basic_string[in-charge](unsigned char const*, std::allocator<unsigned char> const&)': /boost/head-regression/boost/boost/test/detail/basic_cstring/basic_cstring.hpp:531: undefined reference to `std::char_traits<unsigned char>::length(unsigned char const*)' ../bin/boost/libs/test/test/basic_cstring_test.test/gcc-3.2.3-linux/debug/basic_cstring_test.o(.gnu.linkonce.t._ZN5boost9unit_testltIKhEEbRKNS0_13basic_cstringIT_EES7_+0x7c): In function `bool boost::unit_test::operator< <unsigned char const>(boost::unit_test::basic_cstring<unsigned char const> const&, boost::unit_test::basic_cstring<unsigned char const> const&)': /boost/head-regression/boost/boost/test/detail/basic_cstring/compare.hpp:51: undefined reference to `std::char_traits<unsigned char>::compare(unsigned char const*, unsigned char const*, unsigned)' ../bin/boost/libs/test/test/basic_cstring_test.test/gcc-3.2.3-linux/debug/basic_cstring_test.o(.gnu.linkonce.t._ZNK5boost9unit_test13basic_cstringIKhE4findES3_+0xab): In function `boost::unit_test::basic_cstring<unsigned char const>::find(boost::unit_test::basic_cstring<unsigned char const>) const': ../libs/test/test/basic_cstring_test.cpp:329: undefined reference to `std::char_traits<unsigned char>::compare(unsigned char const*, unsigned char const*, unsigned)' ../bin/boost/libs/test/test/basic_cstring_test.test/gcc-3.2.3-linux/debug/basic_cstring_test.o(.gnu.linkonce.t._ZN5boost9unit_test13basic_cstringIKhE10trim_rightES3_+0x8d): In function `boost::unit_test::basic_cstring<unsigned char const>::trim_right(boost::unit_test::basic_cstring<unsigned char const>)': ../libs/test/test/basic_cstring_test.cpp:260: undefined reference to `std::char_traits<unsigned char>::find(unsigned char const*, unsigned, unsigned char const&)' ../bin/boost/libs/test/test/basic_cstring_test.test/gcc-3.2.3-linux/debug/basic_cstring_test.o(.gnu.linkonce.t._ZN5boost9unit_test13basic_cstringIKhE9trim_leftES3_+0x8b): In function `boost::unit_test::basic_cstring<unsigned char const>::trim_left(boost::unit_test::basic_cstring<unsigned char const>)': /boost/head-regression/boost/boost/detail/shared_count.hpp:345: undefined reference to `std::char_traits<unsigned char>::find(unsigned char const*, unsigned, unsigned char const&)' ../bin/boost/libs/test/test/basic_cstring_test.test/gcc-3.2.3-linux/debug/basic_cstring_test.o(.gnu.linkonce.t._ZNK5boost9unit_test13basic_cstringIKhE5rfindES3_+0xab): In function `boost::unit_test::basic_cstring<unsigned char const>::rfind(boost::unit_test::basic_cstring<unsigned char const>) const': ../libs/test/test/basic_cstring_test.cpp:329: undefined reference to `std::char_traits<unsigned char>::compare(unsigned char const*, unsigned char const*, unsigned)' ../bin/boost/libs/test/test/basic_cstring_test.test/gcc-3.2.3-linux/debug/basic_cstring_test.o(.gnu.linkonce.t._ZN5boost9unit_testeqIhhEEbRKNS0_13basic_cstringIT_EERKNS2_IT0_EE+0x5c): In function `bool boost::unit_test::operator==<unsigned char, unsigned char>(boost::unit_test::basic_cstring<unsigned char> const&, boost::unit_test::basic_cstring<unsigned char> const&)': /boost/head-regression/boost/boost/test/test_tools.hpp:434: undefined reference to `std::char_traits<unsigned char>::compare(unsigned char const*, unsigned char const*, unsigned)' ../bin/boost/libs/test/test/basic_cstring_test.test/gcc-3.2.3-linux/debug/basic_cstring_test.o(.gnu.linkonce.t._ZNKSbIhSt11char_traitsIhESaIhEE5c_strEv+0x2e): In function `std::basic_string<unsigned char, std::char_traits<unsigned char>, std::allocator<unsigned char> >::c_str() const': /usr/local/gcc-3.2.3/include/c++/3.2.3/bits/stl_algobase.h:240: undefined reference to `std::char_traits<unsigned char>::assign(unsigned char&, unsigned char const&)' ../bin/boost/libs/test/test/basic_cstring_test.test/gcc-3.2.3-linux/debug/basic_cstring_test.o(.gnu.linkonce.t._ZN5boost9unit_testeqIKhS2_EEbRKNS0_13basic_cstringIT_EERKNS3_IT0_EE+0x5c): In function `bool boost::unit_test::operator==<unsigned char const, unsigned char const>(boost::unit_test::basic_cstring<unsigned char const> const&, boost::unit_test::basic_cstring<unsigned char const> const&)': /boost/head-regression/boost/boost/test/test_tools.hpp:434: undefined reference to `std::char_traits<unsigned char>::compare(unsigned char const*, unsigned char const*, unsigned)' ../bin/boost/libs/test/test/basic_cstring_test.test/gcc-3.2.3-linux/debug/basic_cstring_test.o(.gnu.linkonce.t._ZNSbIhSt11char_traitsIhESaIhEE13_S_copy_charsEPhPKhS5_+0x20): In function `std::basic_string<unsigned char, std::char_traits<unsigned char>, std::allocator<unsigned char> >::_S_copy_chars(unsigned char*, unsigned char const*, unsigned char const*)': /boost/head-regression/boost/boost/detail/shared_count.hpp:100: undefined reference to `std::char_traits<unsigned char>::copy(unsigned char*, unsigned char const*, unsigned)' collect2: ld returned 1 exit status set -e LD_LIBRARY_PATH=/usr/local/gcc-3.2.3/lib:$LD_LIBRARY_PATH export LD_LIBRARY_PATH "/usr/local/gcc-3.2.3/bin/g++wrap" --limit-memory=600 --limit-cpu=1800 -g -o "../bin/boost/libs/test/test/basic_cstring_test.test/gcc-3.2.3-linux/debug/basic_cstring_test" -L"../bin/boost/libs/test/build/libboost_unit_test_framework.a/gcc-3.2.3-linux/debug" -L"/usr/local/gcc-3.2.3/lib" "../bin/boost/libs/test/test/basic_cstring_test.test/gcc-3.2.3-linux/debug/basic_cstring_test.o" "../bin/boost/libs/test/build/libboost_unit_test_framework.a/gcc-3.2.3-linux/debug/libboost_unit_test_framework.a" "../bin/boost/libs/test/build/libboost_unit_test_framework.a/gcc-3.2.3-linux/debug/libboost_unit_test_framework.a" -Wl,-rpath-link,. ...failed gcc-Link-action ../bin/boost/libs/test/test/basic_cstring_test.test/gcc-3.2.3-linux/debug/basic_cstring_test... ...skipped <@boost!libs!test!test/basic_cstring_test.test/gcc-3.2.3-linux/debug>basic_cstring_test.run for lack of <@boost!libs!test!test/basic_cstring_test.test/gcc-3.2.3-linux/debug>basic_cstring_test...

4 6

port of library to vacpp (item 2)
by Toon Knapen 02 Jun '04

02 Jun '04

I stumble on another problem when trying to compile the test library with IBM/VisualAge (vacpp). Apparantly vacpp has a problem on lines 97,98 and 99 of boost/test/detail/basic_cstring/basic_cstring.hpp. Basically the problem is this: this file declares a class template < class CharT > class basic_string { public: typedef basic_string<CharT> self_type ; self_type& trim_left(self_type exclusions = self_type() ) ; // line 97 } ; If I now remove the default initializer, vacpp does not choke anymore (same situation on lines 98 and 99). I tried to isolate this problem in small test but in a small test vacpp seems to deal with the situation just fine. Thus AFAICT this is a compiler-bug but would anyone mind if I remove the default initializers or just remove them in the vacpp compilation to get one step closer to running the regression tests on vacpp again.

5 8