- Boost - lists.boost.org

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

[ptr_container] iterators bug
by Alexey Bakhvalov 17 Jun '05

17 Jun '05

I get compiler error if I try to compare ptr_vector::iterator with ptr_vector::const_iterator. (I use the latest library downloaded from Boost CVS repository) For example, the following code doesn't compile under VC 7.1: typedef boost::ptr_vector<char> TContainer; TContainer some_vector; for (TContainer::const_iterator it = some_vector.begin(); it != some_vector.end(); ++it) ; But it definitely should...

5 19

MPL: clever way to remove *all* duplicates in a (non integral) sequence?
by Brian Braatz 17 Jun '05

17 Jun '05

i.e. the example for mpl::unique shows: typedef vector<int,float,float,char,int,int,int,double> types; typedef vector<int,float,char,int,double> expected; typedef unique< types, is_same<_1,_2> >::type result; BOOST_MPL_ASSERT(( equal< result,expected > )); note that type "expected" : typedef vector<int,float,char,int,double> expected; still has TWO ints in it. 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) I dug through the archives and found a few mentions of people asking this question and talking about it- but no substantial solution. any help appreciated Thanks Brian :)

2 1

More Boost.Range questions
by David Abrahams 17 Jun '05

17 Jun '05

I note: ////////////////////////////////////////////////////////////////////////// // default ////////////////////////////////////////////////////////////////////////// template< typename C > struct range_iterator { typedef BOOST_DEDUCED_TYPENAME C::iterator type; }; (***) ////////////////////////////////////////////////////////////////////////// // pair ////////////////////////////////////////////////////////////////////////// template< typename Iterator > struct range_iterator< std::pair<Iterator,Iterator> > { typedef Iterator type; }; template< typename Iterator > struct range_iterator< const std::pair<Iterator,Iterator> > { typedef Iterator type; }; ////////////////////////////////////////////////////////////////////////// // array ////////////////////////////////////////////////////////////////////////// template< typename T, std::size_t sz > struct range_iterator< T[sz] > { typedef T* type; }; template< typename T, std::size_t sz > struct range_iterator< const T[sz] > { typedef const T* type; }; It seems like for consistency, there should be: template< typename C > struct range_iterator<C const> { typedef BOOST_DEDUCED_TYPENAME C::const_iterator type; }; at (***). What am I missing? -- Dave Abrahams Boost Consulting www.boost-consulting.com

2 1

[Function Types] Review Reminder - just this weekend left for your reviews.
by John Maddock 17 Jun '05

17 Jun '05

This is to remind everyone that we have a review going on at present for Tobias Schwinger's Function Types library. The review period is due to end on the 20th June, which gives everyone just this weekend to take a look at Tobias submission, I'd really like to encourage as many folks as possible to take a look: if necessary we'll also extend the end of the review period if there's demand or to cope with late reviews. We'd particularly like to hear from potential users of this library. Here are the details again: Available from the sandbox at: http://boost-sandbox.sourceforge.net/vault/ or the zip file is: http://boost-sandbox.sourceforge.net/vault/index.php?action=downloadfile&fi… This library provides a metaprogramming facility to classify, decompose and synthesize function-, function pointer-, function reference- and member function pointer types. For the purpose of this documentation, these types are collectively referred to as function types (this differs from the standard definition and redefines the term from a programmer's perspective to refer to the most common types that involve functions). The classes introduced by this library shall conform to the concepts of the Boost Metaprogramming library (MPL). The Function Types library enables the user to: * test an arbitrary type for being a function type of specified kind, * inspect properties of function types, * view and modify sub types of an encapsulated function type with MPL Sequence operations, and * synthesize function types. This library supports variadic functions and can be configured to support non-default calling conventions. (The following is taken from : http://www.boost.org/more/formal_review_process.htm ) Here are some questions you might want to answer in your review: 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. John Maddock (Function Types review manager).

1 0

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

17 Jun '05

----Original Message---- From: Martyn Woerner [mailto:martyn.woerner@tesco.net] Sent: 17 June 2005 08:31 To: boost(a)lists.boost.org Subject: Re: [boost] Header error using boost.regex 1.32 built using vc6 > Mea culpa. I don't think you have (sinned that is), or at least not here. > My test program had a preceding header that included > "using namespace std;". I'd read it was bad practice, now I know > why. Sorry to waste your time. Putting "using namespace std;" before including a boost header ought to be legal. I would regard it as a bug if a boost library failed because of a preceeding "using namespace std;" ON A STANDARDS CONFORMING COMPILER. On the other hand, VC6 is very far from a standards conforming compiler, so it seems perfectly reasonable to require users not to do that. 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". -- Martin Bonner Martin.Bonner(a)Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 441434

2 1