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

Need good semi-high-res timer
by Michael Powell 16 Apr '13

16 Apr '13

Hello, I am looking for a semi-high-res timer solution. Ideally, should be clock-agnostic, shouldn't see non-deterministic behavior in the face of NTP or GPS system or local time updates. Thus far attempts to use boost/timer/timer.hpp have been frustrated by what seems like the common occurrence linker issues. I've defined to use header only, but that doesn't seem to have fixed it. Or possibly I need to rebuild boost with that option? Or something along these lines. I'd like to use boost if that feature is available, and avoid clock-bound timers if at all possible. Recommendations? Thanks much. Regards, Michael Powell

1 0

Re: [Boost-users] boost asio daemon
by Marat Abrarov 16 Apr '13

16 Apr '13

Hi, Philipp. > io::io_service l_ioservice; > io::signal_set l_signals(l_ioservice, SIGINT, SIGTERM); > l_signals.async_wait(daemonhandler); // * > l_ioservice.run(); // ** > > void daemonhandler( const boost::system::Error_code& err ) { > if (!err) > do some log > else > do daemon work > } > > My question is, is the daemonhandler function a function that is called > only if the daemon is stopped or that is run during the daemon is active / > working? According to Boost.Asio docs (http://www.boost.org/doc/libs/1_53_0/doc/html/boost_asio/overview/core/basi cs.html) all callbacks (handlers) are executed (handler::operator() is called) within the threads running asio::io_service::run() (run_one/poll/poll_one). So at the execution point of the daemonhandler function at least one thread of daemon (thread of the daemon's process) runs. If the above code is the only place that executes asio::io_service::run() (see **) then daemonhandler function will be called within the same thread. And if (*) is the only pending async operation then continuation of execution of asio::io_service::run() depends on daemonhandler starting additional async operations on the same instance of asio::io_service (on l_ioservice). Regards, Marat Abrarov.

2 1

[timer] Examples do not compile
by Michael Powell 16 Apr '13

16 Apr '13

Hello, I am trying to setup a "simple" elapsed timer abstraction to hide the boost::timer::cpu_timer concern. However, I am finding that the usage example illustrated here does not compile, or I am not including something I need to include (more likely). http://www.boost.org/doc/libs/1_53_0/libs/timer/doc/cpu_timers.html#using-c… Might there be more complete working examples I can draw from? Thank you... Regards, Michael Powell

1 1

Re: [Boost-users] [graph] dijkstra additional constrains that will stop the search (ex. distance from source)
by The Maschine 16 Apr '13

16 Apr '13

Hi, Not really! (Im not that advance yet) Let me explain. 1) Every vertex in the graph has each own m_length value which is the 'length' of that node only. 2) from the "source" of the search, I want the search to extent to only the node in the radius from the source. So that "radius" cutoff should by something like adding all "m_length" of the route to the current node. At the moment my search only has a weight_map of the "Edge Weights" not some sort of "Vertex Weight". How should I proceed? Is this clear? Sorry for the confusion. Thanks Tasos > I had assumed you were using m_length as the distance map in Dijkstra's > algorithm, and so that would be the total distance you want to compare to. > Is that what you intended? If not, what are you using as your distance > map? > > -- Jeremiah Willcock > >

2 1

program_options allow_unregistered and *nix style
by Michael Powell 16 Apr '13

16 Apr '13

Hello, I would like to find a way to allow_unregistered program_options, as well as specify cls::unix_style ^ cls::allow_short, where cls is po::command_line_style. The code I've got here doesn't seem to like unrecognized ones: //vis_ are my visible options, vars_ is my variable map. po::store(parse_command_line(argc, argv, vis_, cls::unix_style ^ cls::allow_short), vars_); po::notify(vars_); And then a slight variation with apparently a way to do this (untested), how to specify that cls? // http://stackoverflow.com/questions/10178525/how-to-handle-unsolicited-param… po::parsed_options parsed_ = po::command_line_parser(argc, argv) .options(vis_).allow_unregistered().run(); Possible? Thank ye... Regards, Michael Powell

2 4

Re: [Boost-users] [graph] dijkstra additional constrains that will stop the search (ex. distance from source)
by The Maschine 16 Apr '13

16 Apr '13

