- Boost - lists.preview.boost.org

Fwd: ODEInt review
by Steven Watanabe 02 Oct '12

02 Oct '12

-------- Original Message -------- Subject: ODEInt review Date: Wed, 26 Sep 2012 11:48:18 -0400 From: Reese, Greg Dr. <greg.reese(a)miamioh.edu> To: watanabesj(a)gmail.com <watanabesj(a)gmail.com> CC: Reese, Greg Dr. <greg.reese(a)miamioh.edu> Please always state in your review, whether you think the library should be accepted as a Boost library! Absolutely! - What is your evaluation of the design? Good. Good use of policies Is it necessary to set an initial step size on the adaptive integrators? Shouldn't they be able to figure this out on their own? If the size is needed, maybe it could have a default value so the user doesn't have to pass the argument. - What is your evaluation of the implementation? Appears to be good but I didn't look at code in detail. - What is your evaluation of the documentation? Excellent! Probably the best documentation of any Boost library. Suggestions: 1) Add general explanation of "observers", e.g., what they do, sample uses. 2) In documentation of example programs, add plots of outputs. These help users decide if the program ran correctly and if they're interpreting the outputs correctly - What is your evaluation of the potential usefulness of the library? Extremely useful to C++ programmers who want to incorporate ODE solutions into their code - Did you try to use the library? With what compiler? Did you have any problems? Used Microsoft Visual C++ 2012. No problems. - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? 2-3 hours. Read through documentation, ran a number of sample programs - Are you knowledgeable about the problem domain? Yes Suggestion for future (not current!) version - add capability for user routines to stop the Integration process. This is useful for breaking out of periodic solutions, for stopping the computations if the solution attains meaningless values, and for limiting the amount of running time. See, for example, "Event Location" at http://www.mathworks.com/help/matlab/math/ordinary-differential-equations.h… Perhaps this capability can be incorporated into the observers. Greg Reese

3 3

Fwd: [Review] ODEint review
by Steven Watanabe 02 Oct '12

02 Oct '12

-------- Original Message -------- Subject: [Review] ODEint review Date: Fri, 28 Sep 2012 22:56:56 +0200 From: André Bergner <andre.bergner.0(a)gmail.com> To: boost(a)lists.boost.org CC: watanabesj(a)gmail.com === ODEINT REVIEW === I vote for 'YES'. The library ODEint should be accepted and integrated into boost. Boost features many scientific/numeric applications already. Differential equations are fundamental enough to be added to boost's math/numeric category and enhance the scientific use cases of boost. _____________________________________________ What is your evaluation of the design? ODEint features a modern C++ (concept based as opposed to of polymorphism) which improves performance and flexibility tremendously. It demonstrates very well the power of a functional programming style - algorithms and containers are separated strictly. In particular parallelization comes almost for free by 'just' changing the container type. This is one very nice feature I like a lot. The design allows inter-portability to a great extend. Pretty much everything can be exchanged and adapted to specific needs. _____________________________________________ What is your evaluation of the implementation? I did not dive into all the internals deeply. But from what I've seen ODEint is well implemented and its internal structure make sense. Here the well designed interface helps the internals to be structured clearly as well. _____________________________________________ What is your evaluation of the documentation? The documentation is pretty good. It is covering many use-cases in detail and demonstrates the high flexibility of ODEint (CUDE/thrust, etc.) with many examples (missing a lot in some other boost libs). It becomes clear how it is used and what can be done with it. Nevertheless, for somebody not familiar with the topic of differential equations the purpose of the library is unclear from a quick glance into the overview. I would extend the overview with a short introduction (one or two paragraphs, links to wikipedia) of the topic, especially with some demonstrative example in words (e.g. physics engine in computer games or something similar). Concerning a more technical detail of the lib, I would like to have one large html file instead of many linked small ones. This would improve reading and in particular searching a lot. Btw., this is also true for many other boost libraries. I miss some notes about ODEint and C++11 (e.g. some obvious such as lambda should be mentioned, what about literals as units). Further, from a mathematical point of view also some comments about the application to partial differential equations would be useful. For somebody with experience in the field this might be obvious but for a beginner this would be helpful. _____________________________________________ What is your evaluation of the potential usefulness of the library? ODEint has many applications in a huge amount of scientific and engineering fields. It has the potential to become the de-facto standard for solving ODEs and high performance computing. Further, some less obvious use-cases might be: particle systems (quite popular in entertainment apps these days), network layout algorithm, etc... Within its field of application this library is very feature complete and can compete with many standard libs (matlab, python, ...) with ease. I think that ODEint makes the best compromise between simplicity in use and computational performance while not giving up general flexibility. It also features many things (error correction, symplectic methods, ...) not present in many competing libraries. _____________________________________________ Did you try to use the library? With what compiler? Did you have any problems? I was using the library for quite some time with several compilers (gnu, clang, intel). _____________________________________________ How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I was using the library one year age intensively. However, within this year I was not using it due to a different working field of mine. But I was following its improvements. _____________________________________________ Are you knowledgeable about the problem domain? Yes, I used the library extensively. I was successfully combining it with boost::graph to integrate network of coupled differential equations. Best regards, --- André Bergner

1 0

[1.52.0] Release branch closed except by permission, beta next week
by Marshall Clow 02 Oct '12

02 Oct '12

Hello everyone, The release branch is now closed for all changes except by permission from one of the release managers. The beta release is planned for next Monday. Please can you write your entries for the release notes soon. As always you can edit them directly using subversion at: https://svn.boost.org/svn/boost/website/public_html/live/feed/history/ Or you can email them to Daniel James <dnljms(a)gmail.com>. The release notes are linked from the main page soon after the beta is released, so it would be complete by then. Thanks, -- Marshall

