- Boost - lists.boost.org

boost::iterator_range does not work in boost::variant in boost 1.55
by Jon Biggar 11 Mar '14

11 Mar '14

If I try to put a boost::iterator_range into a boost::variant, it breaks the variant, because something in boost::iterator_range doesn't allow variant to use SFINAE deduction. My best guess at the problem is the declarations in boost/range/iterator_range_core.hpp that have a 'class ForwardRange' template argument are insufficiently constrained and accept almost anything as a possible ForwardRange type. I'm guessing that putting the correct enable_if<> template constraints on the templates that use 'ForwardRange' will fix the issue, but I'm having trouble identifing the correct metafunction test to use, since concept FowardRange concept doesn't have too many good targets. I'd like to test a candidate FowardRange type to see if boost::begin() and boost::end() can be successfully called on it, but I haven't figured out how to do that yet. Any suggestions? Known fixes or workarounds? I know about the has_range_iterator metafunction, but it can't be used here due to circular definition issues... Exmaple: #include <boost/variant.hpp> #include <boost/range.hpp> #include <boost/mpl/vector.hpp> using namespace boost; enum E { e1, e2, e3 }; typedef mpl::vector<E, std::string > args; typedef boost::make_variant_over<args>::type OkVariant; typedef mpl::vector<boost::iterator_range<std::string::iterator>, args> args1; typedef boost::make_variant_over<args1>::type BrokenVariant; int main(int argc, char **argv) { OkVariant ok; ok = e1; ok = ""; BrokenVariant broken; std::string s; broken = boost::iterator_range<std::string::iterator>(s.begin(), s.end()); broken = e2; broken = ""; } Yields errors on the last two assignments to 'broken' in g++4.8.2: test.cpp:27:12: required from here ./boost/mpl/eval_if.hpp:60:31: error: no type named 'type' in 'boost::mpl::eval_if_c<true, boost::range_const_iterator<E>, boost::range_mutable_iterator<const E> >::f_ {aka struct boost::range_const_iterator<E>}' typedef typename f_::type type; I've attached the full error log and my project-config.jam. -- Jon Biggar jon(a)floorboard.com jon(a)biggar.org jonbiggar(a)gmail.com

2 2

Boost.Thread project for GSoC 2014
by Haoyue Wang 11 Mar '14

11 Mar '14

Hi, I am Haoyue, a PhD student in geophysics at MIT. I used C++11 to write parallel finite element codes in my research and had some coursework on concurrent programming. Boost is such a powerful and efficient library. I sincerely hope I could contribute to it this summer and beyond. I am interested in the standalone GSoC Projects under Boost.Thread. Particularly, the Work-Stealing-Thread-Pool project is a great one that I expect to learn a lot from. I understand that there could be much more to discuss once I have a preliminary proposal. Here I just want to ask if I am heading in the right direction. I think a good point to start is chapter 6, 7, and 9 of the book C++ Concurrency in Action: Practical Multithreading and the Executors and Schedulers revision 3 from http://www.open-std.org/. I haven't used Executor before but I am ware of its existence in Java for a while. Maybe I could go through some Executor and fork/join Java examples to see how they are used in practice. Finally, I will read and understand the executors codes on GitHub. I hope I could put up a good first draft proposal next Monday. If there is any advice, please let me know. Haoyue Wang

3 10

Review Request: Convert V2
by Vladimir Batov 11 Mar '14

11 Mar '14

I think I've addressed all comments/suggestions received so far. So, to keep things moving I would like to request a formal review of the library. Location: https://github.com/yet-another-user/boost.convert.git Short Description: The main purpose of the framework is to unify and to deploy various conversion facilities through one consistent interface, to provide generic consistent behavior -- one of the factors in improving productivity and code-correctness in commercial s/w development environment. / Boost.Convert/ builds on the /boost::lexical_cast/ experience and takes those conversion/transformation-related ideas further * to be applicable to a wider range of conversion-related deployment scenarios, * to provide a more flexible, extensible and configurable type-conversion framework. Thank you.

