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

[statechart]
by Ernesto Rodriguez Reina 30 Nov '15

30 Nov '15

Hi everyone, The statechart search for an event handler in post-order (children first then parent), however when we have orthogonal states involved then the behaviour I am experiencing is different. Let say we have an state X with two children [orthogonal] states Y and W. Assuming none of the handlers discard (or defer) an event, the handler for that event is called in the following order: Y, X, W, X. Note that the handler of X is called twice. The code in the following link shows that behaviour: http://coliru.stacked-crooked.com/a/14cb35ca23e586a5 If there something that I am missing? Best, Ernesto Rodriguez Reina

1 0

[Ublas] Bug in 1.59 in file boost/numeric/ublas/detail/concepts.hpp
by dariomt＠gmail.com 30 Nov '15

30 Nov '15

In the migration from Boost 1.55.0 to 1.59.0 I found a bug in Ublas. For instance, in 1.55.0 function OneElement() declared in boost/numeric/ublas/detail/concepts.hpp line 716 looks like this: template<> double OneElement (double) { return 1.; } However, in 1.59.0 I think there is a copy'n'paste typo, because the corresponding function (which has been refactored) looks like this: template<class T> T OneElement (T) { return T(0.0); } Please note that the latter version returns a *zero*, instead of a *one*. This same bug affects the vector overload of the function, but the matrix version looks correct (it returns identity_matrix). This looks like a copy'n'paste typo, from a similar function called ZeroElement(), that, of course, returns a zero. I'm not sure if there is time to get a fix for this in the 1.60 release... Regards!

1 0

New to Boost
by Gagan Kumar 30 Nov '15

30 Nov '15

I want to contribute to Boost, can you please give me a small task to start contributing.

3 2

variant has non-trivial destructor even when all constituents have trivial destructor
by ☂Josh Chia (谢任中) 28 Nov '15

28 Nov '15

It seems that boost::variant has non-trivial destructor even for something like boost::variant<int32_t, int64_t>. Thus, It cannot be used in situations that call for a POD where calling the destructor is trivial. Particularly, I can't have a boost::lock_free::queue<boost::variant<X, Y>> even both X and Y are trivially destructible. How about making boost::variant trivially-destructible when everything in it is trivially-destructible?

2 3

[BGL] metric_tsp_approx.cpp Error
by Vicky Vergara 28 Nov '15

28 Nov '15

