- Boost - lists.boost.org

std::string construction/assignment
by Gennadiy Rozental 31 Jan '05

31 Jan '05

Hi, One of my unit tests is failing because following code throw an exception (gcc 3.2.3 linux): #include <list> #include <string> int main() { std::list<char> l; l.push_back( 'a' ); l.push_back( 'b' ); l.push_back( 'c' ); std::string( l.begin(), l.end() ); return 0; } Does it supposed to work? Is there workarounds? Gennadiy

2 1

shared_ptr inheritance query
by Dave Handley 31 Jan '05

31 Jan '05

I wonder if anyone could help me with a particular problem I'm having with shared_ptr. I'm working on a policy template, and I want the policy template to both privately inherit, and inject enable_shared_from_this - but the 2 things seem to be mutually exclusive. Let me give you an idea of what I'm trying to do (with some gross simplification to make the code a little simpler): template <class T> class policy : public enable_shared_from_this<T> { }; template <class T> class base : private policy<T> { public: shared_ptr<T> get_ptr() { return shared_from_this(); } }; class MyClass : public base<MyClass> { }; test() { shared_ptr<MyClass> obj( new MyClass ); shared_ptr<MyClass> obj1 = obj->get_ptr(); } If you run this you get a "conversion from MyClass* to boost::enable_shared_from_this<T> * exists, but is inaccessible" error (on VC++7.1). The same is true with protected inheritance. Is there any way around this? Thanks Dave Handley

2 1

[Boost.Test] Failure building regression tools.
by Martin Wille 31 Jan '05

31 Jan '05

Hi, I can't build the regression test helper programs anymore: In file included from /boost/head-regression/boost/boost/test/included/prg_exec_monitor.hpp:20, from ../../../tools/regression/compiler_status.cpp:749: /boost/head-regression/boost/boost/test/impl/cpp_main.ipp:59: error: syntax error before `(' token /boost/head-regression/boost/boost/test/impl/cpp_main.ipp:68: error: parse error before `try' /boost/head-regression/boost/boost/test/impl/cpp_main.ipp:75: error: ISO C++ forbids declaration of `result' with no type /boost/head-regression/boost/boost/test/impl/cpp_main.ipp:75: error: redefinition of `int result' Looks like Boost.Test is the culprit. Regards, m

1 0

Re: Fw: [boost] Re: Complex type failure with boost::lexical_cast
by Kevlin Henney 31 Jan '05

31 Jan '05

In message <000c01c506b9$fed670b0$0300000a@pc>, Terje Slettebø <tslettebo(a)broadpark.no> writes >----- Original Message ----- >From: "Preston A. Elder" <prez(a)neuromancy.net> >To: <boost(a)lists.boost.org> >Sent: Sunday, January 30, 2005 4:56 AM >Subject: [boost] Re: Complex type failure with boost::lexical_cast > >I am of the opinion we should follow the standard (ie. STL) in this one. >The STL would accept both, and since we rely on operator>>, so should we. Technically, the _STL_ doesn't do anything about spaces because it doesn't do anything with I/O ;-) However, given that I/O streams handle spaces inconsistently wrt what we think of as the representation of a type, it does not seem the best example to follow -- people prefer something that works consistently. >I mean, if you're going to be anal about spaces, be completely anal about >them, but I don't think we should be, I think accepting whitespace before >and after is correct, just as the stringstream operator>> does by default. And that is where the problems begin. The older versions of lexical_cast had problems because they behaved like the other types that work with I/O streams... but since the other types don't work consistently or sensibly with I/O streams, this causes problems. For example, if we do as the standard does, then lexical_cast will not work when reading a single whitespace character and it will pick out the first space-separated sequence from a string. It is unlikely anyone would consider this desirable. So, if you're going to deal with spaces, deal with them consistently and avoid surprises. And over time this is what lexical_cast has been converging on. This latest bug is one that will be fixed, continuing the trend towards total consumption of the input representation -- we thought we had it, but this corner case was missed and fixing it will improve coverage. Reverting to inconsistent behaviour is not an attractive option. Hope that clarifies the rationale! Kevlin -- ____________________________________________________________ Kevlin Henney phone: +44 117 942 2990 mailto:kevlin@curbralan.com mobile: +44 7801 073 508 http://www.curbralan.com fax: +44 870 052 2289 Curbralan: Consultancy + Training + Development + Review ____________________________________________________________

2 1