1 0

speed of light from universal_constants Boost.Units
by Roger Martin 10 Mar '14

10 Mar '14

Hi, I've tried and tried and just not understanding or can't muddle my way through the boost units(looks powerful though). For a start, just trying to get at the speed of light in boost/units/systems/si/codata/universal_constants.hpp boost::units::si::constants::codata::c boost::units<boost::units::si>::constants::codata::c.value() and massive errors; especially if I try to multiplying with something. I use boost::math::constants::pi<double>() from #include "boost/math/constants/constants.hpp" But the universals allude me; and example? where is my brain stuck?

2 2

Regression test failures on the develop branch
by Neil Groves 10 Mar '14

10 Mar '14

Hi! I've been doing some work on Boost.Range and have been ignoring complete failures from the following machines: teeks99* *jc-bell jasonr-Ubuntu13.04-intel-13.0.1 I'm concerned that the errors have been present for a couple of weeks. We are almost without MSVC coverage on the develop branch. I have taken to going off-process and after cycling the other platforms pushing to master to get coverage of MSVC. Of course I completely understand the difficulties balancing our busy schedules to devote time to Boost. This isn't a complaint. I wondered if there was already a plan to fix these and if there was anything I could do to help. Do we need more machines covering Microsoft compilers and platforms? Should we be approaching companies that use Boost with Microsoft that might be willing to donate some equipment and/or time? I don't think the risk is unacceptable at present since the new branching model means that at this stage of the schedule a hiccup on master can be quickly reverted without a total train wreck. I think we should probably get on top of this before we reach the final phase of the next release. Please let me know if I can help in any way. Regards, Neil Groves

5 5

[GSOC] Mentors for a C++11 TMP-related project
by Louis Dionne 10 Mar '14

10 Mar '14

