January 2005 - Boost - lists.preview.boost.org

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

[range] patch to fix begin() and end()
by Eric Niebler 30 Jan '05

30 Jan '05

The following trivial use of Boost.Range fails to compile: #include <boost/range/begin.hpp> template<class Rng> void foo(Rng const& rng) { boost::begin(rng); } int main() { char* sz = "hello"; foo( sz ); } With g++, I get: $ g++ -I$BOOST_ROOT test.cpp /cygdrive/c/boost/cvs/boost/boost/range/begin.hpp: In function `typename boost::range_const_iterator<C>::type boost::range_detail::begin(const C&) [with C = char*]': /cygdrive/c/boost/cvs/boost/boost/range/begin.hpp:162: instantiated from `typename boost ::range_const_iterator<C>::type boost::begin(const T&) [with T = char*]' test.cpp:6: instantiated from `void foo(const Rng&) [with Rng = char*]' test.cpp:12: instantiated from here /cygdrive/c/boost/cvs/boost/boost/range/begin.hpp:40: error: request for member `begin' in `c', which is of non-aggregate type `char* const' The attached patch fixes the problem for both boost::begin() and boost::end(). I have verified that the range tests pass with this change. -- Eric Niebler Boost Consulting www.boost-consulting.com Index: begin.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/range/begin.hpp,v retrieving revision 1.11 diff -b -d -u -r1.11 begin.hpp --- begin.hpp 5 Jan 2005 18:19:30 -0000 1.11 +++ begin.hpp 29 Jan 2005 00:07:13 -0000 @@ -111,20 +111,40 @@ return s; } + inline const char* begin( const char*const& s ) + { + return s; + } + inline char* begin( char*& s ) { return s; } + inline char* begin( char*const& s ) + { + return s; + } + inline const wchar_t* begin( const wchar_t*& s ) { return s; } + inline const wchar_t* begin( const wchar_t*const& s ) + { + return s; + } + inline wchar_t* begin( wchar_t*& s ) { return s; } + + inline wchar_t* begin( wchar_t*const& s ) + { + return s; + } #endif } // namespace 'range_detail' Index: end.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/range/end.hpp,v retrieving revision 1.14 diff -b -d -u -r1.14 end.hpp --- end.hpp 5 Jan 2005 18:19:31 -0000 1.14 +++ end.hpp 29 Jan 2005 00:07:13 -0000 @@ -111,20 +111,40 @@ return range_detail::str_end( s ); } + inline char* end( char*const& s ) + { + return range_detail::str_end( s ); + } + inline wchar_t* end( wchar_t*& s ) { return range_detail::str_end( s ); } + inline wchar_t* end( wchar_t*const& s ) + { + return range_detail::str_end( s ); + } + inline const char* end( const char*& s ) { return range_detail::str_end( s ); } + inline const char* end( const char*const& s ) + { + return range_detail::str_end( s ); + } + inline const wchar_t* end( const wchar_t*& s ) { return range_detail::str_end( s ); } + + inline const wchar_t* end( const wchar_t*const& s ) + { + return range_detail::str_end( s ); + } #endif } // namespace 'range_detail'

2 3

Re: [boost] Help needed with BGL & multi_index_container
by JOAQUIN LOPEZ MU?Z 30 Jan '05

30 Jan '05

