- Boost-users - lists.boost.org

Re: [Boost-users] Fwd: Program Options: string iterator not dereferencable
by Vladimir Prus 24 Apr '06

24 Apr '06

On Monday 24 April 2006 13:13, Olaf van der Spek wrote: [I CC boost-users mailing list, where this discussion originates] > > > There also seem to be 'typos' in some comments. Should I report those > > > to you too? > > > > Yes, please. > > > > > And what about: > > > Is it possible to allow long options without -- prefix? > > > The code doesn't seem to support it, but I think it's handy in cases > > > where positional options aren't used. > > > > Did you try 'allow_long_disguise' style option? > > No, but isn't that with a "-" prefix? I'd like no prefix at all. Hmm, never though this will be requested. Anyway, it's possible with a custom style parser, as the attached example shows. For me, both: extra3 test=10 and extra3 test 10 work. HTH, Volodya

2 1

[program_options] additional parser
by Alexander Kondratyuk 24 Apr '06

24 Apr '06

Have a problem with using additional parser feature: I want to allow user to use double dashes for short options, so user will use "-h" or "--h". But using additional parser the code throws an error about syntax. It seems there is a bug in additional parser wrapper - in case then my option has no parameters defined and declared in description it adds an empty value to the vector of values when additional paser returns pair of strings. Perhaps there is another way to get what I want, please let me know how to do it? Here is an example that illustrates the problem: #define BOOST_WHATEVER_DYN_LINK #define BOOST_LIB_DIAGNOSTIC #include <boost/program_options/variables_map.hpp> #include <boost/program_options/options_description.hpp> #include <boost/program_options/parsers.hpp> #include <boost/program_options/detail/utf8_codecvt_facet.hpp> #include <boost/token_iterator.hpp> #include <boost/shared_ptr.hpp> using namespace boost::program_options; #include <string> #include <vector> using namespace std; pair<string, string> parserDashDashShort(const string& s) { string str = s.substr( 0, s.find('=') ); if( str.length()==3 && str[0]=='-' && str[1]=='-' && str[2]<='z' && str[2]>='a') { string val = s.substr(str.length()); return make_pair( str.substr(1), val ); } return make_pair(string(), string()); } int _tmain(int , _TCHAR* argv[]) { int style = command_line_style::allow_short| command_line_style::allow_dash_for_short | command_line_style::short_allow_adjacent; options_description desc; desc.add_options() ("help,h", "help message") ; char* args[]={"program.exe", "--h"}; int argc = sizeof( args ) / sizeof( args[0] ); parse_command_line<char>( argc, (char**)args, desc, style, parserDashDashShort ); return 0; }

2 1

BGL:"topological_sort" on the output of "strong_components"
by John Krajewski 24 Apr '06

24 Apr '06

For my app (a physics simulator), I need to find the order to process sets of nodes in such a way that no node is processed before any node that it has a directed edge to, and all strongly connected nodes are processed in a set together (this is for determining the order to test stacked objects). So basically, I want to detect all strongly connected components, then create a directed graph from that and perform a topological sort. Then, when I process that sorted list of strongly connected components, I'll need to get the list of original nodes that are in each component. My first inclination to solve this is to just create a second graph from the output of the strongly_connected_components algorithm, and then topological_sort that. But perhaps there is some clever way to avoid that extra expense? This will be my first use of BGL/boost so dumbing-down is encouraged :) Thanks, -John gmail.com account: johnnyk1

3 2

BGL: *** glibc detected *** free(): invalid next size
by Irek Szczesniak 23 Apr '06

23 Apr '06

Vertexes in my graph have the distance and predecessor properties. These properties at each vertex are vectors: they store distances and predecessor of shortest paths to every other node in the graph. Below is my program. I run the program and as input I give the file also listed below, and get this run-time error: *** glibc detected *** free(): invalid next size (fast): 0x085dd110 I would appreciate your advice on what I'm doing wrong. Best, Irek ********************************************************************** #include <string> #include <boost/graph/adjacency_list.hpp> #include <boost/graph/dijkstra_shortest_paths.hpp> #include <boost/graph/iteration_macros.hpp> #include <boost/graph/graphviz.hpp> using namespace std; using namespace boost; typedef adjacency_list_traits<vecS, vecS, undirectedS>::vertex_descriptor Vertex; typedef boost::adjacency_list <vecS, vecS, undirectedS, property<vertex_name_t, string, property<vertex_distance_t, vector<int>, property<vertex_predecessor_t, vector<Vertex> > > >, property<edge_weight_t, int, property<edge_weight2_t, int> > > Graph; int main () { Graph g; dynamic_properties dp; dp.property("node_id", get(vertex_name, g)); dp.property("distance", get(edge_weight, g)); dp.property("lambdas", get(edge_weight2, g)); read_graphviz(cin, g, dp); BGL_FORALL_VERTICES(v, g, Graph) { get(vertex_distance, g, v).resize(num_vertices(g)); get(vertex_predecessor, g, v).resize(num_vertices(g)); dijkstra_shortest_paths (g, v, predecessor_map(&get(vertex_predecessor, g, v)[0]). distance_map(&get(vertex_distance, g, v)[0])); } } ********************************************************************** Graph { a; b; c; d; e; f; a -- b [distance = "100", lambdas = "10"] b -- c [distance = "200", lambdas = "10"] c -- d [distance = "80", lambdas = "10"] b -- e [distance = "40", lambdas = "10"] c -- f [distance = "100", lambdas = "10"] a -- e [distance = "210", lambdas = "10"] e -- f [distance = "340", lambdas = "10"] f -- d [distance = "50", lambdas = "10"] }