Hello, I am trying to run the metric_tsp_approx.cpp example, but I get an error, I am using the suggested data 3 vertices data, I don't know what I am doing wrong, please help. Vicky. http://www.boost.org/doc/libs/1_58_0/libs/graph/test/metric_tsp_approx.cpp $more graph.txt 1,2 20,4 15,7 I get this error: terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::negative_edge> >' what(): The graph may not contain an edge with negative weight. Aborted (core dumped) Its after all the graph is connected: we can parse the given file Opened file 1,2 20,4 15,7 Closed file (1,2) -> (20,4) = 19.105 (1,2) -> (15,7) = 14.8661 (20,4) -> (15,7) = 5.83095 Conected all terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::negative_edge> >' what(): The graph may not contain an edge with negative weight. Aborted (core dumped) This is what I get when doing a backtrace: (shortened) (gdb) bt #0 0x00007ffff722bcc9 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 #1 0x00007ffff722f0d8 in __GI_abort () at abort.c:89 #2 0x00007ffff7b36535 in __gnu_cxx::__verbose_terminate_handler() () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 #3 0x00007ffff7b346d6 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 #4 0x00007ffff7b34703 in std::terminate() () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 #5 0x00007ffff7b34922 in __cxa_throw () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 #6 0x00000000004085c8 in boost::throw_exception<boost::negative_edge> (e=...) at /usr/include/boost/throw_exception.hpp:67 #7 0x0000000000408b0f in examine_edge<boost... #8 boost::breadth_first_visit<boost... vis=..., color=...) at /usr/include/boost/graph/breadth_first_search.hpp:82 #9 0x00000000004038ec in breadth_first_visit<boost... at /usr/include/boost/graph/breadth_first_search.hpp:105 #10 dijkstra_shortest_paths_no_init<... (color=..., vis=..., zero=0, combine=..., compare=..., index_map=..., weight=..., distance=..., predecessor=..., s=0, g=...) at /usr/include/boost/graph/dijkstra_shortest_paths.hpp:337 #11 dijkstra_shortest_paths<boost... (color=..., vis=..., zero=0, inf=1.7976931348623157e+308, combine=..., compare=..., index_map=..., weight=..., distance=..., predecessor=..., s=0, g=...) at /usr/include/boost/graph/dijkstra_shortest_paths.hpp:388 #12 dijkstra_shortest_paths<boost... at /usr/include/boost/graph/dijkstra_shortest_paths.hpp:358 #13 dijkstra_dispatch2<boost... at /usr/include/boost/graph/dijkstra_shortest_paths.hpp:431 #14 dijkstra_dispatch1<boost: at /usr/include/boost/graph/dijkstra_shortest_paths.hpp:462 #15 dijkstra_shortest_paths<boost... params=..., s=0, g=...) at /usr/include/boost/graph/dijkstra_shortest_paths.hpp:480 #16 prim_mst_impl<boost at /usr/include/boost/graph/prim_minimum_spanning_tree.hpp:41 #17 boost::prim_minimum_spanning_tree<boost... at /usr/include/boost/graph/prim_minimum_spanning_tree.hpp:72 #18 0x0000000000408bb3 in boost::metric_tsp_approx_from_vertex<boost::... at /usr/include/boost/graph/metric_tsp_approx.hpp:193 #19 0x0000000000402320 in metric_tsp_approx_tour<boost::... o=..., g=...) at /usr/include/boost/graph/metric_tsp_approx.hpp:89 #20 main (argc=<optimized out>, argv=<optimized out>) at metric_tsp_approximation.cpp:249

1 0

Re: [Boost-users] [BGL]Using a function for weightmap to dijkstra_shortest_path
by alex 27 Nov '15

27 Nov '15

