- Boost-users - lists.boost.org

[bind] static array vs. pointer vector
by Christian Henning 26 Mar '07

26 Mar '07

Hi there, I have posted this question last Friday, already. But maybe my example was too confusing. Here is a more simple example. Basically, I don't see what the big difference is when using boost::bind with a pointer vector ( std::vector<info*> ) and a static array of info. Please consider the following code: #include <string> #include <algorithm> #include <functional> #include <vector> #include <boost/bind.hpp> using namespace std; using namespace boost; struct info { int a; string s; }; static info table[] = { { 16, "Hello" }, { 18, "Moin" } }; string& get_s( info* p ) { return p->s; } int _tmain(int argc, _TCHAR* argv[]) { { vector<info*> v; find_if( v.begin(), v.end() , bind( equal_to<string>() , bind( &get_s, _1 ) , "Moin" )); } { find_if( &table[0], &table[0] + 2 , bind( equal_to<string>() , bind( &get_s, _1 ) , "Moin" )); } } The second find_if wont complie using MSVC 7.1. The errors are: c:\boost\boost\bind.hpp(219) : error C2664: 'std::string &(info *)' : cannot convert parameter 1 from 'info' to 'info *' No user-defined-conversion operator available that can perform this conversion, or the operator cannot be called c:\boost\boost\bind\bind_template.hpp(139) : see reference to function template instantiation 'R boost::_bi::list1<A1>::operator ()<boost::_bi::bind_t<R,F,L>::result_type,std::string&(__cdecl *)(info *),A>(boost::_bi::type<T>,F & ,A &,long)' being compiled with [ R=boost::_bi::bind_t<std::string &,std::string &(__cdecl *)(info *),boost::_bi::list1<boost::_bi::list_av_1<boost::arg<1>>::B1>>::result_type, A1=boost::_bi::list_av_1<boost::arg<1>>::B1, F=std::string &(__cdecl *)(info *), L=boost::_bi::list1<boost::_bi::list_av_1<boost::arg<1>>::B1>, A=const boost::_bi::list1<info &>, T=boost::_bi::bind_t<std::string &,std::string &(__cdecl *)(info *),boost::_bi::list1<boost::_bi::list_av_1<boost::arg<1>>::B1>>::result_type ] c:\boost\boost\bind.hpp(213) : see reference to function template instantiation 'boost::_bi::bind_t<R,F,L>::result_type boost::_bi::bind_t<R,F,L>::eval<const boost::_bi::list1<A1>>(A &)' being compiled with [ R=std::string &, F=std::string &(__cdecl *)(info *), L=boost::_bi::list1<boost::_bi::list_av_1<boost::arg<1>>::B1>, A1=info &, A=const boost::_bi::list1<info &> ] [snip] Any ideas? Christian

2 2

[fusion] Stateful unary functor for for_each loop
by Christian Henning 26 Mar '07

26 Mar '07

