August 2012 - Boost-announce - lists.preview.boost.org

Announce: Boost 1.51 installer for 32/64-bit Windows now available
by John Wiegley 24 Aug '12

24 Aug '12

BoostPro is happy to announce that we now have free 32-bit and 64-bit installers for Windows available for download: http://www.boostpro.com/download This version libraries and/or DLLs for the following compilers: Visual C++ 7.1 (Visual Studio 2003) [32-bit only] Visual C++ 8.0 (Visual Studio 2005 SP1) Visual C++ 9.0 (Visual Studio 2008 SP1) Visual C++ 10.0 (Visual Studio 2010 SP1) -- John Wiegley BoostPro Computing Software Development Training http://www.boostpro.com Clang/LLVM/EDG Compilers C++ Boost

1 0

[Review] Boost.Contract Review Starts Today(*)
by Dave Abrahams 23 Aug '12

23 Aug '12

The review period for Lorenzo Caminiti's Boost.Contract library runs from today through August 31st. I'm pleased to serve as review manager. ,----[ Important Notes ] | - Please begin your review's subject line with "[Review:Algorithms]" | - Please do not post your review or discussion as a reply to this | message. | - Please feel free to note any individual issues in the issue | tracker at https://sourceforge.net/apps/trac/contractpp/report/3 | (you'll need to log in at Sourceforge to add a ticket) and make | reference to them from your review. | - Please see below for *further* important notes `---- THE LIBRARY Boost.Contract implements Contract Programming (a.k.a., Design by Contracts) for C++. In addition, the library implements virtual specifiers, concept checking, and named parameters. Documentation: http://contractpp.sourceforge.net Source: http://sourceforge.net/projects/contractpp/files/latest/download All N1962 requirements and Eiffel features are supported by the library, among others: 1) Support for preconditions, postconditions, class invariants, block invariants, and loop variants. 2) Subcontract derived classes (with support for pure virtual functions and multiple inheritance). 3) Access expression old values and function return value in postconditions. 4) Optional compilation and checking of preconditions, postconditions, class invariants, block invariants, and loop variants. 5) Customizable actions on contract assertion failure (terminate by default but it can throw, exit, etc). This library is implemented for C++03 and it does not require C++11. Obviously, if the library is accepted, all macros will be prefixed by BOOST_... and other symbols will go under the boost::... namespace. Potential Interactions with Existing Boost Libraries ==================================================== This submission potentially interacts with the following existing Boost libraries: * parameter - http://boost.org/libs/parameter * static_assert - http://www.boost.org/libs/static_assert * MPL - http://www.boost.org/libs/mpl * Concept - http://www.boost.org/libs/concept_check Reviewers should consider these potential interactions. What to include in Review Comments ================================== - Keep your criticism constructive. Constructive criticism usually comes with specific suggestions for improvement. - If you identify problems along the way, please note if they are minor, serious, or showstoppers. - Please *do* vote on whether the library should be accepted. Everyone who takes the time to look at the library is qualified to vote, and every vote is valuable. - Other questions you might want to answer in your review: * What is your evaluation of the design? * What is your evaluation of the implementation? * What is your evaluation of the documentation? * What is your evaluation of the potential usefulness of the library? * Did you try to use the library? With what compiler? Did you have any problems? * How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? * Are you knowledgeable about the problem domain? (*) Well, OK, the review period officially started yesterday. Sorry for the delayed announcement -- Dave Abrahams BoostPro Computing Software Development Training http://www.boostpro.com Clang/LLVM/EDG Compilers C++ Boost

1 0

[boost] [type_erasure] Review report -- ACCEPTED
by Lorenzo Caminiti 21 Aug '12

21 Aug '12

Hello all, Steven Watanabe's library Boost.TypeErasure is ACCEPTED into Boost. SUMMARY The library was reviewed from July 18 to August 3, 2012. There were 11 votes to accept the library and 2 votes to accept the library under the condition of some modifications (at the end, these 2 votes were essentially considered as "no" because there was no agreement on implementing all the required modifications). It was noted how the library offers non-intrusive and powerful programming techniques that can be used in place of usual Object Oriented (pure) virtual function interfaces (and with support for some from of virtual "template" functions). The library can also be seen as a generalization of existing Boost libraries like Any, Function, and AnyIterator. The library is accepted "as is", however most reviewers suggested to: 1) Dramatically ease the learning curve of the documentation by providing a motivation section, step-by-step tutorial(s) to introduce the basic features of the library, advanced topics section(s) to introduced the additional features, an example section with non-trivial use cases for the library, and additional examples to the reference section. 2) Support down-casting. While these changes are not a condition for the library acceptance, it would be best if they were made part of the very first release of the library. A few reviewers found the name Type Erasure confusing, however others did not. Alternative name were: Staged Typing, Deferred Typing, Type Interface, Interface, Static Interface, Value Interface, Structural Typing, Duck Typing, and Run-Time Concepts. There was some discussion on the meaning of Type Erasure in Java and on its definition on wiki (these should probably be both referenced in the documentation). The current library name is considered acceptable and the final decision on the library name is left entirely up to Steven. DETAILS "Yes" reviews: [1] http://lists.boost.org/Archives/boost/2012/07/195288.php [2] http://lists.boost.org/Archives/boost/2012/07/195297.php [3] http://lists.boost.org/Archives/boost/2012/07/195299.php [4] http://lists.boost.org/Archives/boost/2012/07/195308.php [5] http://lists.boost.org/Archives/boost/2012/07/195323.php [6] http://www.mentby.com/hossein-haeri/boost-typeerasure-review-ends-today-jul… [7] http://lists.boost.org/Archives/boost/2012/07/195327.php [8] http://lists.boost.org/Archives/boost/2012/07/195329.php [9] http://lists.boost.org/Archives/boost/2012/07/195334.php [10] http://lists.boost.org/Archives/boost/2012/07/195364.php [11] http://lists.boost.org/Archives/boost/2012/08/195420.php "Conditional-yes" reviews (essentially considered as "no"): [12] http://lists.boost.org/Archives/boost/2012/08/195455.php [13] http://lists.boost.org/Archives/boost/2012/08/195561.php Notable comments and discussions (not reviews): (1) http://lists.boost.org/Archives/boost/2012/07/195162.php (2) http://lists.boost.org/Archives/boost/2012/07/195130.php (3) http://lists.boost.org/Archives/boost/2012/07/195149.php (4) http://lists.boost.org/Archives/boost/2012/07/195167.php (5) http://lists.boost.org/Archives/boost/2012/07/195199.php (6) http://lists.boost.org/Archives/boost/2012/07/195200.php (7) http://lists.boost.org/Archives/boost/2012/07/195232.php (8) http://lists.boost.org/Archives/boost/2012/07/195234.php (9) http://lists.boost.org/Archives/boost/2012/07/195408.php (10) http://permalink.gmane.org/gmane.comp.lib.boost.user/75081 (11) http://lists.boost.org/Archives/boost/2012/08/195590.php (12) http://lists.boost.org/Archives/boost/2012/08/195663.php (13) http://lists.boost.org/Archives/boost/2012/07/195342.php (14) http://lists.boost.org/Archives/boost/2012/08/195543.php Note that Steven might have already implemented some of the changes listed below. Features: * Support down-casting. See [1], [10], and (4). * Add macros for defining concepts. These macros could be added in later revisions (they just provide a different syntax, no additional functionality). ** From [10]: BOOST_CREATE_CONCEPT(container_concept, typename T, (void (push_back, T), void (size)) ) ** From Steven: BOOST_TYPE_ERASURE_MEMBERS((push_back)(size)...) template<class V, class T = _self> struct container_concept : mpl::vector< has_push_back<void(const V&), T>, has_size<std::size_t(), const T>, ...> {}; * Add empty() to check if any holds a value or not. See [3] and [11]. * Add a built-in concept for unary plus +x (just pick a name for it). See (11). Implementation: * Can assertion enforce that same bindings are required for the placeholders? See [13] and (3). * Add assertion to check that in functions with multiple arguments the underlining any types must match. See (7). * Add in-code comments to the implementation (at least to normalize.hpp). See [8] and [13]. * Can static assertions be used to improve error messages (see [8])? Concept mismatch spew errors with internal implementation details, see [10]. * Fix bugs: ** http://lists.boost.org/Archives/boost/2012/07/195367.php ** http://lists.boost.org/Archives/boost/2012/07/195396.php ** http://lists.boost.org/Archives/boost/2012/08/195662.php Documentation: * A few typos listed in [9]. * A draft on a proposed way to restructure the docs was offered in [8]. * Sean Parent's BoostCon 2012 "Value Semantics" could be used to write a motivation section. See [9]. * Offer a comparison with usual OO (pure) virtual function interfaces. See [1], [7], [8], and [9]. * Make sure all important elements document in the reference section are also documented in a tutorial section (e.g., how the any constructor binds placeholders, conversions, BOOST_TYPE_ERASURE_MEMBER, concept_of, etc). See (1), (4), (6), and [1]. * Clarify that references can be assigned but they cannot be rebound to a different object. See (2). * Clarify the rationale for using _a, _b, ... instead of _1, _2, ... as soon as _a, _b, ... are first used (most users miss the "named vs. positional parameter" rationale from the design decision section and _1, _2, ... are such common constructs that many users will naturally question the _a, _b, ... choice). See (5). * Add an example section with non-trivial use cases of the library. Consider to add the following examples: ** How to implement visitation, see (8). ** Model view controller, see [1]. ** Run-time expression system (adding Concept = void specialization), see [3]. ** Multi-function, see [4]. ** Printing, see (11) (note that Steven needed to answer too many questions for Paul to be able to program this, ideally the docs would have been clear enough for Paul to program this example without Steven's help). ** Reference related work Adobe::Poly, see (13). * Document all built-in concepts (possibly with a usage example for each) and indicate which ones can be specialized. See [5], and [9]. * Add an example at the bottom of each reference page. See [11]. * Document that any(any<Concpet2, T2>, binding<Concept>) allows to convert the vtable once and re-use it for all anys reducing run-time cost. See [12]. * Consider a number of docs improvements as suggested in [13]. * Document the undefined behaviour pointed out in (12). * Document limitations that some algorithms might encounter if they need to access references and provide rationale of why references cannot be handled differently (i.e., constructor flag and/or overhead of managing vtable in dispatcher layer). See [12], and (14). Many thanks to everyone that participated in the review!! I believe Boost users will find this library useful. The review manager, --Lorenzo On Sat, Aug 4, 2012 at 12:32 PM, Lorenzo Caminiti <lorcaminiti(a)gmail.com> wrote: > Hello all, > > The review of Boost.TypeErasure ended on Aug 3, 2012. Stay tuned for > my decision on the library. > > Thank you very much to Steven, everyone that submitted a review, and > everyone that participated in the discussions. > > The review manager, > --Lorenzo > > On Fri, Aug 3, 2012 at 11:00 AM, Lorenzo Caminiti <lorcaminiti(a)gmail.com> wrote: >> Hello all, >> >> *** The review of Boost.TypeErasure ends today Aug 3, 2012. If you are >> planning to submit a review, please do so by the end of today. *** >> >> Thank you to all that have participated to the review so far. >> >> The review manager, >> --Lorenzo >> >> On Jul 27, 2012 1:41 PM, "Lorenzo Caminiti" <lorcaminiti(a)gmail.com> wrote: >>> >>> Hello all, >>> >>> After consulting the review wizards and Steven, I am extending >>> Boost.TypeErasure review of one week, until August 3, 2012. >>> >>> Thank you to all that have submitted a review already and I am looking >>> forward to receiving additional submissions. >>> >>> The review manager, >>> --Lorenzo >>> >>> On Jul 27, 2012 3:22 AM, "Lorenzo Caminiti" <lorcaminiti(a)gmail.com> wrote: >>>> >>>> Hello all, >>>> >>>> On Mon, Jul 23, 2012 at 9:09 AM, Lorenzo Caminiti <lorcaminiti(a)gmail.com> >>>> wrote: >>>>> On Wed, Jul 18, 2012 at 1:13 AM, Lorenzo Caminiti >>>>> <lorcaminiti(a)gmail.com> wrote: >>>>>> *** The review of Steven Watanabe's proposed Boost.TypeErasure library >>>>>> begins on July 18, 2012 and ends on July 27, 2012. *** >>>>> >>>>> *** Boost.TypeErasure review ends in 5 days. Please submit your reviews >>>>> :D *** >>>> >>>> *** Boost.TypeErasure review ends today July 27, 2012. If you are >>>> planning to submit a review, please do so as soon as possible. *** >>>> >>>> Thank you to everyone who has commented on the library and submitted a >>>> review so far! >>>> >>>> The review manager, >>>> --Lorenzo >>>> P.S. I am considering extending the review until end of day Sunday >>>> July 29, 2012... I will keep you posted. >>>> >>>>> There have been interesting discussions on the library on the ML but I >>>>> have not received any official review yet :( Especially if you are a >>>>> user of Boost Any, Function, and Any Iterator, you definitely want to >>>>> take a look at Type Erasure as it generalizes solutions provided by >>>>> those other libraries. >>>>> >>>>> Thank you. >>>>> >>>>> The review manager. >>>>> --Lorenzo >>>>> >>>>>> THE LIBRARY >>>>>> >>>>>> C++ provides runtime polymorphism through virtual functions. They are >>>>>> a very useful feature, but they do have some limitations. >>>>>> * They are intrusive. In generic programming, we can design an >>>>>> interface which allows third-party types to be adapted to it. >>>>>> * They require dynamic memory management. Of course, most of the >>>>>> problems can be avoided by using an appropriate smart pointer type. >>>>>> Even so, it still acts like a pointer rather than a value. >>>>>> * Virtual functions' ability to apply multiple independent concepts to >>>>>> a single object is limited. >>>>>> The Boost.TypeErasure library solves these problems allowing us to >>>>>> mirror static generic programming at runtime. >>>>>> >>>>>> Library source: >>>>>> http://svn.boost.org/svn/boost/sandbox/type_erasure/ >>>>>> >>>>>> Pre-built documentation: >>>>>> >>>>>> http://steven_watanabe.users.sourceforge.net/type_erasure/libs/type_erasure/ >>>>>> >>>>>> You can also download archives with pre-built documentation from: >>>>>> http://sourceforge.net/projects/steven-watanabe.u/files/ >>>>>> >>>>>> YOUR REVIEW >>>>>> >>>>>> Please submit a review to the mailing-list by replying to this email >>>>>> ("[boost] [type_erasure] Review ..." should be in the subject). >>>>>> >>>>>> Please state clearly whether you think this library should be accepted >>>>>> as a Boost library. >>>>>> >>>>>> Other questions you may want to consider: >>>>>> 1. What is your evaluation of the design? >>>>>> 2. What is your evaluation of the implementation? >>>>>> 3. What is your evaluation of the documentation? >>>>>> 4. What is your evaluation of the potential usefulness of the library? >>>>>> 5. Did you try to use the library? With what compiler? Did you have >>>>>> any problems? >>>>>> 6. How much effort did you put into your evaluation? A glance? A >>>>>> quick reading? In-depth study? >>>>>> 7. Are you knowledgeable about the problem domain? >>>>>> >>>>>> Thanks in advance to all who participate in the review discussion -- >>>>>> I'm looking forward to it! _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

Boost 1.51.0 released!
by Marshall Clow 20 Aug '12

20 Aug '12

Release 1.51.0 of the Boost C++ Libraries is now available. These open-source libraries work well with the C++ Standard Library, and are usable across a broad spectrum of applications. The Boost license encourages both commercial and non-commercial use. This release contains 1 new library (Boost.Context, by Oliver Kowalke) and numerous enhancements and bug fixes for existing libraries. For details, including download links, see http://www.boost.org/users/news/version_1_51_0 You can also download directly from SourceForge: http://sourceforge.net/projects/boost/files/boost/1.51.0/ To install this release on your system, see http://www.boost.org/doc/libs/release/more/getting_started/index.html Thanks, --The Boost release team Beman Dawes Daniel James Eric Niebler Marshall Clow Rene Rivera Vladimir Prus

1 0

Review Wizard Status Report for August 2012
by Ronald Garcia 15 Aug '12

15 Aug '12

============================================== Review Wizard Status Report for August 2012 ============================================== News ==== 1. Multiprecision Arithmetic Reviewed 2. Type Erasure Reviewed 3. Boost 1.50.0 Released. New Libraries: 1) Algorithm 2) Functional/OverloadedFunction 3) LocalFunction 4) Utility/IdentityType Open Issues =========== The following libraries have been reviewed and await reports from their review managers: * Predef - reviewed February 2012; review manager: Joel Falcou. * Multiprecision - reviewed June 2012; review manager: Jeffrey Hellrung 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. The following libraries have been accepted and submitted to SVN, but have not yet appeared in a release: * Atomic - accepted July 2011; author Helge Bahmann. * Type Traits Introspection - accepted August 2011; author: Edward Diener. * Lockfree - accepted August 2011; author: Tim Blechmann. * Context - accepted January 2012; author: Oliver Kowalke. The following libraries have been accepted provisionally to Boost, but have not been submitted for mini-review and full acceptance: * Endian - accepted provisionally November 2011; author: Beman Dawes. * Log - accepted provisionally March 2010; author: Andrey Semashev. 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, 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) * Singularity (M) * Extended Complex Numbers (M) * Metaparse (M) * Polygon: Voronoi Extensions * Coroutine * Range Extensions * Contract * Nowide (M) * ODEint * Array (M) * TypeIndex (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: https://github.com/boost-vault/Miscellaneous/blob/master/Pimpl.zip :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: https://github.com/boost-vault/Sorting :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: This 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: https://svn.boost.org/svn/boost/sandbox/block_ptr/ :Description: Deterministic memory manager of constant complexity capable of handling cyclic collections. Singularity ----------- :Author: Ben Robinson :Review Manager: Needed :Download: https://github.com/cppmaven/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. Extended Complex Numbers ------------------------ :Author: Matthieu Schaller :Review Manager: Needed :Download: http://code.google.com/p/cpp-imaginary-numbers/ :Description: The library is an extension of the std::complex class addressing two issues: 1. The standard does not guaranty the behaviour of the complex class if instantiated with types other than float/double/long double. 2. Some calculation where pure imaginary numbers (i.e. multiples of sqrt(-1)) appear are unnecessarily slowed down due to the lack of support for these numbers. The code I submit contains two interleaved classes boost::complex and boost::imaginary which can be instantiated with any type T provided T overloads the usual arithmetic operators and some basic (real) mathematical functions depending on which complex function will be used. It is thus an extended version of Thorsten Ottosen's n1869 proposal (http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2005/n1869.html) Metaparse --------- :Author: Abel Sinkovics :Review Manager: Needed :Download: http://abel.web.elte.hu/metaparse/metaparse.zip :Description: Metaparse is a library for constructing parsers parsing at compile-time based on template metaprogramming. The parsers built with the library take boost::mpl::strings as input and can produce - types - objects (types with public static members) - callable C++ functions (types with public static method) - template metafunction classes as output (based on the input being parsed). On compilers supporting constexpr the library provides the following syntactic sugar for writing the input of the parsers: BOOST_STRING("this is a string") The library can be used for implementing DSLs in C++, including DSLs making C++ template metaprogramming easier (see examples). Polygon: Voronoi Extensions --------------------------- :Author: Andril Sydorchuk :Review Manager: Lucanus Simonson :Download: http://svn.boost.org/svn/boost/sandbox/gtl/ :Description: This library extends Boost.Polygon with the following features: - Robust and efficient implementation of the sweepline algorithm that allows to construct Voronoi diagram, Delaunay triangulation and medial axis of a set of points and line segments. - Coordinates of the output geometries are computed within the 64 machine epsilon relative error (6 mantissa bits). - Voronoi diagram data structure that allows efficient traversal and data association with the output Voronoi graph. - No 3rd party dependencies (e.g. GMP, MPFR), all the required multiple precision types are implemented as part of the library. - The input and output coordinate type domains are configurable via coordinate type traits, thus allowing to compute coordinates of the Voronoi vertices within any required precision. - The full construction of the Voronoi diagram of 100 000 points takes only 0.27 seconds (see benchmarks). Coroutine --------- :Author: Oliver Kowalke :Review Manager: Hartmut Kaiser :Download: http://gitorious.org/boost-dev/boost-dev/archive-tarball/coroutine :Description: This library is an implementation of coroutines and generators using Boost.Context. Range Extensions ---------------- :Author: Akira Takahashi :Review Manager: Neil Groves :Download: https://github.com/faithandbrave/OvenToBoost :Description: This project adds some features of the Oven Range Library to Boost.Range. Features: - Additional Range Adaptors (taken, taken_while, dropped, dropped_while, elements, elements_key, memoized, outdirected) - Extensions for using Lambda (regular function, regular operator) - Infinite Range (iteration function) - and additional range utilities. Contract -------- :Author: Lorenzo Caminiti :Review Manager: Dave Abrahams :Download: http://sourceforge.net/projects/contractpp/files/latest/download :Description: This library implements Contract Programming for the C++ programming language (see the end of this email). In addition, the library implements virtual specifiers (final, override, and new, see C++11), concept checking, and named parameters. This library is implemented for the C++03 standard and it does not require C++11. Nowide ------ :Author: Artyom Beilis :Review Manager: Needed :Download: http://cppcms.com/files/nowide/ :Description: This library makes cross platform Unicode aware programming easier. It provides an implementation of standard C and C++ library functions, such that their inputs are UTF-8 aware on Windows without requiring to use Wide API. ODEint ------ :Author: Karsten Ahnert and Mario Mulansky :Review Manager: Steven Watanabe :Download: https://github.com/headmyshoulder/odeint-v2 :Description: odeint provides routines for numerically solving Ordinary Differential Equations, a task heavily required when approaching scientific problems numerically. In odeint we have implemented the most common algorithms in a modern, generic way which provides several advantages over existing implementations. The main focus of odeint is to separate algorithms from the underlying basic computation unit. This allows for example to easily use the power of modern GPUs via CUDA or OpenCL to speed up computational heavy simulations. Array ----- :Author: Brian Smith :Review Manager: Needed :Download: https://github.com/BrianJSmith/Array :Description: The array class is a C++11 compatible implementation of static multidimensional arrays. TypeIndex --------- :Author: Antony Polukhin :Review Manager: Needed :Download: https://github.com/apolukhin/type_index :Description: TypeIndex is an extended C++11 type_index library, that * works with disabled RTTI * can store const-volatile-reference info about types (if user requested it) * has all the functionality of std::type_index * has portable across compilers and platforms functionality for getting demangled type names * works across modules/shared libraries * does not require C++11 to work Libraries under development =========================== See http://svn.boost.org/trac/boost/wiki/LibrariesUnderConstruction for a current listing of libraries under development.

1 0

[boost] [review] Multiprecision review results
by Jeffrey Lee Hellrung, Jr. 04 Aug '12

04 Aug '12

Summary -------- John Maddock and Christopher Kormanyos' Multiprecision library is ACCEPTED for inclusion into Boost, with 8 YES votes, 1 NO vote, and 1 CONDITIONAL vote. Details -------- Most reviewers noted that this was a sufficiently good first step toward extended precision arithmetic for inclusion into Boost. I think John and Chris will agree that there remains quite a bit of work left to do, but as one reviewer noted, John has an excellent track record regarding Boost development and Chris has been extremely dedicated during the pre-review development, review process, and post-review development, so I think this bodes well for the library's future. I'm going to highlight what I perceive to be some of the bigger issues raised by various individuals involved with in discussion, but I will share all my notes via Google Docs [1], and of course even further details are available in the mailing list archive. I note that many of the issues raised during the review have already been addressed by John and Chris. Mixed-Type Arithmetic -------- This has come up over and over again, especially in the context of allowing extended precision types within the same "family" to interoperate, which I think is tractable. Removing my review manager hat for a moment, perhaps a tag dispatching system similar to Boost.MPL or Boost.Fusion could be used, where all arithmetic types within the same family have the same tag, and hence only allow mixing types with the same tag. Most types will have a unique tag (which, I don't know, could default precisely to the arithmetic type?), but, e.g., Vicente's family of fixed-precision (and maybe even fixed-point) types would all be identifiable as being in the same family, and a traits class would determine the result types of the various arithmetic operations. Mixed-type arithmetic outside the above scope seems more tricky, but some users seem to still desire this in some form. Actual desired use cases will undoubtedly help here. Naming -------- Several commented on the redundancy of "mp_" prefix for identifiers already residing the boost::mp namespace. Narrowing Conversions -------- cpp_dec_float should round rather than truncate on narrowing conversions. Review manager hat off: I wonder if a radix-2 implementation of an arbitrary precision float should ultimately be prioritized and recommended over the present radix-10 implementation? It sounds like conversions in general should be reviewed, but I'm entirely sure myself where they all stand. If possible, narrowing conversions should be explicit while others (that would guarantee no loss of precision) may be implicit. This would be a departure from C++ builtin types. Performance -------- Phil, the lone NO vote, lamented that the scope of the library was evidently beyond simple fixed-precision (e.g., 128-bit or 256-bit) integral types, which is his desired use case. Indeed, at least in an earlier version of MP, expression templates seemed to give a performance penalty relative to using the raw back-end types; in theory, expression templates should give no performance hit, but compilers just may not be there yet. In any case, several reviewers requested that the scope of the library be clarified up front in the documentation. Regularization/Normalization of Back-End Behavior via Front-End -------- As Edward pointed out, different back-ends generally have different behavior on some "exceptional" cases, making use of the corresponding front-ends in generic contexts at times cumbersome (specifically when the generic context needs to handle said exceptional cases). A couple examples given were division-by-zero and conversion from a string with invalid characters. It is by no means *necessary* to regularize/normalize *all* such differences, but as many as possible and practical should be identified, considered, and documented. Separation of Data Structures and Algorithms -------- Though requested, John and Steven have maintained that this simply isn't very practical. I've gathered that there are too many special cases that (1) would make implementations a nightmare; and (2) would have be addressed very carefully (i.e., in a likely not-very-readable way) to avoid any performance hits. Since this has come up a few times, maybe something could be said in the documentation about this. Thanks to everyone who submitted reviews and participated in the discussion. Let me know if I left out anything you feel is particularly significant or inaccurate. - Jeff [1] https://docs.google.com/document/d/19YgtWBQt0lpjJoJDOtAlScZAZyOwzbHimiYTi-g…

1 0