- Boost-users - lists.boost.org

[BGL] directed_graph_adapter
by Andreas Fabri 19 Apr '13

19 Apr '13

Hello, Did anybody write an adapter class (similar to filtered_graph) that gives a directed view on an undirected bidirectional graph. Or an adapter in the other direction, that is an undirected view on a directed graph. If not, is there a major obstacle, that is it simply cannot be implemented, even if it seems straightforward. best regards, andreas -- Andreas Fabri, PhD Chief Officer, GeometryFactory Editor, The CGAL Project phone: +33.492.954.912 skype: andreas.fabri

2 1

boost::cmatch indices
by Rob.Conde＠ai-solutions.com 19 Apr '13

19 Apr '13

Is there a reason why boost::cmatch.size() returns size_type, but boost::cmatch operator[] takes int? Thanks, Rob Conde

2 1

boost::asio::deadline_timer destruction
by Daniel 19 Apr '13

19 Apr '13

Hello, I've noticed that WaitHandler can be called after boost::asio::deadline_timer destruction. It may cause using of uninitialized data. Are there any other solutions of graceful destruction of boost::asio::deadline_timer to be sure that after this destruction WaitHandler will never be called? Example pseudo code: class UsingDeadlineTimer { char some_data_accessed_from_the_wait_handler[512]; boost::asio::deadline_timer timer; void WaitHandler(const boost::system::error_code &ec) { if(ec == boost::asio::error::operation_aborted) { return; } memset(some_data_accessed_from_the_wait_handler, 'E', 512); // cause the problem, because UsingDeadlineTimer may be already destroyed. } UsingDeadlineTimer() : timer(io_service) { timer.expires_at(the moment of UsingDeadlineTimer destruction); timer.async_wait( boost::bind(&UsingDeadlineTimer::WaitHandler, this, boost::asio::placeholders::error) ); } ~UsingDeadlineTimer() { timer.cancel(); // but we already can be in the WaitHandler body which will access some_data_accessed_from_the_wait_handler } }; Thank you, Daniel

2 5

mpl vector of pair access
by Olaf Peter 19 Apr '13

19 Apr '13

Hello, in these code I try to unpack the 1stand 2nd element, but it doesn't compile (here, it complains about »apply« in »struct boost::mpl::at_impl<boost::mpl::non_sequence_tag>« Is there a better way and how to get it to compile? Thanks, Olaf ---8<--- #include <boost/mpl/vector.hpp> #include <boost/mpl/vector_c.hpp> #include <boost/mpl/max_element.hpp> #include <boost/mpl/pair.hpp> #include <boost/mpl/integral_c.hpp> #include <boost/mpl/size_t.hpp> #include <boost/mpl/placeholders.hpp> #include <boost/mpl/at.hpp> #include <iostream> namespace mpl = boost::mpl; struct code { enum type { undefined, foo, bar }; }; typedef mpl::vector<std::size_t, // min max mpl::pair< mpl::size_t<0>, mpl::size_t<0> >, // undefined mpl::pair< mpl::size_t<1>, mpl::size_t<3> >, // foo mpl::pair< mpl::size_t<2>, mpl::size_t<5> > // bar > arity_info; template <code::type code> struct min_arity : mpl::at_c< typename mpl::at_c<arity_info, code>::type, 0 >::type { }; // same for max_arity at index 1 (pair::second) int main() { std::cout << "min arity = " << min_arity<code::bar>::value << '\n'; // std::cout << "max arity = " // << max_arity<code::bar>::value << '\n'; } --->8---

2 7

Recommended linker order
by Michael Powell 19 Apr '13

19 Apr '13

Hello, So I am reading the article: http://www.boost.org/boost-build2/doc/html/bbv2/faq/liborder.html But I am not clear what this means? For instance, I'd like to put filesystem to use, but was finding linker errors there. Either could use filesystem issues, or std::string issues (<string>), but not both, for instance. No clue how that could even be possible. Build was also failing along similar lines, semantic and/or what I gather are linker failures. So... I get to specify the order CodeBench for Linux targeting ARM, wants to link libraries. Is there a specific order to include boost static libs that keeps the system happy? If so, what? Thank you... Regards, Michael Powell

2 1

heap handle invalidation
by ☂Josh Chia (谢任中) 19 Apr '13

19 Apr '13

Hi, I'm using a mutable heap, in particular a mutable d_ary_heap, for the priority queue in Djikstra's algorithm. When does a handle become invalid? I don't know how a d_ary_heap is implemented, but if it's like the standard array-backed binary heap, then I would expect invalidation of many handles whenever an item gets popped or an item gets increased or decreased. I need references to the elements in order to update them, so if the invalidation I expect does happen as I describe, how can I get permanent references/pointers/iterators to the elements? Perhaps another implementation besides d_ary_heap? Although I haven't profiled the performance, I think even though something like the fibonacci heap may have permanent handles, pointer chasing, more frequent cache misses and frequent dynamic memory allocation may be detrimental to performance. Which heap implementation supports key increase without handle invalidation? Josh

1 0

boost.log: update filters at runtime
by Jonathan Walker 18 Apr '13

18 Apr '13

Hello, I've been working on integrating the boost logger into my application for the past few days now. I'm looking for the ability to update filters at runtime based on settings from a file or other source. A specific use-case would be the ability to decrease a severity level during a debugging session for more detailed log reports without having to restart the application. Is there anything like this available in the current release? Is there any plan to incorporate this kind of functionality in future releases? Thanks, Jonathan ________________________________ This e-mail and any attachments are confidential. If it is not intended for you, please notify the sender, and please erase and ignore the contents.

1 0

[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