1 2

[iterator] Minor comment typo in iterator_facade.hpp
by Team OSS 02 Oct '12

02 Oct '12

Hi! Patch attached for fixing it. It's our first contribution to the open-source community ;) Best regards, NINJA

2 1

Boost Range Joined Range
by Ali Nakipoglu 02 Oct '12

02 Oct '12

How can i create copy a joined_range type and it contents? Any alternatives to make this? For example typedef std::vector<int> VectorT; typedef joined_range< VectorT, VectorT> JoinedRangeT; VectorT vector0, vector1; JoinedRangeT joinedRange0( vector0, vector1 ) // I need this JoinedRangeT joinedRange1 = copyAnyRangeOrContainer( joinedRange0 ); Im planning to use your advices to design copyAnyRangeOrContainer function, so that it can create deep copies from given range or containers that are can be vector,map, joined_range<T1,T2> or even joined_range<joined_range<T1,T2>, joined_range<T1, T2> > Thank you! -- Ali Nakipoglu

3 2

[BGL] graph/properties.hpp (vertex_property) [PATCH]
by Shaun Jackman 01 Oct '12

01 Oct '12

Hi, vertex_property and edge_property should inherit publicly from vertex_property_type and edge_property_type. A patch follows. ./ContigGraph.h:55:39: error: 'type' is a private member of 'boost::mpl::eval_if<boost::detail::has_vertex_property_type<DirectedGraph<ContigProperties, Distance>, mpl_::bool_<false>>, boost::detail::get_vertex_property_type<DirectedGraph<ContigProperties, Distance>>, boost::no_property>' typedef typename vertex_property<G>::type vertex_property_type; ^ /usr/local/include/boost/graph/properties.hpp:251:49: note: constrained by implicitly private inheritance here template <class Graph> class vertex_property: vertex_property_type<Graph> {}; ^~~~~~~~~~~~~~~~~~~~~~~~~~~ Cheers, Shaun --- graph/properties.hpp.orig 2012-09-27 11:37:48.000000000 -0700 +++ graph/properties.hpp 2012-10-01 10:43:34.000000000 -0700 @@ -248,8 +248,8 @@ >::type type; }; - template <class Graph> class vertex_property: vertex_property_type<Graph> {}; - template <class Graph> class edge_property: edge_property_type<Graph> {}; + template <class Graph> class vertex_property: public vertex_property_type<Graph> {}; + template <class Graph> class edge_property: public edge_property_type<Graph> {}; template <typename Graph> class degree_property_map

2 2

[coroutine review] late review + comments
by Jeffrey Lee Hellrung, Jr. 01 Oct '12

01 Oct '12