Hi there, is it possible to have a stateful functor object when using fusion::for_each() loop. I would like to to the following: #include <vector> #include <boost/mpl/assert.hpp> #include <boost/mpl/equal.hpp> #include <boost/mpl/list.hpp> #include <boost/mpl/transform.hpp> #include <boost/fusion/algorithm/transformation/transform.hpp> #include <boost/fusion/algorithm/iteration/for_each.hpp> #include <boost/fusion/sequence/adapted/mpl.hpp> #include <boost/fusion/sequence/container.hpp> #include <boost/fusion/sequence/conversion/as_list.hpp> using namespace std; using namespace boost; struct A { void print() { cout << "A" << endl; }}; struct B { void print() { cout << "B" << endl; }}; struct C { void print() { cout << "C" << endl; }}; std::vector<A> find_all( A ) { return std::vector<A>(12); } std::vector<B> find_all( B ) { return std::vector<B>(12); } std::vector<C> find_all( C ) { return std::vector<C>(12); } typedef mpl::list< A, B, C > _types_; template <typename T> struct add_vector { typedef std::vector<T> type; }; struct find_all_ { template< class T > void operator()( T& t ) const { typedef typename T::value_type type; type v; t = find_all( v ); } }; struct check_size { check_size() : _init( false ), _size( 0 ) {} template< class T > void operator()( T& t ) { if( !_init ) { _size = t.size(); _init = true; return; } if( _size != t.size() ) { throw runtime_error( "vectors don't match up." ); } } private: bool _init; size_t _size; }; struct print { template< class T > void operator()( T& vec ) const { vec[0].print(); } }; int main() { typedef mpl::transform1< _types_, add_vector<mpl::_1> >::type _mpl_list_of_vectors_; typedef fusion::result_of::as_list<_mpl_list_of_vectors_>::type _fusion_list_of_vectors_; _fusion_list_of_vectors_ vectors; fusion::for_each( vectors, find_all_() ); fusion::for_each( vectors, check_size() ); return 0; } Unfortunately it wont compile. The error messages are: c:\boost\boost\fusion\algorithm\iteration\detail\for_each.hpp(28) : error C3848: expression having type 'const check_size' would lose some const-volatile qualifiers in order to call 'void check_size::operator ()<T>(T &)' with [ T=boost::fusion::extension::deref_impl<boost::fusion::cons_iterator_tag>::apply<boost::fusion::cons_iterator<_fusion_list_of_vectors_>>::value_type ] c:\boost\boost\fusion\algorithm\iteration\for_each.hpp(37) : see reference to function template instantiation 'void boost::fusion::detail::for_each<boost::fusion::extension::begin_impl<boost::fusion::cons_tag>::apply<Sequence>::type,boost::fusion::extension::end_impl<boost::fusion::cons_tag>::apply<Sequence>::type,F>(const First &,const Last &,const F &,boost::mpl::false_)' being compiled with [ Sequence=_fusion_list_of_vectors_, F=check_size, First=boost::fusion::extension::begin_impl<boost::fusion::cons_tag>::apply<_fusion_list_of_vectors_>::type, Last=boost::fusion::extension::end_impl<boost::fusion::cons_tag>::apply<_fusion_list_of_vectors_>::type ] test.cpp(100) : see reference to function template instantiation 'void boost::fusion::for_each<_fusion_list_of_vectors_,check_size>(Sequence &,const F &)' being compiled with [ Sequence=_fusion_list_of_vectors_, F=check_size ] Any ideas? Christian

5 13

Re: [Boost-users] [Serialization] issue withportable_binary_oarchive
by Pfligersdorffer, Christian 26 Mar '07

26 Mar '07

Dear Robert, > -----Original Message----- > From: boost-users-bounces(a)lists.boost.org > [mailto:boost-users-bounces@lists.boost.org]On Behalf Of Robert Ramey > Sent: Friday, March 16, 2007 9:49 PM > To: boost-users(a)lists.boost.org > Subject: Re: [Boost-users] [Serialization] issue > withportable_binary_oarchive > > > Pfligersdorffer, Christian wrote: > > > I read this thread with very much interest since I want to use the > > portable binary archive too. Could you please share your experience > > and especially the code of the version that actually works? > > I've made some a few changes. I'll check them in to the HEAD before > tomorrow. I will have a look at that. > a) I made a small change to binary_?archvive which was losing > a "const" along the line and frustrating a template match > > b) I made a change in portable_binary_?archive to fix an > error whereby the sign bit was changed on certain > negative numbers. > > > Did you also add code to treat floating point types? > > Nope - that's an excercise for the user. > Notes on the current implementation: > > a) It presumes a two's complement computer so its not > "truely" portable. OK, I would not use it on some very fancy cpus then. ppc and x86 should probably work and that's what counts with me. > b) It doesn't include floating point. I think this would be more > effort than first meets the eye. At least one attractive proposal on > how to effectively do this was suggested. > c) Its not all that efficient on big endien machines. I think > a better version would write the data out in native mode > with flags in the header indicating how it was written. Then > the endian fix up would occur when it was moved from > one machine to another. I would like to switch to big endian representation to ensure maximum speed on the embedded system. This should easily be possible by changing the #ifdef BOOST_LITTLE_ENDIAN sections into #ifndef, or? ... > d) It focuses more on reducing archive size. So some > a 64 bit value of 0 is written as one byte. This is probably > a good choice for most. But it costs time in sign extending > etc. > > Robert Ramey By the way: did you solve the destruction issue when deleting an archive through the polymorphic interface? I sent you an email about that (a couple of months ago) and you answered you'd have a look at it. Regards, -- DI Christian Pfligersdorffer Software Engineering EOS GmbH

