March 2017 - Boost - lists.preview.boost.org

Boost MSM parallel behavior with delayed self-transitions?
by Danylo Malyuta 21 Mar '17

21 Mar '17

Hi community, This is my first post, so I'm sorry for any mistakes in style. I have also posted this question on StackOverflow: http://stackoverflow.com/questions/42920777/boost-msm-parallel-behavior-wit…. I am using Boost MSM (basic and functor front-ends) and am trying to implement the following state machine (https://i.stack.imgur.com/K79qk.png): enter image description here I am using Boost MSM (basic and functor front-ends) and am trying to implement the following state machine: enter image description here In words: 1. Enter state State1 2. Enter state A and execute action_A. After 2 seconds, print "Trying again..." and re-execute state A (i.e. call its entry action). This loops forever... 3. At the same time as 2 (i.e. "in parallel"), enter state B and execute action_B. After 5 seconds, print "Trying again..." and re-execute state B (i.e. call its entry action). This loops forever... I would like to know the way to create this state machine in Boost MSM. There are two tricks here which I cannot figure out how to do: - Execution in parallel (i.e. running action_A does not stop running action_B at the same time) - Delayed transition (i.e. the transitions which happen after 2 seconds for state A and after 5 seconds for state B). Neither delay should be blocking! The transitions should just "fire" after this time. Thank you very much for helping, Danylo.

2 1

Fwd: [gsoc17] Regarding Boost.Geometry
by Aditya Gupta 21 Mar '17

21 Mar '17

Hi I am Aditya Gupta, IInd Yr. B. Tech. Computer Science at IIT Ropar and I wish to work on Project 3 of Boost.Geometry (Nearly antipodal points distance accuracy improvement.) I have completed the competency test <https://github.com/adityagupta1089/earth-geometry>, but I think maybe it was too small or have I misinterpreted, anyways. I have an initial draft of my [GSoC proposal](https://gist.github. com/adityagupta1089/39863577e1716c55d86c98ff57623893) I have also attached my CV.

2 1

Re: [boost] [smart_ptr] Is there any interest in unique_ptr with type erased deleter?
by Andrey Semashev 21 Mar '17

21 Mar '17

