- Boost - lists.boost.org

Re: [boost] GSoC proposal
by Vissarion Fisikopoulos 22 Mar '17

22 Mar '17

Hi Rasul, thanks for your interest in Boost.Geometry. I guess you have already read this https://svn.boost.org/trac/boost/wiki/SoC2017 There are two possibilities: either you provide a library (with some standards described in the webpage) or you do the test. My opinion is that doing the test (even if not needed) will first strengthen your application and second will give you a good overview of the problem you are going to work on, if selected. >From your repo what is the library that you propose for your application and meets the requirements described in the webpage above (e.g. no coursework, more than 6 months old etc)? The tests are described here: https://svn.boost.org/trac/boost/wiki/SoC2017#a3.Boost.Geometry Depending on what (?) project you prefer to pursue there is a corresponding test. Best, Vissarion ps. I copy the message to boost list so the community can follow and provide feedback if needed On 22 March 2017 at 12:00, Rasul Kerimov <rkerimov(a)std.qu.edu.az> wrote: > Hey Mr. Fysikopoulos, > > I'm really interested in Boost GSoC 2017 project proposal, but I don't > know how to pass Programming competency Test. > > I have a github repo with all my codes that I wrote in C++, but I > don't know if it's enough to pass test. > > Github page: https://github.com/CoderINusE/ > Github repo: https://github.com/CoderINusE/Algorithms-data-structues > > I will be grateful for any response. Thank you!

1 0

[release] 1.64.0 Delayed because of Microsoft (version numbers)
by Rene Rivera 21 Mar '17

21 Mar '17

Sorry to say the beta release of 1.64.0 is hereby going to be delayed for at least another week. The confusion of VS2017 version numbers and the communities inability to address this issue after the beta is to blame. To address the situation the beta release will be published when one of the two tasks below are completed: (A) Boost Config changes to use 1410 as the autolink version to match what the currently working generated libs are taggeg with. Or: (B) The community decides what version number we should be using and the appropriate PRs are filed and applied and tested for all the repos involved. Which means: 1. The community has until 12:00 CDT US March 18 to decide on what the vc version number and tag should be. 2. The community must post PRs for the places where we reference VS2017 version numbers to the new number. Those are at least: <https://github.com/boostorg/config> <https://github.com/boostorg/build> <https://github.com/boostorg/boost> <https://github.com/boostorg/website> People have until 17:00 CDT Monday March 20 to submit those PRs. 3. The community can test the resulting master snapshot when available at the latest 24:00 Monday March 20. 4. If all goes well we can have a beta release on Wednesday March 22 (ie one week late). -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

17 26

[stacktrace] Review
by Peter Dimov 21 Mar '17

21 Mar '17

I think that the Stacktrace library should be ACCEPTED. The design is good. It's unfortunate that to get a stacktrace class that stores the capture internally in a fixed-size array, as the first iteration did, one has to write a special allocator, more so because such an allocator isn't readily available (we don't have one in Boost, for instance). This could easily be addressed by templating basic_stacktrace on a container (default std::vector<frame>) instead, which would allow boost::container::static_vector to be used. The implementation is good. The main problem here, as already discussed in detail, is that under Windows clients of the library that don't make use of the facilities that require windows.h and COM headers to be included still suffer the penalty of this inclusion. Fixing this will be a significant increase in usability. The documentation is adequate, although it could use some editing by a native speaker. The library is potentially very useful. Assert handlers, exceptions and termination handlers can (and should) all make use of it. Wide use under Windows is however hampered by the limitation described above. I tested the library under Windows with msvc-14.0, 14.1, Cygwin g++/clang++. Under Cygwin there is no libbacktrace, but defining BOOST_STACKTRACE_USE_ADDR2LINE worked. I invested a fair chunk of time into my evaluation of the library, and am reasonably knowledgeable about the problem domain.

1 0

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

21 Mar '17

On Tue, Mar 21, 2017 at 4:11 PM, Andrey Semashev <andrey.semashev(a)gmail.com> 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. I agree, I wrote this code just to demonstrate that deleter must capture pointer because it can be changed due to upcasting. > 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). > Your poly_deleter implementation is the same as I used inside my smart pointer implementation, but there is an issue with std::unique_ptr<T, poly_deleter>, namely it is not constructible from std::unique_ptr<T, std::default_delete<T>> because poly_deleter must capture pointer and so it is not constructible from std::default_delete. -- Andrey Davydov