2 1

[Serialization]: Persistent references between archives
by Stefan Holzmann 26 Mar '07

26 Mar '07

Hello, For my application I need to serialize my data distributed into muliple archives and I need a persistent references on objects inside a different archiv. There is one main archiv which has references on other archives. I was thinking on the following solution (Perhaps there is an easier way). I think I have to store and load my objects into several steps. Save: 1. Assign each archiv a unique id. (Build up a archiv map) 2. Assign each object which needs to be referenced a unique id inside the archiv and build up a object map. 3. Serialize the archiv map (e.g. Archiv ID <-> Archiv Filename). 4. Serialize the content of all objects to the archives. If a reference on a objects needs to be stored the id of this object is serialized to the archiv. The 32bit object ID consists of a archiv ID as high word and the ID of the object within the archiv as low word. Load: 1. Load and create all the objects from the archives. 2. Assign again the object IDs to each object which can be referenced and build up a map (object <-> ID). 3. Resolve the references by looking up the the object address for the stored object id. I think step 2 could be skipped if the object IDs are stored also. Whats your opinion on this? Could this work? Any suggestion for implementation? To assign the object ID's I have to traverse the complete object structure in similar manner than during the serialize process. Is there a way to use the same mechanism but don't write any data to the archives. Regards, Stefan -- "Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: www.gmx.net/de/go/mailfooter/topmail-out

1 0

Segmentation fault in boost::iterator_property_map when using bfs visitor
by Stephen Torri 26 Mar '07

26 Mar '07