For some reason my email went directly to Andrey instead of the mailing list. I'm re-sending the message below. PS: This has happened to me multiple times now after we moved the ML infrastructure. Is there a way to protect oneself from such mistakes? Am I the only one so inattentive to have this problem? On 03/21/17 16:11, Andrey Semashev wrote: > On 03/21/17 14:54, Andrey Davydov wrote: >> On Tue, Mar 21, 2017 at 2:15 PM, Andrey Semashev via Boost >> <boost(a)lists.boost.org <mailto:boost@lists.boost.org>> wrote: >> >> On 03/21/17 12:54, Andrey Davydov via Boost wrote: >> >> On Tue, Mar 21, 2017 at 12:00 PM, Richard Hodges >> <hodges.r(a)gmail.com <mailto:hodges.r@gmail.com>> wrote: >> >> What is required, more than simply creating a type-erased >> deleter? >> >> >> Also deleter must capture pointer, because pointer which was >> passed to >> constructor can differ from the pointer which will be deleted. >> For example, >> >> struct Base { /* ... */ }; >> struct Derived : Base { /* ... */ }; >> >> ptr<Derived> p1(new Derived); >> void * raw_p1 = p1.get(); >> ptr<Base> p2 = std::move(p1); >> void * raw_p2 = p2.get(); >> assert(raw_p1 != raw_p2); >> >> >> The above piece of code strikes me as very unsafe and better be >> avoided in the first place. Designing new tools to handle this case >> is IMHO misguided. >> >> Why this code is very unsafe? If change `ptr` to `shared_ptr` this will >> become perfectly valid and widely used pattern. > > Because comparing the void pointers is not safe in general. The above > code in particular will probably work (although not sure if even that's > guaranteed, depending on whether Base and Derived qualify as standard > layout classes), but if the class hierarchy is different, that code will > silently break. > >> Now, I can understand the need to perform casts on smart-pointers, >> but they should still provide some level of safety, at least the >> same level that is provided by pointer casts in the core language. >> But supporting casts should not require a new smart-pointer. And >> indeed it doesn't: >> >> template< typename U, typename T, typename D > >> std::unique_ptr< U, D > static_pointer_cast( >> std::unique_ptr< T, D >&& p) >> { >> D d = p.get_deleter(); >> return std::unique_ptr< U, D >( >> static_cast< U* >(p.release()), >> std::move(d)); >> } >> >> What is `D`? If it is std::default_delete<T> then function result type >> will be std::unique_ptr<U, std::default_delete<T>> and unlikely this >> type is very useful (even if it compiles). > > Ok, that won't work with std::default_delete<T>. But it will work with > this deleter: > > struct static_polymorphic_deleter > { > template< typename T > > void operator() (T* p) const noexcept > { > std::default_delete<T>()(p); > } > }; > > And it should work with a runtime polymorphic deleter that can be > written to implement your proposal (see below). > >> The other part of your proposal, which is polymorphic behavior with >> a deleter knowing the type to call the destructor on, can be solved >> by a custom deleter. I'm not sure a generalized version of such >> deleter would have a large demand, given that there is the >> alternative TONGARI J suggested, but I'm not opposed to a proposal. >> >> May be I doesn't understand what TONGARI J suggested, but >> how can `unique_ptr<T, void(*)(T*)>` hold stateful deleter? > > It doesn't, unless the required state is contained within the object > itself. But just to implement runtime polymorphism, no additional state > is required. > > struct base > { > protected: > ~base() = default; > }; > > struct derived : base > { > }; > > template< typename T > > void poly_deleter(base* p) noexcept > { > delete static_cast< T* >(p); > } > > template< typename T > > using poly_unique_ptr = std::unique_ptr< T, void(*)(base*) >; > > template< typename T > > poly_unique_ptr< T > make_poly_unique() > { > T* p = new T(); > return poly_unique_ptr< T >{ p, &poly_deleter< T > }; > } > > poly_unique_ptr< derived > pd1 = make_poly_unique< derived >(); > poly_unique_ptr< base > pb1 = std::move(pd1); > poly_unique_ptr< derived > pd2 = > static_pointer_cast< derived >(std::move(pb1)); > > But, of course, nothing stops you from saving the state in the deleter. > > struct poly_deleter > { > template< typename T > > poly_deleter(T* p) : m_p(p), m_delete(&poly_deleter::do_delete< T >) > { > } > > void operator() (void*) const noexcept > { > m_delete(m_p); > } > > private: > template< typename T > > static void do_delete(void* p) noexcept > { > delete static_cast< T* >(p); > } > > void* m_p; > void (*m_delete)(void*); > }; > > This will work even if you form std::unique_ptr<void, poly_deleter> > (i.e. don't have a universal base class). >

1 0

Problem with using matrix library with unit test library
by SHIVAM MITTAL 21 Mar '17

21 Mar '17

Hi everyone, I have been developing something, and basically it requires the two boost libraries - the matrix library and unit test library. I have a file test.cpp : #include <boost/numeric/ublas/matrix.hpp> #include <boost/numeric/ublas/io.hpp> #include <boost/test/included/unit_test.hpp> #define BOOST_TEST_DYN_LINK #define BOOST_TEST_MODULE test BOOST_AUTO_TEST_SUITE(Integer_matrices) BOOST_AUTO_TEST_CASE(Constructors) { BOOST_CHECK(2 == 2); } BOOST_AUTO_TEST_SUITE_END() I am compiling this with: g++ -I <path to boost_1_63_0> test.cpp I'm getting the following error: /tmp/ccnxRzsf.o: In function `main': test.cpp:(.text+0x18aa1): undefined reference to `init_unit_test_suite(int, char**)' collect2: error: ld returned 1 exit status Any help will be greatly appreciated. Thanks.

2 1

[Convert] std::isspace requires unsigned #28
by Olaf van der Spek 21 Mar '17

21 Mar '17

Hi, > boost\convert\base.hpp(112): warning C6330: 'const char' passed as _Param_(1) when 'unsigned char' is required in call to 'isspace'. > boost\convert\base.hpp(115): warning C6330: 'const char' passed as _Param_(1) when 'unsigned char' is required in call to 'isspace'. https://github.com/boostorg/convert/issues/28 IMO the code should be fixed and it's not a documentation issue. What do you think? -- Olaf

6 17

Re: [boost] [release] 1.64.0 Delayed because of Microsoft (version numbers)
by Tom Kent 20 Mar '17

20 Mar '17

Sorry all, I meant to send this to the list but only replied to Daniel. This adds an option 4 and 5. On Sun, Mar 19, 2017 at 3:58 PM, Tom Kent <lists(a)teeks99.com> wrote: > > > On Sun, Mar 19, 2017 at 10:17 AM, Daniel James <dnljms(a)gmail.com> wrote: > >> On 19 March 2017 at 13:10, Tom Kent via Boost <boost(a)lists.boost.org> >> wrote: >> > >> > Option 1 - 14.10 Use microsoft toolset version based on cl.exe version >> -5. >> > This is the official version of the c++ toolset that microsoft has been >> > pushing (somewhere). The new $(VCToolsVersion) macro is "14.10.25017", >> this >> > macro is not available in previous versions of visual studio. >> > >> > build bootstrap would use bootstrap.bat vc1410 >> >> [snip] >> >> > Option 2 - 14.1 Use the abbreviated toolset version that microsoft uses >> for >> > their toolset version. The $(PlatformToolsetVersion) macro is "141". In >> > VS2015 this was "140". >> >> [snip] >> >> > I *think* that is all the reasonable options. Let the consensus form! >> >> I disagree, I think we should limit ourselves to values that Microsoft >> actually uses. As far as I'm aware, they don't use 1410, and they >> don't use 14.1. There are already too many ways of writing the version >> number, adding more will just add to the confusion. >> > > So 2-a would meet these requirements. However, I did overlook the mixed > options: > > Option 4 (141 and 14.10) - > build bootstrap would use bootstrap.bat vc141 > build of source would use b2 toolset=msvc-14.10 > build would generat libraries of the format libboost_NAME_vc141-OPTIONS-1_ > 64.lib > config would auto-link libraries of the same format > (4-a is the same as 2-a) > > Option 5 (1410 and 14.1) - > build bootstrap would use bootstrap.bat vc1410 > build of source would use b2 toolset=msvc-14.1 > build would generat libraries of the format libboost_NAME_vc1410-OPTIONS- > 1_64.lib > config would auto-link libraries of the same format > (5-a is the same as 1-a) > > Tom > >

1 0

About all these metaprogramming libraries
by Louis Dionne 20 Mar '17

20 Mar '17

Dear Boost, We've seen two metaprogramming libraries ask for a formal review on the list recently. I expect a third (Brigand) might join the party soon, and maybe even a fourth (Eric Niebler's meta). I think it would be wise to have a plan for how we're going to deal with this. Before going further, I'd also like to clear something out. Some people have asked whether "classic" metaprogramming libraries still had their place given that we now have Hana. As the author of Hana, I think the answer is yes. While Hana is (IMHO) easier to use and more powerful, it also has an important shortcoming. Hana is too slow when dealing with very large inputs. This is due to the fact that it can also handle values, which is much heavier than dealing with types only. This can be alleviated to some extent, but the truth is that our execution model (the compiler) simply has to do more work when handling values. Hence, I think Boost does need a modern classic TMP library to handle these cases where a library writer needs to handle gigantic type lists. I think marketing such a library as an advanced tool for library writers would be a service to the overall C++ community, but that's an orthogonal concern. However, Boost needs one such library, not four. I think we can't just do 4 reviews and include all the libraries that pass in Boost; that would be a huge disservice to our users, who will be left with the burden of choosing. Heck, if we can't even make our mind, how can they? So, how do we pick? Have we ever been in a similar situation where we have multiple competing libraries solving _exactly_ the same problem? Louis -- View this message in context: http://boost.2283326.n4.nabble.com/About-all-these-metaprogramming-librarie… Sent from the Boost - Dev mailing list archive at Nabble.com.

