- Boost - lists.preview.boost.org

[GSOC] Are we going to participate?
by Antony Polukhin 02 May '13

02 May '13

Hi all, Today starts Google Summer of Code. Is Boost community will become one of the mentoring organizations? What project ideas are we proposing? (As for me, I'd love to see unique_ptr+unique_array implemented using Boost.Move; C++11 features support for MPL, Fusion, Graph, Bind, Optional; BTree library; library for getting system info) -- Best regards, Antony Polukhin

16 24

[Log] Plans to use std::thread?
by Rich E 01 May '13

01 May '13

Hi all, As I've been testing out the newly added Boost.Log library, I noticed it is relying on Boost.Thread even when the C++11 <thread> library is present. Are there any plans to allow the native <thread> library to be used when it is available? I think this can be done with Boost.Config's BOOST_NO_CXX11_HDR_THREAD macro. Thanks, Rich

2 2

Re: [boost] GSoC Boost.Multiprecision project
by Jyotesh Choudhari 01 May '13

01 May '13

Hello, > Hi Jyotesh. >>>> Looking at the project description, I think >>>> I have understood what needs to be implemented >>>> in this project. > Yes, you seem to have a good grasp of the issues. > Good work. >>>> I have also gone through the current >>>> code cpp_bin_float.hpp and I have understood some >>>> part of it. I want to know how >>>> detailed should my proposal be? What details >>>> should I include in my proposal? >>>> What should be the deliverables for the project? > Go ahead and add some details from cpp_bin_float > if you like. You can mention that this is a potential > solution method. Thank you for your valuable feedback. I have written project proposal for the first time in my life. So, I did not know what details to include. I have made some changes to my proposal as per your suggestions. > Other than that, I believe you have found > the right level of detail, with a few more suggestions > from my side below. >> I have attached my proposal with this mail. >> Please have a look at it and let me know your feedback. >> Thanks and regards, > I suggest you move the FFT algorithms to an optional > part, add a bit more time for the elementary transcendental > functions, and add some time for testing the various > milestones in the project. > After that, you should start submitting your proposal. > As far as I know, you can modify your proposal up > to May 03. I have written FFT algorithm as an optional algorithm now and made some changes to schedule. Please let me know if it is fine now. > Keep up the good work. > Sincerely, Chris I was studying the code for cpp_bin_float and I have some doubts in my mind. 1. What are eval_ops_signed_type, eval_ops_unsigned_type and eval_ops_float_type? 2. What is the use of following lines? typedef mpl::list<eval_ops_signed_type> signed_types; typedef mpl::list<eval_ops_unsigned_type> unsigned_types; typedef mpl::list<eval_ops_float_type> float_types; These are not used in the class elsewhere. Similar lines are present in cpp_dec_float.hpp also and not used elsewhere in the class. 3. In the function from_float_type, I think the variable number_of_digits should be initialized to zero before using it in while loop. Lastly, I have seen on mailing list, that some of the students are submitting code samples. As I am busy with my end-semester exams and R&D project, I am not able to send any sample code. As soon as I get free, I will send it. Thanks and regards, Jyotesh Choudhari

2 1

[gsoc-13][proposal] Boost.uBLAS
by Aditya Avinash 01 May '13

01 May '13

Hi, I have a proposal for boost in gsoc-13 under boost.ublas *Proposal: SIMD abstraction for uBlas.* - I want to develop SIMD abstraction for uBlas. Goal 1: Develop the Intel SSE & AVX backend for SIMD abstraction in uBLAS. Goal 2: Develop AMD SSE backend for SIMD abstraction in uBLAS. Goal 3: Develop frontend for SIMD abstraction in C++. Goal 4: Joining of frontend and backend, so the the code is flexible to implement on both AMD and INTEL. Goal 5: Develop the ARM-NEON backend for SIMD abstraction in uBLAS. (if time permits). -- ---------------- Atluri Aditya Avinash, India.

2 3

Re: [boost] [gsoc-2013] Boost.Thread/ThreadPool project
by Niall Douglas 01 May '13

01 May '13

> Le 29/04/13 21:35, Niall Douglas a ?crit : > > No major changes to the C++11 futures API is needed. Rather that a > > different, but compatible, optimized implementation of future<> gets > > returned when used from a central asynchronous dispatcher. So the C++ > > standard remains in force, only the underlying implementation is more > > optimal. > > Could you explain me what a central asynchronous dispatcher is? An asynchronous procedure call implementation. Here's Microsoft's: http://msdn.microsoft.com/en-us/library/windows/desktop/ms681951(v=vs.85).as px. Here's QNX's: http://www.qnx.com/developers/articles/article_870_1.html. Boost.ASIO is the same thing for Boost and C++ but implemented by application code. It is *not* like asynchronous POSIX signals which are a nearly useless subset of APCs. > If not, please could you elaborate what kind of optimizations can be > obtained? If you have transactional memory in particular, you gain multi-CAS and the ability to (un)lock large ranges of CAS locks atomically, and a central dispatcher design can create batch lists of threading primitive operations and execute the batch at once as a transaction. Without TM, you really need the kernel to provide a batch syscall for threading primitives to see large performance gains. > > Futures come in because you'd naturally use std::packaged_task<> with > > Boost.ASIO. It returns a future. > Could you point me to the Networking paper proposal that has > packaged_task<> on its user interface. I would expect this to be an > implementation detail. You misunderstand me. *If* you want Boost.ASIO to dispatch unknown std::function<>, *then* std::packaged_task<> is the most obvious route forwards. And the correct way to pass a value from one execution context to another is std::future<>. This includes the single threaded case e.g. when going through a C++ -> C -> C++ transition as a stack unwinds. > > For reference, the AFSIO/AFIO project is *not* a threadpool. It's a batch > > asynchronous execution engine based on Boost.ASIO that lets you chain, in > > vast numbers, huge arrays of std::function<> whose returns are fetched using > > std::future<> to be executed asynchronously according to specified > > dependencies e.g. if A and B and C, then D, then E-G. That sort of thing. > So the thread pool you need is an internal one that is adapted to you > particular needs, isn't it? I think you don't understand what Boost.ASIO is or how it works. Boost.ASIO's core is boost::asio::io_service. That is its dispatcher implementation which each dispatch execution context being executed via boost::asio::io_service::run() which is effectively an event loop. Third parties then enqueue items to be dispatched using boost::asio::io_service::post(). You don't have to run Boost.ASIO using multiple threads: it can be single threaded. So is my thread pool an internal one adapted to my particular needs? In the sense I need not use threads at all, yes. In the sense that boost::asio::io_service's use scenario is inviolate, no. Boost.ASIO has its API, and you have to use it. And Boost.ASIO's API will be similar to the TR2 networking API. There is nothing stopping a person merging a Boost.ASIO managed thread pool with a traditional thread pool. I would struggle to see the use case though - this would an excellent thought project actually which would benefit any Boost.ThreadPool. > > One thing presently implemented on that engine is asynchronous file i/o, but > > in the next month or two you'll hopefully see batch parallel SHA256 using > > 4-SHA256 SSE2 and NEON implementations also added to the asynchronous > > engine. The idea is that the engine is fairly generic for anywhere where you > > do need to chain lots of coroutine type items together (not that it supports > > Boost.Coroutine yet). v1 isn't particularly generic nor optimal, but I'm > > hoping with feedback from Boost that v2 in a few years' time would be much > > improved. > > > As Oliver noted you could take a look at Boost.Fiber and Boost.Task. Right now anything Boost.Context based can't have multiple contexts simultaneously entering the kernel apart from on QNX and possibly Hurd. Therefore, for the time being, full fat threads are the only thing being considered. If kernel support ever includes coroutines or fibres, that will be eagerly added (I like coroutines, I use them a lot on Python). Note that on async i/o capable platforms multiple threads are solely used for non-async APIs like batch directory creation and batch chmod. Normal i/o gets multiplexed using completion handlers. Currently on Windows for example, threads are barely used at all. Niall --- Opinions expressed here are my own and do not necessarily represent those of BlackBerry Inc.

3 2

Re: [boost] [operators] moving forward use return by reference for compilers with proper support?
by Andrew Ho 01 May '13

01 May '13

> They do NOT apply to this scenario: > > X&& func(X&& x) { return std::move(x); } > const X& r3 = func(temporary()); // DANGLING REFERENCE > X&& r4 = func(temporary()); // DANGLING REFERENCE Hmm, I see. sub-clause of 12.2 clause 5: > The lifetime of a temporary bound to the returned value in a function return statement (6.6.3) is not extended; the temporary is destroyed at the end of the full-expression in the return statement. I presume there must be some implementation detail on why a returned temporaries' lifetime can't be extended. Too bad, looks like return by value is the best option available.

1 0

[operators] moving forward use return by reference for compilers with proper support?
by Andrew Ho 01 May '13

01 May '13

Following some feedback I got from MS about the disparity between VS2012 and GCC/Clang in how some the lifetimes of temporaries are handled, it appears that going forward (possibly C++14) overloading operators in the same fashion as Dfrey operators should be safe. For reference, these overloads for a single argument commutative operator are: T operator OP(const T&, const T&); T&& operator OP( T&& lhs, const T& rhs); T&& operator OP( const T& lhs, T&& rhs); T&& operator OP( T&& lhs, T&& rhs); They referred me to http://www.open- std.org/jtc1/sc22/wg21/docs/papers/2012/n3337.pdf (draft of C++ standard), which in section 12.2, clause 5 says that a temporary's lifetime is extended to the lifetime of the reference it is bound to. I checked draft n3376 (latest publicly available draft as of today), and the same clause was present. This is the current behavior in VS2012 and it's likely that future compilers will support this as well. Should we start tracking which compilers do exhibit this behavior in Boost.Config and use the return by rvalue ref code if proper compiler support is available? I know these are just working drafts and can change in the future, but I can't think of a reason why they would remove this clause from the C++14 standard, or of any test cases which would cause a program to fail assuming this clause is properly implemented. We'll have to provide an implementation which supports return by value as well for compilers which don't support this clause, and possibly a third implementation for compilers which don't support move semantics at all, though I have demonstrated that Boost.Move can be used to merge these latter cases.

2 1

GSoC 2013
by Anoop C S 30 Apr '13

30 Apr '13

I wish to participate in GSoC 2013 along with the Boost C++ libraries. I plan to take up the problem of Unified Representation of Vector and Matrix into a unique matrix class. Which of the Boost libraries are to be studied thoroughly inorder to achieve the goal. I already started reading Boost Documentation.

2 1

[GSoC 2013] Boost.Math Bernoulli Numbers and Applications to Special Functions
by Łukasz Marecik 30 Apr '13

30 Apr '13

Hi, My name is Lukasz Marecik, I am fifth year student of Mathematics and fourth year student of Computer Science at Warsaw University. I would like to apply to Google Summer of Code 2013 project. I am interested in Bernoulli Numbers and their applications. While thinking about this project and doing some research, I collected some questions and issues, which I would like to discuss with my (potential) mentors. The answers can have strong influence at my official proposal. 1. Is (one of) the goal of this project to implement FROM SCRATCH completely new boost library, which will calculate Bernoulli Numbers ? I have already found two great C++ open-source programs: - http://www.bernoulli.org/ - http://web.maths.unsw.edu.au/~davidharvey/papers/bernmm/ They are already extremely efficient and fast (the funny thing is that they use completely different approach). Can boost project include and adapt one of them ? Why not ? 2. Are we going to implement only precise calculation of Bernoulli numbers or also Bernoulli numbers modulo p (where p is prime) ? 3. How the implementation of method of computing Bernoulli numbers will look like? Will it be a big template which works with all (reasonable) types (built-in, multiprecision) in the same way ? I was thinking for a while about this and I think it would be better to implement separately computing rational Bernoulli numbers (e.g. gmp_rational type) in a modern way: compute B_n modulo a lot of small primes and then reconstruct B_n via Chinese Remainder Theorem. This algorithm is one of the faster for this concrete type: precise rational numbers, but (in my opinion) it will be inefficient, when we want the output be built-in types. I do not know if I express precise what I want. For example: naive Akiyama–Tanigawa algorithm does not assume the type of output: the calculation can be performed at any type. Will our library work with all types in the same manner, or will our library run different algorithms and choose which one is better in this concrete case ? 4. Do I need to make my own research, reads papers about Bernoulli numbers, find the best practical algorithm and then propose it to my mentor or my mentor will help me to find and choose algorithm ? (so: Can I rely on myself only ?). Until now I have found three interesting approach: - use Chinese Remainder Theorem (described above) - use Euler's formula and the zeta-function algorithm - use completely new subquadratic algorithm (the paper was "submitted to publication", but it was not published in magazine until now ; it is online) The first two of them all already implemented and work (I think) in O(n^(2+eps)) time (it is good to mention that we need \theta(n log n) bits to represent precise number). The third one had (asymptotically) better complexity, but it goes throw a lot of complicated Maths, p-adic numbers etc and it has been not implemented yet - so it can turn out that the constant hidden in Big O notation is so big, that it is unpractical. But who knows. Do I need to discuss in my proposal different approach ? 5. Do I need to include in my proposal some words about applications to boost function: - theoretical view: where bernoulli numbers appear - practical view: how those functions are implemented now and how there will be implemented - and why they will be better ? I am sorry, that I am writing so late, but I was not sure for a long time if I want to apply ; I hope I finish my proposal in time. Kind regards, Lukasz Marecik

2 1

[type_traits] boost::decay vs std::decay
by Agustín K-ballo Bergé 30 Apr '13

30 Apr '13

Hello, It has been pointed out before that `boost::decay` and `std::decay` are not exactly the same. The standard does remove CV qualifiers while boost doesn't. See https://svn.boost.org/trac/boost/ticket/7760 I would like to know if there is a resolution on this issue. If the difference is intentional, then I suggest a note be added to the documentation. I could prepare a patch either way. Regards, -- Agustín K-ballo Bergé.- http://talesofcpp.fusionfenix.com

1 0