March 2007 - Boost-users - lists.boost.org

[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

Boost.Regex - Match whole word
by skywalker Luke 25 Mar '07

25 Mar '07

Hi All, I'm developing my own grep tool and I would like to specify an option to match a whole word. Which mean, if I'm looking for 'main' I don't want to match 'mainVariation' but things like 'main(int' or 'one,main,two'. The equivalent of what you will find in any decent search tool :). I look through regex documentation and didn't find anything about that. If it's not implemented, is it planned to be ? Or shall the Boost.Regex user handle this applying some pre-processing on the regular expression to perform such task ? Thank you. LS ----------------------------------------------------------- www.EmailAsso.net : solutions email pour les associations, email gratuit sans pub ni virus. www.lavacheautomatique.com : email gratuit @lavache.com, original et universel. www.MonEmail.com : l'email professionnel à 1Giga, avec agenda partagé et gestion des contacts. Votre bureau vous suit partout. 30 jours d'essai gratuit.

5 7

[program_option] using vector and config
by Aljaz 25 Mar '07

25 Mar '07

Hello. I want to parse option that has more values. For instance: options_description desc("Allowed options"); desc.add_options() ("include-path,I", value< vector<string> >(), "include path"); Now I want to parse configuration file which looks like: include-path = first/path include-path = second etc.. Can I have something like this instead: include-path = first/path,second,third,.. Is this possible with program_option or I have to use ugly-way configuration? Thanks for help Regards Aljaz

1 0

[BGL] Reading GraphML
by Jens Müller 25 Mar '07

25 Mar '07

I tried to read a GraphML file using Douglas' code and the following: std::auto_ptr<boost::dynamic_property_map> string2string_gen(const std::string& name, const boost::any&, const boost::any&) { typedef std::map<std::string,std::string> map_t; typedef boost::associative_property_map< std::map<std::string, std::string> > property_t; map_t* mymap = new map_t(); // hint: leaky memory here! property_t property_map(*mymap); std::auto_ptr<boost::dynamic_property_map> pm( new boost::detail::dynamic_property_map_adaptor<property_t>(property_map)); return pm; } int main(int argc, char* argv[]){ // create a typedef for the Graph type using namespace boost; typedef boost::adjacency_list<vecS, vecS, directedS> Graph; Graph g; std::ifstream input(argv[1]); boost::dynamic_properties properties(&string2string_gen); typedef graph_traits<Graph>::vertex_descriptor Node; typedef property_map<Graph, vertex_index_t>::type NodeID_Map; NodeID_Map node_id = get(vertex_index, g); boost::read_graphml(input, g, properties); } but when running it I get: Unrecognized attribute `xmlns' of element `graphml'. Ignoring... Unrecognized attribute `xmlns:y' of element `graphml'. Ignoring... Unrecognized attribute `xmlns:xsi' of element `graphml'. Ignoring... Unrecognized attribute `xsi:schemaLocation' of element `graphml'. Ignoring... Unrecognized attribute `yfiles.type' of element `key'. Ignoring... Unrecognized attribute `yfiles.type' of element `key'. Ignoring... Unrecognized element `y:ShapeNode' Unrecognized element `y:Geometry' Unrecognized element `y:Fill' Unrecognized element `y:BorderStyle' Unrecognized element `y:NodeLabel' Unrecognized element `y:Shape' terminate called after throwing an instance of 'boost::bad_any_cast' what(): boost::bad_any_cast: failed conversion using boost::any_cast /bin/sh: line 1: 31380 Abgebrochen ./src/graphml2 Core0bis10_1000.graphml The file contains nodes like this (what a bloat ...): <node id="n1"> <data key="d0" > <y:ShapeNode > <y:Geometry x="2.457598996954175" y="498.06375265283157" width="10.0" height="10.0"/> <y:Fill color="#FF0000" transparent="false"/> <y:BorderStyle type="line" width="1.0" color="#000000" /> <y:NodeLabel x="3.0" y="3.0" width="4.0" height="4.0" visible="true" alignment="center" fontFamily="Dialog" fontSize="12" fontStyle="plain" textC olor="#000000" hasBackgroundColor="false" hasLineColor="false" modelName="internal" modelPosition="c" autoSizePolicy="content"></y:NodeLabel> <y:Shape type="rectangle"/> </y:ShapeNode> </data> </node> I am not even really interested in the d0 properties ... What can I do?

5 19