- Boost - lists.preview.boost.org

emulating concepts in C++11
by lcaminiti 22 Jun '12

22 Jun '12

Hello all, I was not able to find Boost.Generic source code (I asked Matt Calabrese but no reply): http://blip.tv/boostcon/boost-generic-concepts-without-concepts-5262126 Are you aware of any trick (e.g., the tricks used by Boost.Generic) to emulate concepts in C++11? Thanks. --Lorenzo -- View this message in context: http://boost.2283326.n4.nabble.com/boost-emulating-concepts-in-C-11-tp46317… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 2

Still a monolithic library? Or a bunch of independent ones?
by hello world 21 Jun '12

21 Jun '12

Hello, It's been a few years since I didn't come around boost.org, and I was just wondering... Is boost still a monolithic library? or Is it a collection of separate libraries now? Or to state it another way: Is it ``easy'' to take only one library's files from the boost distribution and use it. Or do I have to carry everything around even If I'm using just one library? I understand that this must be library specific, but I'm just asking this to know what your general feel overall. Thanks.

3 2

Interest in a "breadth first" algorithm?
by Gary Powell 21 Jun '12

21 Jun '12

A while ago I needed to serialize and de-serialize a std::map and I realized that the only interface was begin(), end() which of course meant that re-creating this same map was the least efficient way possible, as all the elements were added in sorted order. Because I wrote them out using begin() -> end() So I wrote a breadth first template which takes a container, a template to use as the core of a queue, a template for the allocator, the container and a function to apply to the elements. It doesn't quite do a true breadth first traversal because I don't look at the inner data structure of the map, (works with sets as well) but instead does a middle, then right, left push until it's hit all of the nodes. And it doesn't copy the elements, it pushes the iterators, and calls the function on that iterator when the length is 1. It ended up speeding up my map recreation by about 20% (because I start with a center enough node that it should never have to be rebalanced) at a cost of about 5% to write it this way (It's more expensive to create the queue, and traverse the map from center on out), for a roughly 15% gain in speed. Is there any interest this for boost? I've got working code but not any documentation. And rather than spend a huge amount of time on that I'm looking to see if anyone else has an interest in this. -Gary- -- ------------------ powellg(a)gmail.com "Come gather 'round people wherever you roam. And admit that the waters around you have grown. And accept it that soon you'll be drenched to the bone. If your time to you is worth savin'. Ahh you better start swimmin' or you'll sink like a stone. For the times they are a-changin'" Bob Dylan

4 4

Integrating CUDA nvcc into bjam
by jombi01821 21 Jun '12

21 Jun '12

I would like to know how to take an existing project that build with bjam and have it understand how to handle .cu CUDA files -- View this message in context: http://boost.2283326.n4.nabble.com/Integrating-CUDA-nvcc-into-bjam-tp463163… Sent from the Boost - Dev mailing list archive at Nabble.com.

1 0

[1.50] Is it too late for fixes?
by John Maddock 21 Jun '12

21 Jun '12

I have a trivial fix for 1.50 if it's not too late (missing include guards on a header), see https://svn.boost.org/trac/boost/ticket/7001 Is it too late now, suspect it is? Thanks, John.

1 0

[exception] gcc 4.7 non-virtual destructor warning
by Daniel Larimer 21 Jun '12

21 Jun '12

/usr/local/include/boost/checked_delete.hpp:34:5: warning: deleting object of polymorphic class type 'boost::error_info<boost::tag_original_exception_type, const std::type_info*>' which has non-virtual destructor might cause undefined behaviour [-Wdelete-non-virtual-dtor] Is there a reason why the destructor isn't virtual? This only shows up when I compile with -Wall, which I like to do because it catches many important errors. Unfortunately, if I have to filter out boost warnings it makes it less effective.. particularly when the warning is actually about 30 lines long in my console. Dan

3 3

[release] merge request for test fix
by Jürgen Hunold 20 Jun '12

20 Jun '12

Hi, I would like to merge r78972 to the release branch. It fixes some test failures introduced by 78802 which renamed UTC_TIME to UTC_TIME_. Trunk tests have cycled for 2 days and the interprocress results start to turn green. Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! * voice: ++49 4257 300 ! Fährstraße 1 * fax : ++49 4257 300 ! 31609 Balge/Sebbenhausen * jhunold(a)gmx.eu ! Germany

2 2

hex/unhex()?
by Olaf van der Spek 19 Jun '12

19 Jun '12

Hi, Does Boost have hex/unhex() that support std::string? I can't find them and I think they'd be quite handy to have. -- Olaf

7 35

[svn] post commit hooks broken
by Jürgen Hunold 19 Jun '12

19 Jun '12

Hi, the subversion post commit hooks seem to be broken. The last commit mail I got is Author: garcia Date: 2012-06-07 16:20:43 EDT (Thu, 07 Jun 2012) New Revision: 78856 and there habe been numerous commits since. I have also checked in a followoup to r78802 yesterday, which should have triggered an automated trac entry for #6940. But nothing happens. Can someone with enough karma please take a look at this? As a sidenote: The inofficial git mirror seems stalled, too. Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! * voice: ++49 4257 300 ! Fährstraße 1 * fax : ++49 4257 300 ! 31609 Balge/Sebbenhausen * jhunold(a)gmx.eu ! Germany

2 2

[Locale] VC11 Regressions
by Joshua Boyce 18 Jun '12

18 Jun '12

I am currently porting some code to the VC11 compiler beta, and as part of that process I ran the unit tests on the libraries I use and noticed some failures in Boost.Locale under VC11 that are not present under VC10. Ones of the tests (test_winapi_collate) actually crashes (showing the WER dialog etc). Logs for comparison (tests were run on trunk): http://dl.dropbox.com/u/74751/cpp/boost/logs/locale-test-vc10-20120330-2143… http://dl.dropbox.com/u/74751/cpp/boost/logs/locale-test-vc11-20120330-2143… Has anyone else observed this or is it a configuration issue on my end?

4 11

Multiprecision vs. xint
by Phil Endecott 18 Jun '12

18 Jun '12

Dear All, I'd like to encourage people who are looking at the proposed Multiprecision library to remind themselves of the xint review last year. See e.g. http://thread.gmane.org/gmane.comp.lib.boost.devel/218624 (result) http://thread.gmane.org/gmane.comp.lib.boost.devel/215968 (my review) etc. etc. To what extent do we believe that this new library addresses the weaknesses of the last proposal? It would be great if Vladimir Prus, review manager for xint, could write a review of Multiprecision. Here's my take on it: Multiprecision addresses many of the problems of xint, and also extends the scope into areas that xint did not address at all. However it still suffers some of the same problems: if I want an int128_t that is just 128 bits of data, it doesn't help me. Furthermore, it doesn't help me to build the int128_t that I want. Although Multiprecision is divided into "front" and "back"-ends, this division is not in the right place to let me substitute my own backend that just provides the 128 bits of storage. In the xint reviews, we suggested that the algorithms should be decoupled from the data structures and the same applies here. Similarly, this implementation doesn't provide hooks that would allow me to substitute e.g. assembler implementations of the algorithms. Regards, Phil.

5 9

Re: [boost] Formal Review Request: TypeErasure
by Daniel Larimer 18 Jun '12

18 Jun '12

On Jun 8, 2012, at 9:47 AM, Hite, Christopher wrote: >> >> In a nutshell, concept-based-runtime-polymorphism/type-erasure allows you to have runtime polymorphism while preserving value semantics. The value of that win is very commonly underestimated. > > I think you're overselling it a bit here. You can have value sematics with interfaces, just pass around these and heap all the time in clone and maintain single points of ownership or shared_ptr. It has about the same cost as boost::function. > > struct interface{ > virtual ~interface()=0; > virtual interface* clone()=0; > }; > > > To be fair consider the version of any<..,_self&> which doesn't tackle storage and ownership and compare that with an interface with virtual functions. With the any<...,_self&> I've got a virtual table pointer and a pointer to the type-deleted object. With interface& I've got a pointer to an object with a virtual table intruding into it. I suspect that you could achieve generic 'value semantics' for any pure virtual interface via a very simple macro + other C++11 features. I think the cost of making a call with the following code would be the same as using pointer semantics via a virtual call. Consider the following to define value semantics for my_interface: class my_interface { public: virtual ~my_interface() {}; virtual int add( int ) = 0; virtual int add( double, std::string ) = 0; virtual int sub( int ) = 0; }; BOOST_VALUE( my_interface, (add)(sub) ) struct test : virtual public my_interface { int add( int i ) { return i + 5; } int add( double, std::string ) { return 6; } int sub( int i ) { return i - 5; } }; int main( int argc, char** argv ) { value<my_interface> v; v = test(); std::cerr<<v.add(int(5))<<" == 10\n"; std::cerr<<v.add(double(5.5), "hello")<<" == 6\n"; std::cerr<<v.sub(int(5))<<" == 0\n"; return 0; } The macro would expand to: template<> struct value<my_interface> : public value_base<my_interface> { using value_base<my_interface>::value_base<my_interface>; using value_base<my_interface>::operator=; // this is what the macro would most expand template<typename... Args> auto add(Args&&... args) -> decltype( ((my_interface*)0)->add( std::forward<Args>(args)... ) ) { return impl->add( std::forward<Args>(args)... ); } // this is what the macro would most expand template<typename... Args> auto sub(Args&&... args) -> decltype( ((my_interface*)0)->sub( std::forward<Args>(args)... ) ) { return impl->sub( std::forward<Args>(args)... ); } }; Granted the 'only' downside to this approach is that it is 'intrusive'. I have implemented as much here: https://github.com/bytemaster/mace/blob/master/libs/stub/examples/value.cpp You can achieve non-intrusive version with a slightly more verbose interface definition: template<typename T=void,bool impl=false> struct my_interface{ virtual ~my_interface() {} virtual int add( int ) = 0; virtual int add( double, std::string ) = 0; virtual int sub( int ) = 0; }; template<typename T> struct my_interface<T,true> : public T, virtual public my_interface<>{ template<typename... Args> my_interface(Args&& ...args):T( std::forward<Args>(args)... ){} virtual int add( int i) { return T::add(i); } virtual int add( double d, std::string s) { return T::add( d, s); } virtual int sub( int i) { return T::sub( i ); } }; BOOST_VALUE( my_interface, (add)(sub) ) struct test { /** no intrusive base class required **/ int add( int i ) { return i + 5; } int add( double, std::string ) { return 6; } int sub( int i ) { return i - 5; } }; int main( int argc, char** argv ) { value<my_interface> v; v = test(); std::cerr<<v.add(int(5))<<" == 10\n"; std::cerr<<v.add(double(5.5), "hello")<<" == 6\n"; std::cerr<<v.sub(int(5))<<" == 0\n"; return 0; } https://github.com/bytemaster/mace/blob/master/libs/stub/examples/value2.cpp Other than the repetitive nature of the interface spec, it is very straight forward, clear, and easy to read and understand compared to how TypeErasure currently achieves such a feat. Does this have value?? Could you integrate this technique with TypeErasure? Is it good enough for most use cases (non operator overloading)? It probably wouldn't be difficult to convert this to reference semantics and avoid heap alloc!

6 8

Review Wizard Report for June 2012
by Ronald Garcia 18 Jun '12

18 Jun '12

============================================== Review Wizard Status Report for June 2012 ============================================== News ==== 1. Predef Library Reviewed 2. Boost 1.49.0 Released. New Library: Heaps 3. Multiprecision Arithmetic Review Ongoing Open Issues =========== The following libraries have been reviewed and await reports from their review managers: * Predef - reviewed February 2012; review manager: Joel Falcou. * Conversion - reviewed August 2011; review manager: Gordon Woodhull. The following libraries have been accepted to Boost, but have not yet been submitted to SVN: * Constrained Value - accepted September 2010; author: Robert Kawulak. * GIL.IO - accepted January 2011; author: Christian Henning. * Atomic - accepted July 2011; author Helge Bahmann. * Lockfree - accepted August 2011; author: Tim Blechmann. The following libraries have been accepted and submitted to SVN, but have not yet appeared in a release: * Type Traits Introspection - accepted August 2011; author: Edward Diener. * 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 before we do that, please email Ron or John. The review schedule is an unordered list of the libraries awaiting review. As such, any library on the schedule can be reviewed once the developer is ready, a review manager has been secured, and the manager, developer, and wizards agree on a date to schedule the review. Review Schedule =============== * Join (M) * Pimpl (M) * Sorting (M) * Quaternions, Vectors, Matrices (M) * Variadic Macro Data (M) * Block Pointer (M) * Singularity (M) * Extended Complex Numbers (M) * Metaparse (M) * Polygon: Voronoi Extensions * Coroutine * Type Erasure * Range Extensions (M) * Contract * Nowide (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/icaretaker/Singularity :Description: The Singularity Design Pattern allows you to restrict any class to a single instance. Unlike the infamous Singleton, Singularity gives you direct control over the lifetime of the object, does not require you to grant global access to the object, nor does it limit you to the default constructor for that object. 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. Type Erasure ------------ :Author: Steven Watanabe :Review Manager: Lorenzo Caminiti :Download: http://sourceforge.net/projects/steven-watanabe.u/files/ :Description: The TypeErasure library is a generalization of boost::any and boost::function. It allows easy composition of arbitrary type erased operators. 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. Libraries under development =========================== See http://svn.boost.org/trac/boost/wiki/LibrariesUnderConstruction for a current listing of libraries under development.

3 2

[pool] Improvements to boost.pool
by DUPUIS Etienne 18 Jun '12

18 Jun '12

Greetings, In the boost sandbox, under the /pool folder, I have committed a few small improvements and a few fixes for open tickets. Here is what I have changed : 1. I added boost::static_pool, a pool whose maximum size is known when initializing the pool; in which case all memory is allocated when calling the constructor. This is useful for software that must manage memory with great care. The implementation is a simple subclass of boost::pool. In the same vein, I also added boost::static_object_pool. 2. I also added boost::array_pool, a pool whose maximum size is known at compile time. The array_pool object hence already contains all memory it needs. Same for boost::array_object_pool. I am not sure that this is really useful and I am not sure I have picked a good name for it. 3. I handled ticket #3789 (https://svn.boost.org/trac/boost/ticket/3789) In short, releasing objects from a boost::object_pool was O(n) instead of expected O(1) and this constraint was required to keep the pool ordered so that the destructor of object_pool could destroy all objects that the calling program did not released. To solve this problem, I created an O(n log n) function which orders an unordered pool, a function that I called in the destructor. Thus, with my modification, releasing objects is O(1) and the destructor is O(n log n), or O(1) is the calling program was kind enough to release all objects. Although this does not change the API, it could have a negative impact on software that allocate large number of objects (using object_pool) but that never releases them. However, my modification greatly improves programs who repeatedly requests and releases objects. This modification also handles ticket #6610 (https://svn.boost.org/trac/boost/ticket/6610) 4. I added a pool.get_size() function (https://svn.boost.org/trac/boost/ticket/6865) that returns the current number of elements/objects for which the pool has allocated memory. 5. I clarified the meaning of the 'max_size' parameter, a recent addition to limit the amount of memory a pool can allocate with a single call to the allocator. See ticket #6867 (https://svn.boost.org/trac/boost/ticket/6867) for details. 6. I fixed miscellaneous minor tickets : #5902 (division by zero when requesting null sized buffers), #6561 (crash when releasing a null pointer), #6710 (integer overflows and possible crashes when requesting too many elements). 7. I added test cases for all modifications. I manually tested each case on Windows and used bjam on Linux, although I am not exactly sure that bjam did anything as it did not even report which test it ran. 8. I still need to update the documentation. Before doing that, I thought that I should submit my changes to the Boost community to see whether they are approved or not. And more prosaically, I still need to figure out how to generate the said documentation ! Now that these changes have been made in the sandbox, what is the next step to get them approved/amended/rejected ? Regards, Étienne Ce message et toutes les pièces jointes sont confidentiels et établis à l'intention exclusive de ses destinataires. Toute modification, édition, utilisation ou diffusion non autorisée est interdite. Si vous avez reçu ce message par erreur, merci de nous en avertir immédiatement. ATEME décline toute responsabilité au titre de ce message s'il a été altéré, déformé, falsifié ou encore édité ou diffusé sans autorisation. This message and any attachments are confidential and intended solely for the addressees. Any unauthorized modification, edition, use or dissemination is prohibited. If you have received this message by mistake, please notify us immediately. ATEME decline all responsibility for this message if it has been altered, deformed, falsified or even edited or disseminated without authorization. Note: To protect against computer viruses, e-mail programs may prevent sending or receiving certain types of file attachments.

5 6

Formal Review Request: Boost.Contract
by Lorenzo Caminiti 18 Jun '12

18 Jun '12

Hello all, I have released Contract++ 0.4.0 on SourceForge. If ever accepted into Boost, this library will be Boost.Contract (and all macros/symbols will be prefixed by BOOST_/boost::). 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. Documentation: http://contractpp.svn.sourceforge.net/viewvc/contractpp/releases/contractpp… Source: http://sourceforge.net/projects/contractpp/files/latest/download I would like to request a formal Boost review of the library. Comments are welcome! Thanks, --Lorenzo INTRODUCTION Contract Programming is also known as Design by Contract(TM) and it was first introduced by the Eiffel programming language. All Contract Programming features of the Eiffel programming language are supported by this library, among others: * Support for preconditions, postconditions, class invariants, block invariants, and loop variants. * Subcontract derived classes (with support for pure virtual functions and multiple inheritance). * Access expression old values and function return value in postconditions. * Optional compilation and checking of preconditions, postconditions, class invariants, block invariants, and loop variants. * Customizable actions on contract assertion failure (terminate by default but it can throw, exit, etc). All features: http://contractpp.svn.sourceforge.net/viewvc/contractpp/releases/contractpp… EXAMPLE The example below shows how to use this library to program contracts for the STL member function std::vector::push_back (in order to illustrate subcontracting, the vector class inherits from the somewhat arbitrary pushable base class). #include <contract.hpp> // This library. #include <boost/concept_check.hpp> #include <vector> #include "pushable.hpp" // Some base class. CONTRACT_CLASS( template( typename T ) requires( boost::CopyConstructible<T> ) // Concepts. class (vector) extends( public pushable<T> ) // Subcontracting. ) { CONTRACT_CLASS_INVARIANT_TPL( empty() == (size() == 0) // More class invariants here... ) public: typedef typename std::vector<T>::size_type size_type; public: typedef typename std::vector<T>::const_reference const_reference; CONTRACT_FUNCTION_TPL( public void (push_back) ( (T const&) value ) override precondition( size() < max_size() // More preconditions here... ) postcondition( auto old_size = CONTRACT_OLDOF size(), // Old-of values. size() == old_size + 1 // More postconditions here... ) ) { vector_.push_back(value); // Original function body. } // Rest of class here (possibly with more contracts)... public: bool empty ( void ) const { return vector_.empty(); } public: size_type size ( void ) const { return vector_.size(); } public: size_type max_size ( void ) const { return vector_.max_size(); } public: const_reference back ( void ) const { return vector_.back(); } private: std::vector<T> vector_; }; NOTES This library suffers of two limitations: 1. The unusual syntax used to declare classes and functions within the macros which causes cryptic compiler errors when not used correctly (syntax error checking and reporting could be somewhat improved in future revisions of the library but there are fundamental limitations on what can be done using the preprocessor). http://contractpp.svn.sourceforge.net/viewvc/contractpp/releases/contractpp… 2. High compilation times (the authors have not tried to optimize the library proprocessor and template meta-programming code yet, that will be the focus of future releases). http://contractpp.svn.sourceforge.net/viewvc/contractpp/releases/contractpp… This library could be extended to also support concept definitions (at least for C++11): http://contractpp.svn.sourceforge.net/viewvc/contractpp/releases/contractpp…

2 4

rvalue ref best practices?
by Daniel Larimer 17 Jun '12

17 Jun '12

I am trying to define my library API and have been using rvalue references and have observed some patterns that I would like to run by the community. In c++03 I would pass almost everything by const& unless it was to be modified. This results in extra copies any time a temporary is passed. In c++11 I would pass anything that I plan on 'storing' or 'consuming' by &&. This results in the most efficient code, but 'breaks' lvalue compatibility and forces me to consider having two (or more) versions of every method. Unfortunately, you get a explosion of permutations of rvalue and const& as the number of arguments increases and it makes getting function pointers much more 'ugly'. Instead of providing two (or more) overloads, one for lvalues and one for rvalue, I have decided to only provide the rvalue overload and if the user wants to pass an lvalue they wrap with std::ref(), std::cref(), std::move() or my own helper copy() which makes the copy explicit and converts the lvalue to a rvalue. (std::ref() and std::cref() could only work if the arguments are template parameters... in which case the method would probably use std::forward<>() to handle the auto-detection of move vs copy semantics. template<typename T> T copy( const T& v ) { return v; } If I am writing a method that does not 'store' or 'consume' the input then I use const& As rvalue references are quite new, this 'convention' may be unexpected by users. How would you feel about using an API that assumed move semantics unless you explicitly specify copy or reference semantics? Is there any reason that there shouldn't be a boost::copy() in boost/utility for use in this situation? Are there some down sides to this approach that I am missing? In my experience 90% of functions that take std::string() end up using a temporary and 90% of strings are 'calculated', 'used', and 'forgotten', yet most methods take const& and result in a temporary value. I should probably clarify, that I would use const& for any types that do not benefit from move semantics (no deep copies). But when you are writing template code, you do not want to make that assumption about the type. Another practice I am considering is making certain classes 'explicit copy only'. template<typename T> T copy( const T& t ) { return t; } class test { public: test(){...}; test( test&& t ){...} private: template<typename T> friend T copy(const T&t); test& operator=(const test&); // not implemented test( const test& t ){...} std::vector<char> large_data; }; int main( int argc, char** argv ) { test x; test y = copy(x); test z = x; // error, test(const test&) is private... return 0; } I would use this for any class that contains any 'movable members', such a strings, vectors, maps, etc. Technically there is no reason why I couldn't copy them, but why shouldn't I attempt move semantics everywhere possible unless I really do want to copy? With implicit copies there is no way for the compiler to warn me that I am doing something potentially expensive. If it didn't break backward compatibility I would suggest that all of the standard containers adopt an explicit copy or move syntax or at least have a compiler flag to 'enable/disable' implicit copying for 'testing purposes'. Perhaps we could put them in a different namespace for those of us that want to disable implicit copying of deep data types, ie: xc::vector<>, xc::string, etc. Are these sane conventions? What could go wrong? I am I abusing rvalue references?

13 54

Result of boost::split against empty string changed in post-1.45 release
by Mateusz Loskot 17 Jun '12

17 Jun '12

Hi, I have a simple program runs boost::split against empty string. I'm testing with Boost 1.45 and later versions like 1.46 or 1.49. As stated in the // comment below, there is difference in behaviour depending on the Boost version: // https://gist.github.com/2910461 #include <cassert> #include <string> #include <vector> #include <boost/algorithm/string/split.hpp> #include <boost/algorithm/string/classification.hpp> int main(int argc, wchar_t* argv[]) { std::wstring s; std::vector<std::wstring> a; assert(s.empty()); boost::split(a, s, boost::is_any_of(L", "), boost::token_compress_on); // Boost 1.45: true // Boost 1.46+: false // Assertion failed: s.empty() == a.empty(), file boost_split_empty_string.cpp, line 16 assert(s.empty() == a.empty()); return 0; } IMHO, the behaviour exposed in newer versions is a bug. Could anyone shed light on what happened in post-1.46? Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

4 11

[context] build and warning fixes for gcc on Windows
by news.gmane.org 16 Jun '12

16 Jun '12

Hello Posting here as there's no context component in trac yet. This specifically relates to boost.context and cygwin's mingw64-x64_64_gcc toolchain with ml and ml64 from Visual Studio 2010. The patch attached is against trunk (rev 78752) for the following warnings: * ..\..\../boost/context/detail/fcontext_x86_64_win.hpp:20:0: warning: ignoring #pragma warning * ..\src\seh.cpp:36:87: warning: format %08lX expects type long unsigned int, but argument 5 has type ULONG_PTR (I'm guessing %p used in the patch is probably not the best solution for cross-platformness) * ..\src\seh.cpp:39:53: warning: deprecated conversion from string constant to char* The last issue I've had is with jump_fcontext and make_fcontext exports: Warning: .drectve `/EXPORT:jump_fcontext /EXPORT:make_fcontext 3' unrecognized Which seems to cause: collect2: ld terminated with signal 6 [Aborted], core dumped Removing the EXPORT directive in the asm file results in a successful build, but naturally the symbols aren't exported. I hacked around this by changing the asm functions to jump_fcontext_impl and make_fcontext_impl, and provided an extern C jump_fcontext and make_fcontext in fcontext.cpp that forward to them. I'm sure there are far nicer ways to force the symbols to be exported so I've not attached the patch for this. With these changes, I can more-or-less successfully use context which is great! (A slight issue with exceptions; possibly crossing dll boundaries and/or due to this gcc's exception implementation using setjmp/longjmp.) Finally, is there any technical reason why gas assembly couldn't be provided for use with gcc on Windows? Having to have masm available seems a shame, aside from the issues above. I had a very quick go at it without success but could possibly have another attempt ... Thanks for the library and regards, Luke Elliott.

3 7

Fwd: [Boost-users] [filesystem] is path comparison case-insensitive on Windows?
by Mateusz Loskot 15 Jun '12

15 Jun '12

Hi, I wonder, would it be possible for authors of Boost.Filesystem to provide clear answer to this question in the FAQ [1]? It seems to be a good candidate for FAQ. [1] http://www.boost.org/doc/libs/1_49_0/libs/filesystem/v3/doc/faq.htm Mateusz ---------- Forwarded message ---------- From: Nathan Ridge <zeratul976(a)hotmail.com> Date: 15 June 2012 07:12 Subject: [Boost-users] [filesystem] is path comparison case-insensitive on Windows? To: Boost Mailing List <boost-users(a)lists.boost.org> Hi, I couldn't find this info in the Filesystem documentation, so I thought I'd ask here: is equality comparison between path objects case-insensitive on Windows? I think it ought to be, since the operating system treats two paths differing by case only to be the same, but I thought I'd double-check. Thanks, Nate _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users -- Mateusz Loskot, http://mateusz.loskot.net

1 0

[Multiprecision] Benchmarking
by Phil Endecott 15 Jun '12

15 Jun '12

Dear All, I have attempted to evaluate the proposed multiprecision library by applying it to the "Dealaunay Flip" function for 32-bit integer coordinates, as this is one of the few things that I've ever implemented that needed more than 64-bit integers: inline bool delaunay_test(int32_t ax, int32_t ay, int32_t bx, int32_t by, int32_t cx, int32_t cy, int32_t dx, int32_t dy) { // Test whether the quadrilateral ABCD's diagonal AC should be flipped to BD. // This is the Cline & Renka method. // Flip if the sum of the angles ABC and CDA is greater than 180 degrees. // Equivalently, flip if sin(ABC + CDA) < 0. // Trig identity: cos(ABC) * sin(CDA) + sin(ABC) * cos(CDA) < 0 // We can use scalar and vector products to find sin and cos, and simplify // to the following code. // Numerical robustness is important. This code addresses it by performing // exact calculations with large integer types. i64 ax64 = ax, ay64 = ay, bx64 = bx, by64 = by, cx64 = cx, cy64 = cy, dx64 = dx, dy64 = dy; i64 cos_abc = (ax64-bx64)*(cx64-bx64) + (ay64-by64)*(cy64-by64); i64 cos_cda = (cx64-dx64)*(ax64-dx64) + (cy64-dy64)*(ay64-dy64); if (cos_abc >= 0 && cos_cda >= 0) return false; if (cos_abc < 0 && cos_cda < 0) return true; i64 sin_abc = (ax64-bx64)*(cy64-by64) - (cx64-bx64)*(ay64-by64); i64 sin_cda = (cx64-dx64)*(ay64-dy64) - (ax64-dx64)*(cy64-dy64); i128 sin_sum = static_cast<i128>(sin_abc)*cos_cda + static_cast<i128>(cos_abc)*sin_cda; return sin_sum < 0; } As you can see, with 32-bit inputs, the first set of computations yield 64-bit results and about half of calls terminate at this stage. Otherwise a calculation yielding a 128-bit result is carried out. In practice, the results of the subtractions are typically small and the 128-bit value rarely has more than 64 significant bits. I have compared the following types used for i64 and i128 in the code above: (1) int64_t and int64_t (which gives WRONG ANSWERS, but is useful for comparison) (2) int64_t and my own "quick and dirty" int128_t. (3) cpp_int. (4) int64_t and cpp_int. (5) cpp_int without expression templates. (6) int64_t and cpp_int without expression templates. (7) int64_t and mp_int128_t. (8) mpz_int. (9) int64_t and mpz_int. Mean times per function call are as follows: (1) 39.3 ns (2) 61.9 ns (3) 513 ns (4) 103 ns (5) 446 ns (6) 102 ns (7) 102 ns (8) 2500 ns (9) 680 ns (AMD Athlon(tm) II X2 250e Processor @ 3 GHz; g++ 4.6.1.) Note that: - GMP is slowest, despite oft-repeated claims about its good performance. - Expression templates make the code slower. - Even the fastest Boost.Multiprecision type, mp_int128_t, is significantly slower than my own quick hack. This is all a bit disappointing. Perhaps the problem is that I'm dealing only with 128 bits and the intended application is for much larger values? I am reminded of my experience with xint last year. See e.g. this thread: http://thread.gmane.org/gmane.comp.lib.boost.devel/215565 The current proposal seems much better - xint was hundreds of times slower than my ad-hoc code - but I still find it discouraging. I suspect that the performance difference may be attributable to the use of sign-magnitude representation; as a result, the implementation is full of sign-testing like this: template <unsigned MinBits, bool Signed, class Allocator> inline void eval_subtract(cpp_int_backend<MinBits, Signed, Allocator>& result, const signed_limb_type& o) { if(o) { if(o < 0) eval_add(result, static_cast<limb_type>(-o)); else eval_subtract(result, static_cast<limb_type>(o)); } } I think I understand the motivation for sign-magnitude for variable-length representation, but I don't see any benefit in the case of e.g. mp_int128_t. I also wonder about the work involved in e.g. a 64 x 64 -> 128-bit multiplication. Here is my version, based on 32x32->64 multiplies: inline int128_t mult_64x64_to_128(int64_t a, int64_t b) { // Make life simple by dealing only with positive numbers: bool neg = false; if (a<0) { neg = !neg; a = -a; } if (b<0) { neg = !neg; b = -b; } // Divide input into 32-bit halves: uint32_t ah = a >> 32; uint32_t al = a & 0xffffffff; uint32_t bh = b >> 32; uint32_t bl = b & 0xffffffff; // Long multiplication, with 64-bit temporaries: // ah al // * bh bl // ---------------- // al*bl (t1) // + ah*bl (t2) // + al*bh (t3) // + ah*bh (t4) // ---------------- uint64_t t1 = static_cast<uint64_t>(al)*bl; uint64_t t2 = static_cast<uint64_t>(ah)*bl; uint64_t t3 = static_cast<uint64_t>(al)*bh; uint64_t t4 = static_cast<uint64_t>(ah)*bh; int128_t r(t1); r.high = t4; r += int128_t(t2) << 32; r += int128_t(t3) << 32; if (neg) r = -r; return r; } So I need 4 32x32->64 multiplies to perform 1 64x64->128 multiply. But we can't write this: int64_t a, b ...; int128_t r = a * b; because here a*b is a 64x64->64 multiply; instead we have to write something like r = static_cast<int128_t>(a)*b; so that our operator* overload is found; but this operator* doesn't know that its int128_t argument is actually a promoted int64_t, and it has to do an 128x64->128 or 128x128->128 multiply, requiring 8 or 16 32x32->64 multiplies. The only chance of avoiding the extra work is if the compiler can do constant-propagation, but I have my doubts about that. Any thoughts? My test code is here: http://chezphil.org/tmp/boost_mp_review.tbz2 $ make $ cat nn100000.dat | benchmark (Note that this needs a fix to the resize() issue reported earlier in order to get accurate answers, but that doesn't much alter the execution time.) Regards, Phil.

8 15

help
by Bertolino, Keith D. 15 Jun '12

15 Jun '12

unsubscribe

1 0

[multiprecision review] Possible use of uninitialised value
by Phil Endecott 14 Jun '12

14 Jun '12

Dear All, I decided to try to evaluate the proposed Boost.Multiprecision on the code that I wrote recently when looking at the proposed Delaunay Triangulation / Voronoi Diagram code. Specifically, this function: inline bool delaunay_test(int32_t ax, int32_t ay, int32_t bx, int32_t by, int32_t cx, int32_t cy, int32_t dx, int32_t dy) { // Test whether the quadrilateral ABCD's diagonal AC should be flipped to BD. // This is the Cline & Renka method. // Flip if the sum of the angles ABC and CDA is greater than 180 degrees. // Equivalently, flip if sin(ABC + CDA) < 0. // Trig identity: cos(ABC) * sin(CDA) + sin(ABC) * cos(CDA) < 0 // We can use scalar and vector products to find sin and cos, and simplify // to the following code. // Numerical robustness is important. This code addresses it by performing // exact calculations with large integer types. i64 ax64 = ax, ay64 = ay, bx64 = bx, by64 = by, cx64 = cx, cy64 = cy, dx64 = dx, dy64 = dy; i64 cos_abc = (ax64-bx64)*(cx64-bx64) + (ay64-by64)*(cy64-by64); i64 cos_cda = (cx64-dx64)*(ax64-dx64) + (cy64-dy64)*(ay64-dy64); if (cos_abc >= 0 && cos_cda >= 0) return false; if (cos_abc < 0 && cos_cda < 0) return true; i64 sin_abc = (ax64-bx64)*(cy64-by64) - (cx64-bx64)*(ay64-by64); i64 sin_cda = (cx64-dx64)*(ay64-dy64) - (ax64-dx64)*(cy64-dy64); i128 sin_sum = static_cast<i128>(sin_abc)*cos_cda + static_cast<i128>(cos_abc)*sin_cda; return sin_sum < 0; } Here i64 and i128 are typedefs for appropriate 64- and 128-bit signed integer types. when I try to use boost::multiprecision::cpp_int, I get answers that are only mostly correct. Specifically, sometimes the very first call gives the wrong answer. It is dependent on the number of iterations of my benchmark loop and other factors. valgrind reports the following: ==15713== Conditional jump or move depends on uninitialised value(s) ==15713== at 0x8053B0C: boost::multiprecision::mp_number<boost::multiprecision::backends::cpp_int_backend<0u, true, std::allocator<unsigned int> >, true>::mp_number<boost::multiprecision::detail::plus, boost::multiprecision::detail::mp_exp<boost::multiprecision::detail::multiply_immediates, boost::multiprecision::mp_number<boost::multiprecision::backends::cpp_int_backend<0u, true, std::allocator<unsigned int> >, true>, boost::multiprecision::mp_number<boost::multiprecision::backends::cpp_int_backend<0u, true, std::allocator<unsigned int> >, true>, void, void>, boost::multiprecision::detail::mp_exp<boost::multiprecision::detail::multiply_immediates, boost::multiprecision::mp_number<boost::multiprecision::backends::cpp_int_backend<0u, true, std::allocator<unsigned int> >, true>, boost::multiprecision::mp_number<boost::multiprecision::backends::cpp_int_backend<0u, true, std::allocator<unsigned int> >, true>, void, void>, void, void>(boost::multiprecision::detail::mp_exp<boost::multiprecision::detail::plus, boost::multiprecision::detail::mp_exp<boost::multiprecision::detail::multiply_immediates, boost::multiprecision::mp_number<boost::multiprecision::backends::cpp_int_backend<0u, true, std::allocator<unsigned int> >, true>, boost::multiprecision::mp_number<boost::multiprecision::backends::cpp_int_backend<0u, true, std::allocator<unsigned int> >, true>, void, void>, boost::multiprecision::detail::mp_exp<boost::multiprecision::detail::multiply_immediates, boost::multiprecision::mp_number<boost::multiprecision::backends::cpp_int_backend<0u, true, std::allocator<unsigned int> >, true>, boost::multiprecision::mp_number<boost::multiprecision::backends::cpp_int_backend<0u, true, std::allocator<unsigned int> >, true>, void, void>, void, void> const&) (in /home/phil/boost_mp_review/benchmark) As expected, the error is impenetrable. Can anyone guess what is going on? (I seem to get the right answers and no valgrind errors with the fixed-size and no-expression-templates types.) Regards, Phil.

2 3

[mpi] MPI_IN_PLACE equivalent
by Alain O Miniussi 14 Jun '12

14 Jun '12

Some collective mpi operations allow the user to re-use the input buffer as the output buffer (MPI_IN_PLACE). I did not find that functionality in boost::mpi and filed a ticket (https://svn.boost.org/trac/boost/ticket/6704) along with a patch for a possible implementation for all_reduce and the associated testing. What is the best way to get some input regarding that proposed patch ? (the ticket itself has been untouched for 3 months now) Best regards, -- Alain Miniussi Responsable Tech. Centre de Calcul Haute Performance Observatoire de la Côte d'Azur - BP 4229 - 06304 Nice Cedex 4 tel: +33 4 92 00 30 09 https://crimson.oca.eu

1 0

[multiprecision review] EOF not declared, and noexcept errors
by Phil Endecott 14 Jun '12

14 Jun '12

Dear All, I'm trying to do some simple tests with the proposed Boost.Multiprecision, but anything that includes e.g. boost/multiprecision/cpp_int.hpp gives errors like this: /big_number/boost/multiprecision/mp_number.hpp:1730:11: error: ‘EOF’ was not declared in this scope /big_number/boost/multiprecision/rational_adapter.hpp:208:45: error: expected ‘;’ at end of member declaration /big_number/boost/multiprecision/rational_adapter.hpp:208:47: error: ‘noexcept’ does not name a type My guess is that the EOF error may be a missing include, while the latter two errors may be something that's missing in the relatively old Boost installation on this test machine. Can anyone suggest what I need to do? Regards, Phil.

4 4

Cannot access structure elements using iterator to list containing shared_ptr<struct>
by Manjunath BJ 14 Jun '12

14 Jun '12

> > Hi, >> I would like to have a list(STL) of shared_ptr. The shared_ptr >> would hold the pointer to the structure "packet_holder" >> . >> > struct packet { > >> int c; >> union{ >> struct pkt_header header; >> struct ip_header ip_hd; >> }type; >> > }packet_holder; >> >> > list<boost::shared_ptr<packet_holder> > pkt_list; > boost::shared_ptr<packet_holder> pkt(new packet_holder); > pkt_list.push_pack(pkt); > > Having defined this, I would like to use iterator to iterate > through the list. > list<boost::shared_ptr<packet_holder> >::iterator it; > for(it = list.begin();it != list.end();it++) > But I am not able to access the inner details of the struct > "packet_holder" using the iterator. > it->type.header is not accessible. > > Can anyone please suggest me where exactly I might be wrong. > > -- >> With Regards, >> Manjunath BJ >> > > > > -- > With Regards, > Manjunath BJ > -- With Regards, Manjunath BJ

2 2