- Boost - lists.boost.org

test serialization/shared_ptr_132*: fails due to #include error
by Phil Richards 17 Jun '05

17 Jun '05

Test serialization - test_shared_ptr_132_text_archive - gcc Compiler output: ../libs/serialization/test/test_shared_ptr_132.cpp:24:50: error: boost/serialization/shared_ptr_132.hpp: No such file or directory The error is correct (amazingly enough) - test_shared_ptr_132.cpp has a #include for <boost/serialization/shared_ptr_132.hpp> The actual file location is boost/serialization/detail/shared_ptr_132.hpp Also, a warning that could be got rid of: In file included from ../libs/serialization/test/test_shared_ptr_132.cpp:32: /home/pgr/src/boost/boost/serialization/export.hpp:201:75: warning: backslash and newline separated by space phil -- change name before "@" to "phil" for email

1 0

[preprocessor][vacpp] BOOST_PP_SEQ_FOR_EACH failing
by JOAQUIN LOPEZ MU?Z 17 Jun '05

17 Jun '05

The attached sample fails in IBM VisualAge C++ V6.0 for AIX with the following message: vacpp.compile.c++ bin/vacpp/debug/seq.o "seq.cpp", line 10.14: 1540-0861 (S) Too few arguments are specified for macro "BOOST_PP_IIF_0". Empty arguments are used. "/home/tk/ext_projects/boost_life/boost/boost/preprocessor/control/iif.h pp", line 31.10: 1540-0425 (I) "BOOST_PP_IIF_0" is defined on line 31 of "seq.cpp". "seq.cpp", line 10.14: 1540-0861 (S) Too few arguments are specified for macro "BOOST_PP_IIF_0". Empty arguments are used. "/home/tk/ext_projects/boost_life/boost/boost/preprocessor/control/iif.h pp", line 31.10: 1540-0425 (I) "BOOST_PP_IIF_0" is defined on line 31 of "seq.cpp". Any PP guru knows how to fix this? For motivation, this problem is currently breaking a good portion of Boost.Test in vacpp, and transitively lots of test cases in other libraries. Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

4 6

[Boost-bugs] [ boost-Bugs-1222776 ] TOP environment variable crashes installation via bjam
by SourceForge.net 17 Jun '05

17 Jun '05

Bugs item #1222776, was opened at 2005-06-17 12:02 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1222776&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Christopher Dunn (cxdunn) Assigned to: Nobody/Anonymous (nobody) Summary: TOP environment variable crashes installation via bjam Initial Comment: Immediate segmentation fault running bjam! I found the cause: I had TOP=all set as an environment variable. (This tells the UNIX utility 'top' my default settings.) That causes bjam to crash, which prevents installation of boost. I don't mind that bjam uses "TOP", but it shouldn't seg fault. This was not easy to track down. (I compared my environment with that of a friend who could compile boost, and changed everything one at a time. It took hours.) Probably, if somebody else has this problem, he'll never even figure out the cause. So this really needs to be changed. Op System: Red Hat Linux boost 1.32 g++ 3.4.3 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1222776&group_… ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

libs/regex/example/grep/grep.cpp: g++ 4.0 compilation error
by Phil Richards 17 Jun '05

17 Jun '05

Test regex/grep is failing due to a compilation error with g++ 4.0: ../libs/regex/example/grep/grep.cpp: In function 'int main(int, const char**)': ../libs/regex/example/grep/grep.cpp:130: error: invalid conversion from 'const char**' to 'char**' ../libs/regex/example/grep/grep.cpp:130: error: initializing argument 2 of 'boost::program_options::basic_command_line_parser<charT>::basic_command_line_parser(int, charT**) [with charT = char]' This is due to "main" being declared as: int main(int argc, const char * argv[]) ... phil -- change name before "@" to "phil" for email

3 2

Re: [boost] Header error using boost.regex 1.32 built using vc6
by Martin Bonner 17 Jun '05

