- Boost-users - lists.boost.org

write_graphviz: write out edges when vertex data is a boost::shared_ptr?
by Stephen torri 09 Nov '04

09 Nov '04

How does one write out the proper edge node names when the vertex data is a boost::shared_ptr? My graph is defined as: typedef property< vertex_index_t, uint32_t, property< vertex_name_t, boost::shared_ptr<Component> > > VertexProperty; typedef adjacency_list<setS, // OutEdgeList setS, // VertexList directedS, // Directed VertexProperty> // VertexProperties Graph_Type; The call in graphviz.hpp at line 269 has me confused. I understand that the node ids are printed out by looking for the value stored in the vertex_index_t property, graphviz.hpp at line 263. So if the value stored at the vertex_index_t property was the value '3' the node's name would be '3'. The edges are what have me confused. I would expect that the source id and the target it would be the value of the vertex_index_t property. So if there are two nodes the dot file would be: 0[label="A"]; 1[label="B"]; 0 -> 1; Yet with a boost::shared_ptr stored in a vertex_name_t property I get: 0[label="A"]; 1[label="B"]; 0x807a108->0x807a128; Well anything starting with a '0x' is ambigiuos to the dot parser. It breaks the 0x807a108 into two names. I need to use a boost::shared_ptr for my data. I believe I have not used the right boost::property type. Is that right? What I expect to see as output for the dot file is: 0[label="A"]; 1[label="B"]; 0->1; Stephen -- Email: storri(a)torri.org

4 4

PropertyWriter problem - how to handle a boost::shared_ptr type
by Stephen torri 08 Nov '04

08 Nov '04

I have the following graph: typedef property< vertex_index_t, uint32_t, property< vertex_name_t, boost::shared_ptr<Component> > > VertexProperty; typedef adjacency_list<setS, // OutEdgeList setS, // VertexList directedS, // Directed VertexProperty> // VertexProperties Graph_Type; When I looked at the documentation I did not see an example which used a boost::shared_ptr to store information at the vertex. Here is my attempt at writing a PropertyWriter. I cannot figure out how to write the 2nd function argument type: class Component_Writer { public: void operator()(std::ostream& out, const boost::shared_ptr<Component> obj) const { out << "[label=\"" << obj_ptr->get_Name() << "\n" << obj_ptr->get_ID() << "\"]"; } }; The error I get is: cd /home/storri/src/libreverse/src/infrastructure/ g++ -g -Wall -o graph_test2 graph_test2.cpp /usr/include/boost/graph/graphviz.hpp: In function `void boost::write_graphviz(std::ostream&, const Graph&, VertexPropertiesWriter, EdgePropertiesWriter, GraphPropertiesWriter) [with Graph = boost::adjacency_list<boost::setS, boost::setS, boost::directedS, boost::property<boost::vertex_index_t, uint32_t, boost::property<boost::vertex_name_t, boost::shared_ptr<Component>, boost::no_property> >, boost::no_property, boost::no_property, boost::listS>, VertexPropertiesWriter = Component_Writer, EdgePropertiesWriter = boost::default_writer, GraphPropertiesWriter = boost::default_writer]': /usr/include/boost/graph/graphviz.hpp:292: instantiated from `void boost::write_graphviz(std::ostream&, const Graph&, VertexWriter) [with Graph = boost::adjacency_list<boost::setS, boost::setS, boost::directedS, boost::property<boost::vertex_index_t, uint32_t, boost::property<boost::vertex_name_t, boost::shared_ptr<Component>, boost::no_property> >, boost::no_property, boost::no_property, boost::listS>, VertexWriter = Component_Writer]' graph_test2.cpp:484: instantiated from here /usr/include/boost/graph/graphviz.hpp:264: error: no match for call to `( Component_Writer) (std::basic_ostream<char, std::char_traits<char> >&, void* const&)' graph_test2.cpp:49: error: candidates are: void Component_Writer::operator()(std::ostream&, const boost::shared_ptr<Component>&) const Compilation exited abnormally with code 1 at Mon Nov 8 00:15:3 Stephen -- Email: storri(a)torri.org

2 4

Best method for storing a type in a boost graph vertex.
by Stephen torri 08 Nov '04

08 Nov '04

What is the best method for storing a type in a boost graph vertex? By value or pointer? I have the following graph type: typedef property< vertex_index_t, uint32_t, property< vertex_name_t, boost::shared_ptr<Component> > > VertexProperty; typedef adjacency_list<setS, // OutEdgeList setS, // VertexList directedS, // Directed VertexProperty> // VertexProperties Graph_Type; The Component is a class. I thought it was best to store it in the vertex as a pointer. Is this going to cause me trouble? Stephen -- Email: storri(a)torri.org

2 1

ublas compatible solvers (newbie question)
by Zrubavel Zodikovich 08 Nov '04

08 Nov '04

Hi all, I'm looking into using uBLAS for solving some big sparse systems, specifically with conjugate gradient family of solvers. Could anyone point me towards boost-compatible implementation of such solver ? thanks in advance

2 1

signals library with stlport
by tweety 08 Nov '04

08 Nov '04

how can i compile the signals library with stlport? i have tried setting STL_PORT_PATH and STL_PORT_VERION but when i run bjam -sTOOLS=vc-7.1-stlport it says it cannot find vc-7.1-stlport.jam (which is true, there's only jamfile and jamfile.v2 in signals/build) and if i just run bjam it gives me the native stl libraries (which, of couse, won't autolink with my program). can you help me? ---------------------------------- Peace and love, Tweety mitea(a)sympatico.ca - tweety_04_01(a)users.sourceforge.net YahooID: tweety_04_01

