- Boost-users - lists.boost.org

1.32 installation: where is the smart_ptr lib?
by Paul Johnson 23 Jun '05

23 Jun '05

Sorry for the dumb question... Just installed boost following the instructions on boost.org, and I can't find the smart_ptr library. I downloaded the 1.32 .bz file, and bjam, and installed on Linux/RHEL4. I've now got 189 boost libraries in /usr/local/lib, and 32 in /usr/lib. However, the only base libraries seem to be date_time, filesystem, prg_exec_monitor, program_options, python, regex, serialisation, signals, test_exec_monitor, thread, unit_test_framework, and wserialisation, some of which aren't even listed on the libraries page at boost.org. Where's smart_ptr? None of these libraries appear to have it. The smart_ptr headers are in /usr/local/include/boost-1_32/boost, as expected (but why 2 levels down? Surely I'm not expected to #include <boost-1_32/boost/xx.hpp??) Cheers.

2 2

bcp error
by Ronald Sipkema 23 Jun '05

23 Jun '05

hi, when trying to use bcp as follows: "bcp --list build" I get the following error: **** exception(205): std::runtime_error: Bad file name: ../boost.css Any idea what's happening? Other module lists )for example regex) work just fine. --Ronald

2 1

date_time problem: where are fractional seconds?
by Serge Skorokhodov 23 Jun '05

23 Jun '05

Hi, The following code (boost 1.32, MSVC.NET 2003): ptime pt = from_iso_string("20030912T211733.01204"); cout << pt << endl; cout << to_simple_string(pt) << endl; cout << to_iso_extended_string(pt) << endl; cout << to_iso_string(pt) << endl; cout << pt.time_of_day().fractional_seconds() << endl; time_duration td = pt.time_of_day(); cout << to_iso_string(td) << endl; cout << to_simple_string(td) << endl; cout << td.fractional_seconds() << endl; yealds: 2003-Sep-12 21:17:33 2003-Sep-12 21:17:33 2003-09-12T21:17:33 20030912T211733 0 211733 21:17:33 0 Is the fractional part of time (.01204) absent by design? I failed to find it out from the documentation? Is there a workaround? TIA -- Serge

2 3

[bind / lambda] binding a factory funtion instead of an value
by Bertolt Mildner 23 Jun '05

23 Jun '05

Lets say i need a functor of type typedef boost::function1<Ret, Arg1> Functor; and i have a function Ret Foo(Arg1 a, Arg2 b); Creating a Functor object is easy if i have a Arg2 object Arg2 arg2; Functor f(boost::bind<Ret>(&Foo, _1, arg2); But what if i want to create the Arg2 object in the functor when it is used? Like i have a function Arg2 CreateArg2(); and i don't want Functor f(boost::bind<Ret>(&Foo, _1, CreateArg2()); but something like Functor f(boost::bind<Ret>(&Foo, _1, &CreateArg2); so that f(arg1) = Foo(arg1, CreateArg2()); I have a vague feeling that lambda might have a solution to this, but i don't know how! Bertolt

2 2

[BGL] overlaying a graph-like structure
by martin f krafft 22 Jun '05

22 Jun '05

I am looking at the possibility to use BGL for the structural representation of an artificial neural network: nodes would be neurons, edges would be synapses. The advantage for me would be that I don't have to worry about complexity of the graph structure. For this to work, I need to be able to strap behaviour and data onto the edges and nodes. The bundled properties interfaces seems to be a good way to do this, but there is something fundamental that I am apparently not understanding: What is an edge descriptor, what is a vertex descriptor? From the code: typedef typename boost::ct_if_t<is_rand_access, std::size_t, vertex_ptr>::type vertex_descriptor; vertex descriptors are indices or pointers. And typedef detail::edge_desc_impl<directed_category, vertex_descriptor> edge_descriptor; and edge is actually a struct containing source and target vertex, and a property pointer (void*). There does not seem to be a way to get the property object from an edge descriptor without casting to the expected type. Thus, vertex and edge descriptors are really just minimal and provide absolutely no way to access the relevant data through their interface. Instead, BGL expects people to have access to the containing graph object, to be able to call functions like target(), out_edges(), or operator[] to get at the downstream vertex/edge, or a vertex'/edge's properties. In the context of my application, I know have two options: adopt the graph-centric perspective of BGL, in which the graph object is needed to answer any questions about the graph, even about single components therein, or to strap a layer on top of all this to return to proper object encapsulation: - where a node knows about its incident edges - where an edge knows about its source and target vertices - where both give access to the associated properties. If I wanted to go the latter way, I'd have to store an additional 8 bytes (descriptor + graph references) with each object, which is just a waste if you ask me. However, there seems to be no other way as I cannot derive from vertex/edge descriptors. Does anyone have any experience with folding BGL into an existing graph-like structure? My ideal solution would be my neuron and synapse classes derived from the vertex and edge descriptors, such that I can treat them like components of the graph as well as neural components. From looking at the LEDA stuff, I guess the way to do this is to modify the graph traits to replace edge and node descriptors with custom classes. If I take care to model the behaviour of the existing edge and node descriptors wrt their interfaces, I shouldn't actually need to override the public Graph API, right? Is it sensible to derive from detail::edge_desc_impl, or should detail::* stuff not be touched outside of BGL code? Thanks for any comments, thoughts, suggestions, pointers. -- martin; (greetings from the heart of the sun.) \____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck invalid/expired pgp subkeys? use subkeys.pgp.net as keyserver! spamtraps: madduck.bogus(a)madduck.net "i have smoked pot. it is a stupid business, like masturbation." -- thomas pynchon

3 7

[BGL] adding behaviour to nodes and edges
by martin f krafft 22 Jun '05

22 Jun '05

I would like my nodes and edges to have behaviours. Bundled properties -- the method to attach struct instances to nodes and edges -- seems like the way to go. However, if that is the suggested method, then "bundled properties" is somewhat of a misnomer. What's the suggested way to attach behaviour to nodes and edges? I.e. I'd love to be able to iterate through vertices(G) with std::for_each and have it call a member function for each vertex. -- martin; (greetings from the heart of the sun.) \____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck invalid/expired pgp subkeys? use subkeys.pgp.net as keyserver! spamtraps: madduck.bogus(a)madduck.net the english take english for granted. but if we explore its paradoxes, we find that quicksand can work slowly.

2 6

Problem using edge_descriptors as indices into an external property
by Andrea Olgiati 22 Jun '05

22 Jun '05

Folks, I've encountered a problem whilst compiling the following program, and I can't quite figure out why it shouldn't work. Whilst compiling usign boost 1.32.0 and gcc 3.3.4, I get cannot convert `boost::detail::edge_desc_impl<boost::bidirectional_tag, size_t>' to `int' for argument `2' to `const T& get(const T*, int) [with T = int]' I believe this is saying that edge descriptors cannot be used as indices into a property map (that is, "wm"). Why is this different from vertex descriptors, which are accepted as indices into "p" and "dist"? Any help appreciated. Thanks, Andrea #include <boost/graph/graph_traits.hpp> #include <boost/graph/adjacency_list.hpp> #include <boost/graph/bellman_ford_shortest_paths.hpp> int main () { typedef boost::adjacency_list < boost::vecS, boost::vecS, boost::bidirectionalS > Graph; Graph G; std::vector < int > wm; std::vector < boost::graph_traits < Graph >::vertex_descriptor > p; std::vector < int > dist; boost::bellman_ford_shortest_paths (G, boost::num_vertices(G), &wm[0], &p[0], &dist[0], boost::closed_plus < int >(), std::less < int >(), boost::default_bellman_visitor ()); return 0; }

2 1

[signal] custom connect/disconnect
by John Maguire 22 Jun '05

22 Jun '05

Hi all, I have a program where I have several signals, and I want an action to be taken when connect/disconnect occurs on them. I would prefer to avoid wrapping the calls, since it would reduce composibility. I would imagine that this isn't the first time that such a requirement has been made of signals, so I was wondering if someone could point me towards the standard solution for this? Regards, John

2 1

[BGL] Question on prim_minimum_spanning_tree
by Wang Johny 22 Jun '05

22 Jun '05

Hi, there I am a new user of boost (in particular BGL). For my project, I am using the function of "prim_minimum_spanning_tree" to construct the minimum spanning tree. But I found a strange problem and hope to get your help. Specifically, I am following the sample code "prim-example.cpp" (using MSVC), with one modification to the weight property. That is, I am defining the weight property as property < edge_weight_t, float > not the original one property < edge_weight_t, int > And I found by doing so, the function of "prim_minimum_spanning_tree" return wrong results (no edge is returned at all). But the original version using "property < edge_weight_t, int >" definition works well. So I am wondering if I missed something to make user-defined weitgh property work for this function. Any suggestion is welcome. Thank you very much. Best regards, Shenai Problematic code: /////////////////////////////////////////////////////////////////////////////////////////////////// typedef adjacency_list < vecS, vecS, undirectedS, property<vertex_distance_t, int>, property < edge_weight_t, float > > Graph; typedef std::pair < int, int >E; const int num_nodes = 5; E edges[] = { E(0, 2), E(1, 1), E(1, 3), E(1, 4), E(2, 1), E(2, 3), E(3, 4), E(4, 0) }; float weights[] = { 1.0f, 2.0f, 1.0f, 2.0f, 7.0f, 3.0f, 1.0f, 1.0f }; Graph g(num_nodes); property_map<Graph, edge_weight_t>::type weightmap = get(edge_weight, g); for (std::size_t j = 0; j < sizeof(edges) / sizeof(E); ++j) { graph_traits<Graph>::edge_descriptor e; bool inserted; tie(e, inserted) = add_edge(edges[j].first, edges[j].second, g); weightmap[e] = weights[j]; } std::vector < graph_traits < Graph >::vertex_descriptor > p(num_vertices(g)); property_map<Graph, vertex_distance_t>::type distance = get(vertex_distance, g); property_map<Graph, vertex_index_t>::type indexmap = get(vertex_index, g); prim_minimum_spanning_tree(g, *vertices(g).first, &p[0], distance, weightmap, indexmap, default_dijkstra_visitor()); for (std::size_t i = 0; i != p.size(); ++i){ if (p[i] != i){ TRACE("I am here"); } } /////////////////////////////////////////////////////////////////////////////////////////////////// --------------------------------- Do You Yahoo!? 150万曲MP3疯狂搜，带您闯入音乐殿堂美女明星应有尽有，搜遍美图、艳图和酷图 1G就是1000兆，雅虎电邮自助扩容！

2 1

style: overloading vs default parameters
by Noel Yap 22 Jun '05

22 Jun '05

Is there any particular reason why at least some boost code uses default parameters. IME, I've found the using overloading is preferable. For example, when using boost::bind, one would have to explicitly give the default parameters whereas one wouldn't if overloading were used. Also, using overloading rather than default parameters when a new function interface is needed can potentially break less client code (eg code that uses the type of the function won't break if overloading were used). Given this, I'd like to hear some arguments for using default arguments over overloading (outside of constructors, of course, where one may not have much of a choice). Thanks, Noel

2 1