- Boost - lists.boost.org

Re: [boost] [Boost.Move] [Boost.Container] Compiling with older versions of Boost and Performance
by THOMAS JORDAN 10 Jan '12

10 Jan '12

Thomas Klimpel wrote: >THOMAS JORDAN wrote: > > Thanks, yes that would be the sensible way to proceed. > > My other question was, though - > > Does Boost::Move library rely on compiler optimisations of > > copy-elision/return value optimisation, as is the case with the Adobe > > Source Library (ASL) Move library, for example. The reason I ask is > > that I suspect the compiler I want to target is not very good at > > said optimisations. Or are there any other known factors which > > could > > mitigate > > against its effectiveness for a. n. other compiler? > Note the RVO (return value optimization) is a feature that is either working > or not, similarly to tail recursion in functional languages. This is unlike > URVO (unnamed return value optimization), which depends on the code > analysis capabilities of a optimizer. (Well, some compilers used to turn off > RVO in debug mode, but this should no longer be the case.) > Writing tests to check whether RVO is implemented is easy. I guess you > have a pretty good chance that even your compiler supports RVO (so I > guess the ASL Move library would work). But this doesn't mean that it will > be easy to get Boost.Move working with your compiler. Actually, just to clarify, I ran some tests which indicate the compiler (Sun C++ 5.10) does RVO on temporaries, but does not do NRVO and also does not seem to do copy-elision (as often as it might, at least). Now the ASL Move library does definitely depend on copy elision to provide any performance benefit, as is stated in its documentation. I tried that library and saw no gain - exactly the same call sequence took place. That seems to make sense I have pulled in the Boost::Move library - actually I only just pulled/hacked in the bare minimum, i.e., the macros and the ::boost::rv class and little else, as I am not so concerned about the C++0x/C++03/platform portability to begin with, just the performance. I got it compiling and running just before I knocked off for the day. It looks like there may be a couple fewer copies than with ASL or than without any move library, but not as much of a reduction as I wanted/expected, though I need to analyse it again more thoroughly tomorrow. It looks from the design of the boost::rv classes and associated overloads, and the conversion operators generated like the macros, that unlike ASL, Boost::Move doesn't rely on RVO/NRVO/copy elision in order to perform. Is that a reasonable assumption? Or is there anything else that people are aware of which could hinder the optimal performance of Boost::Move? Regards, T.

1 0

[range] SinglePassIterator concept check is too strict
by Nathan Ridge 10 Jan '12

10 Jan '12

Hello, It seems to me the concept checking performed by Boost.Range for the SinglePassIterator concept is too strict. In boost/range/concepts.hpp, SinglePassIteratorConcept checks for the following usage (line 157 in trunk): BOOST_DEDUCED_TYPENAME boost::detail::iterator_traits<Iterator>::reference r1(*i); This requires that the return type of operator* be convertible to the iterator's reference type. However, looking at the specification for single pass iterators [1], I don't see any requirement that the return type of operator* be convertible to the reference type - it just needs to be convertible to the value type. An example of an iterator for which the return type of operator* is not convertible to the iterator's reference type is std::istreambuf_iterator<charT>, whose reference type is charT&, but the return type of its operator* is charT. (Both of these are specified explicitly in section 24.5.3 of the C++03 standard.) As a result, code such as the following fails to compile with GCC or MSVC in C++03 mode: #include <boost/range/concepts.hpp> #include <boost/range/iterator_range.hpp> #include <iterator> #include <istream> int main() { BOOST_CONCEPT_ASSERT (( boost::SinglePassRangeConcept< boost::iterator_range< std::istreambuf_iterator<char> > > )); } (In C++11, things changed - a requirement was added that the return type of operator* be the same as the iterator's reference type, and correspondingly std::istreambuf_iterator<charT>'s reference type was changed to be charT). What can be done about this? Regards, Nate [1] http://www.boost.org/doc/libs/1_48_0/libs/iterator/doc/new-iter-concepts.ht…

3 2

[context review] Performance questions
by Antony Polukhin 10 Jan '12

10 Jan '12

