- Boost - lists.preview.boost.org

[reference_wrapper] Overloading operator() in reference_wrapper
by Nathan Crookston 02 May '13

02 May '13

Hi all, std::reference_wrapper includes an overload of operator()[1] which allows a wrapped function object to be called without needing to first unwrap: #include <boost/ref.hpp> #include <functional> #include <iostream> int main() { auto f = [](int i) { std::cout << i * 2 << std::endl; }; std::ref(f)(5);//change this to boost::ref and it will not compile. } I think it would be valuable to update boost::ref to match the standard version. On compilers which support variadic templates and rvalue references the code is obvious. Those which support one or neither could still have overloads for some number of arguments. This would be handy in a few places, notably boost::gil::for_each_pixel[2]. I know that boost::bind + reference wrapper could be used instead (boost::bind(boost::ref(f), 5)). Given that implementing operator() is relatively simple, and that the standard object based on boost::reference_wrapper has it (rather than requiring std::bind), I'd argue that this change is desirable. Thanks, Nate [1] http://en.cppreference.com/w/cpp/utility/functional/reference_wrapper/opera… [2]http://comments.gmane.org/gmane.comp.lang.c%2B%2B.isocpp.general/513

6 9

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

02 May '13

> Le 01/05/13 20:39, Niall Douglas a ?crit : > >> I don't see the term "central asynchronous dispatcher" used in any of > >> the links. Could you clarify what it is? > > I have to admit I'm struggling to see where your block is, but Dave Abrahams > > often found the same with me, so it must be me. > It is just that I don't know the term. > As I don't know the domain (the words) you are talking about we can stop > the exchange here if you prefer, or you could continue to explaining me > the things I don't know/understand. Don't worry, it's almost certainly me as native English speakers rarely understand me either. Besides when I lived in Spain I remember only too well the problem with domain terminology, like when a dentist told me I had a "del gasto" which I took to him wanting money because he had high rent :). I'll keep going as long as you need. We'll get there eventually. > > The central means one execution context does the dispatch. The asynchronous > > means that callbacks are processed by recipients asynchronous to the > > dispatcher. And dispatcher, well that dispatches. > In order to be sure I understand what you say could you tell me how a > decentralized asynchronous dispatcher behaves? What are the differences? A centralized dispatcher dispatches from one execution context to many. A decentralized dispatcher dispatches from many execution contexts to one or more contexts. An example of the latter is cloud apps actually, where millions of apps will dispatch events to a load balanced core cluster of servers i.e. many => few. By execution context I mean a thread, a fibre, a coroutine, a handler or even a closure. Generally if it's got its own distinct stack separate from other stacks, it's an execution context. > > I'd take a reasonable guess that MCAS will benefit centralized kernel-based > > threading primitives architectures such as Windows NT more than > > decentralized threading primitive architectures such as POSIX. That said, I > > could see Linux using TM for batch multi-kernel-futex ops, though I'd have > > to say implementing that without breakage would be daunting. > > > Are you saying that current TM technology should be much more useful for > centralized than decentralized asynchronous dispatchers? I'm saying my suspicion is that. Others on SG5 may disagree (they disagree with me about most of my opinions). It's still very early days for TM in C++. > Does this means that the whole application would improve its > performances using always centralized asynchronous dispatchers? I'm saying it's a likely optimization case. Other than a recompile, application need not know the difference. > > You may find N3562 Executors and schedulers coproposed March 2013 for > > Bristol by Google and Microsoft of use to you in understanding the relation > > between thread pools and Boost.ASIO > > (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3562.pdf) > I know this proposal. Could you explain me how it is related to > Boost.Asio? Could you point me where in the Asio documentation could I > find related information? I think your other post is more relevant, so I'll answer there. But agreed that Asio's documentation assumes the user already understands how it works. If you come from a NT kernel or VMS or libuv programming background, it's obvious. But much less so for everyone else. > > My > > proposed Boost.AFIO library is an implementation of that same N3562 idea, > > albeit I extend Boost.ASIO which is IMHO more C++-y whereas Google and > > Microsoft have gone with proprietary implementations. Also, they include > > timing and many other more general purpose features, and mine does not > > (currently) as it's mainly aimed at maximising input/ouput with highly > > jittery random latency storage. > > > Thanks Niall for all the explanations and sorry if all this is trivial > for you. These types of discussion always add to the collective good. Niall --- Opinions expressed here are my own and do not necessarily represent those of BlackBerry Inc.

