- Boost - lists.boost.org

[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

boost.filesystem - rationale for copy_file
by larsbj＠gullik.net 30 Jan '05

30 Jan '05

What is the rationale for having copy_file fail if the target file exists? This is not how any cp/copy in any shell I know of works, actually quite surprising. And with boost.filesystem there is no way to avoid this, short of rewriting the function to allow it. The other way around would have been easy: fs::exists(target) || fs::copy_file(source, target) (One option is to delete the target before doing the copy, but then it is impossible to keep the same inode as before, and f.x. for backup files this is something that you want.) -- Lgb

8 17

Re: [boost] [iostreams] [regression] iostreams added to CVS
by JOAQUIN LOPEZ MU?Z 30 Jan '05

30 Jan '05

Hi, I think the note on the first page of the docs is no longer needed: Boost.Iostreams is now part of Boost. Also, don't forget to add an entry in libs/libraries.htm and in /index.htm (under the "Version 1.33.0" paragraph). Joaquín M López Muñoz Telefónica, Investigación y Desarrollo ----- Mensaje original ----- De: Jonathan Turkanis <technews(a)kangaroologic.com> Fecha: Domingo, Enero 30, 2005 0:29 am Asunto: [boost] [iostreams] [regression] iostreams added to CVS > Dear all, > > The iostreams library has been added to CVS. > > I've also added a line to boost-root/status/Jamfile. Is this > enough to have the > library included in the regression tests, or is something more > required? > Jonathan > > > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost

2 1

Composites and Visitors
by Dave Handley 30 Jan '05

30 Jan '05

Since my last post concerning my implementation of a composite and visitor framework, I have been working on a memory management policy for the composite. The new version of the code is available in the sandbox. I would like to highlight the key changes, along with a few comments from a very useful offline discussion I had with Pavel Vozenilek: 1) A few bugs have been fixed - specifically to do with memory management. I haven't written a full test suite yet (but intend to do so in the near future) so I can't guarantee any degree of robustness in the code as yet. 2) I have put in 3 memory management policies. These enable you to ignore memory management, allow the composite to be responsible for its own memory with conventional pointers, or allow the composite to be responsible for its own memory with boost smart pointers. As yet I have been unable to sort out deep copying of the tree with the smart pointer policy. One option on this may be to implement shallow copies of the tree in the copy constuctor and equals operator, and implement a separate deep_copy function. What are the general views on this? Are there any tricks with boost shared_ptrs that enable you to do deep copies of trees from the constructor? 3) I am intending to put in a policy that will allow you to select the type of container used for internal storage. Thanks to Pavel for this suggestion. 4) I know that this is not strictly a composite in the traditional GoF sense. I actually created this particular version of a composite due to the fact that it is easier to write deep iterators when every node in a composite tree knows that it is part of the tree (unlike the GoF model where only the group nodes actually know about the tree structure). My design goals for this code were: a) Create a tree where individual nodes know about their location in the tree. b) Provide various iterators for this tree. c) Provide tight integration with the visitor pattern. These design goals were specifically designed to try and reduce virtual function bloat that, in my experience, is common with composites. In discussion with Pavel, I have come up with a design that also succeeds in meeting these criteria but ensures that leaf nodes do not carry around an empty list. I am working on this at present, but it is worthy of note that the API will be slightly more complex. The files in the sandbox are now: composite_visitor.zip - contains only the composite and visitor headers and a quick instruction document. composite_visitor_tests_win32.zip - contains the win32 test program. I haven't included the vcproj or sln files, but they should be trivial to create. Dave Handley

1 0

shared_ptr doubts
by Don G 29 Jan '05

29 Jan '05