Hi Alexander, ----- Mensaje original ----- De: Me here <rhjrjlbk2002(a)yahoo.com> Fecha: Viernes, Enero 28, 2005 5:21 pm Asunto: [boost] Help needed with BGL & multi_index_container > Hi there, > > I need an advanced container which allows me to access > my data over number of different indices. That is > exactly what for boost::multi_index_container was > made. But, my data items also have relationships with > other data in the same container, which could be > represented as directed graph. > > So, I have made a custom container, which aggregates > multi_index_container (MIC) to store data items and a > graph (BGL) to store relationships. To allow switching > from MIC to walk over relationships, as an additional > field of my item in MIC I store BGL vertex; as vertex > property in graph I store the key of unique index in > MIC. So, MIC and BGL refer to each other. But, it is > difficult to have those two containers in sync. > > So, I made another attempt to have MIC as customized > vertex storage. I succeed two write the code for it > (see it below). It also compiles and links :-). > Unfortunately, I can not add neither vertices not > edges. If I try to add vertex as in commeted code > below, an error errors that there is no convertion > from vertex property to vertex descriptor (error > message is below). > > What's wrong? Well, I'm no BGL expert, so take this with a grain of salt, but I think adjacency_list does not work the way you're assuming: it is adjacency_list that internally defines its vertex_descriptor type, and uses the container supplied to store them: so, you just cannot select what vertices actually are (like it seems you're trying with ItemHolder.) In fact, the primary API for adding vertices is add_vertex(g); which does not specify the vertex being added (it is created internally by adjacency_list). The syntax add_vertex(p,g); is shorthand for adding a vertex and attaching it a property. I'd say that, in order to blend BGL with multi_index_container, you have three options: 1. Maintain the two structures in sync, like you've done in your first approach. 2. Use multi_index_container as a property map attached to a graph. I don't know if this would work, since I'm not a BGL conoisseur. 3. Create your own data structure modeling mutable graph which internally uses multi_index_container. Besides the multi-index container, you'll need another one for storing edges, if you are to follow the way adjacency_list works. Good luck with your project, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo > > My another question is: how can I get access to my > MIC stored in graph? I would like to use its indices. > > Best wishes, > Alexander > > --------- sample code ----------- > #include <iostream> > > #include <boost/multi_index_container.hpp> > #include <boost/multi_index/ordered_index.hpp> > > #include <boost/graph/adjacency_list.hpp> > > using namespace boost; > using namespace boost::multi_index; > > using namespace std; > > > struct MICSelector {}; > > struct Item > { > Item(int _a=0, int _b=0, int _c=0) > : a(_a), b(_b), c(_c) {} > > int a,b,c; > }; > > struct ItemHolder > { > ItemHolder(int id=0, const Item item=Item()) > : m_ID(id), m_item(item) {} > > int m_ID; > Item m_item; > }; > > struct ItemHolderKey > { > typedef int result_type; > int operator()(const ItemHolder& v) const > { return v.m_ID; } > }; > > template<class ValueType> > struct MICWrapper > { > typedef multi_index_container > < > ValueType, > indexed_by > < > ordered_unique< ItemHolderKey > > > > > type; > }; > > namespace boost > { > // the specialization for your selector > template<class ValueType> > struct container_gen<MICSelector, ValueType> > { > typedef typename MICWrapper<ValueType>::type type; > }; > > template <> > struct parallel_edge_traits<MICSelector> { > typedef allow_parallel_edge_tag type; > }; > }; > > typedef adjacency_list > < listS, MICSelector, > bidirectionalS, ItemHolder > > MG; > > int tmain(int argc, char* argv[]) > { > > MG mg; > > /* > ItemHolder IH( 1, Item(1) ); > > add_vertex( &IH, mg ); > > // add_edge( > // ItemHolder( 1, Item(1) ), > // ItemHolder( 2, Item(2) ), > // mg ); > */ > > cout << typeid( > boost::graph_traits<MG>::vertex_descriptor ).name(); > > return 0; > } > --------- sample code ----------- > > ----------- error message ------------- > Compiling... > MIC_BGL.cpp > c:\test\MIC_BGL.cpp(87) : error C2664: > 'boost::add_vertex' : cannot convert parameter 1 from > 'ItemHolder *__w64 ' to 'const > boost::detail::adj_list_gen<Graph,VertexListS,OutEdgeListS,DirectedS,Ver texProperty,EdgeProperty,GraphProperty,EdgeListS>::config::vertex_proper ty_type > &' > with > [ > > Graph=boost::adjacency_list<boost::listS,MICSelector,boost::bidirectiona lS,ItemHolder>, > VertexListS=MICSelector, > OutEdgeListS=boost::listS, > DirectedS=boost::bidirectionalS, > > VertexProperty=boost::detail::retag_property_list<boost::vertex_bundle_t ,ItemHolder>::type, > > EdgeProperty=boost::detail::retag_property_list<boost::edge_bundle_t,boo st::no_property>::type, > GraphProperty=boost::no_property, > EdgeListS=boost::listS > ] > Reason: cannot convert from 'ItemHolder *__w64 ' to > 'const > boost::detail::adj_list_gen<Graph,VertexListS,OutEdgeListS,DirectedS,Ver texProperty,EdgeProperty,GraphProperty,EdgeListS>::config::vertex_proper ty_type' > with > [ > > Graph=boost::adjacency_list<boost::listS,MICSelector,boost::bidirectiona lS,ItemHolder>, > VertexListS=MICSelector, > OutEdgeListS=boost::listS, > DirectedS=boost::bidirectionalS, > > VertexProperty=boost::detail::retag_property_list<boost::vertex_bundle_t ,ItemHolder>::type, > > EdgeProperty=boost::detail::retag_property_list<boost::edge_bundle_t,boo st::no_property>::type, > GraphProperty=boost::no_property, > EdgeListS=boost::listS > ] > No constructor could take the source type, or > constructor overload resolution was ambiguous > ----------- error message ------------- > > > > > __________________________________ > Do you Yahoo!? > Yahoo! Mail - Find what you need with new enhanced search. > http://info.mail.yahoo.com/mail_250 > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

Platform independent types available in boost?
by Roland Schwarz 30 Jan '05

30 Jan '05

Sorry for my possibly ignorant question, but I couldn't find any pertinent information so far. Is there a recommended way of how to proceed when an application needs to store data in platform independent manner? Is there support in boost? Is anything planned? Thank you for any hints. Roland

4 5