I am receiving a segmentation fault in boost::iterator_property_map for the following code. // Prepare Data infrastructure::Graph_Base::Data_Map_t m_data_map; // Process Graph visitor::Graph_Visitor graph_visitor_ref ( *graph_ptr, &m_data_map ); // Segmentation fault starts here boost::breadth_first_search ( graph_ptr->get_Graph(), // Grabs the adjacency list reference graph_ptr->get_Vertex ( 1 ), // Grabs the first vertex descriptor boost::visitor ( graph_visitor_ref ) ); // Call visitor (line 218) Here is the backtrace: #0 0x00d343ff in boost::iterator_property_map<__gnu_cxx::__normal_iterator<boost::default_color_type*, std::vector<boost::default_color_type, std::allocator<boost::default_color_type> > >, boost::adj_list_vertex_property_map<boost::adjacency_list<boost::setS, boost::setS, boost::directedS, boost::property<boost::vertex_index_t, unsigned int, boost::property<boost::vertex_name_t, boost::shared_ptr<libreverse::infrastructure::Component>, boost::no_property> >, boost::no_property, boost::no_property, boost::listS>, unsigned int, unsigned int const&, boost::vertex_index_t>, boost::default_color_type, boost::default_color_type&>::operator[] (this=0xbff21818, v=0x4) at /usr/include/boost/property_map.hpp:349 #1 0x00d3445a in boost::put<boost::iterator_property_map<__gnu_cxx::__normal_iterator<boost::default_color_type*, std::vector<boost::default_color_type, std::allocator<boost::default_color_type> > >, boost::adj_list_vertex_property_map<boost::adjacency_list<boost::setS, boost::setS, boost::directedS, boost::property<boost::vertex_index_t, unsigned int, boost::property<boost::vertex_name_t, boost::shared_ptr<libreverse::infrastructure::Component>, boost::no_property> >, boost::no_property, boost::no_property, boost::listS>, unsigned int, unsigned int const&, boost::vertex_index_t>, boost::default_color_type, boost::default_color_type&>, boost::default_color_type&, void*, boost::default_color_type> (pa=@0xbff21818, k=0x4, v=@0xbff217ec) at /usr/include/boost/property_map.hpp:319 #2 0x00d3b4d0 in boost::breadth_first_search<boost::adjacency_list<boost::setS, boost::setS, boost::directedS, boost::property<boost::vertex_index_t, unsigned int, boost::property<boost::vertex_name_t, boost::shared_ptr<libreverse::infrastructure::Component>, boost::no_property> >, boost::no_property, boost::no_property, boost::listS>, boost::queue<void*, std::deque<void*, std::allocator<void*> > >, libreverse::visitor::Graph_Visitor, boost::iterator_property_map<__gnu_cxx::__normal_iterator<boost::default_color_type*, std::vector<boost::default_color_type, std::allocator<boost::default_color_type> > >, boost::adj_list_vertex_property_map<boost::adjacency_list<boost::setS, boost::setS, boost::directedS, boost::property<boost::vertex_index_t, unsigned int, boost::property<boost::vertex_name_t, boost::shared_ptr<libreverse::infrastructure::Component>, boost::no_property> >, boost::no_property, boost::no_property, boost::listS>, unsigned int, unsigned int const&, boost::vertex_index_t>, boost::default_color_type, boost::default_color_type&> > (g=@0x81e70c8, s=0x81e6c10, Q=@0xbff21830, vis= {<boost::bfs_visitor<boost::null_visitor>> = {m_vis = {<> = {<No data fields>}, <No data fields>}}, m_graph_ref = @0x81e70c8, m_data_map = 0xbff21970}, color= {<boost::put_get_helper<boost::default_color_type&,boost::iterator_property_map<__gnu_cxx::__normal_iterator<boost::default_color_type*, std::vector<boost::default_color_type, std::allocator<boost::default_color_type> > >, boost::adj_list_vertex_property_map<boost::adjacency_list<boost::setS, boost::setS, boost::directedS, boost::property<boost::vertex_index_t, unsigned int, boost::property<boost::vertex_name_t, boost::shared_ptr<libreverse::infrastructure::Component>, boost::no_property> >, boost::no_property, boost::no_property, boost::listS>, unsigned int, const unsigned int&, boost::vertex_index_t>, boost::default_color_type, boost::default_color_type&> >> = {<No data fields>}, iter = {_M_current = 0x81ec4b0}, index = {<boost::put_get_helper<const unsigned int&,boost::adj_list_vertex_property_map<boost::adjacency_list<boost::setS, boost::setS, boost::directedS, boost::property<boost::vertex_index_t, unsigned int, boost::property<boost::vertex_name_t, boost::shared_ptr<libreverse::infrastructure::Component>, boost::no_property> >, boost::no_property, boost::no_property, boost::listS>, unsigned int, const unsigned int&, boost::vertex_index_t> >> = {<No data fields>}, <No data fields>}}) at /usr/include/boost/graph/breadth_first_search.hpp:97 #3 0x00d3b5f0 in boost::detail::bfs_helper<boost::adjacency_list<boost::setS, boost::setS, boost::directedS, boost::property<boost::vertex_index_t, unsigned int, boost::property<boost::vertex_name_t, boost::shared_ptr<libreverse::infrastructure::Component>, boost::no_property> >, boost::no_property, boost::no_property, boost::listS>, boost::iterator_property_map<__gnu_cxx::__normal_iterator<boost::default_color_type*, std::vector<boost::default_color_type, std::allocator<boost::default_color_ty---Type <return> to continue, or q <return> to quit--- pe> > >, boost::adj_list_vertex_property_map<boost::adjacency_list<boost::setS, boost::setS, boost::directedS, boost::property<boost::vertex_index_t, unsigned int, boost::property<boost::vertex_name_t, boost::shared_ptr<libreverse::infrastructure::Component>, boost::no_property> >, boost::no_property, boost::no_property, boost::listS>, unsigned int, unsigned int const&, boost::vertex_index_t>, boost::default_color_type, boost::default_color_type&>, libreverse::visitor::Graph_Visitor, libreverse::visitor::Graph_Visitor, boost::graph_visitor_t, boost::no_property> (g=@0x81e70c8, s=0x81e6c10, color= {<boost::put_get_helper<boost::default_color_type&,boost::iterator_property_map<__gnu_cxx::__normal_iterator<boost::default_color_type*, std::vector<boost::default_color_type, std::allocator<boost::default_color_type> > >, boost::adj_list_vertex_property_map<boost::adjacency_list<boost::setS, boost::setS, boost::directedS, boost::property<boost::vertex_index_t, unsigned int, boost::property<boost::vertex_name_t, boost::shared_ptr<libreverse::infrastructure::Component>, boost::no_property> >, boost::no_property, boost::no_property, boost::listS>, unsigned int, const unsigned int&, boost::vertex_index_t>, boost::default_color_type, boost::default_color_type&> >> = {<No data fields>}, iter = {_M_current = 0x81ec4b0}, index = {<boost::put_get_helper<const unsigned int&,boost::adj_list_vertex_property_map<boost::adjacency_list<boost::setS, boost::setS, boost::directedS, boost::property<boost::vertex_index_t, unsigned int, boost::property<boost::vertex_name_t, boost::shared_ptr<libreverse::infrastructure::Component>, boost::no_property> >, boost::no_property, boost::no_property, boost::listS>, unsigned int, const unsigned int&, boost::vertex_index_t> >> = {<No data fields>}, <No data fields>}}, vis= {<boost::bfs_visitor<boost::null_visitor>> = {m_vis = {<> = {<No data fields>}, <No data fields>}}, m_graph_ref = @0x81e70c8, m_data_map = 0xbff21970}, params=@0xbff219ac) at /usr/include/boost/graph/breadth_first_search.hpp:185 #4 0x00d3b7c0 in boost::detail::bfs_dispatch<boost::detail::error_property_not_found>::apply<boost::adjacency_list<boost::setS, boost::setS, boost::directedS, boost::property<boost::vertex_index_t, unsigned int, boost::property<boost::vertex_name_t, boost::shared_ptr<libreverse::infrastructure::Component>, boost::no_property> >, boost::no_property, boost::no_property, boost::listS>, libreverse::visitor::Graph_Visitor, boost::graph_visitor_t, boost::no_property> (g=@0x81e70c8, s=0x81e6c10, params=@0xbff219ac) at /usr/include/boost/graph/breadth_first_search.hpp:226 #5 0x00d3b84a in boost::breadth_first_search<boost::adjacency_list<boost::setS, boost::setS, boost::directedS, boost::property<boost::vertex_index_t, unsigned int, boost::property<boost::vertex_name_t, boost::shared_ptr<libreverse::infrastructure::Component>, boost::no_property> >, boost::no_property, boost::no_property, boost::listS>, libreverse::visitor::Graph_Visitor, boost::graph_visitor_t, boost::no_property> (g=@0x81e70c8, s=0x81e6c10, params=@0xbff219ac) at /usr/include/boost/graph/breadth_first_search.hpp:255 #6 0x00d2fa8c in libreverse::api::Reverse_Impl::process_Graph (this=0xbff21aeb, graph_ptr=@0xbff21a30, val=@0xbff21a28) at Reverse_Impl.cpp:218 I checked the graph_ptr and it appears to be initialized correctly. At frame #0, the value of 'v' is 0x4. Is there a way to print out more information to figure out why I am getting a segfault? Am I asking my questions in the right place? I say that because I have posted quite a few messages recently with no one responding. Stephen

