March 2012 - Boost - lists.boost.org

[contract] syntax redesign
by Lorenzo Caminiti 04 May '12

04 May '12

Hello all, After a long time of inactivity for Boost.Contract, I am considering how to re-design its macro syntax to make it simpler. I can eliminate a large number of extra parenthesis based on a few pp tricks I've learned in processing Boost.Local's `const bind(type)& var`. Plus, I can provide (optional) support for variadics macros so to use comma-separated pp tuplets instead of parenthesized pp sequences on preprocessors with variadics. For example, I _think_ (but I've not implemented this yet) that I can simplify the syntax like this: #include <contract.hpp> #include <vector> #include "myvector/pushable.hpp" // Wrapper class that adds contracts to std::vector. CONTRACT_CLASS( template( typename T ) class (myvector) extends( public pushable<T> ) // Subcontracting. ) { CONTRACT_CLASS_INVARIANT( empty() == (size() == 0) // More invariants here (comma separated)... ) CONTRACT_FUNCTION( public void (push_back)( (const T&) element ) precondition( size() < max_size() // More preconditions here (comma separated)... ) postcondition( auto old_size = CONTRACT_OLDOF(size()), // Old value. size() == old_size + 1 // More postconditions here (comma separated)... ) ) { vector_.push_back(element); // Implementation. } // Rest of the class here (with more contracts if needed)... public: typedef typename std::vector<T>::size_type size_type; size_type size(void) const { return vector_.size(); } size_type max_size(void) const { return vector_.max_size(); } bool empty(void) const { return vector_.empty(); } const T& back(void) const { return vector_.back(); } private: std::vector<T> vector_; }; For a side-by-side comparison with N1962 syntax: http://svn.boost.org/svn/boost/sandbox/contract/libs/contract/doc/html/inde… For a comparison of the entire std::vector (plus Boost.ConceptCheck concepts): http://svn.boost.org/svn/boost/sandbox/contract/libs/contract/doc/html/cont… For a comparison for all Boost.Contract features (plus Boost.ConceptCheck concepts and Boost.Parameter named parameters): http://svn.boost.org/svn/boost/sandbox/contract/libs/contract/doc/html/cont… (Don't pay attention to the rest of the docs that are way out of date.) A few notes: * Extra parenthesis are still needed around class and function names. * Extra parenthesis are still needed around types (like for the parameter `(T) element`) but only if the type is not a C++ keyword (no parenthesis needed aournd int, double, void, etc) or it contains a symbol (parenthesis needed if & or * are used `(int&) x`, etc). * In postconditions, the `auto old_size = CONTRACT_OLDOF(size())` only copies the vector size (and not the entire vector :)) ). Similarly, `auto result = return` can be used to access the return value for non-void functions. (The `auto ...` is parsed by the pp and it's implemented using Boost.Typeof so no C++0x is required.) * Template declaration (but not instantiation) angular parenthesis <> are replaced by round parenthesis (). All of this _should_ be implementable in pure ISO C++. What do you think? Based on the discontent that the previous "parenthesized" syntax generated among Boosters, the key question is: Would you consider this new syntax usable?? Thanks, --Lorenzo

5 45

Review request: extended complex number library
by Matthieu Schaller 02 May '12

02 May '12

Dear all, Following the comments from V. Escriba, I formally propose my complex number library for review. The library is an extension of the std::complex class addressing two issues: - The standard does not guaranty the behaviour of the complex class if instantiated with types other than float/double/long double. - 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) Performance tests show some non-negligible speed-ups compared to std::complex for calculations where pure imaginary numbers are involved. A speed-up of 25% has been observed when solving the Schroedinger equation explicitly on a regular mesh and some comparable figures can be observed when computing the Mandelbrot set (the two examples snippets provided in the archive). Furthermore, the functions (sin(), exp(), log(),...) involving boost::imaginary numbers are more precise than their equivalent using a std::complex with the real part set to 0. The code and (doxygen) documentation is available in the repository http://code.google.com/p/cpp-imaginary-numbers/ A comprehensive zip archive can be found in the "download" and the code can also be checked-out via the SVN repository. The archive contains the class header, two examples, a comprehensive precision test, a brute-force performance test and the documentation. I'd be happy to answer any question from your side and to provide more detailed information if required. Regards, Matthieu -- Matthieu Schaller PhD student - Durham University

8 23

Re: [boost] Slow Bugs Tracker
by Olaf van der Spek 29 Apr '12

29 Apr '12

Hi, A few months ago there seemed to be plans to improve Trac. What's the status of those plans? Trac is still slow as hell. http://lists.boost.org/Archives/boost/2011/12/188639.php http://lists.boost.org/Archives/boost/2011/12/188937.php -- Olaf

7 44

Boost.ntree_container (bi_tree, quad_tree, oct_tree, etc ptr containers) Is there any interest in this?
by Dan Walters 27 Apr '12

27 Apr '12

Hi all, I am proposing adding spacial containers for efficiently storing and accessing data of a spacial nature in fixed size trees. n-tree data structures would be useful where data relates to a 1D, 2D or 3D location, providing n-array searching of an n-array volume. N-tree data structures are commonly used in 3d applications, and are rarely particularly specialized. Their use is fundamental however they are frequently written by application programmers, due to a lack of free open source implementations (to the limit of my research). Their sophistication, like any container, is slim but easy to get wrong and beyond the ability and time contraints that should be assumed of the application programmer. It is a flexible and standard enough concept that a single implementation can be expected to meet a majority of requirements. I think there is the opportunity to create a solid implementation of templated n-tree pointer containers. The ntree container would be a tree representing an narray of elements with all dimensions being the same and being a power of two. The tree is memory efficient where areas within the volume are not occupied, and so "branches" and "leaves" are not created. The tree is well suited to geometrical operations such as ray picking or plane culling of the volume. An n-tree structure could be used in the place of any sparely populated n dimensional array where memory saving is the objective. The existing libraries I have found are licensed under GNU licenses. A ntree container should implement: get reset overloaded (array style) operators Optional implementations: views - a subset object representing an area or volume within the tree for accelerated access to a group of leaves that are positioned near to each other raycasting plane culling (getting leaves within a set of planes) etc. Is there interest in such a library? Many thanks, Dan

