- Boost-users - lists.boost.org

[Range] size and list, for example.
by Robert Jones 17 Apr '13

17 Apr '13

I know this has come up before, so I'm really seeking to discover the current situation. boost::size( std::list<...> ) fails because the implementation of size is end - begin. I know I could use distance, but am surprised size(list) doesn't work out of the box. * So, is it correct that size(list) doesn't work? * Does distance(begin, end) specialise for random access iterators to O(n) performance? * Why doesn't size similarly specialise? Thx, Rob.

3 2

[filesystem] Using filesystem with std::string
by Michael Powell 17 Apr '13

17 Apr '13

Hello, Or vice versa. When I include <boost/filesystem.hpp> and <string>, uses of std::string fall over it seems. As long as I do not include filesystem.hpp, it's okay. Would like to use the filesystem features if possible, but I also want to keep track of some strings, possible override operator<< for various requirements (TBD). Is this a boost bug? Or what do I need to do to make it work? I am building against a static library, multithreading AFAIK, targeting ArchLinux ARM. Building against a GCC 4.7.2 toolchain (CodeBench). Thank you... Regards, Michael Powell

3 3

Re: [Boost-users] [graph] dijkstra additional constrains that will stop the search (ex. distance from source)
by a.hagen-zanker＠surrey.ac.uk 17 Apr '13

17 Apr '13

From: Boost-users [mailto:boost-users-bounces@lists.boost.org] On Behalf Of The Maschine boost::dijkstra_shortest_paths(m_ugraph, *vertex_iterator_begin, boost::predecessor_map(predecessorMap).distance_map(distanceMap)); currently works ok. Finds the shortest path based on the "edge_weight" (this is what I need). The addition I need: I need the search for the shortest path to stop if outside a radius. (my graph is a street network). lets say max "travel distance" = 4 Source -> V1(length=1) -> V2(length=3) -> V3(length=2) -> V4(length=1) -> V5(length=1) ->VEnd The search should end on V3 and V3 should be "unreachable" from the source (V4,V5 and Vend should be unreachable too) The distance_map should have the distances for V1 and V2 based on the "edge_weight". This explanation seems to be better. Thanks Tasos Hi Tasos, You could consider that "unreachable" is the same as "d = travel distance". You could use a closed plus and a custom value for infinite distance. You would need to create a closed plus that is a bit more robust than the closed_plus currently in BGL, e.g.: struct robust_closed_plus { robust_closed_plus (double d) : d(d) {} double operator(double a, double b){ return (d-a < b) >? d : a+b; } double d; }; Then you can use dijkstra_shortest_path, using your travel distance as infinity. robust_closed_plus plusser(travel_distance); boost::dijkstra_shortest_paths(m_ugraph, *vertex_iterator_begin , boost::predecessor_map(predecessorMap) .distance_map(distanceMap) .distance_compare(plusser) .distane_inf(travel_distance); This should already give you the correct result, but will also make you visit more vertices than necessary. Still combine with a visitor like Jeremiah suggested before: struct hit_inf{}; template<typename DistanceMap> struct inf_quit_visitor: boost::default_dijkstra_visitor { inf_quit_visitor (DistanceMap dm, double inf) : dm(dm), inf(inf) {} template<typename V, typename G> void examine_vertex(V v, const G& g) { if (get(dm, v) == inf) throw hit_inf(); } DistanceMap dm; double inf; }; robust_closed_plus plusser(travel_distance); inf_quit_visitor<DistanceMap> quitter(distanceMap, travel_distance); try { boost::dijkstra_shortest_paths(m_ugraph, *vertex_iterator_begin, boost::predecessor_map(predecessorMap) .distance_map(distanceMap) .distance_compare(plusser) .distane_inf(travel_distance) .visitor(quitter) ); } catch(hit_inf&) { } Hope this helps, Alex

1 0

Boost for GPUs
by Blesson Varghese 17 Apr '13

17 Apr '13

Hi All I am new to using Boost libraries. I have written a function that makes use of the boost for computing the inverse of the cummulative distribution function of the beta distribution (quantile) in C++ which works fine. Now I would like to use the same function on the GPU, but I cannot call a host function from device. Are there any alternatives to use boost functions on GPU? Looking forward to your reply. Many thanks and kind regards Blesson

4 5

[timer] Error linking boost::chrono::steady_clock::now
by Michael Powell 17 Apr '13

17 Apr '13

Hello, I get the following linker error. Description Resource Path Location Type undefined reference to `boost::chrono::steady_clock::now()' detector line 0 C/C++ Problem I am using Boost 1.53. A little unclear what the docs are talking about. If I can go header only, and if it is advantageous to do so, I'd like to. http://www.boost.org/doc/libs/1_53_0/doc/html/chrono/users_guide.html#chron… However, not sure what else we're talking about here, when it talks about building boost with buggy header only support (?). Regards, Michael Powell

3 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

:) My description of the problem is hopeless. The boost::dijkstra_shortest_paths(m_ugraph, *vertex_iterator_begin, boost:: predecessor_map(predecessorMap).distance_map(distanceMap)); currently works ok. Finds the shortest path based on the "edge_weight" (this is what I need). The addition I need: I need the search for the shortest path to stop if outside a radius. (my graph is a street network). lets say max "travel distance" = 4 Source -> V1(length=1) -> V2(length=3) -> V3(length=2) -> V4(length=1) -> V5 (length=1) ->VEnd The search should end on V3 and V3 should be "unreachable" from the source (V4,V5 and Vend should be unreachable too) The distance_map should have the distances for V1 and V2 based on the "edge_weight". This explanation seems to be better. Thanks Tasos

2 1

How to print boost::exceptions to ostream
by Michael Powell 16 Apr '13

16 Apr '13

Hello, Basically like the subject says. I need a way to print boost::exceptions through an ostream. Or std::exception if that's a better more portable route to take. Suggestions? Regards, Michael Powell

2 1

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