April 2006 - Boost-users - lists.preview.boost.org

managing "interesting syntax" checks
by Howard Gardner 24 Apr '06

24 Apr '06

/* This code detects the presence of particular syntax in a type. The relevant part is the template class syntax_member_insert: it will ramify into an unbounded set of similar classes, each of which is checking for some particular interesting bit of syntax. I am aware of parts of boost that grapple with this issue very directly: boost::concept_check The concepts to be checked are close kin to the syntax I'm looking for. boost::concept_traits Again, the concepts to be checked are close kin to the syntax I'm looking for. And I'm aware of parts of boost that touch on this issue indirectly: boost::function Contains a really nice mechanism for expressing function signatures. In point of fact, one effort that I made to generalize the implementation of syntax_member_insert yielded a solution with template classes like: template< typename x, typename xRet, typename xDummy = dummy, ... > struct member_function; template< typename x, typename xRet > member_function< x, xRet >; template< typename x, typename xRet, typename xP0 > member_function< x, xRet, xP0 >; These look suspiciously like the boost::functionX< > templates. boost::type_traits The is_* classes are used in one of the ways that I would want to use supports_syntax. boost::mpl Represents a *lot* of other uses for supports_syntax. It seems to me that it would be good to express this unbounded set of interesting syntax checks so that all of those facilities can use it. Does such a mechanism already exist? Is it feasable to create it using existing boost facilities? Is it feasable to create it at all? */ #include<ostream> using namespace std; template< typename xParm > struct syntax_member_insert { template< typename x, x & (x::*)( xParm ) = &x::insert > struct match; }; template< typename x, typename xSyntax > struct supports_syntax { private: typedef char ret_true; struct ret_false{ char c[2]; }; template< typename > static ret_false func( ... ); template< typename xX > static ret_true func( typename xSyntax::template match< xX > * ); public: static const bool value = ( sizeof( func< x >( 0 ) ) == sizeof( ret_true ) ); }; struct passes { passes & insert( char ); }; struct fails{}; int main() { cout << supports_syntax< passes, syntax_member_insert< char > >::value << endl; cout << supports_syntax< fails, syntax_member_insert< char > >::value << endl; }

1 0

[program_options]How to save options to storage
by Ken 24 Apr '06

24 Apr '06

HI, BOOST I am sorry if this is a stupid question. I did not found similar question yet. Sometimes we need to read config from a file and change some values then need to save it. So how can I serialize an option_description to stream? Thanks a lot. Regards Ken

3 4

i18n (and program_options)
by Christoph Duelli 24 Apr '06

24 Apr '06

Hi, I am using spirit and program_options so far. When Boost.Program_options fails to parse some command line options it throws an exception (which is fine). So far, I write (if e is such an exception) e.what() to stderr. An obvious example of the the output I get is 'unknown option ...' I would like to present my users a text in their own language (i.e. german). Does Boost or Boost.Program_options support i18n? If yes, how can I set the language to use? (Or is the intended use to catch the exception, analyze it and produce my own translation?) Best regards, Christoph

2 1

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