Apologies to Hartmut, Oliver, and the community for my late presence regarding the recently reviewed Coroutine library. I finally had a good block of time this afternoon/evening to look through the documentation [1], so I figured, even if Hartmut doesn't count this as a formal review, at least Oliver can use these comments to improve the documentation. First, if I were to vote on whether Coroutine should be accepted, it would be CONDITIONAL ACCEPTANCE just based on present documentation issues. At a minimum, the documentation needs some fixing up, but I also think Oliver should address the design and interface suggestions Vicente, Eugene, and others (I myself haven't yet gone through the entire discussion yet, though I've been meaning to) have had, which mostly seem to have merit, and then present an updated. Unfortunately, I can't come up with a specific list of said suggestions, but I trust Oliver can pick through the discussion as well as I can :/ Second, I would really like to see some form of this library in Boost :) One thing that benefits the documentation of a library with a seemingly nontrivial design space (like Coroutine) is a comparison with past and present solutions. A quick google search of "c++ coroutine" found 3 libraries that ostensibly implement coroutines or an approximation thereof [2-4]. I haven't gone through these quite yet, but I'd like to see why one should use the proposed Coroutine library over these alternatives (even a 1-line justification, like "Library X lacks critical feature Y, by design" or "Library X does not work on platform Z" would be sufficient.) I think some documented research to justify the existence of this library is warranted. My specific comments on the documentation follow (I just copy/pasted from a Google document, so I hope this doesn't format badly...). I'm pretty sure some of what's below repeats what someone else has said, but, for completeness, I just included everything that initially came to mind as I was reading the documentation. - Rename namespace boost::coro to (e.g.) boost::coroutine or something similarly spelled out and not (arguably cryptically) abbreviated. - "Executing a coroutine" - s/it can migrated/it can be migrated/ - The first example uses “coro_t c( boost::bind( f, _1 ) );”; I’m confused as f is a binary function, but the boost::bind expression only works for unary functions. - “The coroutine-function, as well as its arguments, if any, are copied into the coroutine's state.” Can you elaborate on what you mean by “its arguments...are copied into the coroutine’s state”? You must mean when you call the coroutine, i.e., the copying of the coroutine-function and the copying of the coroutine-function’s arguments occur at different times, right? - The example with output uses ctx when (I believe) you mean c. Also, it implies that coroutine<>::is_complete actually executes the coroutine-function, which seems non-intuitive to me; I would expect it to be non-modifying and only indicate whether the coroutine-function has completed or not. - s/preemtive/preemptive - “Calling coroutine<>::operator()() from inside the same coroutine results in undefined behaviour.” Can you give an example of how one could possibly mistakenly do this? - s/allways/always - “The arguments passed to coroutine<>::operator()(), in one coroutine, is returned by coroutine<>::self_t::yield() in the other coroutine or, if it is the first call to coroutine<>::operator()() ( coroutine was not started), the coroutine-function will be entered and the arguments are passed to coroutine-function on entry.” I think I know what you’re trying to say here, but talking about 2 coroutines when your examples only have one coroutine object is ripe for confusion. Either clarify your terminology, clarify this explanation of the signature, or both. - The fact that self_t::yield() must package its return value into a boost::tuple (when the coroutine-function has more than one argument beyond self) suggests to me that we should strive for more uniformity between how the coroutine-function is initially entered (now with explicitly separate arguments) and subsequently continued (now with a packaged set of arguments). A couple of suggestions: - Force all coroutine-functions to be nullary or unary (sans the self argument); one can manually address more than one argument via boost::tuple packaging, and maybe boost::coro::coroutine could automatically package >1 argument up into a boost::tuple to convenience. You may also want to provide a macro (named, e.g., BOOST_TUPLE_UNPACK) that can can unpack a tuple into variables, e.g., something that looks like BOOST_TUPLE_UNPACK( ( int x ) ( int y ), tuple ); - Use a coroutine-function signature that looks something like void f(coro_t::self_t & self) { BOOST_TUPLE_UNPACK( ( int x0 ) ( int y0 ), self.arguments() ); // … BOOST_TUPLE_UNPACK( ( int x1 ) ( int y1 ), self.yield() ); } Perhaps equivalently, one can always call self.arguments() to get the most recently passed set of arguments. - “coroutine-function with multiple arguments” - Isn’t the boost::bind in this example superfluous? - “Exit a coroutine-function” - yield_break or yield_return? You mention both. - There are 2 “Important” notes on forced_unwind exceptions that appear to say the same thing. - “Stack unwinding” - I’m starting to get really confused by your uses of boost::bind; “boost::bind( fn, _1 )” when fn is a nullary function??? I guess you forgot the self_t argument? If so, again, why is boost::bind even necessary? Did you check that these examples actually compile? - The default behavior of the destructor of always unwinding the stack seems entirely reasonable, but the preconditions you list seem entirely unreasonable and unsafe! Basically, I’m reading that { coro::coroutine< void ( ) > c; } results in undefined behavior, as the preconditions for the destructor are not met. This almost has to be a documentation error. Further: “After unwinding, a coroutine is complete.” I was under the impression that unwinding only occurs in the destructor of the coroutine, at which point the coroutine object does not exist anymore, so what coroutine are you referring to, and even if you’re referring to the recently destructed coroutine, in what way is it complete? - “Executing a generator” - s/The default StackAllocator concept/The default StackAllocator/ - Be consistent on when you use StackAllocator, stack-allocator, etc. I.e., what do you mean by each? - “The first argument of generator-function...”: You mean the *only* argument? - s/The generator-function executed/The generator-function is executed/ - Same notes as at the bottom of “Executing a coroutine”. - “Exit a generator-function” - Again, yield_break or yield_return? - “boost::bind( fn, _1, _2 )” ??? Huh? How is “a” bound within fn, then??? - s/self_yield/self.yield/ - It’s unclear to me why a separate generator class is provided in addition to the coroutine class. Can you explain what the differences are? E.g., I don’t see why coroutine can’t also have an operator unspecified-bool-type () rather than is_complete. - “Performance” - 10 doesn’t seem like a very convincing sample size. If you can’t nail down the CPU cycles and time exactly via theoretical analysis of the assembly code, then I don’t see what’s preventing you from using a sample size several orders of magnitude larger than 10! Okay, now time to go through the second half of the recent Coroutine discussion... - Jeff [1] http://ok73.ok.funpic.de/boost/libs/coroutine/doc/html/index.html [2] http://code.mozy.com/projects/mordor/ [3] http://www.akira.ruc.dk/~keld/research/COROUTINE/ [4] http://dunkels.com/adam/pt/

2 1

[spirit] Symbols parser with overlapping symbols
by Andrey Semashev 01 Oct '12

01 Oct '12

Hi, I wonder how qi::symbols parser behaves when it contains partially overlapping symbols. For example: qi::symbols< char, int > syms; syms.add("a", 1); syms.add("aaa", 2); What will this parser return when "aaa" is passed as input? I couldn't find it in the docs.

2 1

[1.52.0] [request permission to merge to release] Changeset 80790
by Jeffrey Lee Hellrung, Jr. 30 Sep '12

30 Sep '12

As I was updating the Release Notes for 1.52.0, I thought about a recently introduced restriction on function_input_iterator (due to addressing ticket #5825 [1] in [2]) that could be relaxed. trunk changeset is here: https://svn.boost.org/trac/boost/changeset/80790 I think it's pretty benign but given that the release branch is closed tomorrow (Monday) and the beta rc is just a few days after that, I figured that whether and when this gets merged to release is up to the release managers. Please advise, - Jeff [1] https://svn.boost.org/trac/boost/ticket/5825 [2] https://svn.boost.org/trac/boost/changeset/80467

1 1

Inspection tool run
by Paul A. Bristow 30 Sep '12

30 Sep '12

I've been trying to get Boost.Math off the Sinners List on the Inspection Report at http://boost.cowic.de/rc/inspect-trunk.html#math. It last ran 25 July 12, so I can't see if I have succeeded yet. When can I expect it to run again? Paul --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow(a)hetp.u-net.com

8 12

[website] Latest version of page links
by Daniel James 30 Sep '12

30 Sep '12

Hello all, I finally got round to finishing off the links from old documentation to the latest version. It's a little hacked in so the markup isn't wonderful, and it only works for libraries whose documentation is altered by the site's php scripts. That's usually the documentation with no frames and the green header (some libraries put the green header in themselves, it won't work for them). At the moment it's just on the beta site, for example: http://beta.boost.org/doc/libs/1_49_0/libs/phoenix/doc/html/index.html Not all pages have a page in the same location in the most recent version, so for some pages you will just get a link to the latest documentation list: http://beta.boost.org/doc/libs/1_41_0/doc/html/boost/units/si/constants/cod… This will go live soonish. I might tweak it a little first, maybe change the wording on the notices, but it's pretty much done for now. Please try it out with your favourite documentation to check I haven't made too much of a mess. thanks, Daniel

2 2

Review Wizard Status Report for September 2012
by Ronald Garcia 29 Sep '12

29 Sep '12

============================================== Review Wizard Status Report for September 2012 ============================================== News ==== 1. Boost 1.51.0 Released. New Libraries: 1) Context 2. Multiprecision Accepted 3. Type Erasure Accepted 4. Contract Reviewed 5. Coroutine Reviewed 6. ODEInt Reviewed 7. Contract Accepted 8. Polygon Extensions integrated into Polygon Open Issues =========== The following libraries have review managers, but have not yet been scheduled for review: * Range Extensions - added May 2012; review manager: Neil Groves. The following libraries have been reviewed and await reports from their review managers: * Predef - reviewed February 2012; review manager: Joel Falcou. * Coroutine - reviewed September 2012; review manager: Hartmut Kaiser. 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. * Contract - accepted September 2012; author: Lorenzo Caminiti. 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. 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 * Nowide (M) * 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. 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. 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.

3 5

[Review] ODEInt review starts today, September 19, ends September 28
by Steven Watanabe 28 Sep '12

28 Sep '12

AMDG The review of Karsten Ahnert and Mario Mulansky's ODEInt library starts today September 19th and will end on September 28. -------------------------------------- About the library: 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. Features: - provides most of the standard algorithms, including step size control, dense ouput and extrapolation routines - symplectic routines for Hamiltonian systems - implicit routines based on boost::ublas (MTL4 in progress) - high level integrate functions - interchangeable computation backend with existing bindings to CUDA and OpenCL - native support of ODEs defined for complex values - support of Boost.Units in most of the algorithms - support of arbitrary precision types You can download the library and view the documentation here: zip: http://github.com/headmyshoulder/odeint-v2/zipball/master github: http://headmyshoulder.github.com/odeint-v2/ docs: http://headmyshoulder.github.com/odeint-v2/doc/index.html -------------------------------------- Please always state in your review, whether you think the library should be accepted as a Boost library! Additionally please consider giving feedback on the following general topics: - 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? In Christ, Steven Watanabe

6 8

Contributing a thread pool class
by BOLTON Gawain 28 Sep '12

28 Sep '12

Hello, It seems that boost's "thread" library does not have a thread pool class. It does have a thread_group class but this class is has the following limitations: 1. It does not limit the number of threads created. 2. Threads added are not managed and raw pointers are used exposing the developer to memory leaks. 3. The API deals with threads and not "tasks" to be executed by a thread. As such I have developed a thread pool class which allows for: · A maximum number of "worker" threads to configured. · Arbitrary "tasks" to be submitted by any thread and executed by one of the worker threads. o Worker threads are created as and when needed. · Worker threads can terminate after being idle a configurable amount of time. o They will be re-created if needed afterwards. The amount of code is quite small (< 500 lines including blank lines, API usage document in the header file and comments) and just uses standard C++ and boost thread functionality. My question is, would the boost community be interested in such a contribution to the thread library? I apologize in advance if this is the Nth time such a contribution has been proposed and rejected. I have developed this while working for my employer (a French bank called Société Générale). I have my manager's support and am in the process of obtaining agreement from my employer to get permission to submit the thread pool class developed. Cheers, Gawain Bolton Domino Development ITEC/CTT/GEF/TED 17 cours Valmy 92 800 Puteaux France Telephone : +33 1 42 13 52 43 ************************************************************************* This message and any attachments (the "message") are confidential, intended solely for the addressee(s), and may contain legally privileged information. Any unauthorised use or dissemination is prohibited. E-mails are susceptible to alteration. Neither SOCIETE GENERALE nor any of its subsidiaries or affiliates shall be liable for the message if altered, changed or falsified. ************ Ce message et toutes les pieces jointes (ci-apres le "message") sont confidentiels et susceptibles de contenir des informations couvertes par le secret professionnel. Ce message est etabli a l'intention exclusive de ses destinataires. Toute utilisation ou diffusion non autorisee est interdite. Tout message electronique est susceptible d'alteration. La SOCIETE GENERALE et ses filiales declinent toute responsabilite au titre de ce message s'il a ete altere, deforme ou falsifie. *************************************************************************

3 2

Release branch closing for new features
by Marshall Clow 27 Sep '12

27 Sep '12

[ resending because it doesn't seem to have gone through ] So, we missed announcing this on Monday, so we're pushing back the deadline until Friday. On (tomorrow) Friday, Sep 29th, the release branch will close for new features, and be open only for bug fixes and doc fixes. On Tuesday, October 2nd, the release branch will close except by permission from the release managers. This is in preparation for the first 1.52.0 beta, scheduled for Monday, Oct 8th. -- The release managers

1 0

[reminder] [Review] ODEInt review ends tomorrow September 28
by Steven Watanabe 27 Sep '12

27 Sep '12

AMDG The review of Karsten Ahnert and Mario Mulansky's ODEInt library will end tomorrow. Only a few reviews have been submitted so far. If you plan to submit a review, please let me know. If anyone needs more time, we can see about extending the review period. -------------------------------------- About the library: 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. Features: - provides most of the standard algorithms, including step size control, dense ouput and extrapolation routines - symplectic routines for Hamiltonian systems - implicit routines based on boost::ublas (MTL4 in progress) - high level integrate functions - interchangeable computation backend with existing bindings to CUDA and OpenCL - native support of ODEs defined for complex values - support of Boost.Units in most of the algorithms - support of arbitrary precision types You can download the library and view the documentation here: zip: http://github.com/headmyshoulder/odeint-v2/zipball/master github: http://headmyshoulder.github.com/odeint-v2/ docs: http://headmyshoulder.github.com/odeint-v2/doc/index.html -------------------------------------- Please always state in your review, whether you think the library should be accepted as a Boost library! Additionally please consider giving feedback on the following general topics: - 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? In Christ, Steven Watanabe

1 0

heap corruption on windows due to windows_file_codecvt
by Pedro Larroy 27 Sep '12

27 Sep '12

Hi When using debug mode in windows with boost_filesystem there's "Debug Assertion Failed!" in _CtrIsValidHeapPointer When operator new is redefined it causes windows_file_codecvt not to be released with the matching release that it allocated it. We reported this to Microsoft as seems it's a bug in their STL. But so far, I tried with VS2012 and the bug seems not fixed... There's a workraround in boost that we are using for the moment: This has to be changed in path.cpp to fix it: - std::locale loc(global_loc, new windows_file_codecvt); + std::locale loc(global_loc, _NEW_CRT windows_file_codecvt); Should this fix be applied in boost until is fixed on Microsoft's side? This is a very nasty issue that will happen only with a redefined operator new. (For example we are using new with the sacalable allocator of tbb). Regards. Pedro.

1 0

[context] boost::ctx::?
by Dave Abrahams 27 Sep '12

27 Sep '12

ctx seems like a needlessly short abbreviation. Wouldn't it be better and more consistent with the rest of Boost to ask users to write using namespace ctx = boost::context; if they want something short? -- Dave Abrahams BoostPro Computing Software Development Training http://www.boostpro.com Clang/LLVM/EDG Compilers C++ Boost

9 13

[shared_ptr][thread] spinlock initialization
by Yi Ding 27 Sep '12

27 Sep '12

I started using the spinlock in boost/smart_ptr/detail/spinlock.hpp and discovered that it needs to be manually initialized, even for the spinlock_sync version, which became a nasty bug when it manifested itself. This seems a bit out of sync with the rest of the mutexes in boost::thread. Now, I'm guessing that the fact that the spinlock is in boost::detail means that it's not really for outside consumption (newbie boost user here), but is there something in the works that will be? In the meantime, would it be possible to automatically initialize the spinlock (trivial in the case of spinlock_sync) or are there architectural issues with that? Otherwise, could we add a comment that says "in order to use these spinlocks you must initialize with BOOST_DETAIL_SPINLOCK_INIT" or "move along, these aren't the spinlocks you're looking for."

3 2

Problem using dijkstra_shortest_paths with Boost 1.51
by John Wiegley 27 Sep '12

27 Sep '12

Hello, I tried building my Ledger project today with Boost 1.51 and clang --std=c++11, and received the following error: --8<---------------cut here---------------start------------->8--- /usr/local/include/boost-1_51/boost/mpl/eval_if.hpp:38:26: error: no type named 'type' in 'boost::no_property' typedef typename f_::type type; ~~~~~~~~~~~~~^~~~ [...] /Users/johnw/Projects/ledger/src/history.cc:455:3: note: in instantiation of function template specialization 'boost::dijkstra_shortest_paths<boost::filtered_graph<boost::adjacency_list<boost::vecS, boost::vecS, boost::undirectedS, boost::property<boost::vertex_name_t, const ledger::commodity_t *, boost::property<boost::vertex_index_t, unsigned long, boost::no_property> >, boost::property<boost::edge_weight_t, long, boost::property<boost::edge_price_ratio_t, std::__1::map<boost::posix_time::ptime, ledger::amount_t, std::__1::less<boost::posix_time::ptime>, std::__1::allocator<std::__1::pair<const boost::posix_time::ptime, ledger::amount_t> > >, boost::property<boost::edge_price_point_t, ledger::price_point_t, boost::no_property> > >, boost::property<boost::graph_name_t, std::__1::basic_string<char>, boost::no_property>, boost::listS>, ledger::recent_edge_weight<boost::adj_list_edge_property_map<boost::undirected_tag, long, long &, unsigned long, boost::property<boost::edge_weight_t, long, boost::property<boost::edge_price_ratio_t, std::__1::map<boost::posix_time::ptime, ledger::amount_t, std::__1::less<boost::posix_time::ptime>, std::__1::allocator<std::__1::pair<const boost::posix_time::ptime, ledger::amount_t> > >, boost::property<boost::edge_price_point_t, ledger::price_point_t, boost::no_property> > >, boost::edge_weight_t>, boost::adj_list_edge_property_map<boost::undirected_tag, ledger::price_point_t, ledger::price_point_t &, unsigned long, boost::property<boost::edge_weight_t, long, boost::property<boost::edge_price_ratio_t, std::__1::map<boost::posix_time::ptime, ledger::amount_t, std::__1::less<boost::posix_time::ptime>, std::__1::allocator<std::__1::pair<const boost::posix_time::ptime, ledger::amount_t> > >, boost::property<boost::edge_price_point_t, ledger::price_point_t, boost::no_property> > >, boost::edge_price_point_t>, boost::adj_list_edge_property_map<boost::undirected_tag, std::__1::map<boost::posix_time::ptime, ledger::amount_t, std::__1::less<boost::posix_time::ptime>, std::__1::allocator<std::__1::pair<const boost::posix_time::ptime, ledger::amount_t> > >, std::__1::map<boost::posix_time::ptime, ledger::amount_t, std::__1::less<boost::posix_time::ptime>, std::__1::allocator<std::__1::pair<const boost::posix_time::ptime, ledger::amount_t> > > &, unsigned long, boost::property<boost::edge_weight_t, long, boost::property<boost::edge_price_ratio_t, std::__1::map<boost::posix_time::ptime, ledger::amount_t, std::__1::less<boost::posix_time::ptime>, std::__1::allocator<std::__1::pair<const boost::posix_time::ptime, ledger::amount_t> > >, boost::property<boost::edge_price_point_t, ledger::price_point_t, boost::no_property> > >, boost::edge_price_ratio_t> >, boost::keep_all>, f_max<long>, boost::distance_combine_t, boost::bgl_named_params<boost::iterator_property_map<long *, boost::vec_adj_list_vertex_id_map<boost::property<boost::vertex_name_t, const ledger::commodity_t *, boost::property<boost::vertex_index_t, unsigned long, boost::no_property> >, unsigned long>, long, long &>, boost::vertex_distance_t, boost::bgl_named_params<boost::iterator_property_map<unsigned long *, boost::vec_adj_list_vertex_id_map<boost::property<boost::vertex_name_t, const ledger::commodity_t *, boost::property<boost::vertex_index_t, unsigned long, boost::no_property> >, unsigned long>, unsigned long, unsigned long &>, boost::vertex_predecessor_t, boost::no_property> > >' requested here dijkstra_shortest_paths(fg, /* start= */ vs, ^ --8<---------------cut here---------------end--------------->8--- My graph type is: typedef adjacency_list <vecS, // Store all edges in a vector vecS, // Store all vertices in a vector undirectedS, // Relations are both ways // All vertices are commodities property<vertex_name_t, const commodity_t *, property<vertex_index_t, std::size_t> >, // All edges are weights computed as the absolute difference between // the reference time of a search and a known price point. A // filtered_graph is used to select the recent price point to the // reference time before performing the search. property<edge_weight_t, long, property<edge_price_ratio_t, price_map_t, property<edge_price_point_t, price_point_t> > >, // Graph itself has a std::string name property<graph_name_t, std::string> > Graph; The full source is located here: https://github.com/jwiegley/ledger/blob/next/src/history.cc What has changed in Boost.Graph since 1.50? The same code builds fine with all the same compiler options using that version. Thanks, -- John Wiegley BoostPro Computing Software Development Training http://www.boostpro.com Clang/LLVM/EDG Compilers C++ Boost

2 4

[odeint] Documentation comments
by John Bytheway 27 Sep '12

27 Sep '12

This is not a review, just a few things I've caught while reading the odeint docs. Mostly cosmetic issues, but a couple of deeper questions. * http://headmyshoulder.github.com/odeint-v2/doc/boost_numeric_odeint/getting… - "They also occur if partial differential equations (PDEs) are discretized in one coordinate."; wouldn't you have to discretize in all but one coordinate? * http://headmyshoulder.github.com/odeint-v2/doc/boost_numeric_odeint/getting… - I see no mention of any headers except the global one boost/numeric/odeint.hpp. Is it useful or possible to include only parts of the library? * http://headmyshoulder.github.com/odeint-v2/doc/boost_numeric_odeint/getting… - "a simple function calculating f(x)'"; I think you mean either "f(x)" or "x'", not "f(x)'". * http://headmyshoulder.github.com/odeint-v2/doc/boost_numeric_odeint/tutoria… - There's one case here where you use "--" as an em dash. "on the example of explicit_error_rk54_ck -- a 5th order Runge-Kutta method". There are various other places throughout the docs which use just "-" for em dash. It would be best if you could use a proper em dash character, but in any case you should be consistent. * http://headmyshoulder.github.com/odeint-v2/doc/boost_numeric_odeint/tutoria… - "which lead to the whole new subject of Chaos Theory"; s/lead/led/ * http://headmyshoulder.github.com/odeint-v2/doc/boost_numeric_odeint/tutoria… - "the so called Rosenbrock method"; is "so called" necessary? * http://headmyshoulder.github.com/odeint-v2/doc/boost_numeric_odeint/tutoria… - "the first numerical experiment which has been implemented on a computer in 1953. It was studied at Los Alamos on one of the first computer (a MANIAC I) and it triggered a whole new tree of mathematical and physical science."; This is ambiguous (it could mean the first experiment amongst those in 1953). If you really mean it was the first computational numerics experiment then you should probably say something like "the first numerical experiment to be implemented on a computer. It was studied at Los Alamos in 1953 on one of the first computers (a MANIAC I) and triggered a whole new tree of mathematical and physical science." - "For example the unit test for Boost.Units take up to 4 GB of memory at compilation."; are you referring to the unit tests of Boost.Units, or a unit test of odeint that uses Boost.Units? Please clarify. - The matrix-as-state example has a bug: for( size_t j=0 ; j<x.size2() ; ++j ) dxdt( 0 , j ) = dxdt( 0 , x.size1() -1 ) = 0.0; should be for( size_t j=0 ; j<x.size2() ; ++j ) dxdt( 0 , j ) = dxdt( x.size1() -1, j ) = 0.0; This bug makes me think that you ought to provide a debug mode where every entry in dxdt is set to NaN before calling the system operator(), and then they are checked to be non-NaN afterwards. Of course, this would only work for types with a NaN value, but I think all your examples do have that (except maybe the multiprecision types). - "This is in principle all"; awkward phrasing, perhaps "In principle this is all" - I assume you know about the unfinished chunk of docs re PDEs and equations on networks. - "for full support the min( x , y ), max( x , y ), pow( y , y ) must be callable"; what are x and y? Is it significant that pow has both arguments equal but min and max don't? I hope the requirements on the numeric type are laid out more formally elsewhere; please link to that. - "We exemplary show this for a Hamiltonian system"; "exemplary" doesn't work here. You could use s/exemplary show/demonstrate/. * http://headmyshoulder.github.com/odeint-v2/doc/boost_numeric_odeint/tutoria… - "simply to small"; s/to/too/ * http://headmyshoulder.github.com/odeint-v2/doc/boost_numeric_odeint/odeint_… - "Implicit solvers do only work"; s/do // - "They safe a part of their history" s/safe/save/ - In the section on controlled steppers, the formulae are getting sufficiently complex that it might be worth trying to use TeX-generated pngs rather than straight HTML (as is done in Boost.Math, e.g. <http://www.boost.org/doc/libs/1_51_0/libs/math/doc/sf_and_dist/html/math_to…>) - I can't figure out what the three lines after table 1.6 are about. - The long line "boost::numeric::odeint::result_of::make_dense_output< r..." in Dense output steppers is too long for my screen; can you break it? - The resizing policy names are a bit clumsy; I think always_resize, initially_resize, and never_resize might be better. - "Typical use cases for this kind of resizer are self expanding lattices like shown in the tutorial"; can you link to the relevant example in the tutorial? - "So it might be suitable that the system function itself is a pair of functions, one for computing the deterministic and one for the stochastic part. The first element of the pair simply computes the deterministic part while the second the stochastic one."; this is rather redundant; how about "So it might be suitable that the system function is a pair of functions. The first element of the pair computes the deterministic part and the second the stochastic one." * http://headmyshoulder.github.com/odeint-v2/doc/boost_numeric_odeint/odeint_… - Personally I think the ranges are more useful than the iterators, so it would be nice if they were mentioned in the section title (e.g. "Iterators and Ranges") - "that is you write the above example in a shortified form"; "shortified" is not a word; perhaps "so you can write this example in a more succinct form". * http://headmyshoulder.github.com/odeint-v2/doc/boost_numeric_odeint/odeint_… - The note "odeint already includes all the code presented here, see gsl_wrapper.hpp, so gsl_vectors can be used straight out-of-box. The following description is just for educational purpose." is duplicated in the subsequent paragraph. - Using x/y for element-wise division in vector_space_algebra seems potentially contentious. Similarly for abs. Perhaps it would be better to provide a customization point in boost::numeric::odeint as you have done with vector_space_reduce, whose default implementations use / and abs as in the current scheme. That way people will not be required to implement potentially misleading operators for their types. - "vector_space_reduce_impl< state_type >::reduce( state , operator , init )"; you probably shouldn't use the keyword "operator" as an identifier here. * http://headmyshoulder.github.com/odeint-v2/doc/boost_numeric_odeint/odeint_… - "the state_type of the stepper must not necessarily be used to call the do_step method"; I'm not sure what this means; should it be "the state_type of the stepper need not necessarily be used to call the do_step method" * http://headmyshoulder.github.com/odeint-v2/doc/boost_numeric_odeint/concept… - Concepts are normally written without underscores, so SymplecticSystem rather than Symplectic_System. * http://headmyshoulder.github.com/odeint-v2/doc/boost_numeric_odeint/concept… - In various places you have ScaleSum/N/ with literal '/' characters, where I presume they were intended to be formatting to make 'N' italics. - Rather than having a dedicated array_algebra, could you not have range_algebra automatically switch to the more efficient implementation when it detects a suitable State type? I hope to get a chance to play with the library later and submit a proper review. For now, congratulations on an impressive library. John Bytheway

3 6

[test] Patches to improve test log detail for better thirdparty integration
by Jamie Allsop 26 Sep '12

26 Sep '12

In light of recent discussions regarding Boost.Test I've created 3 tickets in trac with patches against trunk that incrementally improve the ease with which Boost.Test can be integrated with thirdparty continuous integration tools, while at the same time improving the output offered. These are patches we've been using for some time locally, the recent discussions highlighted the importance of pushing patches like these to a wider audience. In summary the key changes are: * https://svn.boost.org/trac/boost/ticket/7410 * all test cases/suites have file and line information captured so that external tools can use the Boost.Log output to create links into the source tree, answering questions like, "What is this test case?". It is possible to simply follow the link and see. * https://svn.boost.org/trac/boost/ticket/7417 * update the Boost.Test log output to include summary status information when a test case or suite is completed. This includes the test status, assertions passed and total assertions. This allows live test status to be viewed and nicer tools to be built around this. For example each test can be shown starting, in progress and then complete with the resulting status in detail. I should note that Boost.Test reports currently output this additional test status but this is done only on completion of all tests and so cannot be used to show live progress. * this additional test status as part of the log can be easily captured using regular expressions if HRF is used and many IDEs will allow colourisation, autolinking and so on using similar approaches. * https://svn.boost.org/trac/boost/ticket/7397 * update Boost.Test to use the new Boost.Timer classes introduced in Boost 1.48. This can be suppressed through the use of a macro should the old timers be preferred. The new Boost.Timer provides much better timing information than the old Boost.Timer library. You should refer to the library itself for an explanation of why the previous timer library was deprecated: http://www.boost.org/doc/libs/1_51_0/libs/timer/doc/index.html These patches address what I believe to be important missing features of Boost.Test. We have been using these patches in our systems with Boost 1.49 and enjoy very nice CI integration with Trac Bitten and our Scons build tools. I would therefore encourage those that use Boost.Test and who are interested in these patches in general to take a look. The Boot.Timer patch is important as it also addresses compile issues. See the recent thread here: http://thread.gmane.org/gmane.comp.lib.boost.devel/234411 Gennadiy - assuming you find these acceptable they could be committed to trunk. I don't have commit privileges to do it myself and besides they need reviewed first. Also I would prefer a closer look was taken at the impact they might have on Boost.Test's tests. Finally I should also note that one reason for providing the BOOST_TEST_USE_DEPRECATED_TIMER macro was to circumvent the issue of the new Boost.Timer depending on Boost.System. I don't recall if Boost.System can used header-only? I certainly remember a lot of discussion about it. Jamie

2 2

[test] Support use of test tools and report generation in non-test programs - facilitating test/validation modes
by Jamie Allsop 26 Sep '12

26 Sep '12

An important use case that we have is the ability to run test scenarios on a production binary by specifying a 'test' mode. In test mode we essentially run through a series of different scenarios, asserting various conditions, comparing expected results and so on. In order to minimise the custom code we needed for this we decided to make use of Boost.Test. All the test tools are there, report generation and so on. In addition we have all the report analysis tools in place to interpret the output. The problem however, is that Boost.Test essentially requires a custom main() function. Either one of the ones provided by Boost.Test or one performing Boost.Test specific initialisation. In our production systems we have, like many, a fairly standard main() that ensures uniform behaviour across binaries and we do not want to pollute that with Boost.Test specific code. Notably we also do not want to pollute our command line parameters or configuration with 'global' Boost.Test arguments to control the test report output. Finally we want to control exactly when the tests are executed. I've created ticket #7419 to cover this use case and have also attached a small patch that facilitates the capabilities required to support it. https://svn.boost.org/trac/boost/ticket/7419 Essentially the patch does two things: * It allows boost::unit_test_framework::init() to be called more than once. The result is to reset the test status and master test suite so that new tests can be added and new reports generated through multiple calls. The CLA parsing is also reset. Recent changes to this code may make my call to clear() redundant. I'll let Gennadiy be the judge of that. * This first change then allows the framework setup and teardown to be encapsulated in a helper class (not provided in the patch but one could be). In our systems we use a helper class that exposes a simple API that allows the user to implement a method where test units can be added directly to the master test suite - see the ticket for an example. As I said the patch focuses solely on enabling the possibility of writing such a class, not the class itself. * It provides scoped Boost.Test arguments for the commandline when BOOST_TEST_USE_QUALIFIED_COMMANDLINE_ARGUMENTS is defined. All command line arguments are then called --boost.test.<argument> for example --boost.test.log_level instead of --log_level. This of course means that all Boost.Test related arguments will not clash with any program arguments. On its own this is a generally useful feature as it allows custom main() functions to pass arguments down to other components during simple unit testing. The patch attached is based on a patch against boost 1.49. The one attached to the ticket is for trunk. Again this is a small patch that is genuinely useful so I'd like to see it make its way into trunk. As far as I know there are no side-effects for adding these changes, tests all pass and so on. Jamie

1 0

Formal Review Request [stl_ext_adv]
by Vadim Stadnik 26 Sep '12

26 Sep '12

Hi all, I would like to request a formal review of the library “STL extensions based on advanced data structures” [stl_ext_adv]. Project location: https://github.com/vstadnik/stl_ext_adv_review Quick view of documentation: http://dl.dropbox.com/u/51041088/stl_ext_adv_review/doc/index.html The previous version of this library is based on dynamically allocated data structures. It was discussed by Boost community in this thread: http://boost.2283326.n4.nabble.com/stl-ext-adv-Interest-in-advanced-data-st… The new version has two major improvements. It offers more efficient array based data structures and extensions of move semantics functions of STL containers. I am looking for the review manager. I would really appreciate if someone interested in advanced data structures could take this role. Early comments are welcome! Regards, Vadim Stadnik SUMMARY The proposed library [stl_ext_adv] offers augmented array based B+ trees and STL containers that support the interfaces of the C++03 sequences and associative containers. The library offers a number of extensions and performance improvements that are not available in C++03 and C++11 standard containers. OVERVIEW Both sequences and associative containers support: - random access iterators; - logarithmic time insert and erase operations for a single element anywhere within a container; Sequences support: - the union of interfaces of the C++03 sequence containers: std::list, std::deque and std::vector; - complete set of move semantics functions splice() and split() that guarantee logarithmic complexity in the worst case; Associative containers support: - equally efficient access to elements by their keys and positions; - logarithmic time search operations using keys of the container elements; - logarithmic time split operations in the general case and logarithmic time merge operations in special cases. One basic container implements the efficient algorithm accumulate(), which sums up any consecutive elements of a container in logarithmic time. The algorithm is fundamental to many important applications, such as the numerical integration and statistics. The array based data structures improve locality of reference and offer more efficient algorithms against equivalent dynamically allocated data structures. The wide set of the efficient member functions provided by the new containers makes them useful to improve the performance of algorithms using the standard containers with at least one relatively inefficient operation or a bidirectional iterator.

1 0

Boost/utility : addressof.hpp Error due to usage of Werror flag.
by GAURAV GUPTA 26 Sep '12

26 Sep '12

Hi , While using Boost (ver 1.51.0) file "addressof.hpp" I am getting following errors: *Boost/1.51/Inc/boost/utility/addressof.hpp:41:69: error: cast from 'char*' to 'std::vector<std::pair<std::basic_string<char>, std::basic_string<char> > >*' increases required alignment of target type [-Werror=cast-align] cc1plus: all warnings being treated as errors* I need to use "Werror" flag in my application. Any solution for this problem? *It works fine if i use . Is it the correct solution?* diff -Naur a/boost/utility/addressof.hpp boost/utility/addressof.hpp --- a/boost/utility/addressof.hpp +++ boost/utility/addressof.hpp @@ -37,7 +37,8 @@ static inline T * f( T & v, long ) { return reinterpret_cast<T*>( - &const_cast<char&>(reinterpret_cast<const volatile char &>(v))); + reinterpret_cast<void*>(&const_cast<char&>(reinterpret_cast<const volatile char &>(v)))); } -- Regards, Gaurav

1 0