1 0

[testing] run.py and cross compilation
by Niall Douglas 02 May '13

02 May '13

> Is there some possibility to compile sources on one platform (x86) and > then run compiled tests on other platform (ARM/Android) using run.py > script? > > This is required, because Android SDK exists only for x86 so there is > no way to compile tests on ARM Android device. I believe we have a related or similar problem with unit testing Boost on BB10. Niall --- Opinions expressed here are my own and do not necessarily represent those of BlackBerry Inc.

1 0

[gsoc2013] Proposal for Boost.Math Bernoulli numbers and special functions project
by Artemy Margaritov 02 May '13

02 May '13

Hi folks! I want to provide my proposal for Boost.Math Bernoulli numbers and special functions poject to the Boost community. Please, lets discuss it! I will be grateful for your advices. -- Best regards, Artemy Margaritov

2 6

Re: [boost] [gsoc-13][proposal] Boost.uBLAS
by Aditya Avinash 02 May '13

02 May '13

On Thu, May 2, 2013 at 1:24 AM, Aditya Avinash <adityaavinash143(a)gmail.com>wrote: > I have updated the proposal. Here it is. > > > On Thu, May 2, 2013 at 1:21 AM, Aditya Avinash <adityaavinash143(a)gmail.com > > wrote: > >> Hi, this is my GSOC 13 proposal on Boost uBLAS. >> >> >> On Wed, May 1, 2013 at 3:15 PM, David Bellot <david.bellot(a)gmail.com>wrote: >> >>> Great. I'm looking forward to it. >>> >>> Best, >>> David >>> >>> >>> On Tue, Apr 30, 2013 at 11:06 PM, Aditya Avinash < >>> adityaavinash143(a)gmail.com >>> > wrote: >>> >>> > I'll upload in 16 hrs. >>> > >>> > On Wed, May 1, 2013 at 2:55 AM, David Bellot <david.bellot(a)gmail.com> >>> > wrote: >>> > >>> > > Hi Aditya, >>> > > >>> > > yes, please send me a written proposal, so that I can help you on >>> that. >>> > > It's definitively something we want to do for ublas. >>> > > >>> > > Best, >>> > > David >>> > > >>> > > >>> > > On Mon, Apr 29, 2013 at 6:56 PM, Aditya Avinash >>> > > <adityaavinash143(a)gmail.com>wrote: >>> > > >>> > > > 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. >>> > > > >>> > > > _______________________________________________ >>> > > > Unsubscribe & other changes: >>> > > > http://lists.boost.org/mailman/listinfo.cgi/boost >>> > > > >>> > > >>> > > _______________________________________________ >>> > > Unsubscribe & other changes: >>> > > http://lists.boost.org/mailman/listinfo.cgi/boost >>> > > >>> > >>> > >>> > >>> > -- >>> > ---------------- >>> > Atluri Aditya Avinash, >>> > India. >>> > >>> > _______________________________________________ >>> > Unsubscribe & other changes: >>> > http://lists.boost.org/mailman/listinfo.cgi/boost >>> > >>> >>> _______________________________________________ >>> Unsubscribe & other changes: >>> http://lists.boost.org/mailman/listinfo.cgi/boost >>> >> >> >> >> -- >> ---------------- >> Atluri Aditya Avinash, >> India. >> > > > > -- > ---------------- > Atluri Aditya Avinash, > India. > -- ---------------- Atluri Aditya Avinash, India.

1 0

[gsoc 2013] draft proposal for chrono::date
by Anurag Kalia 02 May '13

02 May '13

I have prepared a draft proposal for Boost.chrono/date implementation. Could you kindly go through it and tell me of any errors and suggestions? Regards, Anurag Kalia.

3 9

