- Boost-users - lists.boost.org

Constructing vertex_iterator from vertex_descriptor
by Martin Magnusson 20 Oct '04

20 Oct '04

I'm using BGL, and I noticed that add_vertex returns a vertex_descriptor to the new vertex. However, I would like to have a vertex_iterator pointing to the same element. Is there a way to construct a vertex_iterator when given a vertex_descriptor? / martin

3 2

compiling bgl
by Emre Turkay 19 Oct '04

19 Oct '04

Hi all, I've compiled boost on windows with vc71. However, I don't see a generated binary file for the boost graph library, though it was generating in linux. Do I need to do some manual tricks? Thanks, Emre Turkay

2 1

[BGL]DIJKSTRA - ospf-example
by Khaled Saleh 18 Oct '04

18 Oct '04

I'm trying to grasp the BGL using the user guide and reference manual book by J.Seik et al. Trying the ospf-example (\boost_1_31_0\libs\graph\example) using Borland C++ 5.6.4 for Win32 raise the follwing error: "dijkstra_shortest_paths.hpp": E2285 Could not find a match for 'dijkstra_shortest_paths<VertexListGraph,Param,Tag,Rest>(const adjacency_list<vecS,vecS,directedS,no_property,property<edge_weight_t,int,no _property>,no_property,listS>,unsigned int,unsigned int * const,iterator_property_map<int *,vec_adj_list_vertex_id_map<no_property,unsigned int>,int,int &>,adj_list_edge_property_map<directed_tag,int,const int &,unsigned int,const property<edge_weight_t,int,no_property>,edge_weight_t>,vec_adj_list_vertex_i d_map<no_property,unsigned int>,undefined,const closed_plus<int>,undefined,undefined,const default_dijkstra_visitor)' in function void dijkstra_dispatch2<adjacency_list<vecS,vecS,directedS,no_property,property<e dge_weight_t,int,no_property>,no_property,listS>,const iterator_property_map<int *,vec_adj_list_vertex_id_map<no_property,unsigned int>,int,int &>,adj_list_edge_property_map<directed_tag,int,const int &,unsigned int,const property<edge_weight_t,int,no_property>,edge_weight_t>,vec_adj_list_vertex_i d_map<no_property,unsigned int>,bgl_named_params<unsigned int *,vertex_predecessor_t,no_property> >(const adjacency_list<vecS,vecS,directedS,no_property,property<edge_weight_t,int,no _property>,no_property,listS> &,unsigned int,iterator_property_map<int *,vec_adj_list_vertex_id_map<no_property,unsigned int>,int,int &>,adj_list_edge_property_map<directed_tag,int,const int &,unsigned int,const property<edge_weight_t,int,no_property>,edge_weight_t>,vec_adj_list_vertex_i d_map<no_property,unsigned int>,const bgl_named_params<unsigned int *,vertex_predecessor_t,no_property> &) at line 247 The offending line is: choose_param(get_param(params, graph_visitor), make_dijkstra_visitor(null_visitor()))); Please advise in order to get myself going. Best Regards

1 0

Vertex descriptor invalidation
by Greg Emerson 18 Oct '04

18 Oct '04

Re: Boost Graph Library I have a feeling I am having some problems due to add_edge and vertex invalidation. According to the table on http://www.boost.org/libs/graph/doc/adjacency_list.html decriptors are stable, but http://groups.yahoo.com/group/boost/message/5435 claims otherwise. Could you clear this up for me? Thanks much, Greg Emerson

3 3

Vertex descriptor invalidation (again)
by Greg Emerson 18 Oct '04

18 Oct '04

Sorry, I forgot to mention that I have set VertexList=vecS (and wish to keep it that way). Thanks again, Greg Emerson

2 1

Re: Extending the boost::thread class
by arno.schaefer＠sqs.de 18 Oct '04

18 Oct '04