4 5

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

21 Mar '17

It is widely known that deleter type is part of std::unique_ptr type. It is the most effective decision, but sometimes not very convenient. The most important use cases (for me) when std::unique_ptr<T, std::default_delete<T>> doesn't work are following: 1. unique_ptr to incomplete class struct MyClass; unique_ptr<MyClass> create(); auto ptr = create(); // compilation error 2. upcast to base without polymorphic destructor struct Base { // ... // no virtual ~Base() here }; struct Derived : Base { // ... }; unique_ptr<Base> ptr = make_unique<Derived>(); // compiles by leaks! 3. unique_ptr with non-default deleter unique_ptr<FILE, int (FILE *)> open_file(std::string const & path) // works but looks ugly, why should the fact that fclose returns `int` be visible from the signature of the function `open_path`? { return { std::fopen(path, "r"), &std::fclose }; } Of course, all this examples could be fixed if unique_ptr would be replaced by shared_ptr, but the semantic of the shared ownership is not desirable often. I have implemented smart pointer with semantics of unique ownership and type erased deleter (https://github.com/AndreyG/unnamed) It has size of 3 pointers and it doesn't require additional memory allocations for the case when deleter is empty class (for example, std::default_delete or non-capturing lambda) and for the case when deleter is known at compile time function (for instance, fclose). The are some simple examples of usage and tests in the repo. Why don't just use unique_ptr<T, function<void (void *>>? The main reason is that due to the small object optimization std::function has rather big size. For instance, sizeof(unique_ptr<T, function<void (void *>>) == 72 for MSVC x64! Results for the other platforms can be found in the repo README. Does it seem useful? -- Andrey Davydov

5 11

[GSOC17] Regarding project Boost.uBLAS
by SHIVAM MITTAL 21 Mar '17

21 Mar '17

Hi, I am *Shivam Mittal*, a sophomore student of *Computer Science & Engineering *discipline of *Indian Institute of Technology, Ropar, India.* I wish to contribute to *Boost.uBLAS*, and develop cool and useful things with the community in GSOC 17. While going through the ideas list, I found the project *Data.Frames in boost.uBlas *very interesting and suitable for me. I think I am well prepared for the task as described in the requirement section. I am very comfortable in C/C++ and fairly comfortable in MATLAB, Python, HTML, CSS, PHP, SQL. I have more than 6 years of experience coding in C++. I have been developing data structures, algorithms, hardware simulators, artificial intelligence programs, and miscellaneous things in C++. The coursework (relevant to this project) which I have completed is : 1. Introduction to computing (in C++) 2. Data structures (in C++) 3. Linear Algebra Some of my selected projects are uploaded on github: https://github.com/shivam5 Please have a look at them. Some projects which I have implemented in C++ are: 1. Simple_RISC plagiarism checker 2. Simple_RISC functional and pipeline simulator 3. Pattern matching system by implementing hash tables. 4. Implementing graphs 5. Implementing AVL and Red black trees 6. Solcvng combinatorial auctions 7. Room booking system 8. Sudoku Solver I have implemented the programming competency test and sent the mentor on personal mail. Can you guide me further on how should I proceed and increase my chances of getting selected. Thank You, Shivam Mittal B.Tech Computer Science & Engineering, IInd Year Indian Institute of Technology Ropar Phone: +91-9888927245, +91-9899461223

1 0

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