>-----Original Message----- >From: Boost-users [mailto:boost-users-bounces@lists.boost.org] On Behalf Of >Amit Prakash Ambasta >Sent: 23 November 2015 08:20 >To: boost-users(a)lists.boost.org >Subject: [Boost-users] [BGL]Using a function for weightmap to >dijkstra_shortest_path > >Hi, > > >I am trying to write use BGL.dijkstra to calculate a shortest path in a time >dependent network where edge.cost C(u, v) is a function of >distance(a)edge.source and a variable wait time dependent on Edge.departure >i.e. > Are you confident that you can use Dijkstra Shortest Paths for this? To me it seems that would only be possible if you knew that delay times are increasing over time, but not when they are fluctuating up and down. The code might be simpler if you put the dynamic part in the combine functor instead of the weight map. using Time = double; using Money = double; struct Distance { Time time; Money cost; }; struct Weight { Time duration; Money cost; Time delay(cost Time& start) const { // delay as a function of start time } }; struct Combine { Distance operator()(const Distance& start, const Weight& weight) const { Distance finish; finish.time = start.time + weight.delay(start.time) + weight.duration; finish.cost = start.cost + weight.cost; return finish; } };

2 1

Boost.Type_erasure: member function return _self
by Yuan Yao 26 Nov '15

26 Nov '15

2 1

[1.60] Beta date?
by Joaquin M López Muñoz 26 Nov '15

26 Nov '15

Hi, Is there a planned date for Boost 1.60 beta (we have beta RC3 so far) or do we intend to jump directly to 1.60 RC? I'm asking because I've got a couple of fairly minimal commits that run succesfully in develop and I'd like to merge to release before it's too late: https://github.com/boostorg/multi_index/commit/ 1f4d33012bb0537d6bd5667aed8a02d29eb1ed26 https://github.com/boostorg/flyweight/commit/ adda32bfa9af8a4427affc41c64b792660ffffae Thank you, Joaquín M López Muñoz Telefónica

4 3

[Statechart] question about event processing rules in orthogonal states.
by Ernesto Rodriguez Reina 25 Nov '15

25 Nov '15

Hi everyone, The event processing order of a normal (non-orthogonal) state is first the innermost and if not handled (or forwarded) then it parent, and that behaviour is repeated upward until the event is discarded (or deferred). But when we are in the presence of orthogonal states, then the behaviour I am getting is a bit different, for example given the following statechart: <code> struct EvTest : sc::event< EvTest > {}; struct Test; struct Inner1; struct Inner2; struct Machine : sc::state_machine< Machine, Test > {}; struct Test : sc::simple_state<Test, Machine, mpl::list<Inner1, Inner2> >{ typedef sc::custom_reaction< EvTest > reactions; sc::result react( const EvTest){ std::cout << "Test" << std::endl; // return discard_event(); return forward_event(); } }; struct Inner1 : sc::simple_state<Inner1, Test::orthogonal< 0 > >{}; struct Inner2 : sc::simple_state<Inner2, Test::orthogonal< 1 > >{ typedef sc::custom_reaction< EvTest > reactions; sc::result react( const EvTest){ std::cout << "Inner2" << std::endl; return forward_event(); } }; </code> When received the event "EvTest" the output I am getting is: <output> Test Inner2 Test </output> That means that the handler in the state "Test" is called twice. If in the handler at test we discard instead of forwarding then we get that only the handler of "Test" is called. I thought that without taking into account if the children are orthogonal or not, the event will be processed first by the children (all of them in the case of orthogonal state until one discard or defer the event), and event is not discarded (or deferred) then the parent process the event. It is that OK? If so why I am getting that weird behaviour in my example? Any thoughts and comments are more than welcome. Best, Ernesto Rodriguez Reina

1 0

boostboost::filesystem::detail::copy_file undefined when using c++14
by ken 25 Nov '15

25 Nov '15

Hello I am building an application that uses boost libraries that I also complied. This is on a mac os x 10.9 system using gnu gcc 5.2 installed with mac ports. I built the boost 1.59.0 libraries as instructed and built the application without any problems (after a few tries). Then I changed the c++ language standard for the build of the application to -std=gnu++14 (the default is gnu++11). However, I now get the following error during the linking phase: g++ -std=gnu++14 -U_WIN32 -Dunix -DNDEBUG -O3 -DTIXML_USE_STL -DBOOST_FILESYSTEM_VERSION=3 -fmessage-length=0 -I[...] -lboost_date_time-mt -lboost_filesystem-mt -lboost_regex-mt -lboost_system-mt -lboost_locale-mt -lboost_thread-mt -lboost_chrono-mt [...] Undefined symbols for architecture x86_64: "boost::filesystem::detail::copy_file(boost::filesystem::path const&, boost::filesystem::path const&, boost::filesystem::copy_option, boost::system::error_code*)", referenced from: [...] ... ld: symbol(s) not found for architecture x86_64 collect2: error: ld returned 1 exit status [...] I rebuilt the boost libraries with the -std=gnu++14 option and verified that they are using the same std library, but I still got the same error when linking those libraries to my application. I removed the c++14 option from the application build and the error went away. So next I took a look at the functions in libboost_filesystem-mt.a and for lib/libboost_filesystem-mt.a(operations.o) I found this function: 0000000000007720 T __ZN5boost10filesystem6detail9copy_fileERKNS0_4pathES4_NS1_11copy_optionEPNS_6system10error_codeE or boost::filesystem::detail::copy_file(boost::filesystem::path const&, boost::filesystem::path const&, boost::filesystem::detail::copy_option, boost::system::error_code*) I see that this differs from what the linker is looking for in that copy_option (third parameter) is in the detail name space. Any ideas on where to go from here? Thanks

1 0