16 39

Newcomer Contributor to Boost C++ Libraries
by Aman Gupta 20 Mar '17

20 Mar '17

Hello everyone, I am Aman Kumar Gupta, an undergraduate 1st year student from International Institute of Information Technology, Bhubaneswar, India. I'm a newcomer to Boost C++ community. I have ,what i think, medium to good C++ coding background as i've been coding in C++ since past 5-6 years and have won some coding competitions as well. I have a good C++ STL knowledge and am very keen and interested in contributing to Boost's STL libraries. But as i'm a newbie to this community, i'm little confused where and how to start. I would be very glad and thankful if anyone would please help me and guide me through.

2 1

Re: [boost] [gsoc17]The implement of Programming competency test From Ruoyun Jing
by Ruoyun Jing 20 Mar '17

20 Mar '17

Hi Vissarion, 2017-03-20 20:29 GMT+08:00 Vissarion Fisikopoulos <fisikop(a)gmail.com>: > Hi Ruoyun, > > > - The main work I should do during GSoC about project 1 is just to > improve > > the algorithms of compare two distances of two point pairs or try to > > consider different situations which used compare distance predicates to > > avoid calculation? > > the project is about algorithms that does not compute the actual distance > but an approximation (as rough as possible) that suffices to accurately > compare the lengths of two geodesic segments on the ellipsoid > > Thanks for your answer, I have the correct point of these project and will continue to write my proposal. > > - Do "In some algorithms there is the need to compare two distances of > two > > point pairs" this means compare two points distances on Earth? Or on > every > > ellipsoid model? > > the later (see answer above) > > > - Do I need to find the approaches of filter by myself? Could you please > > help me get more information about these? Like the implement detail about > > the predicate compare_distance function, mathematical calculation papers > > about compare distance on ellipsoid? > > Well we give one approach on the website (there is another proposal of > another > candidate on the list). My opinion is that if you understand these > approaches > (pos and cons, differences etc) that will help you towards a solid > application. > Having another idea for an approach will definitely strengthen you > application. > Thanks for your help. I can get the point of those approaches and will try to have new ideas. :) > > - In my view, just like compute the shortest distance between two given > > points on Earth, the background approach can be used. And I used > cartisian > > coordinate to avoid many trigonometric function calculation, but I can > not > > find more improve with my lacking knowledge, could you give me some > aspects > > to get more approaches? > > Please see answer above > > At this point I think it is better to jump to boost list because our > discussion > could interest more people. I will not copy anything of our private > conversation > there but feel free to do the jump and I will continue answering there. > > Btw, any news from you test and comparison with Boost.Geometry. > > I reply you and jump to boost with your advice. Hope this will help more people. :) Vissarion > > ps. you can send questions whenever you want, I will answer them a.s.a.p. > my zone is UTC+2 > > Thanks for your answer. Best regards. Ruoyun -- Northwest University of China Software Engineering jingry0321(a)gmail.com <jingry0321(a)163.com>

