- Boost-users - lists.boost.org

Trouble building Boost for Comeau
by Edward Diener 23 Jul '05

23 Jul '05

When I attempt to build the Boost libraries for the Comeau compiler using vc71 as my backend, each build line fails with: "Command-line error #595: too many arguments on command line" Is there a workaround to this problem ? I am surprised to see that for compilers which support the use of a file to hold command line parameters the build process does not use this technique, which leads to such an error.

2 3

boost cvs acces?
by Serge Skorokhodov 23 Jul '05

23 Jul '05

Hi, Something real bad happend with access to :pserver:anonymous@cvs.sourceforge.net:/cvsroot/boost:( 'unrecognized auth responce from cvs.sourceforge.net' I've found no clues on boost site and on sourceforge site. Any help? TIA -- Serge

2 1

nontemplate iterators
by Mike Gibson 23 Jul '05

23 Jul '05

Does such a thing exist? So you could the following (with some_iterator begin the 'thing'): template <typename Value> class some_iterator { ...magic... }; void f(some_iterator<int> begin, some_iterator<int> end) { ...do something cool with begin and end... } int double_int(int i) { return i * 2; } int main() { std::vector<int> vec_int; ...fill vec_int... f( make_some_iterator(vec_int.begin()), make_some_iterator(vec_int.end())); f( make_some_iterator( make_transform_iterator(vec_int.begin(), double_int)), make_some_iterator( make_transform_iterator(vec_int.end(), double_int))); std::deque<int> deq_int; ...fill deq_int... f( make_some_iterator(deq_int.begin()), make_some_iterator(deq_int.end())); }

2 1

[Filesystem] path refuses "foo\bar" on win32/mingw
by Alo Sarv 23 Jul '05

23 Jul '05

When passing "foo\bar" to boost::filesystem::path constructor, it is accepted when compiled with MSVC, but is refused when compiled with mingw-gcc (v3.4.2). "foo/bar" argument is accepted with both compilers. Test-case: #include <boost/filesystem/path.hpp> #include <iostream> using namespace boost::filesystem; using namespace std; int main(int argc, char *argv[]) { path::default_name_check(native); try { path p1("foo/bar"); cerr << "ok - constructed from 'foo/bar'" << endl; } catch (std::exception &e) { cerr << e.what() << endl; } try { path p1("foo\\bar"); cerr << "ok - constructed from 'foo\\bar'" << endl; } catch (std::exception &e) { cerr << e.what() << endl; } return 0; } Compiled with: g++ -I c:\boostcvs\include\boost-1_33 -L c:\boostcvs\lib test-path.cpp -o test-path -lboost_filesystem-mgw-d Tested against: Boost 1.32 release, CVS HEAD Is it a bug in FS library, or I'm doing something wrong? One would expect native paths be accepted by path with native namechecker, and I can't see any mingw/msvc-specific code in FS library, which could explain why it works with one compiler, but not with other compiler... Alo

2 2

performance issue with graph edge removal
by Feldman, Yulik 22 Jul '05

22 Jul '05

Hi, Our project has recently run into severe performance issue with remove_edge() function of Boost graph. In our particular case, we use adjacency list specialized as: typedef adjacency_list< listS, vecS, bidirectionalS, CdfgNodeProperty, CdfgEdgeProperty> CdfgType; At some point in the flow, we need to remove great amount of edges from the graph, an amount comparable to the total number of edges in the graph. Unfortunately, since the complexity of removal of each edge is about O(E/V) the complexity of removal of all edges is about O(E * E/V). This appears to be too much, when the number of edges is big. What is actually interesting about this situation, is that I see no way to remove all edges (let's say we need to remove all edges) with any Boost function and with any adjacency list specialization in O(E) complexity, not necessarily the one we're currently using. The O(E/V) complexity of the remove_edge() comes from the fact that there is a need to remove the edge from in/out edge lists of the vertices connected by the edge. Even though I know I will not need any of these lists after all edges are removed, remove_edge() doesn't know that, so it is doing the "extra" work of updating the lists one-by-one. Moreover, in case of edge lists such as vector/list/multiset, i.e. containers that allow parallel edges in the graph, the search is linear in the size of containers (resulting in O(E/V) complexity of the operation). The question is what can be done, in any way, to do this "simple" operation of removing all edges of the graph in "more reasonable" complexity O(E) instead of O(E * E/V)? It doesn't help to try to remove many edges at once, such as using clear_in_edges() function to remove all in-edges of the given node, or clear_vertex() to remove all edges of the given node, because these functions still have to remove all the edges being removed from the edge list of the connected nodes. This results in the same complexity of the operation, as with using repetitive remove_edge() calls. It also doesn't help using other containers for storing in/out edge lists, such as list or multiset, instead of vector. Although the removal operation is faster in these containers, the search operation that looks for the edge to be removed is still in the order of the size of the container. For containers such as set or hash set, the search operation is faster, but such containers do not allow parallel edges, since the edges are indexed by the node identifier on the other side of the edge. The search operation that looks for the edge to be removed is in the order of the size of the container because it is necessary to find all the parallel edges. Therefore, for implementations allowing parallel edges, the implementation goes over all edges stored in the container and checks whether the edge connects to the node whose edges are being removed (in case of clear_in_edges()/clear_vertex()). If it is, the edge is removed from the in/out edge list. In our graph implementation, we need to support parallel edges. Even without parallel edges, the total complexity of removal of all edges still can't be brought down to O(E) (only to O(E * log(E/V))). If I would be free to change Boost's graph implementation, one possible solution could be to store in each edge two iterators pointing to the position of this edge in the corresponding in/out edge lists. This would allow removal of the edge from "list" container in O(1). However, it doesn't seem to be possible to do with current Boost implementation. Still, even if it would be possible, the memory consumption would increase due to the storage of the two iterators (at least two additional extra pointers per edge). Another approach could be to index the edges in in/out edge lists by edge identifier (which is not a part of Boost graph infrastructure), instead of indexing them by node identifier. This would allow using "multiset" container to find the edges to remove faster (in logarithmic time). But this still doesn't seem to be possible to do with current Boost implementation and it will also incur a memory overhead (due to usage of complex container as multiset). And still the complexity will be more than O(E). Is there a way to remove all edges in O(E) complexity? Do I miss something, or there is an inherent performance issue in current Boost graph implementation with regard to the edge removal? Even if the current situation is by design due to memory consumption trade offs, I wish the graph implementation would be flexible enough to let the user control performance/memory balance, instead of requiring the performance hit. Or, at least, to provide an atomic function for removal of all edges of the graph, which can be easily implemented to work fast and without incurring any memory overhead with all underlying in/out edge container implementations (just clear all edge-related containers). Any thoughts are welcome. Thanks, Yulik.

3 2

Subgraph problem
by odisseo＠despammed.com 22 Jul '05

22 Jul '05

Look at the following code, as you it print out: ----------- name: graph name sg1: subgraph 3 name sg2: subgraph 3 name sg3: subgraph 3 ----------- when I waiting for ----------- name: graph name sg1: subgraph 1 name sg2: subgraph 2 name sg3: subgraph 3 ----------- WHY? Is this a bug in the library? #include <string> #include <iostream> using namespace std; #include <boost/config.hpp> #include <boost/graph/graphviz.hpp> #include <boost/graph/adjacency_list.hpp> #include <boost/graph/graph_utility.hpp> int main() { boost::GraphvizDigraph gr; boost::get_property(gr, boost::graph_name) = "graph"; std::cout << "name: " << get_property(gr, boost::graph_name) << std::endl; boost::subgraph<boost::adjacency_list<boost::vecS, boost::vecS, boost::directedS, boost::GraphvizVertexProperty, boost::GraphvizEdgeProperty, boost::GraphvizGraphProperty, boost::listS> > sg1 = gr.create_subgraph(); get_property(sg1, boost::graph_name) = "subgraph 1"; boost::subgraph<boost::adjacency_list<boost::vecS, boost::vecS, boost::directedS, boost::GraphvizVertexProperty, boost::GraphvizEdgeProperty, boost::GraphvizGraphProperty, boost::listS> > sg2 = gr.create_subgraph(); get_property(sg2, boost::graph_name) = "subgraph 2"; boost::subgraph<boost::adjacency_list<boost::vecS, boost::vecS, boost::directedS, boost::GraphvizVertexProperty, boost::GraphvizEdgeProperty, boost::GraphvizGraphProperty, boost::listS> > sg3 = gr.create_subgraph(); get_property(sg3, boost::graph_name) = "subgraph 3"; std::cout << "name sg1: " << get_property(sg1, boost::graph_name) << std::endl; std::cout << "name sg2: " << get_property(sg2, boost::graph_name) << std::endl; std::cout << "name sg3: " << get_property(sg3, boost::graph_name) << std::endl; }

2 1

question on property tags and bundled properties.
by sr kumar 22 Jul '05

22 Jul '05

Hi, I am attempting use bundled properties for my graph processing. My attempt to 'write_graphviz' fails because of a lack of an vertex_index as an internal property. But how does one specify this? Named params do not seem to be an option. Being new to the template meta programming game, I am having some trouble figuring out how to make this work. Code snippet below is the simplest that would reproduce my problem. Thanks in advance for any clues/hints on how to proceed. -sr #include <boost/graph/adjacency_list.hpp> #include <boost/graph/topological_sort.hpp> #include <boost/graph/graphviz.hpp> using namespace boost; using namespace std; class A { public: // dummy class }; typedef struct VertexProperties { A* a; std::size_t index; boost::default_color_type color; } VertexProperties; typedef struct EdgeProperties { A* a; } EdgeProperties; int main(void) { typedef adjacency_list<vecS, listS, directedS, VertexProperties, EdgeProperties> Graph; Graph g(3); property_map<Graph, std::size_t VertexProperties::*>::type id = get(&VertexProperties::index, g); property_map<Graph, boost::default_color_type VertexProperties::*>::type color = get(&VertexProperties::color, g); boost::graph_traits<Graph>::vertex_iterator vi, viend; int vnum = 0; for (boost::tie(vi,viend) = vertices(g); vi != viend; ++vi) { id[*vi] = vnum++; } add_edge(vertex(0, g), vertex(1, g), g); add_edge(vertex(2, g), vertex(1, g), g); typedef graph_traits<Graph>::vertex_descriptor vertex_descriptor; std::vector< vertex_descriptor > c; // Just check to ensure that all is ok. topological_sort(g, std::back_inserter(c), color_map(color). vertex_index_map(id)); // See error below... property_map<Graph, vertex_index_t>::const_type ver_idx = get(vertex_index_t(),g); remove_edge(vertex(0, g), vertex(1, g), g); remove_edge(vertex(2, g), vertex(1, g), g); return 0; }; // ------------- C:\test>cl /EHsc /IC:\CheckMate\boost\boost_1_32_0 btest.cpp Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.50215.44 for 80x86 Copyright (C) Microsoft Corporation. All rights reserved. btest.cpp btest.cpp(53) : error C2440: 'initializing' : cannot convert from 'boost::adj_list_vertex_property_map<Graph,ValueType,Reference,Tag>' to 'boost::adj_list_vertex_property_map<Graph,ValueType,Reference,Tag>' with [ Graph=Graph, ValueType=boost::detail::error_property_not_found, Reference=boost::detail::error_property_not_found &, Tag=boost::vertex_index_t ] and [ Graph=Graph, ValueType=boost::detail::error_property_not_found, Reference=const boost::detail::error_property_not_found &, Tag=boost::vertex_index_t ] No constructor could take the source type, or constructor overload resolution was ambiguous

2 1

BGL: EdgeIterator construction of graphs
by Sebastian Weber 22 Jul '05

22 Jul '05

Hi everybody! I'm trying to initialize my adjacency_list graph via an EdgeIterator. Since I do not want parallel edges to be present in my graph, but still use vecS as EdgeList-storage because of memory considerations, my EdgeIterator needs somehow a reference to the graph under construction. Some code might explain it better: typedef boost::adjacency_list<boost::vecS, boost::vecS, boost::undirectedS > graph_t; typedef boost::my_edge_iterator<base_rand_gen_t, graph_t> SFGen; graph_t bg = graph_t(SFGen(bg, base_rand, 100), SFGen(), 100); This code compiles fine, but seg-faults immediatly since bg does not seem to be defined when my iterator gets constructed. A solution would be to provide a add_edge_range-function which gets as input the EdgeIterator and the corresponding empty boost graph. This function would then build up the graph or is there a better way to do this? Thanks a lot in advance for your help. Greetings, Sebastian

2 2

Re: [Boost-users] compiler warnings using date_time library onVS.NET2003
by Sean Rohead 22 Jul '05

22 Jul '05

Yes, I am using boost 1.32 and have /W3 as the warning level. Thanks, Sean -----Original Message----- From: boost-users-bounces(a)lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Bart Sent: Friday, July 22, 2005 7:06 AM To: boost-users(a)lists.boost.org Subject: Re: [Boost-users] compiler warnings using date_time library onVS.NET2003 "Sean Rohead" <sean.rohead(a)nextpage.com> wrote in message news:dbpf56$hig$1@sea.gmane.org... >I am using VS.NET 2003 and have a simple program which merely includes the > Boost date_time library. When compiling, I get 4 warning messages about > unsafe conversions. Is there some compiler setting that I can change to > get > rid of this warning? Shouldn't I be able to include a Boost library > without > getting warnings? > > Thanks! Could you please tell me, what warning level are you using and are you using boost 1.32 or current cvs? Thanks, Bart _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

2 1

Building Boost for Comeau
by Edward Diener 22 Jul '05

22 Jul '05

In the explanation for como-win32 toolset configuration variables, the variable COMO_BACKEND_PATH, which says "Path to backend compiler" has a default value of $(VC7_TOOLS). Running vcvars32.bat for vc7 does not set any such environment variable. To what does the COMO_BACKEND_PATH need to be set ? Is it the path to the backend compiler executable itself or is it the path to the entire installation ? If I had Vc7 installed in c:\vsnet, would COMO_BACKEND_PATH be c:\vsnet or would it be c:\vsnet\vc7\bin ?

2 2