7 7

[result_of] Make `cpp0x_result_of_impl` public
by Michel Morin 26 Apr '12

26 Apr '12

There are two implementations of boost::result_of: a TR1-style implementation and a decltype-based implementation. While the TR1-style implementation has a public interface `boost::tr1_result_of`, decltype-based one doesn't have a public interface. By defining BOOST_RESULT_OF_USE_DECLTYPE, boost::result_of use decltype-based implementation. But this is not always a viable solution, since this breaks some Boost libraries. So how about adding `boost::cxx11_result_of` as public interface of the decltype-based implementation? Attached a patch to add `boost::cxx11_result_of`. (This patch also changes the name of `cpp0x_result_of_impl` to `cxx11_result_of_impl` to reflect the recent discussion on the cpp/cxx naming.) P.S. Is it worth trying to use this `boost::cxx11_result_of` in `boost::transform_iterator` code on trunk? Regards, Michel

7 40

[quickbook] controlling table of contents
by lcaminiti 14 Apr '12

14 Apr '12

Hello all, Is there a way for more fine control of QuickBook table of contents (toc)? Specifically, I'd like to: 1) Have a toc in the first page with only the sections (no subsections) listed. 2) Then, have a full toc on the second documentation page with all sections and subsections listed. I can use any rev of QuickBook for this. Thanks a lot. --Lorenzo -- View this message in context: http://boost.2283326.n4.nabble.com/boost-quickbook-controlling-table-of-con… Sent from the Boost - Dev mailing list archive at Nabble.com.

3 6

[typeof] registration question
by Cromwell Enage 14 Apr '12

14 Apr '12

Hi, folks! In emulation mode, given the following definition: template <typename Container> struct some_metafunction { typedef BOOST_TYPEOF_TPL( Container().insert( typename Container::iterator() , typename Container::value_type() ) ) type; }; Which of the following types need to be registered? 1. The argument passed as `Container` 2. The result of `typename Container::iterator` 3. The result of `typename Container::value_type`

3 7

[lockfree] tagged_ptr as a separate library
by Philipp Moeller 12 Apr '12

12 Apr '12

In the review of lockfree it has been suggested that tagged_ptr should make it into the public API of lockfree. Wouldn't it make sense to move it into a separate library entirely? It would possibly get more exposure and cross-platform ports. The technique itself also requires some extra documentation. And it might find it's way into a release earlier than lock-free itself. Philipp Moeller

5 7

[range] adaptors vs. rvalue to lvalue& binding
by Arno Schödl 11 Apr '12

11 Apr '12

Hello, ideally I would like to use range-adapted lvalue ranges like any other lvalue ranges. Writing it down naively, as below, does not compile because LoadRefRange takes (and should take?) the range it modifies by lvalue&, while adaptor expressions are rvalues. template<typename Range> void modifies_range( Range& rng ); A a[5]; main() { // modifies all elements of a modifies_range ( a ); // modifies all elements (except for one) of a // adaptor is rvalue, does not compile: modifies_range ( boost::range::join( boost::adaptors::slice( a, 0, 1 ), boost::adaptors::slice( a, 2, countof(a) ) ) ); // compiles, but ugly: auto rng=boost::range::join( boost::adaptors::slice( a, 0, 1 ), boost::adaptors::slice( a, 2, countof(a) ) ); modifies_range(rng); } Any thoughts? Should adaptors receiving lvalues offer an operator adaptor&() &&; // overload on rvalue-ness so they are passing through the lvalue or their argument? A suitable baseclass a la boost::additive could do that. Regards, Arno -- Dr. Arno Schödl | aschoedl(a)think-cell.com Technical Director think-cell Software GmbH | Chausseestr. 8/E | 10115 Berlin | Germany http://www.think-cell.com | phone +49 30 666473-10 | US phone +1 800 891 8091 Amtsgericht Berlin-Charlottenburg, HRB 85229 | European Union VAT Id DE813474306 Directors: Dr. Markus Hannebauer, Dr. Arno Schoedl

8 21

[config] unexpected explicit operators conversion on some compilers.
by Vicente J. Botet Escriba 10 Apr '12

10 Apr '12

Hi, Given the following explicit bool conversion template<typename Mutex> class unique_lock { public: explicit operator bool() const BOOST_NOEXCEPT I was expecting the following code to compile fail (note the int cast) boost::unique_lock<boost::mutex> lk0; int i = int(lk0); It fails with gcc-4.7.0, but compile with gcc-4.6.2 and clang-3.0 (I have not tested yet with msvc). When BOOST_NO_EXPLICIT_CONVERSION_OPERATORS is defined I use the bool safe idiom to emulate the conversion #if defined(BOOST_NO_EXPLICIT_CONVERSION_OPERATORS) typedef void (unique_lock::*bool_type)(); operator bool_type() const BOOST_NOEXCEPT; bool operator!() const BOOST_NOEXCEPT; #else explicit operator bool() const BOOST_NOEXCEPT; #endif and in this case the compile fail as desired. Do we need a new macro to state that even if explicit operators are provide, there are some unexpected conversions that could be introduced? Best, Vicente

1 1