[mpl][range_c][doc]integral_rank requirement not mentioned
by Larry Evans 31 Jan '05

31 Jan '05

Apparently, the T in: range_c<T,n,m> on page: http://www.boost.org/libs/mpl/doc/refmanual/range-c.html requires a specialization of integral_rank<T> to compile. Otherwise, I'm getting error: intel-linux.compile.c++ ../../../../bin.v2/lje/libs/indexed_types/test/range_c_enum_test.test/intel-linux/debug/range_c_enum_test.o /home/evansl/prog_dev/boost-release/boost_1_32_0/boost/mpl/aux_/largest_int.hpp(48): error: incomplete type is not allowed ( integral_rank<T1>::value >= integral_rank<T2>::value ) ^ However, this requirement is not mentioned on the range-c.html page. Shouldn't it be?

1 1

C++ standards committee meetings
by Beman Dawes 30 Jan '05

30 Jan '05

The schedule for C++ standards committee meetings can be found at http://www.open-std.org/jtc1/sc22/wg21/docs/meetings The next two meetings are scheduled for: April 11-15, 2005, in Lillehammer, Norway October 3-7, 2005, in Mont Tremblant, Canada Information about the Lillehammer meeting is available at http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1707.htm There is a FAQ for Boost members who might want to attend a committee meeting. See http://www.boost.org/more/cpp_committee_meetings.html --Beman

1 0

boost:::iterator (1_32_0) and sunpro
by Tim Van Epps 30 Jan '05

30 Jan '05

I'm trying to use boost::tokenizer with the sunpro compiler and encountering an error in the boost interator. Sunpro compiler: CC: Sun C++ 5.5 Patch 113817-10 2004/10/05 boost 1_32_0 program that demonstrates the error: #include <boost/tokenizer.hpp> using namespace boost; int main(int argc, char ** argv) { std::string ret; char_separator<char> sep("\r\n"); tokenizer<char_separator<char> > tok(ret, sep); for(tokenizer<char_separator<char> >::iterator i =tok.begin(); i != tok.end(); ++i) {} } the output from CC -I$D/src/vendor/incl -o bug bug.C: "/usr/local/dailyLibraryBuild/src/vendor/incl/boost/iterator/iterator_facade.hpp", line 837: Error: Could not find a match for boost::iterator_core_access::equal<boost::iterator_core_access::Facade1, boost::iterator_core_access::Facade2>(const boost::token_iterator<boost::char_separator<char, std::char_traits<char>>, const char*, std::string>, const boost::token_iterator<boost::char_separator<char, std::char_traits<char>>, const char*, std::string>, boost::is_convertible<boost::token_iterator<boost::char_separator<char, std::char_traits<char>>, const char*, std::string>, boost::token_iterator<boost::char_separator<char, std::char_traits<char>>, const char*, std::string>>). 1 Error(s) detected. I've seen variations on this issue discussed on the boost mailing lists, but I'm not sure I've seen a definitive answer. Does anybody have one? -- Tim Van Epps Archelon 312.788.6328

3 2

overloads: request for discussion
by Alexander Nasonov 30 Jan '05

30 Jan '05