Proposal for Bernoulli numbers
by Gaurav Deshmukh 02 May '13

02 May '13

Mentors for Boost.Math, please review my proposal at the melange site. http://www.google-melange.com/gsoc/proposal/review/google/gsoc2013/gaurav42… Shall I include details about the templates of functions I will have to implement? Or are there any corrections or details needed? Thanking you, Gaurav Deshmukh

1 0

Re: [boost] [GSOC] Are we going to participate?
by Stefan Seefeld 02 May '13

02 May '13

Hi Boris, I just noticed today someone inquiring about Boost.XML as a GSoC project. Being the one who originally suggested that idea almost ten (!) years ago (and who then also implemented a simple sandbox project as a proof-of-concept), I would love to see such a project being successful. Do you think it's still time to work on a proposal ? Where should I register to be an eligible mentor with boost.org ? (I'm already registered with GSoC - my ID is 'stefan'.) Thanks, Stefan -- ...ich hab' noch einen Koffer in Berlin...

2 2

[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

GAL (Generic Audio Library) based on GIL
by Brendon Costa 30 Apr '13

30 Apr '13

I am looking into the possibility of developing a library based on the same concepts and a similar interface to Boost.GIL call Boost.GAL. The idea is simply to define something very similar to GIL but for audio processing instead of image processing. Most of the concepts in GIL map almost 1 to 1 to audio processing as well. What are peoples thoughts on such a project? Is there anything in Boost.GIL that we have learn't from that should be done differently? --- Basic Premise --- The base concepts for GAL are described below and shown are the direct equivalents in the GIL library: * GAL.Sample ~= GIL.Channel Represents the amplitude of a single audio sample (float32, int16, ...) * GAL.SampleTime ~= GIL.Point Identifies the "time" a sample was taken (in units of the SampleRate) * GAL.Channel ~= GIL.Colour Identifies an audio channel location (FRONT_LEFT, or FRONT_RIGHT might be a channel for example) * GAL.ChannelMapping ~= GIL.Colour-space Maps channels to specific layout in memory (offset 0 is FRONT_LEFT, ...) * GAL.Frame ~= GIL.Pixel Identifies a single time slice (multiple channels for single sample point in time) * GAL.Block ~= GIL.Image Identifies a 1D sequence of Frame's * GAL.SampleRate ~= GIL.PPI I don't think GIL has this concept at the moment, but would be similar to Pixels Per Inch in the image world * GAL.Layout ~= GIL.?? This is the same in GIL and GAL the memory layout can be interleaved or not (planar for GIL) * GAL.Format ~= GIL.?? I don't think GIL has this concept at the moment but it represents the format of data without actually storing any data. It contains: - Sample type - ChannelMapping (implicitly identifies count of channels) - SampleRate - Layout

4 6

[Boost.FixedPoint] Choose notation
by Dmitriy Gorbel 30 Apr '13

30 Apr '13

Hello, community! I propose extending the Boost Libraries to provide binary fixed-point arithmetic, within GSOC project. Fixed-point library will provide nonnegative and negatable class templates for fractional arithmetic, and cardinal and integral for integer arithmetic. In total, four class templates. Fixed-point arithmetic use more than one notation, and I want to provide several notation to make happy all. Now I plan to implement two notations - Q notation and notation from C++1y proposal. Examples: C++1y proposal notation: cardinal<16> 0 <= n < 65536 integral<4> -16 < n < 16 nonnegative<8,-4> 0 <= n < 256 in increments of 2^-4 = 1/16 negatable<16,-8> -65536 < n < 65536 in increments of 2^-8 = 1/256 Q notation: cardinal<16> 0 <= n < 65536 integral<4> -16 < n < 16 nonnegative<8, 4> 0 <= n < 256 has 4 bit for fractional part negatable<16, 8> -65536 < n < 65536 has 8 bit for fractional part Please, help me to choose default notation, propose other notation, or just make any feedback. Sincerely, Dmitriy. -- View this message in context: http://boost.2283326.n4.nabble.com/Boost-FixedPoint-Choose-notation-tp46462… Sent from the Boost - Dev mailing list archive at Nabble.com.

8 16

[GSoC 2013] Moving to Boost to Boost.Move
by Vicente J. Botet Escriba 30 Apr '13

30 Apr '13

Hi, In case there are some students that are looking for a last idea. There a re a lot of Boost libraries that don't support move semantics. It would be nice if one student propose to adapt the some of the existing libraries. The idea is to use Boost.Move so that an emulation is provided for compilers not supporting rvalue references. Some of the libraries (let me know if I'm wrong are). My priority is given between [], lower numbers means higher priority. Of course others would have others priorities: C++11 * [0] Tuple or * Fusion/tuple (it seems that it support or will support c++11 move semantics but don't use Boost.Move) * [0] Bind * [1] Function * [2] SmartPtr * [8] Array ? Accepted for C++14 * [5] optional Having an active proposal for C++1y * [3] Heaps * [6] Any * [7] Variant Other * [4] LockFree * [9] Parameters * [10] Signals? Please help me to complete this list. Adding constexpre and noexcept would be welcome also. Best, Vicente

3 4

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

30 Apr '13

> > There are many ways systemically of implementing futures. The way you > > and Anthony have taken to date is a non-intrusive approach such that > > futures stand alone. This is great for not forcing design onto third > > parties and is a decentralised POSIX-y approach, but it comes with > > significant performance and memory costs because it's hard to get > > standalone, non-intrusive futures to batch themselves without > > sacrificing performance. > > I have no merit here. This is the approach the standard has defined futures. 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. > > An alternative approach is to assume a central dispatcher/event loop > > which can optimize then() chaining because it knows of all futures and > > their relationships currently in flight (this is a much more > > centralized statist NT-y approach, and it you can see that philosophy > > clearly in Microsoft's N3428). You can see an example of this approach > > to implementing future chaining with multiple dependencies which > > extends Boost.ASIO in > > https://github.com/ned14/TripleGit/blob/master/triplegit/include/async > > _file_ io.hpp#L785. I also went ahead and implemented N3428's > > when_all() which returns a future chained to multiple input futures, > > not that I claim the implementation mature yet. > > I don't know ASIO enough to understand the advantages or liabilities. > While a central dispatcher/event loop could be useful for some applications > other need more concurrency. > I'll need to take a deep look at ASIO when I would have enough time. I know you'll have studied Microsoft's N3428 in depth. Their proposal is quite trivial to implement when you have an NT kernel to hand where the kernel directly manages all multithreading primitives and there is a top quality APC implementation. Implementing N3428 without a NT kernel to hand is very considerably harder, indeed there are many, many gotchas as I know you know. Even then() is tricky, because code called from then() needs two main call forms, asynchronous and synchronous (i.e. the original object completes only after type B then() completes, whereas type A then() lets the original complete first). Not introducing race conditions is quite hard (for me at least). > > My concern with Boost.ThreadPool right now is that it could get in the > > way of the latter approach. I have zero objection to a formulation > > which embraces both approaches, but when you ask why a thread pool > > isn't in the standard, I think it's because until we've fixed futures > > implementation and all the composibility and chaining we're sure we > > need, and made sure that interops smoothly with the forthcoming TR2 > > networking proposal, then and only then is it wise to proceed with > > threadpool design. > > I'm not aware of the TR2 networking proposal needs respect to futures or > thread pool. Again I'll take a look to the current proposals. Futures come in because you'd naturally use std::packaged_task<> with Boost.ASIO. It returns a future. > > All that said, this is purely a cautious opinion of mine. You're one > > of the Boost.Thread maintainers, so I happily defer to your judgment > > on this. If you think we need a threadpool now, you'll find no > > opposition from me. > > If IIUC you are not suggesting that the student uses the ASIO approach, but that > it is not time to solve the thread_pool now. Could you confirm? > If yes, could you tell me what is blocking that we can not try to solve? We ought to finish N3428 for pure POSIX first. During implementation, you will find many areas where significant optimization using a central dispatcher become possible. Specialisations of N3428 for some arbitrary central dispatcher might be worth prototyping as a thought exercise. After that I see no reason to hesitate on thread_pool as it now has the type inferences available to it to have an optimal design. > I was not aware that there was a AFSIO GSoC project as described here > https://svn.boost.org/trac/boost/wiki/SoC2013#Boost.ASIO and that this > project propose also thread pool. I understand better now your concerns. I hadn't announced it to this list for various reasons. Hopefully I'll have news there soon. 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. 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. Niall --- Opinions expressed here are my own and do not necessarily represent those of BlackBerry Inc.