1 0

Re: [boost] [geometry] [gsoc17] boost.geometry
by Vissarion Fisikopoulos 20 Mar '17

20 Mar '17

Hi Aman, thanks for your interest in Boost.Geometry and projects 1, 3 in particular. Do you have particular preference between 1 and 3? I think you should specify in your application. Regarding you idea, indeed that could be an option. Do you expect that would be faster or more accurate than the one proposed in the boost GSoC ideas webpage? How would you compare the two approaches? To be clear, I am not testing you but answering that questions could lead to a stronger application. Regarding application there are two options, either you do the competency test or you send a link of a project of you. Please read https://svn.boost.org/trac/boost/wiki/SoC2017 (and links therein) also for details on how to proceed, that is on how to write your proposal. Best, Vissarion. ps. I copy to the boost list for potential feedback from the community On 20 March 2017 at 13:07, Aman Gupta via Geometry <geometry(a)lists.boost.org > wrote: > Respected sir/ma'am > I, Aman Gupta, want to contribute in Boost.Geometry; mainly in Project 1(Filtering > of compare distance predicates) and Project 3( Nearly antipodal points > distance accuracy improvement) . > I have good knowledge in geometry and want to learn more . > > For the problem given in Project 1, another approach I can suggest is to > get 2 intersections of plane (which would be ellipse) with the help given > points and compute the respective distances using those ellipses. > > I hope to get selected for the project work. > > Thanking You. > AMAN GUPTA > resume: https://drive.google.com/open?id=0B9HCqOWnVVvDcm9PQkYtczFjVmM > > _______________________________________________ > Geometry mailing list > Geometry(a)lists.boost.org > http://lists.boost.org/mailman/listinfo.cgi/geometry > >

1 0