"Ben Hutchings" <ben.hutchings(a)businesswebsoftware.com> schrieb im Newsbeitrag news:<416D5B83.4090404(a)businesswebsoftware.com>... > Why do you think you want suspend, resume and terminate? There are very > few safe uses for these operations, and programs that use them tend to > suffer from data corruption and/or deadlocks. I am in the situation, that I have a lot of existing C++ Code, which work in this way. All kind of threads are running in an endless loop and will be controlled from outside over the resume and terminate interfaces. I have to deliver a class what satisfy the given interface, because I will have no chance to rewrite all the other code, which run very well on our given plattforms (SUN, HP, AIX, Linux, Windows). So my point is, I want use the portable boost code as a base and manage the non portable parts by myself and looking now for the best way to do it without manipulating the boost source code. > It would be fairly easy to add support for priority settings to > Boost.Thread, but since priority values are only meaningful in the > context of a scheduling policy and policies vary between operating > systems it would be hard to provide a genuinely portable priority system. Can you link to some examples? regards Arno

2 1

Bjam and cygwin
by Foster, Gareth 18 Oct '04

18 Oct '04

Hello all, I keep getting the following errors using bjam ... "<directory-grist>" I have set the install to use GCC and install to /usr. I also tried with /usr/local. I read that it might be a windows/unix line break thing, but I tried the zip file, bz2 and normal tarball, extracting with the windows gui tools and the cygwin cli tools. What am I doing wrong? Thanks for any help. Gaz -----Original Message----- From: boost-users-bounces(a)lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Joel Sent: 15 October 2004 00:55 To: boost-users(a)lists.boost.org Subject: Re: [Boost-users] Spirit Foster, Gareth wrote: > Hello all, > > I am trying to find some source code that uses spirit to parse C++ and > convert it to HTML, i found some on google, but i misplaced it and i > can't find it again. It looked like it could have been an example > provided with the library, but i can't see it listed in the documentation. > > On a side note, anyone know the best way to use boost with cygwin? From > source? Is there even another way? See the repository: http://spirit.sourceforge.net/repository/applications/show_contents.php Cheers, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

1 0

RE: [Boost-users] boost::bind, MSVC7.1 and volatile-qualification
by Schalk_Cronje＠McAfee.com 18 Oct '04

18 Oct '04

>I wouldn't go that way. After the great flame wars in >comp.programming.threads regarding the article, Andrei himself has >acknowledged that this might not be the proper way to do sychronization. >He's since proposed a better approach. >http://www.informit.com/articles/article.asp?p=25298 Oh right, I happened to attend his presentation he did this year at ACCU 2004.

1 0

dijkstra_shortest_paths and vertex_index
by Steve Buchko 16 Oct '04

16 Oct '04

I understand that when using listS to define vertices for a graph, I must also assign values to vertex_index before attempting to make use of dijkstra_shortest_paths. My question is, do the values assigned to vertex_index need to be sequential (i.e. 0 to n where n is the number of vertices in the graph), or can I assign any "random" integer to each vertex_index, as long as the values assigned are unique for each node? Does dijkstra_shortest_paths simply use the vertex_index as a unique identifier for the vertex, or is it using those indices to build an internal data structure such as an array or vector ... in which case using relatively large (or non-sequential) integers for vertex_index might be prohibitive from a memory or performance viewpoint? Thanks, steve

3 2

RE: [Boost-users] boost::bind, MSVC7.1 and volatile-qualification
by Schalk_Cronje＠McAfee.com 15 Oct '04

15 Oct '04

> I wonder why gcc is able to compile it. :-) Well considering that the following also yields different results on MSVC7.1 and gcc 3.2/3.3 I would wonder if there is a problem with one of the compilers #include <iostream> #include <boost/bind.hpp> struct X { void f() {std::cout << "None" << std::endl;} void f() const {std::cout << "const" << std::endl;} }; template <typename T> void run( void (T::*f_)(), T& t_) {(t_.*f_)();} template <typename T> void run( void (T::*f_)() const, T const& t_) {(t_.*f_)();} int main() { X x; run(&X::f,x); boost::bind(&X::f,_1)(x); } >Do you really have a volatile member function somewhere? I thought that they >were "officially" worthless. Well, that is a different matter. If one might want to follow Andrei's suggestion of using volatile to encapsulate synchronisation then they are still worthwhile. (CUJ February 2001).

2 2