Not to be contentious, but IMHO it seems that shared_ptr's reach has exceeded its grasp. After looking thoroughly into shared_ptr, I have major doubts about what appear to be design-induced inefficiencies: 1. There is no support for "introducing" shared_ptr to a type T such that shared_ptr would use an intrusively managed count. This is just about required in my book for practicle use of reference counting in large applications. I see intrusive_ptr<>, but this would not help template code that wanted to share ownership of some type T; should it use shared_ptr<T> or intrusive_ptr<T>? Only type T knows. 2. The idea of weak_ptr seems to force external reference counting and a mutex (of some sort) to guard the counter(s). If there is a safe way to use lock-free counting and still get the assurances of weak_ptr::lock, I'm not clever enough to see it. Also, I can see no hope of tuning shared_ptr<T> for intrusive counting and keep weak_ptr. To me, this feature is worth no more than sizeof(ref_count) per object and no hidden locks, at least on platforms that support atomic integer operations. weak_ptr<T> would not be available if shared_ptr<T> was based on intrusion, again unless someone more clever than I could find a way to do so that wouldn't burden code that doesn't use weak_ptr. 3. The deleter feature also adds virtual function bloat as well as more per-object overhead. To me, this kind of overhead would preclude use of shared_ptr in all by the most trivial applications. The problem again is that this is not something that can be avoided by shunning the use of some features. For example, if the deleter where part of a shared_ptr<void> specialization or something. While I like the aesthetics of these features, I can see little practicle need for them given their cost. In other words, I would trade both of them for the knoweldge that I could "use the shared_ptr, Luke" without concern for such bloat. Herb Sutter advocated this position in a recent C++ User Journal article, which is what sparked my curiousity in the first place. Again, perhaps I've missed something profound and fundamental in the specification of shared_ptr that would allow for these features and a highly effecient implementation of basic reference counting. As I see it, I will have to keep my own counted_ptr which does "just the counting, ma'am." My $2e-02, Don ===== __________________________________ Do you Yahoo!? Yahoo! Mail - You care about security. So do we. http://promotions.yahoo.com/new_mail

2 1

mpl::set problem
by Alexander Nasonov 29 Jan '05

29 Jan '05

I can't understand why derefencing begin of set<int,char> gives set2<int,char>, not char or int as one would expect. typedef set<int,char> s; typedef deref<begin<s>::type>::type e; BOOST_MPL_ASSERT(( or_<is_same<e,int>, is_same<e,char> > )); If I change s definition to typedef insert<set<int>,char>::type s; it compiles fine on gcc 3.4 and intel-linux 8.0. -- Alexander Nasonov

1 0

StringAlgo::split issue
by Dirk Gregorius 29 Jan '05

29 Jan '05

Hi, I used the split function on the following string: vector<string> tokens; string str= "( 448 448 64 ) ( 448 0 64 ) ( 0 448 64 ) name 0 0 0 0.5 0.5 0 0 0"; split( tokens, str, is_any_of( ()), token_compress_on ); // I pass 'space' , '(' and ')' into is_any_of() I was supposed to get 18 tokens. The first nine values, the string "name" and the remaining eight digits. "split" always returns a string vector containing 19 tokens, where the first element of the vector is an empty string. Why does the function insert empty strings into the collection? Can I use split to obtain the 18 wanted tokens? -Dirk

3 4

Boost Test - when you've got nothing else to do
by Robert Ramey 29 Jan '05

29 Jan '05

I find Boost Test very valuable and use on a regular basis. I think that it would be even more useful if it had the following additional features: a) automatic heap checking for memory leaks for libraries that can support it. b) the ability to create a temporary fstream with a unique name in a safe way. c) The ability to specify an execution time limit so that if the program goes off into space it doesn't waste an in ordinate amount of time. (perhaps this would be easier to include in bjam) d) The abtility to specify a maximum amount of memory to be allocated. When this allocation is passed, the program would terminate. e) Currently, all tests compiled with borland compilers fail immediatly when the program and library are built in release mode. I would like to see this fixed. I did spend a little time trying to track this down but was unsuccessful. f) A more tutorial type manual. Robert Ramey

4 7