1 1

[BGL]adjacency_list_traits does not define edges_size_type
by Louis Lavery 23 Apr '06

23 Apr '06

Hello, The class adjacency_list_traits<EdgeList,VertexList,Directed> provides an alternate method for accessing the types of edge_descriptor and vertex_descriptor, with out this we'd run into a problem with mutually recursive types. I need to know the order in which edges are added to the vertices of my graph. To do that I intend to stamp each edge with an (increasing) integral number as it is added to the graph. It seems to me the stamp's type should be edges_size_type, but that's not available via adjacency_list_traits<EdgeList,VertexList,Directed>. Should it be? Can it be? Thanks, Louis.

3 9

memory problems with BGL
by borech＠tepkom.ru 23 Apr '06

23 Apr '06

Hello, I've been in fight with memory leaks in my application for some days. And now I found that most memory is losing while using adjacency_list<> (boost 1.33.1 + VC++6.0). Basically we've lost about 100Kb after each graph life cycle (created - changed - removing). Moreover, I guess, I found the similar problem on the very simple test: #include "..\boost_1_33_1\boost\graph\adjacency_list.hpp" using namespace boost; typedef adjacency_list<> Graph; void main() { int num_vertex = 10000; Graph* graph = new Graph(); for(int j=0; j<num_vertex; ++j) { add_vertex(graph); } delete graph; } Here I've lost some memory too (about 20 Kb). Maybe I'm doing something wrong? Thanks

1 0

Compatibility problems BDS40 vs boost
by Christian Askeland 23 Apr '06

23 Apr '06

Hi all, I am running boost 1.33.1 with BDS40, the Borland compiler. I upgraded to BDS Update pack 2 yesterday, and the two following files failed to compile: boost/iterator_adaptors.hpp boost/function.hpp Have anyone else seen this? The failures are inside a lot of compiler-ifdefs, so I guess that this might require some rewrite of boost. Regards, Christian

2 2

Is there a way to avoid manually adding each lib dir?
by Andrew Schweitzer 23 Apr '06

23 Apr '06

boost for dummies question here: When I use boost with VC 7.1, if I link to a lib, I have to include the header, get the compiler error, copy the enormous name of the lib onto the clipboard, then search in c:\boost_1_33_1\bin for that lib. Then I select the properties of that file, copy the enormous directory name, then open the visual studio project, and add the enormous directory name to the list of directories in which to look for libs. Repeat for each lib linked to. I tried adding e:\boost_1_33_1\bin\boost\libs, e:\boost_1_33_1\bin\boost, e:\boost_1_33_1\bin e:\boost_1_33_1 as lib directories. That didn't help. Is there a less process with fewer manual steps? Thanks, Andy

4 5

[regex] Library did not build
by Ed Keith 23 Apr '06

23 Apr '06

A while back I installed boost 1.33.1 I followed the instructions to build the libraries with mingw and have been using it successfully. Today, for the first time since installing, I tried to used the regex library. I was surprised to discover that the regex library did not build. date_time, file system, iostreams, program_options, python, serialization, signals, test_exec_monitor, unit_test_framework, thread, & wave all built, but no regex. Has anyone else had this problem? It seems to have built for cygwin (but I have not tested it.) -EdK Ed Keith http://www.freecherrypy.org/edk __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

3 2

Boost.Program_options and optional arguments
by Dale McCoy 23 Apr '06

23 Apr '06

I'm trying to convert from getopt (GNU's getopt_long, to be more specific) to boost::program_options, but have run into trouble converting "D::" and {"data",optional_argument,NULL,'D'} (If you're not familiar with getopt, that means that --data is equivalent to -D, and both take an optional argument, so "-D", "--data", "-Darg", and "--data=arg" are all valid.) I see that the first argument to add_option should be "data,D", but then things get fuzzy. I saw nothing in the documentation concerning optional arguments, either directly, or using additional parsers. What is the appropriate method for implementing such options? I'm using currently using Boost 1.33.1. Dale

1 0