An overload set can be represented as a class with _numbered_ call operators: struct has_intersection { bool operator()(id<1>, Circle&, Circle& ) const; bool operator()(id<2>, Circle&, Rectangle&) const; bool operator()(id<3>, Rectangle&, Circle& ) const; bool operator()(id<4>, Rectangle&, Rectangle&) const; }; I wonder how to pass it to different kind of algorithms. Here's my brain dump of the topic: 1. Pass an overload set, MPL sequence of positions and a predicate find_if< has_intersection , range_c<int,1,5> , is_same<first_arg<_>, Circle&> > The find_if algorithm works with mpl sequence of positions, that is, it takes positions and return an iterator to first found position. Unlike mpl::find_if, the predicate takes a signature, not a position. I used it till recently. But it's not quite an OverloadSet concept. 2. MPL-like sequence would be nice to have. Something similar to: mpl::vector< bool(Circle&, Circle& ) , bool(Circle&, Rectangle&) , bool(Rectangle&, Circle& ) , bool(Rectangle&, Rectangle&) > or mpl::set< bool(Circle&, Circle& ) , bool(Circle&, Rectangle&) , bool(Rectangle&, Circle& ) , bool(Rectangle&, Rectangle&) > Unfortunately, if typeof is not available, deref and some other operations work only in deduced context (that is, inside special function). Presumably that sequence should store pairs of id and a signature in deduced context or id and unknown otherwise: pair<id<1>, bool(Circle&,Circle&) > // deduced context pair<id<1>, unknown> // non-deduced context (This reminds me of mpl::map but I'm not sure about keys and values: id -> signature or signature -> id?) Algorithms that accept boolean predicates will be using deduced context (this can be extended to predicates that return integral constants in limited range). Question about whether to implement other algorithms is open. This approach has an advantage on a long run. When typeof becomes standartized, everything can be switched to the first case. To summarize, I see it being as close to MPL sequence (I don't know to which one, though) as possible typedef overload_set<has_intersection, range_c<int,1,5> > seq; but not closer. For example, overload_set is extensible only in a limited way: you can't insert new overload but you can restore an overload removed by previous algorithm or a filter. This means, in particular, that sort should work because it only changes an order of elements. Note that sorting by id or signature is less important then sorting by return or argument type and then applying unique algorithm. At best, sorting of huge overload set can be avoided. MPL has a trick for this: mpl::copy<from, inserter<set<>, insert<_1,_2> > > Something similar can be done for overload_set. Otherwise, new algorithm should be introduced because of its high importance. It has to be very fast at compile-time to deal efficiently with huge overload sets. (This algorithm exists already under name "unique"). 3. Fusion-like interface. Overload sets are not pure compile-time entities as shown in this example: tuple< bool (has_intersection::*)(id<1>, Circle&, Circle& ) const, bool (has_intersection::*)(id<2>, Circle&, Rectangle&) const, bool (has_intersection::*)(id<3>, Rectangle&, Circle& ) const, bool (has_intersection::*)(id<4>, Rectangle&, Rectangle&) const > t( &has_intersection::operator(), &has_intersection::operator(), &has_intersection::operator(), &has_intersection::operator() ); Something like that would be great addition for overloads library. The library is available at cpp-experiment.sf.net (please, use CVS). -- Alexander Nasonov

2 12

Iterator lib tests broken
by John Maddock 30 Jan '05

30 Jan '05

Guys, The Jamfile for the iterator tests is currently rather badly broken: don't know how to make <@boost!libs!iterator!test>../../utility/iterator_traits_test.cpp don't know how to make <@boost!libs!iterator!test>../../utility/transform_iterator_example.cpp don't know how to make <@boost!libs!iterator!test>../../utility/reverse_iterator_example.cpp don't know how to make <@boost!libs!iterator!test>../../utility/projection_iterator_example.cpp don't know how to make <@boost!libs!iterator!test>../../utility/indirect_iterator_example.cpp don't know how to make <@boost!libs!iterator!test>../../utility/fun_out_iter_example.cpp don't know how to make <@boost!libs!iterator!test>../../utility/filter_iterator_example.cpp don't know how to make <@boost!libs!iterator!test>../../utility/counting_iterator_example.cpp don't know how to make <@boost!libs!iterator!test>../../utility/iterator_adaptor_examples.cpp and so on. Any chance of a fix? Thanks! John.

3 4

Type traits change alert
by John Maddock 30 Jan '05

30 Jan '05

Hi folks, Its that time of year again when type traits gets a bit of maintenance, and as some of you will know, almost any change is guaranteed to break something, so here are the changes just in case: 1) The existing traits classes have been modified to inherit from boost::integral_constant, as per TR1. I've done everything I can to retain MPL compatibility, and tested every way I can think of, but you never know something may go wrong somewhere... I've also had to defer this change for VC6 in one case (couldn't get variant to compile unless alignment_of inherited from mpl::size_t; even using mpl::integral_c as a base just made VC6 ICE all the time). 2) The addition of true_type/false_type meant a minor change to boost/pending/ct_if.hpp. 3) New traits classes added: aligned_storage, extent, has_virtual_destructor, is_member_object_pointer, is_signed, is_unsigned, rank, remove_all_extents, all as per the TR. There is just about an outside chance that old and broken compilers will be unable to parse one of these when including boost/type_traits.hpp, but it's pretty unlikely. 4) Renamed: remove_bounds -> remove_extent is_base_and_derived -> is_base_of is_float -> is_floating_point To bring those names into line with the TR, the old names all remain as well for backwards compatibility. 5) Docs: these really need rewriting (Boostbook?), will do when I get a chance. Regards, John Maddock.

1 0