17 Jun '05

From: John Maddock [mailto:john@johnmaddock.co.uk] >> It would be nice if there was warning somewhere in the documentation >> "that error means you have done this, and we can't cope if you have >> to use VC6". > > Good point, although if I document every VC6 bug (just how long has > that compiler been superseded for now?), it's going to take a long > long time.......... Sigh. Yes :-( (BTW, our legacy tools still use VC5. VC6 didn't seem to offer much advantage at the time, and although VC7.1 is now standard compliant, there are too many other breaking changes in the extensions to be able to switch.) -- Martin Bonner Martin.Bonner(a)Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 441434

1 0

Re: [boost] MPL: clever way to remove *all* duplicates in a (nonintegral) sequence?
by Brian Braatz 17 Jun '05

17 Jun '05

> "Brian Braatz" <brianb(a)rmtg.com> writes: > > > > I am looking for a way to basically do this: > > > > typedef vector<int,float,float,char,int,int,int,double> types; > > typedef vector<int,float,char, double> expected; > > typedef unique_all< types, is_same<_1,_2> >::type result; > > > > BOOST_MPL_ASSERT(( equal< result,expected > )); > > > > > > (note the examples I am using use integral types, in my situation I am > > not using integral types) > > > [David Abrahams Writes:] > If you don't need to preserve order, just stick them in an > mpl::set<>. In fact, you might be able to use a set<> to begin with > and just skip the vector<>. > > Otherwise, I would write a little algorithm based on the > implementation of remove_if (which you can find nicely described in > the online reference manual). Instead of passing along a predicate at > each stage of the fold<>, pass along a set<> that accumulates the > elements you've already seen. When the next element is already in the > set<>, skip it. > > Try working that out for yourself; it'll be good for you ;-) > If you get stuck, ask again! > [Brian Braatz Writes:] :) Thank you for the advice. There is a common mental pattern that occurs: "Hmm.. there SHOULD be a SIMPLE way to do X." (flip through MPL book, MPL ref manual, google boost archives, write sample code) "Hmm.. Ok I can see there maybe a way to do this COMPLETELY from scratch, but I am not totally certain I need to do that. I need to keep looking. There probably is a clever one liner to solve the problem".... Your advice was EXACLY what I needed. (i..e how to THINK about the solution) THANK YOU :) Brian

2 1

boost::implicit_cast - no documentation, misleading header comment
by Phil Richards 17 Jun '05

17 Jun '05

In a moment of outstanding boredom, I ran the regression tests for the latest gcc 4.0.1 snapshot under Linux. Looking through the fails in the HTML report I noticed that boost::implicit_cast was shown as failing test implicit_cast_fail. The output of the test is: ../libs/conversion/test/implicit_cast_fail.cpp: In function 'int test_main(int, char**)': ../libs/conversion/test/implicit_cast_fail.cpp:21: error: conversion from 'const char*' to non-scalar type 'foo' requested ../libs/conversion/test/implicit_cast_fail.cpp:21: warning: unused variable 'x' ../libs/conversion/test/implicit_cast_fail.cpp:22: warning: control reaches end of non-void function (failed-as-expected) ../bin/boost/libs/conversion/test/implicit_cast_fail.test/gcc/debug/implicit_cast_fail.o Given that (as far as my understanding of the test suite goes) compilation failure is the expected behaviour, why is this highlighted as a test failure in the HTML report? Anyway, off I trundle to find out what it is supposed to do. Unfortunately, there doesn't appear to be any documentation for "implicit_cast". So I look in the header file and find: // implementation originally suggested by C. Green in // http://lists.boost.org/MailArchives/boost/msg00886.php And dutifully follow the link to find an article by Peter Dimov about "Perfect Forwarding". I apologise if I'm being dumb and missing something obvious, but something looks a little screwy... phil -- change name before "@" to "phil" for email