I`ve read through the documentation of Boost.Context and some questions pop up: 1) What if we reimplement the ASIO example without Boost.Context (server class will look like this): class server : public boost::enable_shared_from_this< server > { private: boost::asio::ip::tcp::acceptor acceptor_; boost::array< char, 1024 > buffer_; void do_() { boost::asio::ip::tcp::socket socket( acceptor_.get_io_service() ); acceptor_.async_accept( socket, boost::bind( & server::do_1_, this->shared_from_this(), _1) ); } void do_1_(boost::system::error_code ec) { if (!ec) { socket.async_read_some( boost::asio::buffer(buffer_), boost::bind( & server::do_2_, this->shared_from_this(), _1, _2) ); } else { do_(); } } void do_2_(boost::system::error_code ec, size_t n) if (!ec) { boost::asio::async_write( socket, boost::asio::buffer( buffer, n), boost::bind( & server::do_1_, this->shared_from_this(), _1) ); } else { do_(); } } } server( boost::asio::io_service & io_service, short port) : acceptor_( io_service, boost::asio::ip::tcp::endpoint( boost::asio::ip::tcp::v4(), port) ), {} public: typedef boost::shared_ptr< server > ptr_t; static ptr_t create( boost::asio::io_service & io_service, short port) { return ptr_t( new server( io_service, port) ); } void operator()( boost::system::error_code /*ec*/, size_t /*n*/) { do_(); } }; Looks like this implementation will be faster (it has the same amount of io_service posted functions, no dynamic allocations, but has no context switches). Am I missing something? 2) Can we use contexts like condition variables? For example: struct task{ }; std::deque void thread_1() void threads

3 7

[C++ Now! 2012] Deadline extension: Call for Submissions, new deadline is January 20th, 2012
by Hartmut Kaiser 10 Jan '12

10 Jan '12

INAUGURAL C++ NOW! CONFERENCE 2012 Aspen CO, USA, May 14-18, 2012, www.cppnow.org CALL FOR SUBMISSIONS We invite you to submit session proposals to the Inaugural C++ Now! Conference: C++Now! 2012 (Aspen CO, USA, May 14 - 18, 2012). Based on the successful traditions of 5 years of BoostCon, which was the main face-to-face event for all things C++ and Boost (www.boost.org) C++Now! 2012 will present leading speakers from the whole C++ community. The conference name is changing to C++ Now! to reflect the current value of the language, the focus on its new state (from the new Standard), and the need to continually look to the future so the language remains useful to the C++ community. The focus of this conference will be the new C++11 language Standard and as usual Boost: what's new in C++, its Standard library, and in the Boost libraries, how to write and maintain them, how to evangelize or to deploy Boost within your organization. The new C++ Standard, but also the infrastructure and process of Boost, its vision and mission - no matter what you are interested in, it all comes together in the C++Now! sessions. Meet the colleagues, and feel the inspiration to support your work with C++ and Boost for the next year. The C++ Now! Conference is dedicated to discussion and education about C++, an open and free language and standard. Our Conference will focus on discussion and education about open source software usage and developments in the C++ developer and user community. To reflect the breadth of the C++ and Boost communities, the conference includes sessions aimed at three constituencies: C++ and Boost end-users, hard-core Boost library and tool developers, and researchers pushing the boundaries of computation. The program fosters interaction and engagement within and across those groups, with an emphasis on hands-on, participatory sessions. As a multi-paradigm language, C++ is a melting pot where the most compelling ideas from other programming communities are blended in powerful ways. Historically, some of the most popular sessions at C++Now! have highlighted these concepts, from DSLs to functional programming to transactional memory and more. Bring your C#, Python, Ruby or Haskell influences to bear in an environment that will broaden their exposure. IMPORTANT DATES New proposal submissions due: January 20th, 2012. UPDATED! Proposals decisions sent (tentative program): February 17th, 2012. Fully scheduled program available: February 25th, 2012. Session materials due: April 15th, 2012. BEST PRESENTATION AWARDS We know how much effort it takes to prepare talks for our conference. For this reason we will award the best presentations in the following categories: Best Presentation, Best Short Presentation, Best Tutorial, and Best Workshop. The awards will be given based on the audience's voting. Each award will include the author's name listed on the cover of the C++Now! website for that year and a plaque containing all the C++Now! conference information. SESSION TOPICS Topics of interest include, but are not restricted to, the following: * C++11 and how it changes life for users and library writers * General tutorial sessions on C++11, the C++11 Standardslibrary, and one or more Boost libraries * In-depth sessions on using specific Boost libraries * Case studies on using Boost * Experts panels * Advanced sessions on implementation techniques used within Boost libraries * Development workshops to extend or enhance existing Boost libraries * Workshops on design process * Infrastructure workshops such as Build tools, Website, Testing * Concepts and Generic Programming * Hardware and infrastructure presentations focused on how libraries can make better use of the technology * Software development tools and their application to C++ and or Boost * Other topics likely to be of great interest to Boost users and developers Interactive and collaborative sessions are encouraged, as this is the style of learning and participation that has proven most successful at such events. Sessions can be tutorial based, with an emphasis on interaction and participant involvement, or workshop based, whether hands-on programming or paper-based, discussion-driven collaborative work. SESSION FORMATS Presentations Presentations focus on a practitioner's ideas and experience with anything relevant to C++11, Boost and users. Panels Panels feature three or four people presenting their ideas and experiences relating to C++11 and Boost's relevant, controversial, emerging, or unresolved issues. Panels may be conducted in several ways, such as comparative, analytic, or historic. Tutorials Tutorials are sessions at which instructors teach conference participants specific skills relevant to C++11 and Boost. Workshops Workshops provide an active arena for advancements In Boost-relevant topics. Workshops provide the opportunity for experienced practitioners to develop new ideas about a topic of common interest and experience. Author's Corner These were introduced at BoostCon 2008, and were a great Presentations success They are short (30 minute) sessions, focusing on tips on usage and design. In addition, we're looking to uncover the hidden design gems in Boost libraries. Tool Vendors We actively encourage tool vendors and ISP's to submit presentations proposals for a special Tool Vendors Session Track aimed at products related to Boost and C++ (compilers, libraries, tools, etc.). Other formats may also be of interest. Don't hold back a proposal just because it doesn't fit into a pigeonhole. SUBMITTING A PROPOSAL Standard Sessions are 60 minutes. You may submit a proposal for fractions or multiples of 90-minutes. Fractional proposals will be grouped into 60 minute sessions covering related topics. Longer sessions, such as tutorials and classes, will be assigned 90 minute, three hour (i.e. half day), or six hour (i.e. full day) time slots. Please include: * The working title. * Type of session: presentation, panel, tutorial, workshop, authors corner, vendor track, other. * A paragraph or two describing the topic covered, suitable for the conference web site. * Proposed length: 10-20 minute short talks, 45 minutes, 90 minutes, half day, full day. * Alternate lengths, if you are willing to make adjustments: 10- 20 minute short-talks, 45 minutes, 90 minutes, half-day, full day. * Audience: users, developers, both. * Level: basic, intermediate, advanced. * A biography, suitable for the conference web site. * Your contact information (will not be made public). SUBMISSION DETAILS All submissions should be made through the EasyChair conference management system: http://www.easychair.org/conferences/?conf=cppnow2012. If you have not already registered at EasyChair, you will need to do so in order to submit your proposal. All submissions will go through a peer review process. Authors are invited (but are not required) to submit PDF versions of full papers of up to 10 pages in ACM conference proceedings format (see http://www.acm.org/sigs/publications/proceedings-templates) The full papers are not required unless you want them published in the proceedings. All accepted proposals will be made available in the Association for Computing Machinery (ACM) Digital Library (approval pending). Best papers, after further reviews, will be considered to be book chapters or journal articles in a renowned journal. The session materials go on the C++Now! website and will be available to attendees. For general information on the C++Now! 2012 paper submission or the scope of technical papers solicited, please refer to the conference website at www.cppnow.org. For any other questions about the submission process or paper format, please contact the Program Committee at cppnow2012(a)easychair.com. If you have any technical problems with EasyChair, please contact EasyChair for help. Note: Presenters must agree to grant a non-exclusive perpetual license to publish submitted materials, either electronically or in print, in any media related to C++ Now!. Hartmut Kaiser, email: hartmut.kaiser(a)gmail.com (Program Committee Chair) Dave Abrahams, email: dave(a)boostpro.com (Conference Chair) On behalf of the conference organizers

2 1

[Boost.Test] g++ compilation error due to ambiguity between template<class Cond, class T> struct boost::enable_if and class boost::unit_test::decorator::enable_if as well as the disable_if counterparts introduced after Boost 1.48.0 (up to at least svn rev. 76217)
by Torsten Maehne 10 Jan '12

10 Jan '12

Hello, I would like to draw your attention to an issue in Boost.Test that I'm experiencing with Boost trunk after the 1.48.0 release up until at least SVN rev. 76398. Just including directly or indirectly boost/typeof/ native.hpp into a unit test module (which includes boost/test/included/ unit_test.hpp) will cause compiler errors with g++: ==== begin: test_boost_test_decorator_enable_if.cpp ==== #define BOOST_TEST_MODULE test_boost_test_decorator_enable_if #include <boost/test/included/unit_test.hpp> #include <boost/typeof/native.hpp> //! \test Dummy test. BOOST_AUTO_TEST_CASE(test_dummy) { // do nothing } ==== end: test_boost_test_decorator_enable_if.cpp ==== g++ reports: In file included from test_boost_test_decorator_enable_if.cpp:62: boost/typeof/native.hpp:30: error: expected nested-name-specifier before ‘enable_if’ boost/typeof/native.hpp:30: error: expected initializer before ‘<’ token boost/typeof/native.hpp:34: error: expected nested-name-specifier before ‘disable_if’ boost/typeof/native.hpp:34: error: expected initializer before ‘<’ token The reason is an ambiguity between template<class Cond, class T> struct boost::enable_if and class boost::unit_test::decorator::enable_if in boost/typeof/native.hpp, as well as the disable_if counterparts. The test case compiles correctly against Boost 1.48.0 using Apple g++ 4.2.1, MacPorts? g++ 4.5.3 and 4.6.2 as well as Apple clang++ 3.0 on Mac OS X Lion 10.7.2 and Xcode 4.2.1. It fails to compile against Boost trunk until at least svn rev. 76217 using any of the mentioned g++ versions. Surprisingly, clang++ 3.0 is still able to correctly compile the test case. The test case is derived from test_signed_integer_output_with_karma.cpp in Trac ticket #6126. During the discussion of ticket #6126 on the Boost- Spirit-general mailing list, Jeroen Habraken identified the header boost/ test/tree/decorator.hpp as the origin for the compilation failure of the test case against Boost trunk. He found the cause to be an ambiguity: $ g++-mp-4.6 -o test_boost_test_decorator_enable_if test_boost_test_decorator_enable_if.cpp -I.../boost-trunk In file included from test_boost_test_decorator_enable_if.cpp:58:0: boost/typeof/native.hpp:30:18: error: expected nested-name-specifier before 'enable_if' boost/typeof/native.hpp:30:27: error: expected initializer before '<' token boost/typeof/native.hpp:34:18: error: expected nested-name-specifier before 'disable_if' boost/typeof/native.hpp:34:28: error: expected initializer before '<' token These occur because the code states "typename enable_if<Cond, T>::type" and the type name doesn't make sense in combination with boost::unit_test::decorator::enable_if. When removing the typename, on gets the following ambiguity error: boost/typeof/native.hpp:30:9: error: reference to 'enable_if' is ambiguous boost/utility/enable_if.hpp:36:10: error: candidates are: template<class Cond, class T> struct boost::enable_if boost/test/tree/decorator.hpp:184:23: error: class boost::unit_test::decorator::enable_if showing the conflict between template<class Cond, class T> struct boost::enable_if and class boost::unit_test::decorator::enable_if. As enable_if is often used without being fully qualified this breaks in a major fashion. Since boost/test/tree/decorator.hpp seems to be quite new (added 2011-10-02 11:00:16 +0200) it might be best fixed there. My search on trac for boost::unit_test::decorator_enable_if turned up changeset 74663 by rogeeff, who I therefore put in CC of the ticket 6331, which describes the findings of Jeroen and me. However, there hasn't been any feedback over the past 12 days. Therefore, I'm posting it now to the Boost.Devel mailing list hoping that the issue can be resolved before Boost 1.49 is released. Regards, Torsten Maehne

1 0

Re: [boost] FW: FW: Proposal for a Differential Evolution C++ library
by Adrian Michel 10 Jan '12

10 Jan '12

On 1/9/2012 9:11 AM, Paul A. Bristow wrote: > > I, for one, think this looks a very useful library. > > But few of the Boosters who follow these lists will be expert or even > potential users of this > 'niche' topic - which is why I think you've not had a deservedly rave > response ;-) > Thanks. I'm actually not surprised by the limited response for the exact reasons you mention, but I imagine this must have been the case with other libraries as well. > The documentation looks in a good state. The code looks clean and portable, > but finding someone to > run on a non-MSVC platforms would be useful - Boost likes to be *seen* to be > portable. > I thought that was going to be a requirement in a later stage, after the library was accepted. Nevertheless, if somebody on this list is willing to test the library on a non MS platform and using a compiler different from Visual Studio, I will appreciated your help! > The folder structure should be 'Boost standard' so that it is possible to > use bjam to build and use > Boost.Test. (Do not hesitate to ask for help - bjam is the Outer Mongolian > of computer languages > and using it is a dark art!) I'll look into it and make the necessary changes. > > You will first need to find a review manager (preferably a Boost > contributor), and it will be > necessary to have some reviewers too! (Reviewers need not necessarily be > currently active Boost > followers for a specialist library like this - expertise is the key thing). > > So you may need to find and drum up support from some potential (or better > still, actual) users ? The library was reviewed from a functional and conceptual standpoint by the creators of the DE algorithm and they seem to have validated it, maybe less so from a C++ standpoint though. I also received very useful feedback for further enhancements that I'll be adding in a future release. As far as a boost review manager and other reviewers, I can only count on list members that are willing to volunteer some of their time for this purpose (please let me know if interested). I'll also try to gather some support outside of the list. One of the nice things about DE is that it is relatively simple and generic, and it doesn't require any advanced or domain specific knowledge, so I'm sure anybody on this list could learn enough about it to be able to review the library, without spending too much time and effort. Adrian Michel www.tradery.com

2 1

Re: [boost] [Boost.Move] [Boost.Container] Compiling with older versions of Boost and Performance
by THOMAS JORDAN 10 Jan '12

10 Jan '12

>From: "Vicente J. Botet Escriba" <vicente.botet(a)wanadoo.fr> >To: boost(a)lists.boost.org >Subject: Re: [boost] [Boost.Move] [Boost.Container] Compiling with > older versions of Boost and Performance >Message-ID: <4F09F0C3.4080306(a)wanadoo.fr> >Content-Type: text/plain; charset=ISO-8859-1; format=flowed Ø Le 08/01/12 12:25, Thomas Jordan a ?crit : Ø >> Message: 3 Ø >> Date: Sat, 07 Jan 2012 15:58:20 +0100 Ø >> From: "Vicente J. Botet Escriba" <vicente.botet(a)wanadoo.fr> Ø <snip> Ø >> Le 07/01/12 12:10, Thomas Jordan a ?crit : Ø >>> Hi, Ø >>> I am interested in experimenting with v1.48 Boost.Move and Ø >>> Boost.Container. However, I am otherwise constrained to using Boost Ø >>> libraries v1.33.1 with Ø >>> a Sun C++ v5.10 compiler. I couldn't seem any 'Boost library Ø >>> dependencies' listed in the Move/Container documentation, but a Ø >>> quick look through the header files suggests Ø >>> that it is mainly MPL and Type Traits. So... Ø >>> First question: would it be feasible for me to combine the headers Ø >>> for these two libraries with the v1.33.1 libraries and get it to Ø >>> work (albeit maybe with a little customisation), or would it be a Ø >>> big job/non-starter? Ø >>> Second question - I don't see any performance analysis published for Ø >>> Boost.Move. I know that move semantics is about more than improved Ø >>> performance, but am interested in that side of things, especially as Ø >>> the above compiler appears suboptimal in terms of copy elision and Ø >>> RVO. I am wondering for example whether are there any Ø >>> (compiler-specific) factors which could mitigate against the Ø >>> performance benefits of doing a move vs a copy of a vector, using Ø >>> these libraries, for example. Ø >>> Ø >> Ø >> Hi, Ø >> Ø >> unfortunately Boost.Move and Boost.Container are not working up to now Ø >> on Sun c++ even on trunk (1.49). See Ø >> http://www.boost.org/development/tests/trunk/developer/container.html. Ø >> Ø >> Best, Ø >> Vicente Ø Ø >Thanks for pointing me to that. In general is there anything more Ø >detailed than pass/fail available to look at? Ø >Is the assumption that something with so many fails it not fixable one Ø >the library side, and is not worth investigating? Ø > Ø > Ø Lastly there were some issues reporting the failure on the Sandia Ø testers. Sun compiler miss a lot of useful features for many Boost Ø libraries. Ø I think the best you can do is to install the version 1.48 (or the Ø trunk), run the tests yourself, look for the first failures in Ø Boost.Move and try to understand what is going wrong. Report the Ø failures here and try to solve them with the help of Ion and the Boost Ø comunity. Ø HTH, Ø Vicente Thanks, yes that would be the sensible way to proceed. My other question was, though - Does Boost::Move library rely on compiler optimisations of copy-elision/return value optimisation, as is the case with the Adobe Source Library (ASL) Move library, for example. The reason I ask is that I suspect the compiler I want to target is not very good at said optimisations. Or are there any other known factors which could mitigate against its effectiveness for a. n. other compiler? Regards, T.

2 1

[random] uniform_real problem (what, again?)
by Neal Becker 10 Jan '12

10 Jan '12

Testing with 1.47.0, I know we added an assert min <= max But is min==max valid? I just tried testing with a uniform_real (0,0), and it seems to hang forever. I haven't tried to fully analyze the code, but I'm guessing this could be a problem: if(result < max_value) return result; So should that assert be min < max? Also, I find it unfortunate that it is not possible to use uniform_real (x,x) as a limiting case - it occurs naturally in my code when I don't actually want to generate a range of values but just a constant value.

1 0

Boost Review Wizard Report for January 2012
by Ronald Garcia 10 Jan '12

10 Jan '12

============================================== Review Wizard Status Report for January 2012 ============================================== News ==== 1. Type Traits Library Extensions Accepted 2. AutoIndex Tool Accepted 3. Heaps Library Accepted 4. Assign v2 Library Rejected 5. Type Traits Introspection Library Accepted 6. Lockfree Library Accepted 7. Algorithm Library Accepted 8. Atomic Library Accepted 9. Local Library Accepted 10. Context Mini-review Ongoing Open Issues =========== The following libraries have been reviewed and await reports from their review managers: * Conversion - reviewed August 2011; review manager: Gordon Woodhull. The following libraries have been accepted to Boost, but have not yet been submitted to SVN: * Constrained Value - accepted September 2010; author: Robert Kawulak * GIL.IO - accepted January 2011; author: Christian Henning. * Atomic - accepted July 2011; author Helge Bahmann * Lockfree - accepted August 2011; author: Tim Blechmann. * Algorithm - accepted December 2011; author: Marshall Clow The following libraries have been accepted and submitted to SVN, but have not yet appeared in a release: * Heaps - accepted June 2011; author: Tim Blechmann. * Type Traits Introspection - accepted August 2011; author: Edward Diener. The following libraries have been accepted provisionally to Boost, but have not been submitted for mini-review and full acceptance: * Log - accepted provisionally March 2010; author: Andrey Semashev. * Endian - accepted provisionally November 2011; author: Beman Dawes. After repeated failed attempts to contact the author, the following library has been marked as Orphaned. * Switch library, accepted provisionally January 2008 author: Steven Watanabe. General Announcements ===================== As always, we need experienced review managers. Please take a look at the list of libraries in need of managers and check out their descriptions. In general review managers are active boost participants, including library contributors, infrastructure contributors, and other mailing list participants with a substantial track record of constructive participation. If you can serve as review manager for any of them, email Ron Garcia or John Phillips, "rxg at cs dot cmu dot edu" and "phillips at pacific dot mps dot ohio-state dot edu" respectively. We are also suffering from a lack of reviewers. While we all understand time pressures and the need to complete paying work, the strength of Boost is based on the detailed and informed reviews submitted by you. If you are interested in reviewing a library but won't have time during the review period, you can always prepare your review ahead of time. No rule says you can only work on a review during the review period. A link to this report will be posted to www.boost.org. If you would like us to make any modifications or additions to this report before we do that, please email Ron or John. The review schedule is an unordered list of the libraries awaiting review. As such, any library on the schedule can be reviewed once the developer is ready, a review manager has been secured, and the manager, developer, and wizards agree on a date to schedule the review. Review Schedule =============== * Join (M) * Pimpl (M) * Sorting (M) * Quaternions, Vectors, Matrices (M) * Variadic Macro Data (M) * Block Pointer (M) * Network (M) * Singularity (M) * Predef (M) ``(M)`` marks libraries that need review managers. -------------------- Join ---- :Author: Yigong Liu :Review Manager: Needed :Download: http://channel.sourceforge.net/ :Description: Join is an asynchronous, message based C++ concurrency library based on join calculus. It is applicable both to multi-threaded applications and to the orchestration of asynchronous, event-based applications. It follows Comega's design and implementation and builds with Boost facilities. It provides a high level concurrency API with asynchronous methods, synchronous methods, and chords which are "join-patterns" defining the synchronization, asynchrony, and concurrency. Pimpl ----- :Author: Vladimir Batov :Review Manager: Needed :Download: | `Boost Vault <http://www.boost-consulting.com/vault/index.php?action=downloadfile&fil…>`__ | http://www.ddj.com/cpp/205918714 (documentation) :Description: The Pimpl idiom is a simple yet robust technique to minimize coupling via the separation of interface and implementation and then implementation hiding. This library provides a convenient yet flexible and generic deployment technique for the Pimpl idiom. It's seemingly complete and broadly applicable, yet minimal, simple and pleasant to use. Sorting ------- :Author: Steven Ross :Review Manager: Needed :Download: `Boost Vault <http://www.boostpro.com/vault/index.php?action=downloadfile&filename=al…>`__ :Description: A grouping of 3 templated hybrid radix/comparison-based sorting algorithms that provide superior worst-case and average-case performance to std::sort: integer_sort, which sorts fixed-size data types that support a rightshift (default of >>) and a comparison (default of <) operator. float_sort, which sorts standard floating-point numbers by safely casting them to integers. string_sort, which sorts variable-length data types, and is optimized for 8-bit character strings. All 3 algorithms have O(n(k/s + s)) runtime where k is the number of bits in the data type and s is a constant, and limited memory overhead (in the kB for realistic inputs). In testing, integer_sort varies from 35% faster to 2X as fast as std::sort, depending on processor, compiler optimizations, and data distribution. float_sort is roughly 70% faster than std::sort. string_sort is roughly 2X as fast as std::sort. Quaternions, Vectors, Matrices ------------------------------ :Author: Emil Dotchevski :Review Manager: Needed :Download: http://www.revergestudios.com/boost-qvm/ :Description: QVM defines a set of generic functions and operator overloads for working with quaternions, vectors and matrices of static size. The library also defines vector and matrix data types, however it allows users to introduce their own types by specializing the q_traits, v_traits and m_traits templates. Variadic Macro Data ------------------- :Author: Edward Diener :Review Manager: Needed :Download: `Boost Sandbox <http://svn.boost.org/svn/boost/sandbox/variadic_macro_data/>`__ :Description: The variadic_macro_data library adds support and functionality for variadic macros to Boost as well as integrating variadic macros with the Boost PP library without changing the latter library in any way. Block Pointer ------------- :Author: Phil Bouchard :Review Manager: Needed :Download: `Boost Sandbox <https://svn.boost.org/svn/boost/sandbox/block_ptr/>`__ :Description: Deterministic memory manager of constant complexity capable of handling cyclic collections. Network ------- :Author: Dean Michael Berris :Review Manager: Needed :Download: http://cplusplus-soup.com/2011/04/18/cpp-netlib-0-9-0-released/ :Description: This is a library that provides application layer protocol support using modern C++ techniques. It is light-weight, fast, cross-platform and is intended to be as easy to configure as possible. Singularity ----------- :Author: Ben Robinson :Review Manager: Needed :Download: https://github.com/icaretaker/Singularity :Description: The Singularity Design Pattern allows you to restrict any class to a single instance. Unlike the infamous Singleton, Singularity gives you direct control over the lifetime of the object, does not require you to grant global access to the object, nor does it limit you to the default constructor for that object. Predef ------ :Author: Rene Rivera :Review Manager: Needed :Download: http://tinyurl.com/73n6a3k :Description: The Predef library implements two simple tasks: 1. Definition of a single version number macro to provide consistent version number at the preprocessor level. 2. A collection of detected definitions for compilers, standard libraries, architectures, operating systems, and languages. Unlike the Boost Config Library it doesn't define language features and capabilities. But only defines presence of detected compilation context. Documentation and downloads are available in the sandbox.. Libraries under development =========================== See http://svn.boost.org/trac/boost/wiki/LibrariesUnderConstruction for a current listing of libraries under development.

1 0

[context] 4 days left on Boost.Context mini-review
by Giovanni Piero Deretta 10 Jan '12

10 Jan '12

Hi All, This is a call for reviewers for Boost.Context. The mini review period will end the 11th of this month and we only had 1 review so far and we were expecting a few more. We had some interesting discussions on the original review period and quite a few people were involved, so anybody who has an interest in boost.context please write a review. thank you all, -- gpd

6 12