Hi, I am a student considering to apply for GSOC 2014. Short story =========== I would like to know if someone is interested to mentor a project whose aim is boldly to: - Document the current state of the art in C++11 template metaprogramming. - Propose modifications to the current Boost.MPL or perhaps write a TMP library as a successor to the MPL. Full story ========== I have been working on a C++11 TMP library[1] for a while now, and I will present the state of my work at C++Now 2014. In the process of writing the library, I experiment with several TMP techniques, which I document and benchmark. The goal is to propose a new library that improves over the current MPL in a measurable way (i.e. it's not just my preference). That library could be seen as a C++11 successor to the MPL and new code could use that instead of the MPL. Now, while I expect the library to be fairly advanced by the beginning of the summer, there will certainly be criticism when I present it publicly. I see two possibilities here: (1) Input is negative enough that the idea to propose it is dropped. In that case, I could work on improvements to the current MPL during the summer. The kind of improvements I'm talking about range from documentation to bugfixes to support for C++11 when available. (2) Input is generally positive and the library is proposed circa the beginning of the summer. If the library is refused, then I'm back to (1). Otherwise, I can work on improvements and modifications required for the library to officially make it in. In both cases, the scope of the project seems reasonable to me. There is nothing similar in the list of proposed GSOC projects, so if someone is interested in mentoring this project, please speak up. I will then go through the normal process for proposing GSOC projects and include a more detailed description of it, and we'll see what happens. Regards, Louis Dionne [1]: http://github.com/ldionne/mpl11

5 18

[thread] Address sanitizer failures on marshall-mac
by Andrey Semashev 09 Mar '14

09 Mar '14

Hi, I'm observing Boost.Log and Boost.Atomic test failures on marshall-mac with AddressSanitizer enabled. http://www.boost.org/development/tests/develop/developer/output/marshall-ma… http://www.boost.org/development/tests/develop/developer/output/marshall-ma… The error messages don't contain function names but the backtraces have Boost.Thread on top. I can also see similar failures in Boost.Thread: http://www.boost.org/development/tests/develop/developer/output/marshall-ma… Is this a known problem in Boost.Thread? Can the backtraces be deciphered so that function names are shown?

5 18

[thread, async] Mini design review requested for a generic extensible Boost monadic continuations framework
by Niall Douglas 09 Mar '14

09 Mar '14

Dear Boost, I've been working on a Boost generalisation framework for N3857 "Improvements to std::future<T> and Related APIs" (Jan 2014). It's also an extension of Vicente's N3865 "More Improvements to std::future<T>" (Jan 2014), though slightly incompatible with it. I would appreciate the Boost community's feedback on what is essentially pure exploratory prototype code before I commit any major design flaws in a proper implementation. The proposed design is specifically intended to allow proposed Boost.AFIO's async_io_op future-like object to seamlessly interoperate with any other future-like object e.g. std::future<T> or boost::future<T>. The design is intended to be extensible to any other third party future-like object, even including ones whose implementation is completely external (e.g. Qt). I would like to thank some people whose off-list discussions helped inform this design: to Bjorn Reese who has done so much to help me knock the kinks out of AFIO; to Vicente J. Botet Escriba for engaging with me pitching this proposal to him (he disagrees with it by the way); to Artur Laksberg and Niklas Gustafsson for continuing to reply to my criticisms and thoughts of the papers which precede N3857. What N3857 proposes for reference: * future<T> and shared_future<T> gain a .then(R(prec_future_type<T>)) method. Callable will be called with the signalling future after the future signals. Return type is a future<R>. * A new when_all(...) can be used to compose a future which signals when all input futures are signalled. Inputs can be futures of heterogeneous types, in which case a future<tuple<...>> is returned. * A new when_any(...) composes a future which signals when any of its input futures signals. Inputs can be futures of heterogeneous types, in which case a future<tuple<...>> is returned. To avoid the linear scan on return, for a homogeneous types a when_any_swapped(...) swaps the last item in the return value with the ready item. Note there is no way in N3857 to avoid a when_any() linear scan when input types are heterogenous (something I feel is a deficiency, all you need to return is an index!). * A new executor base class, with subclass thread_pool are added. Executors allow adding a std::function<void()> for asynchronous execution. These are detailed by N3785 "Executors and schedulers, revision 3" (Oct 2013). I haven't mentioned in detail here, but N3857 specifies overloads for .then(executor, ...) to send some continuation to some executor. You will note the below framework makes it possible to use tag dispatch instead which looks much cleaner and is easier to write, nevertheless this explicit form is intended to be preserved. I won't mention executor support again for brevity. Where I find issue with a naïve implementation of N3857 (and Vicente's N3865 mentions some of these same issues): * N3857 only understands std::future<> and std::shared_future<>. That means the following code will not compile: std::future<int> &a; boost::future<int> &b; boost::afio::async_io_op &c; std::future<std::tuple<int, int, std::shared_ptr<async_io_handle>>> f=when_all(a, b, c); This is unhelpful for interoperation. It doesn't just affect Boost: imagine mashing up Qt async objects and C++17 objects for example, or even WinRT Task<T> objects and C++17 objects. Most C++ (and C) libraries of any complexity supply their own async notification objects, and this problem of writing never ending boilerplate to get some async object from library X to work with library Y is very tedious considering the compiler can do it for you. * As I mentioned earlier, when_any() is suboptimal when called with heterogenous types. I don't particularly like the when_any_swapped() hack either - a better solution would solve when_any() of all kinds optimally. * The .then(R(prec_future_type<T>)) is not tremendously useful in practice because it's too limited. Witness the very common use pattern of this form: auto ret=openedfile .then(write({ "He", "ll", "o ", "Wo", "rl", "d\n" }, 0)) .then(sync()); .then(write({ "He", "ll", "o ", "Wo", "rl", "d\n" }, 12)) .then(sync()); This sequence of code is clearly a *transaction* i.e. the programmer intends the set of continuations as a contained group of operations, and indeed some async i/o providers may guarantee atomic rollback (hint: forthcoming TripleGit does exactly this). A big additional problem is the lack of error handling logic: if say the second write() fails, you may wish to undo the first write, or do something custom. The problem with N3857 is that only the state of the first sync() is passed into the second write, and it may be the case that in generic code sync() needs to always sync irrespective of its preceding operation and therefore might pass through a garbage state. N3857 provides no easy method for a later .then() to inspect preceding .then()'s and do something about them (e.g. rewinding until it finds a valid open file handle rather than error states), other than by declaring special wrapper lambdas to pass through state. I personally think that is ugly. * Vicente mirrors my point above in N3865 by pointing out that having .then(R(prec_future_type<T>)) push the error handling into the callable makes your callables unnecessarily boilerplate. N3865 proposes adding .next(R(prec_future_type<T>)) for when a preceding operation succeeds and .recover(R(exception_ptr)) for when a preceding operation fails, with .fallback_to(value) as a way of default setting the return from an errored future. I think Vicente's argument here is a good one: but it's not generic enough in my opinion. I think continuations should be able to _filter_ outputs from preceding continuations in a really generic and customisable way. What I'd really like is this: continuations::thenable_get_placeholder<-1> last; auto ret=openedfile .then(write({ "He", "ll", "o ", "Wo", "rl", "d\n" }, 0)) .then(if_error(last, [](future<...> f){ do something with last; })) .then(sync()); .then(write({ "He", "ll", "o ", "Wo", "rl", "d\n" }, 12)) .then(if_error(last, [](thenable<...> t){ do something more with everything; })) .then(sync()); Which treats the continuation as a functional transformation. In other words, Vicente's .recover(R(exception_ptr)) becomes tag dispatched instead of explicitly specified, so it's very easy for the programmer to transform state according to state. What I am proposing instead: a generic extensible Boost monadic continuations framework which via metaprogramming lets the compiler assemble the right code from N3857 like syntax. A quick summary of the proposed generic extensible Boost monadic continuations framework follows: * Future-like behaviours such as .valid(), .then(), .get(), .wait() and .share() have functional mixin classes of the form (simplified for brevity, but you get the picture): namespace boost { namespace continuations { // Indicates the derived type provides a future compatible valid() template<class I> struct validable : public I { bool valid() const; }; // Indicates the derived type provides a future compatible then() template<class I, class... Types> struct thenable : public I { template<class F> thenable<decltype(F(...))>, Types..., I> then(F &&f); }; // Indicates the derived type provides a future compatible get() template<class T, class I> struct gettable: public I { T get(); }; // Indicates the derived type provides a future compatible wait() template<class I> struct waitable: public I { void wait() const; template<class Rep, class Period> std::future_status wait_for(const std::chrono::duration<Rep,Period> &timeout_duration) const; template<class Clock, class Duration> std::future_status wait_until(const std::chrono::time_point<Clock,Duration> &timeout_time) const; }; } } To mark up a type as being future-like, one might use: namespace boost { namespace continuations { template<class T> using monad = thenable<waitable<gettable<T, validable<std::future<T>>>>>; // Do all the partial specialisations of the internal machinery // for this type to hook it into the metaprogramming } } // Voila, boost::continuations::monad<T> is now an interoperable // form of std::future<T> * .then() can now take callables of the following forms: 1. R() and R(prec_future_type<T>) for compatibility with N3857. 2. R(..., continuations::thenable_get_placeholder<idx>, ...) inserts an item from the continuation chain into the call. thenable_get_placeholder can be fed a negative number to wrap from the bottom, so thenable_get_placeholder<-1> is the most recently preceding operation. Therefore R(prec_future_type<T>) from above is actually implemented as R(continuations::thenable_get_placeholder<-1>). This can be used to insert error processing filters as illustrated earlier which can view a preceding chunk of chain at once, and act. 3. R(thenable<...> &&) which gives a continuation access to the entire continuation chain, just for those people who really need it. You saw this in the example above. 4. Any specially treated prototype depending on what the metaprogramming has extended for some future_type. For example, if one does async_io_op.then(void(const boost::system::error_code& error, size_t bytes_transferred)) - which is the ASIO callback spec - then AFIO would emulate the ASIO callback calling convention for the completion of some i/o. This only happens if and only if the item being .then() is an async_io_op i.e. such custom extensions are type specific. * future_type<T>.then(R()) now returns a thenable<future_type<R>, future_type<T>> which auto decays to a future_type<R> on demand for compatibility with N3857. Similarly a future_type<T>.then(R()).then(S()) would return a thenable<future_type<S>, future_type<T>, future_type<R>> and so on. You can convert a thenable<T, ...> into a std::tuple<..., T> using an overload of the make_tuple() function. * when_all() and when_any() gain overloads for thenable<...>. These simply convert the tuple taken out of a thenable chain into a future with the results - AFIO will implement this generically using its closure engine, but a more intelligent solution might decompose all inputs into HANDLEs and do an asynchronous WaitForMultipleObjects() for example. Note this is a BREAKING CHANGE from N3857: If you do a when_all() under N3857 on a .then() chain, you will get a future to the last then() return, whereas under this proposal you will get a future to all the returns from all the then()s. This breaking change may still actually compile and work as expected - however when_any() actually now has completely different behaviour: when_any() under N3857 will be the same effect as when_all() on a .then() chain under N3857, whereas under this proposal when_any() will signal when any of the then() chain signals (I would assume the first item). I personally doubt this breaking change would affect any real world code, but it's worth noting. Note the following: 1. The proposed continuations framework, despite being monadic, is separate from the mooted Boost.Functional/Monads framework. This continuations framework could be implemented using such a Boost.Functional/Monads framework, but I suspect there wouldn't be much gain except interoperability with other monadic patterns. Continuation monads are a very limited specialisation of general monads, especially under the tight constraints of the N3857 requirements, so reuse of any Boost.Functional/Monads I suspect would be minimal. 2. The proposed framework is 100% compatible with N3857 apart from the when_all()/when_any() breakages which I would assume shouldn't turn up in real world code, and it should be viewed as a Boost-specific extension which may get standardised later if it proves popular. Here is the very rough prototype code: https://github.com/BoostGSoC/boost.afio/blob/monadic_continuations/lib s/afio/test/tests/monadic_continuations_test.cpp. It compiles using VS2013 only. It probably doesn't work, but it's simply there to demonstrate the viability of the concept and to help those confused by my unclear explanation above. Thoughts regarding the design much appreciated! My thanks in advance. Niall -- Currently unemployed and looking for work in Ireland. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/

2 5

Segment Tree Implementation for GSoC 2014
by Kevin Zuniga Garate 09 Mar '14

09 Mar '14

Hello everyone, I'm Kevin and I'd like to contribute to Boost in this SoC. I enjoy coding in C++ and participate a lot in competitive programming sites such as TopCoder, Codeforces, etc. A data structure I have learn from participating in those contests is segment tree. A segment tree is a data structure for storing data and querying and updating it in intervals, I haven't found a segment tree library in C++, so I thought it may be a good data structure for Boost. Do you think that would be a good addition for Boost? If not, what other data structure would you like to see implemented? Greetings. -- Kevin

4 9

Multi-methods and type switch
by Camille GILLOT 08 Mar '14

08 Mar '14

Hello, SoC2014 page on trac mentions interest for an implementation of type-switch for C++. For now, I have implemented a toy library for open multiple dispatch. It is based on compressed dispatch tables. It still just supports single inheritance and needs to attach integer tags to the dispatched class hierarchy. Is there any interest for further development of this library ? What would be the typical use cases ? Note : Although I opened with a reference to SoC2014, I do not intend to write a GSoC proposal for this work. Best regards, Camille Gillot

3 5