2 1

Re: [boost] MPL: clever way to remove *all* duplicates in a(nonintegral) sequence?
by Brian Braatz 17 Jun '05

17 Jun '05

GOT IT! see below: > -----Original Message----- > On Behalf Of Brian Braatz > a(nonintegral) sequence? > > > "Brian Braatz" <brianb(a)rmtg.com> writes: > > > > > > I am looking for a way to basically do this: > > > > > > typedef vector<int,float,float,char,int,int,int,double> types; > > > typedef vector<int,float,char, double> expected; > > > typedef unique_all< types, is_same<_1,_2> >::type result; > > > > > > BOOST_MPL_ASSERT(( equal< result,expected > )); > > > > > > > > > (note the examples I am using use integral types, in my situation I > am > > > not using integral types) > > > > > > [David Abrahams Writes:] > > If you don't need to preserve order, just stick them in an > > mpl::set<>. In fact, you might be able to use a set<> to begin with > > and just skip the vector<>. > > > > Otherwise, I would write a little algorithm based on the > > implementation of remove_if (which you can find nicely described in > > the online reference manual). Instead of passing along a predicate at > > each stage of the fold<>, pass along a set<> that accumulates the > > elements you've already seen. When the next element is already in the > > set<>, skip it. > > > > Try working that out for yourself; it'll be good for you ;-) [Brian Braatz Writes:] OK I finally figured this out, thanks in BIG PART to David sending me down the right path of thinking. I am also going to save this mail, and double back around at some point and write this by hand. (I still a little shaky with the full bore compile time recursion code- and (as David suggests) this would be an excellent way to get better) I have written a small sample and am including it in this mail. I am doing this for the benefit of someone in the future searching the list archives looking for a solution. here is the working solution: this sample takes a list of types in a sequence and removes the duplicate types struct A {}; struct B {}; struct C {}; struct D {}; void RemoveDupsFromSequence() { // 10 elements in dups, but only 4 unique types typedef vector<B,D,A,B,C,B,D,B,C,C>::type dups; // copy it into a set<>, // the insert<> applied to set<> will // ensure the same type cannot be added twice typedef copy< dups , inserter< set< >, insert<_1,_2 > > >::type result; // Prints 10 cout << "dups size " << mpl::size<dups>::value << endl; // Prints 4 - result is now something like set<A,B,C,D> // Note: actual order is unknown\indeterminate for result cout << "result size " << mpl::size<result>::value << endl; } BIG THANKS to David Abrahams :) Brian

1 0

[new lexical cast] all codewarrior tests are broken
by Thorsten Ottosen 17 Jun '05

17 Jun '05

Hi, Take a look at http://tinyurl.com/9kh7f please. All codewarrior test in ptr_container are broken due to this. -Thorsten Thorsten Ottosen ---------------------------- www.dezide.com http://www.cs.aau.dk/index2.php?content=Research/mi www.boost.org www.open-std.org/JTC1/SC22/WG21/

2 1

[interval] Borland patch
by AlisdairM 17 Jun '05

17 Jun '05

The interval library is currently marked 'unusable' for Borland so any patch will not show up in regular regression testing! There is a strange compile error that the member functions lower/upper cannot be found in class interval. I still don't have a small test case for the bug, but it appears to depend on the order of declaration in the class itself. Moving these two declarations higher up the file solves the problem: cvs diff interval.hpp (in directory \boost\boost\numeric\interval) Index: interval.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/numeric/interval/interval.hpp,v retrieving revision 1.7 diff -r1.7 interval.hpp 46a47,49 > const T& lower() const; > const T& upper() const; > 68,70d70 < const T& lower() const; < const T& upper() const; < In particular, anywhere above the constructor: template<class T1, class Policies1> interval(interval<T1, Policies1> const &r); seems to do the trick. This assumes the library author wants to start supporting Borland again of course ;¬) -- AlisdairM

2 1