June 2012 - Boost - lists.preview.boost.org

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