2 2

spirit question
by Cory Nelson 08 Nov '04

08 Nov '04

I'm trying to write a parser with elements that might not occur - is this possible? like: string ['-' number] that matches "foo" or "foo-123" -- Cory Nelson http://www.int64.org

3 4

Re: boost graph library bugs
by Qiaofeng Yang 07 Nov '04

07 Nov '04

Hi, Below is a list of bugs (at least I think so) in boost graph library: 1. I used the functions illustrated in file "components_on_edgelist.cpp" on a adjacency_list graph instead of a edge_list graph. It gave the correct number of components in the graph, but when printing out each components, the nodes in some of the components were disconnected. Also, segmentation fault was flagged.(This happened when the graph had a lot of components.) 2. I ran the source code in file "subgraph.cpp" as it was, the output was different from the sample output given in the same file. The difference was: the subgraph had global edge index, but local vertex index. 3. When creating multiple subgraphs, code like below would give segmentation fault: " typedef property<vertex_name_t, string> VertexName; typedef property<vertex_index_t, int, VertexName> VertexProperty; typedef property<edge_index_t, int> EdgeProperty; typedef subgraph< adjacency_list<vecS, vecS, undirectedS, VertexProperty, EdgeProperty> > Graph; ... Graph G(N); //add edges to G //assign names to vertices in G ... Graph & G1 = G.creat_subgraph(); //add vertices to G1 //assign names to vertices in G1 ... " When using function put(PropertyTag, const subgraph& g, Key k_local, const Value& value) to assign names to the vertices of subgraph G1(it seems that the name of vertices in G is not automatically inherited by G1.), it gave segmentation fault. This problem would not happen if the number of subgraphs was few such as 2. I found the above problems when I tried to create subgraphs for each component in the graph when the number of components was large. Thanks for your time, Qiaofeng

3 2

problem with boost::thread libraries
by Vinodth Mohanam 06 Nov '04

06 Nov '04

Hi, I came across this problem in using the threads package. I used the following files: boost_thread-vc71-mt-gdp-1_31.lib boost_thread-vc71-mt-gdp-1_31.dll boost_thread-vc71-mt-p-1_31.lib boost_thread-vc71-mt-p-1_31.dll While trying out a simple example from the test folder: #include <boost/thread.hpp> #include <boost/thread/xtime.hpp> using namespace boost; ............ ............ ............ void HelloWorld() { } ............ ............ ............ // Test threads boost::thread thrd(&HelloWorld); thrd.join(); ............ ............ ............ The application gave the following link error: Abacus error LNK2019: unresolved external symbol "__declspec(dllimport) public: __thiscall boost::thread::thread(class boost::function0<void,class _STL::allocator<class boost::function_base> > const &)" (__imp_??0thread@boost@@QAE@ABV?$function0@XV?$allocator@Vfunction_base@ boost@@@_STL@@@1@@Z) referenced in function "public: unsigned int __thiscall mok3::Abacus::Application::init(void)" (?init@Application@Abacus@mok3@@QAEIXZ) The program works fine without any parameters to the constructor ( boost::thread thrd; ), but of course that's not useful. If it were a syntax error it should be at compile-time, but there is no problem during compilation. Also, if there is a patch for statically linking threads package, it would be appreciated if you could send it. I am compiling the libraries with the following settings: Boost_1_31_0> bjam -sTOOLS=vc7.1-stlport -sSTLPORT_PATH=... install Thanks, -Vino

2 2

write_graphviz with listS as vertex container
by Meredith L. Patterson 05 Nov '04

05 Nov '04

Hi all, I've been using the Boost Graph Library for a project that requires the use of the graphviz library, and have run into a quandary. For reasons that are a bit complicated to get into right now, my users need to be able to remove vertices from what are at times extremely large graphs (~75,000 vertices), so vecS is clearly the wrong type for runtime reasons. The problem comes with write_graphviz. As the documentation points out, the graph must have an internal vertex_index property map; listS doesn't have an inherent vertex_index the way vecS does, so I've defined vertex_index as a property (along with vertex_name); the code compiles and runs. However, in the DOT output, I get a vertex list that looks like: 0[label="foo"]; 1[label="bar"]; 2[label="baz"]; [....] and an edge list that looks like 0x8061d90->0x8061db8 [weight="5"]; 0x8061d90->0x8061c50 [weight="13"]; [....] Obviously, the edge list is using vertex descriptors (which in this case end up being the memory location of each vertex object), while the vertex list is using vertex indices (and a quick look at graphviz.hpp confirms this; starting from line 262, the function uses get(vertex_index, *i) to get vertex identifiers for the vertex list in the DOT file, and source(*ei, g) and target(*ei, g) to get source-vertex and target-vertex identifiers for the edge list. This isn't a big deal when the vertex list type is vecS, of course, because vertex-index is basically a pointer into the vector, but it doesn't work for listS, setS, et cetera. Any suggestions for how to resolve this contradiction? I suppose I could try overloading source() and target(), but if there's an easier way to do it, I'd rather go that route. :) Cheers, Meredith L. Patterson

1 0

boost.test not autolinking (1.32)
by Cory Nelson 05 Nov '04

05 Nov '04

boost.test isn't autolinking in vc71, is this intentional? -- Cory Nelson http://www.int64.org

3 2