3 2

[iterator] Is there general const_iterator adaptor?
by TONGARI 30 Apr '13

30 Apr '13

Hi folks, I wonder if there's a general const_iterator adaptor that transforms any iterator to a const one: template<class Iterator> struct const_iterator : iterator_adaptor < const_iterator<Iterator>, Iterator , typename iterator_value<Iterator>::type const > { const_iterator() {} const_iterator(Iterator const& base) : const_iterator::iterator_adaptor_(base) {} }; Which is simple but handy for use in that we don't have to make 2 versions for both const & non-const iterators each time we make a container. Does Boost offer this which I missed somewhere, or would you think it's a good idea to add? Thanks

3 5

GSOC 2013
by Razvan Florea 29 Apr '13

29 Apr '13

Hello, I'm a student interested in working on odeint project this summer in GSOC. In the last weeks I spoke with Mario Mulansky about my ideas. After he gave me a task in order to accustom with odeint project, I started building my proposal. He suggested me to put my first version of proposal on the mailing list to get feedback or some advice about what should I change. Is this the right mailing list to share my proposal? If yes, how should I share my proposal with you? Should I put on melange or can I put it on a google doc and give you a link to it? Have a nice day, Razvan

3 3

Re: [boost] hi
by dominic ibeme 29 Apr '13