1 0

[smart_ptr | ptr_container] Customize deletions
by Ray Hilton 26 Mar '07

26 Mar '07

Is there anyway to get the destructors to use free or ptr->release() instead of delete ptr? Looking at the docs they don't seemed to take a deleter functor Thanks in advance! Ray Hilton _________________________________________________________________ Mortgage refinance is hot 1) Rates near 30-yr lows 2) Good credit get intro-rate 4.625%* https://www2.nextag.com/goto.jsp?product=100000035&url=%2fst.jsp&tm=y&searc…

2 2

[review] intrusive container comments
by Thorsten Ottosen 26 Mar '07

26 Mar '07

Hi Ion, Here are some comments I have from reading the online documentation. I haven't followed the review discussion (because I don't have the time), so I apologize if my comments have already been discussed. I was originally review manager for Olaf, and was almost ready to allow a review when he said he did not have time to finnish the library. From what I recall, the docs have been improved somewhat, so kudos for that work. 1. "Constant time size: The intrusive container holds a size member that it's updated with every insertion/erasure. This implies that the size() function has constant time complexity. On the other hand, increases the size of the container, and some operations, like splice() taking a range of iterators, have linear time complexity in linked lists." Howward Hinnant proposed a new splice() function that allows one to pass the size into splice() to keep splice() O(1). Would this not be an idea here? 2. My general view of the design: fairly complicated, though the extra speed can be worth the effort. I find the amount of typedef'ing fairly large and can't help feeling it could be simplified. 3. Is 'Foo' really needed twice: typedef boost::intrusive::ilist_base_hook<Foo>::value_traits<Foo> FooValueTraits; ??? 4. The cloning example (http://ice.prohosting.com/newfunk/boost/libs/intrusive/doc/html/intrusive/c…) I don't quite get; I thought the whole point of intrusive container was to avoid memory allotions. Also, how does this affect exception-safety? In general I feel this is an important library with many uses for performance savy applications. I feel the quality in general is high. I had one major discussion with Olaf which relates to the general easy-of-use and also to space-tradeoffs: ---------------------------------------- When it is a design-time decision to allow the object to be inserted into 1 container, one object always carry the node-structure overhead (that is also when I don't insert the object into an intrusive container). Furthermore, If some objects must be in more than one container, all objects of that type pay the space penalty even though only a few objects are in several containers. Third, the compile-time dependency is fairly complicated, and would be cool to get rid of. Therefore I think there are compelling reasons for exploring a different design: an extrusive design where the node-structure is not part of the object. This immediately eliminates three problems: -1- there is no compile-time dependency -2- there is by default no any space overhead -3- there is by default no problem or contstraint when an object is added to more containers at runtime The approach has one serious drawback: -1- it might require extra memory This happens when all live objects are added to an intrusive container. An example: consider an ilist of size N. The node structure requires two T* objects and so the space required is N * 2 * sizeof(T*) An extrusive approach would look a bit like this: template< class T > class extrusive_list { struct Node { T* prev; T* next; T* me; }; std::vector<Node> nodes; }; Thus the space required would be N * 3 * sizeof(T*) if all N objects are put into the container. If less than 2/3's of the live objects are put into the container, the extrusive version takes up less space. As you add support for several containers, the extrusive version is even more likely to save space IMO. Now, I haven't actually implemented extrusive containers as out-lined above, but the simplity of use and the potential space savings tells me that it would be well worth persue. Let me know what you all think. best regards Thortsen

3 7

help with cgal..
by suganya baskaran 26 Mar '07

26 Mar '07

hi everyone, i am trying to compile cgal library which has a pre-requisite "BOOST'.. i believe Boost is almost done. While compiling cgal using MS .net 8.0, i get errors, "/boost/static_assert.hpp" and "/boost/mlp/if.hpp" are not found. These files are in their proper location and I cant figure out what went wrong.. Help please --------------------------------- Bored stiff? Loosen up... Download and play hundreds of games for free on Yahoo! Games.

2 1

Re: [Boost-users] Question about ifstream ranges
by Pfligersdorffer, Christian 26 Mar '07

26 Mar '07

> How about an iostreams restriction? > http://boost.org/libs/iostreams/doc/functions/restrict.html > I'm using it to pull data out of a zip file and zlib_decompressor to > decompress it. :-) > Also, > http://www.teslacore.it/wiki/index.php?title=BoostPicks#Restriction > has some sample code. > Hope this helps! > Phillip Dear Phillip, this is exactly was I was looking for! Thank you very much!! -- DI Christian Pfligersdorffer Software Engineering EOS GmbH

1 0

[Regex] Debug Assert Failure boost::cmatch or std::copy
by News Group 25 Mar '07

25 Mar '07

All, I am trying to copy from a boost::cmatch variable to a std::set. It compiles fine but when I run it I get a: Debug Assertion Failure xtree 245 map/set iterator not dereferencable I think it's the "match.begin()" and "match.end()" in std::copy that is failing. This is a short version of what I have: #include <boost/regex.hpp> #include <algorithm> #include <string> #include <set> bool Parse( const std::string &page, std::set< std::string > &links ) { const boost::regex expression( "123" ); boost::cmatch match; if( boost::regex_search( page.c_str(), match, expression ) ) { std::copy( match.begin(), match.end(), links.begin() ); return true; } return false; } int main() { std::string test_data = "www.abc123.com/index.php"; std::set< std::string > links; Parse( test_data, links ); return EXIT_SUCCESS; } Thanks in advance. Carl.

3 2