Hi Jeremiah, As far as I understand this will examine only the "local" value (node length for example) against the threshold. In my path search I need to be able to find the "total length/distance" from the source to the vertex in question. Adding up the lengths (of the nodes that the path is passing) from source to current vertex and then tested against the threshold. Am I clear or my description is wrong? Thanks a lot, Tasos > Here's the basic idea (not tested); use this as your Dijkstra visitor, and > change the part labeled "threshold" to your threshold computation: > > struct threshold_visitor: boost::default_dijkstra_visitor { > double threshold; > > threshold_visitor(double threshold): threshold(threshold) {} > > struct hit_threshold {}; > > void examine_vertex(vertex_descriptor v, const unGraph& g) { > if (get(&VertexProperties::m_ref, g, v) > threshold) > throw hit_threshold(); > } > }; > > Remember to wrap your call to Dijkstra's algorithm in a try-catch block > for threshold_visitor::hit_threshold. > > -- Jeremiah Willcock > >

2 1

[graph] dijkstra additional constrains that will stop the search (ex. distance from source)
by The Maschine 16 Apr '13

16 Apr '13

Hi all, I've been reading around the list (Ill post examples below) but I dont really know how to implement the thing below. I want the search to be able to stop based on some "value" or "result of a function". For example, every node has a "length" value in a custom "struct VertexProperties". How is it possible for dijkstra_shortest_paths to only consider nodes that are inside a radius from the source? Everything else should be considered as 'unconnected'. I have checked a couple of posts form the list but I dont know what do really do. (function property map, exceptions in visitors etc) http://thread.gmane.org/gmane.comp.lib.boost.user/54392/focus=54397 http://thread.gmane.org/gmane.comp.lib.boost.user/72072/focus=72074 http://thread.gmane.org/gmane.comp.lib.boost.user/73358/focus=73384 I havent found any example or source online that deals with something similar. Any ideas? code example or tutorials? Best, Tasos my graph for example: struct VertexProperties { double m_length; int m_ref; }; typedef double Weight; typedef boost::property<boost::edge_weight_t, double> EdgeWeightProperty; typedef boost::adjacency_list<boost::vecS, boost::vecS, boost::undirectedS, VertexProperties, EdgeWeightProperty> unGraph;

2 1

Re: [Boost-users] [Graph] dijkstra_shortest_paths: weird distance to vertex (1.79769e+308)
by The Maschine 16 Apr '13

16 Apr '13

Hi Jeremiah, How do I eliminate cases like this? (not connected vertex) For you post I think you cannot use "isnan" or "isinfinate" right? My only option is colormap or predecessors? (I havent use them yet) Best, Tasos

2 1

boost asio daemon
by Philipp Kraus 16 Apr '13

16 Apr '13

Hello, I use boost::asio for creating a daemon, I do this: io::io_service l_ioservice; io::signal_set l_signals(l_ioservice, SIGINT, SIGTERM); l_signals.async_wait(daemonhandler); l_ioservice.run(); my daemonhandler shows: void daemonhandler( const boost::system::Error_code& err ) { if (!err) do some log } The daemon handler function is a function, that runs in a thread loop, does it? Can I create something like: void daemonhandler( const boost::system::Error_code& err ) { if (!err) do some log else do daemon work } My question is, is the daemonhandler function a function that is called only if the daemon is stopped or that is run during the daemon is active / working? Thanks Phil

1 0

Re: [Boost-users] [CMake] [boost][b2] Differenciate 32bit and 64 bit binaries when using CMake.
by Klaim - Joël Lamotte 16 Apr '13

16 Apr '13

Júlio Hoffimann said: > > I don't know if i understood correctly, but you can set the library > directory by hand, please refer to > /usr/share/cmake-<version>/Modules/FindBoost.cmake, in particular the > variable BOOST_LIBRARYDIR. On Thu, Oct 11, 2012 at 1:29 PM, Miller, Frank <FMiller(a)sjm.com> wrote: > A simple solution would be to install only the 64bit version of boost > into a new directory and change the environment variable to point there. > Then FindBoost will only be able to see the version you want. > Thanks, this will solve my immediate problem, but it don't solve it in general. (I will use it though, so thanks) I can't guarantee where the boost libraries are installed, that's why I use FindBoost. My current understanding is that boost don't have a specific default lib dir for different address models, which is the source of the problem as FindBoost script can't rely on a protocol to find these lib files. Am I correct? Joel Lamotte

3 8