29 Apr '13

http://expecthead.com/wp-content/plugins/wp-plugin-repo-stats/china.php?ygf… \\\\\\ The improver of knowledge absolutely refuses to acknowledge authority, as such. For him, skepticism is the highest of duties, blind faith the one unpardonable sin. -- Thomas Huxley (1866)

1 0

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

29 Apr '13

> > I'm not ruling out the merit of a Boost.Thread threadpool. For me > > personally though, the hurdle is very significantly raised: you need > > to strongly prove to me why your proposed thread pool is much superior > > to a Boost.ASIO based threadpool. Otherwise I will zero score the GSoC > > proposal, because in the end we need other proposed projects more. > This is your right, but I don't know how the fact you can write easily the thread > pool you need to diminish a generic thread pool working well with futures. > [snip] > Hopping this helps you to understand the project I'm looking for. There are many ways systemically of implementing futures. The way you and Anthony have taken to date is a non-intrusive approach such that futures stand alone. This is great for not forcing design onto third parties and is a decentralised POSIX-y approach, but it comes with significant performance and memory costs because it's hard to get standalone, non-intrusive futures to batch themselves without sacrificing performance. An alternative approach is to assume a central dispatcher/event loop which can optimize then() chaining because it knows of all futures and their relationships currently in flight (this is a much more centralized statist NT-y approach, and it you can see that philosophy clearly in Microsoft's N3428). You can see an example of this approach to implementing future chaining with multiple dependencies which extends Boost.ASIO in https://github.com/ned14/TripleGit/blob/master/triplegit/include/async_file_ io.hpp#L785. I also went ahead and implemented N3428's when_all() which returns a future chained to multiple input futures, not that I claim the implementation mature yet. My concern with Boost.ThreadPool right now is that it could get in the way of the latter approach. I have zero objection to a formulation which embraces both approaches, but when you ask why a thread pool isn't in the standard, I think it's because until we've fixed futures implementation and all the composibility and chaining we're sure we need, and made sure that interops smoothly with the forthcoming TR2 networking proposal, then and only then is it wise to proceed with threadpool design. All that said, this is purely a cautious opinion of mine. You're one of the Boost.Thread maintainers, so I happily defer to your judgment on this. If you think we need a threadpool now, you'll find no opposition from me. Niall --- Opinions expressed here are my own and do not necessarily represent those of BlackBerry Inc.

3 2