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

[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

[test] max_digits10 code breaks regression testing for many older platforms
by David Deakins 13 Jun '12

13 Jun '12

Paul, I noticed that the change to set_precision in Boost.Test (rev 78908) seems to have broken regression testing on the trunk for all of the platforms that don't have max_digits10 in their standard library (even for non-math-related tests). Is there any way to restrict this new code to only platforms that can support it? Thanks, -Dave

1 0

Boost mpi, serialization and shared_ptr
by Max Moorkamp 13 Jun '12

13 Jun '12

Hi, I have started to parallelize one of my applications using MPI and I am running into trouble with serializing classes that contain shared_ptr member to be send through MPI. Below is a minimal case that demonstrates my problem. #include <boost/serialization/serialization.hpp> #include <boost/shared_ptr.hpp> #include <boost/mpi.hpp> #include <boost/serialization/shared_ptr.hpp> #include <boost/serialization/export.hpp> class Base { private: friend class boost::serialization::access; template<class Archive> void serialize(Archive & ar, const unsigned int version) { } public: Base() { } virtual ~Base() { } }; class Derived: public Base { private: double b; boost::shared_ptr<Base> MemberPointer; friend class boost::serialization::access; template<class Archive> void serialize(Archive & ar, const unsigned int version) { ar & boost::serialization::base_object<Base>(*this); ar & MemberPointer; ar & b; } public: Derived() { } virtual ~Derived() { } }; //BOOST_CLASS_EXPORT(Base) BOOST_CLASS_EXPORT(Derived) int main(int argc, char *argv[]) { boost::mpi::environment env(argc, argv); boost::mpi::communicator world; boost::shared_ptr<Base> Pointer(new Derived()); boost::mpi::broadcast(world, Pointer, 0); } I want to broadcast the derived class that has a member that is a shared_ptr. When I compile this code with gcc-4.6, intel or clang all compilers complain, this is the output from gcc-4.6 In file included from Hacks/serialization_mpi.cpp:11:0: /usr/local/include/boost/serialization/shared_ptr.hpp: In function ‘void boost::serialization::load(Archive&, boost::shared_ptr<U>&, unsigned int) [with Archive = boost::mpi::packed_skeleton_iarchive, T = Base]’: /usr/local/include/boost/serialization/split_free.hpp:58:9: instantiated from ‘static void boost::serialization::free_loader<Archive, T>::invoke(Archive&, T&, unsigned int) [with Archive = boost::mpi::packed_skeleton_iarchive, T = boost::shared_ptr<Base>]’ /usr/local/include/boost/serialization/split_free.hpp:74:5: instantiated from ‘void boost::serialization::split_free(Archive&, T&, unsigned int) [with Archive = boost::mpi::packed_skeleton_iarchive, T = boost::shared_ptr<Base>]’ /usr/local/include/boost/serialization/shared_ptr.hpp:171:5: instantiated from ‘void boost::serialization::serialize(Archive&, boost::shared_ptr<U>&, unsigned int) [with Archive = boost::mpi::packed_skeleton_iarchive, T = Base]’ /usr/local/include/boost/serialization/serialization.hpp:128:9: instantiated from ‘void boost::serialization::serialize_adl(Archive&, T&, unsigned int) [with Archive = boost::mpi::packed_skeleton_iarchive, T = boost::shared_ptr<Base>]’ /usr/local/include/boost/archive/detail/iserializer.hpp:188:5: instantiated from ‘void boost::archive::detail::iserializer<Archive, T>::load_object_data(boost::archive::detail::basic_iarchive&, void*, unsigned int) const [with Archive = boost::mpi::packed_skeleton_iarchive, T = boost::shared_ptr<Base>]’ Hacks/serialization_mpi.cpp:64:3: instantiated from here /usr/local/include/boost/serialization/shared_ptr.hpp:133:9: error: ‘class boost::mpi::packed_skeleton_iarchive’ has no member named ‘append’ /usr/local/include/boost/serialization/shared_ptr.hpp:139:5: error: ‘class boost::mpi::packed_skeleton_iarchive’ has no member named ‘reset’ If I remove the shared_ptr member, it compiles and runs. If I remove BOOST_CLASS_EXPORT(Derived) it compiles, but when running it I get terminate called after throwing an instance of 'boost::archive::archive_exception' what(): unregistered class - derived class not registered or exported Is this a bug or am I doing something wrong? A google search shows an old discussion (2007) that concludes that this problem is fixed in boost 1.45. I see this happening with both 1.48 and 1.49. Any help is appreciated. Regards Max

3 6

[Nowide] Formal Review Request
by Artyom Beilis 13 Jun '12

13 Jun '12

Hello, I'd like to ask to add Boost.Nowide to review queue: Boost.Nowide is a library implemented by Artyom Beilis that make cross platform Unicode aware programming easier. The library 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. Sources: http://cppcms.com/files/nowide/ Docs: http://cppcms.com/files/nowide/html/ Git: git://cppcms.git.sourceforge.net/gitroot/cppcms/nowide Thank You Very Much! Artyom Beilis P.S.: Previous mail was sent accidentally to boost.users list, sorry. -------------- CppCMS - C++ Web Framework: http://cppcms.com/ CppDB - C++ SQL Connectivity: http://cppcms.com/sql/cppdb/

3 4

[pool] Broken documentation
by Klaim - Joël Lamotte 12 Jun '12

12 Jun '12

Hi, http://www.boost.org/doc/libs/1_49_0/libs/pool/doc/html/boost_pool/pool/poo… In this page all images are broken for me. Joel Lamotte

3 3

Review Request : Boost.Range Extension
by Akira Takahashi 11 Jun '12

11 Jun '12

Hi, Neil Groves and Boosters. OvenToBoost is a project that intend to add some features of Oven Range Library into Boost.Range. I'd like to request a review. 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. Future Plan: I have written primary features. If these features are accept, I'd like to implement/add following features: - Range of Range Adaptors (concatenated, transposed) - Cyclic Range - Range Utilities for String Source Code: https://github.com/faithandbrave/OvenToBoost Document: http://dl.dropbox.com/u/1682460/git/OvenToBoost/libs/range/doc/html/index.h… Regards, Akira >>======================== Akira Takahashi mailto:faithandbrave@gmail.com site: https://sites.google.com/site/faithandbrave/about/en

4 24

From an user to developers
by Oodini 10 Jun '12

10 Jun '12

Hello, I am an user, and I am currently reviewing all the Boost libraries. But for a common user, some needs are not satisfied in the libraries descriptions. The Boost organization should compel the libraries authors to put in their documentation : 1. the history of all releases, with notes for each release 2. the motivation of their library 3. when they offer services similar to the ones provided by the STL, why did they feel the need to complete it, and what are the differences 3. for the relevant libraries, their status regarding the new features of C++11 (are they obsolete ? do they remain some differences ? ex : Array, Chrono, DateTime), especially the ones related to TR1 An homogeneous structure for the documentation would be welcome.

5 6

[1.50] OK to merge documentation changes?
by John Maddock 10 Jun '12

10 Jun '12

I have some documentation changes that I'd like to merge: * Corrected typos in Boost.Math docs. * Updated some scripts and Jamfiles for correct PDF doc build generation. Is there a good time to commit these to release, or is it all to late for 1.50 now? Thanks, John.

2 1

[git/modularization] Suggested names for branches?
by Beman Dawes 10 Jun '12

10 Jun '12

At the C++Now! session discussing moving to git and modularization, I showed the usual git flow overview graphic from http://nvie.com/posts/a-successful-git-branching-model/ showing the workflow for a library. Someone (Dave?) mentioned that the git flow choices for branch names were not what we would like for Boost. I agree, but don't recall the exact suggestions for more appropriate names. The three branches in question, with the git-flow names in parens, were the main development branch (develop), release prep branches (?), and the branch with actual releases (master). Is there a better usual convention for these names? I have a vague memory of someone mentioning "master" for the main development branch, "release" for the branch with the actual releases, and maybe "beta-x.xx.x" for release prep branches. To try to avoid an extended bicycle shed discussion, perhaps people could mention names they have actually seen used and know worked well. --Beman

8 14

Re: [boost] [review] Multiprecision review scheduled for June 8th - 17th, 2012
by Marc Glisse 09 Jun '12

09 Jun '12

(sorry for the broken thread, I wasn't subscribed yet) A few quick comments: * gmpxx != mpfr_class * the version of gmpxx in the repository hasn't used any temporary for the example given in the introduction for a while, it is only because of a slow release cycle that you haven't seen it yet (will be in 5.1). * the example about using 0 vs 11 temporaries doesn't mention what happens to the boost package if we disable expression template. Does it use a single temporary (using rvalue-references) or plenty? * having an implicit narrowing conversion from double to bigint is a bad idea, it should be explicit (it isn't completely obvious from the doc if that is the case). * you could get good results with a backend that uses gmp's mpn_* functions but not the mpz_t type. * what about infinite precision floats? By that I mean something like bigint*2^n, where operations + - * are computed exactly. It can be quite a bit faster than rationals, when it is sufficient. * if I want reference-counting, I guess that should be done in a back-end. -- Marc Glisse

5 22

C++Now! keynote videos are available
by Marshall Clow 08 Jun '12

08 Jun '12

Howard's was not recorded Daveed: http://www.youtube.com/watch?v=8SOCYQ033K8 Sean: http://www.youtube.com/watch?v=iGenpw2NeKQ The full list of videos is at: http://www.youtube.com/user/BoostCon (more will be added soon) -- Marshall Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki

1 0

basic information: code post
by Majid Qureshi 08 Jun '12

08 Jun '12

Hi I am new to boost mailing list. I am wondering if I wish to submit my template class for review to be added as part of boost library, what do I need to do? and please advise if I am not suppose to send email to this mailing list for any such proposal. Also what mailing list do I need to send such emails? Very much appreciated.Thanks

2 1

[Who's using boost?] Sankel Software
by David Sankel 08 Jun '12

08 Jun '12

Sankel Software Sankel Software has been using boost for over 10 years to develop high performance and customized CAD/CAM applications, industrial control, computer artistry, and business software. If it wasn't for Boost, we would have stopped using C++ long ago. Its libraries allow us to write more concise code and, more importantly, give us the tools to implement higher level constructs such as denotational semantics based, top-down program design. Home Page: http://sankelsoftware.com Here is a list of the libraries we currently use: - Boost.Any - Boost.Serialization - Boost.Array - Boost.Assign - Boost.Bind - Boost.Integer - Boost.DateTime - Boost.Foreach - Boost.Function - Boost.Fusion - Boost.Variant - Boost.Optional - Boost.LexicalCast - Boost.SmartPtr - Boost.Math - Boost.MPL - Boost.MultiIndex - Boost.Operators - Boost.Signals2 - Boost.Thread - Boost.Tuple - Boost.TypeTraits - Boost.Utility - David -- David Sankel Sankel Software www.sankelsoftware.com 585 617 4748 (Office)

1 0

[1.50.0] Release branch open for bug fixes and doc updates
by Beman Dawes 07 Jun '12

07 Jun '12

The final release is scheduled for Monday, June 25th. The release candidate is scheduled to to be built Thursday, June 21st. That gives us two weeks to apply post-beta bug fixes and doc updates. Let's try a slightly more streamlined procedure for this post-beta period; until Monday, June 18th permission is not required to merge bug fixes and documentation updates. Starting June 18th permission of a release manager is required for all merges. As always, New libraries and new features are not allowed during a post-beta period. Thanks, --Beman

2 1

[1.50] Can't build quickbook PDF docs.
by John Maddock 07 Jun '12

07 Jun '12

Just a note that the quickbook docs don't build as a PDF due to XML validation failures at the FO stage: fop.render.pdf ..\..\bin.v2\tools\quickbook\doc\msvc-10.0\debug\link-static\threading-multi\quickbook.pdf M:/download/programs/xep/xep.bat ..\..\bin.v2\tools\quickbook\doc\msvc-10.0\debug\link-static\threading-multi\quickbook.fo ..\..\bin.v2\tools\quickbook\doc\msvc-10.0\debug\link-static\threading-multi\quickbook.pdf (document [system-id file:/M:/data/boost/branches/release/doc/pdf/../../bin.v2/tools/quickbook/doc/msvc-10.0/debug/link-static/threading-multi/quickbook.fo] (validate [error] Element 'fo:block' cannot be a child of 'fo:root'. [error] Element 'fo:block' cannot be a child of 'fo:root'. [error] Element 'fo:block' cannot be a child of 'fo:root'. [error] Attribute 'space-before.optimum' cannot occur at element 'fo:block'. [error] Attribute 'space-before.minimum' cannot occur at element 'fo:block'. [error] Attribute 'space-before.maximum' cannot occur at element 'fo:block'. [error] Attribute 'id' cannot occur at element 'fo:inline'. [error] Attribute 'break-before' cannot occur at element 'fo:block'. [error] Attribute 'id' cannot occur at element 'fo:block'. [error] Attribute 'margin-left' cannot occur at element 'fo:block'. [error] Attribute 'font-family' cannot occur at element 'fo:block'. [error] Attribute 'keep-together.within-column' cannot occur at element 'fo:block'. [error] Attribute 'keep-with-next.within-column' cannot occur at element 'fo:block'. [error] Attribute 'font-family' cannot occur at element 'fo:block'. [error] Attribute 'font-weight' cannot occur at element 'fo:block'. [error] Attribute 'keep-with-next.within-column' cannot occur at element 'fo:block'. [error] Attribute 'space-before.minimum' cannot occur at element 'fo:block'. [error] Attribute 'space-before.optimum' cannot occur at element 'fo:block'. [error] Attribute 'space-before.maximum' cannot occur at element 'fo:block'. [error] Attribute 'text-align' cannot occur at element 'fo:block'. [error] Attribute 'start-indent' cannot occur at element 'fo:block'. [error] Attribute 'marker-class-name' cannot occur at element 'fo:marker'. [error] Element 'fo:marker' should be a descendant of 'flow'. [error] Attribute 'font-size' cannot occur at element 'fo:block'. [error] Attribute 'id' cannot occur at element 'fo:inline'. [error] Attribute 'internal-destination' cannot occur at element 'fo:basic-link'. [error] Attribute 'color' cannot occur at element 'fo:inline'. [error] Attribute 'space-before.optimum' cannot occur at element 'fo:block'. [error] Attribute 'space-before.minimum' cannot occur at element 'fo:block'. [error] Attribute 'space-before.maximum' cannot occur at element 'fo:block'. [error] Attribute 'id' cannot occur at element 'fo:block'. [error] Attribute 'border-color' cannot occur at element 'fo:block'. [error] Attribute 'border-width' cannot occur at element 'fo:block'. [error] Attribute 'border-style' cannot occur at element 'fo:block'. [error] Attribute 'padding-left' cannot occur at element 'fo:block'. [error] Attribute 'padding-right' cannot occur at element 'fo:block'. [error] Attribute 'padding-top' cannot occur at element 'fo:block'. [error] Attribute 'padding-bottom' cannot occur at element 'fo:block'. [error] Attribute 'widows' cannot occur at element 'fo:block'. [error] Attribute 'orphans' cannot occur at element 'fo:block'. [error] Attribute 'font-size' cannot occur at element 'fo:block'. [error] Attribute 'hyphenate' cannot occur at element 'fo:block'. etc. Any ideas? Thanks, John.

2 1

status of sp_counted_base_solaris.hpp
by Graham Bennett 07 Jun '12

07 Jun '12

Hi all, I'm interested in getting boost::shared_ptr to use atomic ops on Solaris. I notice there is an implementation using the OS-provided atomics in boost/detail/sp_counted_base_solaris.hpp, but it doesn't seem to be included. According to this thread: http://lists.boost.org/Archives/boost/2006/07/107144.php, it seems the reason might be that it wasn't possible to come up with a proper preprocessor condition to include it on the right versions of Solaris. I'm considering modifying my boost installation to include this header on Solaris - does anyone know of any issues with the code, or can they confirm that it has been well tested? Are there any other reasons for its omission? Thanks, Graham -- Graham Bennett

4 7

[review] Multiprecision review scheduled for June 8th - 17th, 2012
by Jeffrey Lee Hellrung, Jr. 07 Jun '12

07 Jun '12

Hi all, The review of the proposed Boost.Multiprecision library authored by John Maddock and Christopher Kormanyos has been scheduled for June 8th - June 17th, 2012 and will be managed by myself. >From the Introduction: -------- "The Multiprecision Library provides *User-defined* integer, rational and floating-point C++ types which try to emulate as closely as practicable the C++ built-in types, but provide for more range and precision. Depending upon the number type, precision may be arbitrarily large (limited only by available memory), fixed at compile time values, for example 50 decimal digits, or a variable controlled at run-time by member functions. The types are expression-template-enabled for better performance than naive user-defined types." -------- And from the original formal review request from John: -------- Features: * Expression template enabled front end. * Support for Integer, Rational and Floating Point types. Supported Integer backends: * GMP. * Libtommath. * cpp_int. cpp_int is an all C++ Boost licensed backend, supports both arbitrary precision types (with Allocator support), and signed and unsigned fixed precision types (with no memory allocation). There are also some integer specific functions - for Miller Rabin testing, bit fiddling, random numbers. Plus interoperability with Boost.Rational (though that loses the expression template frontend). Supported Rational Backends: * GMP * libtommath * cpp_int (as above) Supported Floating point backends: * GMP * MPFR * cpp_dec_float cpp_dec_float is an all C++ Boost licensed type, adapted from Christopher Kormanyos' e_float code (published in TOMS last year). All the floating point types, have full std lib support (cos sin exp, pow etc), as well as full interoperability with Boost.Math. There's nothing in principal to prevent extension to complex numbers and interval arithmetic types (plus any other number types I've forgotten!), but I've run out of energy for now ;-) Code is in the sandbox under /big_number/. Docs can be viewed online here: http://svn.boost.org/svn/boost/sandbox/big_number/libs/multiprecision/doc/h… -------- I hope everyone interested can reserve some time to read through the documentation, try the code out, and post a formal review, either during the formal review window or before. I expect to conduct the review in the "traditional" manner, i.e., entirely within the regular boost developers' mailing list (boost(a)lists.boost.org) I will send a reminder of review process details closer to the review window. Thanks! - Jeff

4 23

1.50.0 beta 1 Beta release available
by Beman Dawes 06 Jun '12

06 Jun '12

Boost release 1.50.0 beta 1 is now available from SourceForge See http://sourceforge.net/projects/boost/files/ This release contains 4 new libraries (Algorithm, Functional/OverloadedFunction, LocalFunction, Utility/IdentityType) and numerous enhancements and bug fixes for existing libraries. For details of what's in the release, see http://beta.boost.org/users/history/version_1_50_0.html. Note that the links to files on this web page are for the final release - use the SourceForge link above to get the beta files. Please download the beta, give it a try, and report any problems you encounter. Thanks, -- The Boost Release Team

2 1

[1.50.0] Beta 1 release candidates available for testing
by Beman Dawes 06 Jun '12

06 Jun '12

Release candidate files for 1.50.0 beta 1 are available at http://boost.cowic.de/rc/ As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. This helps ensure the candidates build OK before we push them out to SourceForge. Thanks, --Beman --PS: I tested the 7z version, and it built without errors on Win7/VC++ Express 2010 sp1

16 43

Re: [boost] [review] Multiprecision review scheduled for June 8th - 17th, 2012
by John Maddock 06 Jun '12

06 Jun '12

>>Let us know as soon as you have some results. > > Tested the time taken to run through all the Boost.Math Bessel function > tests, with type double, real_concept (a simple wrapper around double from > Boost.Math's test suite) and mp_number<float_backend<double> > (a trivial > mp_number backend that wraps a floating point type): > > Time for double = 0.0157549 seconds > Time for real_concept = 0.0166421 seconds > Time for float_backend<double> = 0.0408635 seconds > Time for float_backend<double> - no expression templates = 0.0253047 > seconds > > So as you can see, expression templates are a dis-optimization for such > simple types, and even without them you take a noticeable hit: I'm a > little disappointed by this, but not that surprised, mp_number is a rather > heavyweight solution for lightweight types if you see what I mean. > > In any case I'll have a look at the assembly to see if there are any > obvious non-optimizations going on. >From a quick casual look it appears as though the extra time is going in functions not expanded inline - that's certainly the case for the expression template unpacking code. Seems like there may be some small opportunity for optimization of the comparison operators as well (i.e. not evaluating in terms of a compare() function). However, that latter case is only appropriate for exceptionally lightweight backends, for most typical extended precision backends, non of this will make the slightest difference at all... John.

3 3

[COUNTERTREE + SUBALLOCATOR ] New Version
by Francisco José Tapia 05 Jun '12

05 Jun '12

Hi this message is to announce the new version of the [countertree + suballocator] library. You can find in (http://dl.dropbox.com/u/8437476/works/countertree/index.html)<http://dl.dropbox.com/u/8437476/works/countertree/index.html> When I was writing the document explaining the allocator's algorithm. I reexamined my code , and It run well and have an easy interface , but the internal design was obscure and difficult to understand. Due this, I decided redesign it in order to make it clear and easy to understand. I changed too the version of the GCC compiler form the 4.6 to 4.7, and the machine used for the benchmarks. My old computer, where I developed the code, had a good cache but a bad bus memory (Single channel 533Mz), and this introduce a distortion in the comparison of some algorithms. The new machine is a QuadCore with 8M of cache and 8G dual channel 1066 MHz. The results obtained are more similar to the obtained in a modern machine. I added a new point to the documentation explaining the additional features of the countertree set, multiset, map and multimap with two examples. You can find in ( http://dl.dropbox.com/u/8437476/works/countertree/ordered.html#functionality) For the people who don't know this project, this is a description : *COUNTERTREE* This library is an implementation of a binary red-black counter tree. This tree have an additional counter in each leaf. This permit the access to the elements by the position, like in a vector. It is a random access container with random access iterators . With this tree we have vectors (cntree::vector_tree) with identical interface than std::vector. The vector_tree have the same speed inserting and deleting in any position (all the operations are O(log N)).It is slower than std:vector inserting and deleting at end, but much faster for to insert and delete in any other position. With ordered information, we have in the cntree namespace the classes set, multiset, map and multimap, with identical interface than the STL classes, with the plus of access to the elements by position, like in a vector. The iterators are random access , and you can subtract two iterators in a O(log N) time for to know the number of nodes between them (even with the end( ) and rend( ) iterators) *SUBALLOCATOR* The allocator is the data structure defined in the STL, as interface between the data structures and the memory provided by the Operating System (O.S.). The allocator manages the memory received from the Operating System, and the memory requested in the allocate operations and the memory returned in the deallocate operations. To write an allocator for to manage a wide range of size elements and a big number of elements (several millions) of each size in a fast way, it's a very difficult task. When the number of elements grows, many allocators begin to have speed problems. For to improve the speed allocating of the small size elements, many allocators request to the Operating System big chucks of memory. With this, the allocator don't need request memory to the operating system for each allocation. But many allocators don't return well the unused chucks of memory to the Operating System and the memory used by the allocator is the maximum used, never decrease . These allocators are named pool allocators. If you have a small number of elements, you have a small problem, small resources and small time operations. But, if you have several millions of elements allocated, perhaps you are using several GB of memory. Running a program with GB of memory don't used, because the allocator don't return the memory request, is a great waste of resources. This problem is specially important in two environments : - When you have a limited resources, as occurs in the mobile phones, pads , tablets... - When the programs must run continuously in a multitask environment If you use an allocator for the allocation of variable size elements, and a pool allocator for the allocation of fixed size elements, this improve the speed, but increase the memory consumption, which is the sum of the maximum memory of the pool allocator and the memory used by the allocator. If the pool allocator don't return to the Operating System the unused memory, this can't be reused by the allocator. The *suballocator is a solution to these problems*, and others memory problems described in the suballocator page. The suballocator is a layer between the allocator and the data structures, compatible with any allocator with the STL definition. The suballocator request memory to the allocator, and return to it when unused. With the suballocator a) *We have a very fast allocation* *(around 2 times faster than the std::allocator of GCC 4.7, CLANG 3.0 and 3 times than Visual Studio 10 *See details in the *Suballocator Benchmark<http://dl.dropbox.com/u/8437476/works/countertree/suballocator.html#benchma…> *)* b) *Return memory to the allocator, for to be used by others types of data*. Many allocators, return this memory to the Operating System, and decrease the memory used by the program, *( as you can see in the *Suballocator Benchmark <http://dl.dropbox.com/u/8437476/works/countertree/suballocator.html#benchma…> *)* c) *You can use with any allocator if it is according with the STL definition*. The suballocator provides speed and memory management to any allocator d) Even the time of the allocation is a small part of the time spent in the insertion in a std::set, the suballocator obtain time reductions over over the 30% respect the std::allocator. The secret is the cache performance due to the data locality improvement. *COUNTERTREE + SUBALLOCATOR* The join of the two ideas provide us data structures with a suballocator built-in. They are, in the namespace cntree, the vector_tree_pool, set_pool, multiset_pool,map_pool and multimap_pool, with identical interface than the STL classes but better performance. Tray it. It fast, useful and easy to understand and use,. They are the STL classes with a few additional functions. I had checked this code with GCC 4.7 (32 and 64) , CLANG/LLVM 3.0 and Visual Studio 1010 (32 and 64). If you find any error or problem in the code , the documentation or in any other part ( as friendly do Mr Rene Rivera in the first version). Please mail me ( fjtapia(a)gmail.com) or if you mail Boost, please insert [countertree] in the head of the message. Some days I have not time to read all messages arrived to my mail, but if I see that I detect and respond first. If you have some idea, or have any comment, please mail me, always two legs run more than only one in the pursuit of the goal, to be useful to the community of programmers in the same way than our predecessors had been useful to us. Sincerely yours Francisco Tapia fjtapia(a)gmail.com

1 0

[Who's Using Boost?] FaceBook
by Brian Wood 05 Jun '12

05 Jun '12

Thanks for the link. I notice Folly has an IntrusiveList derived from boost::intrusive::list. We have a nickname for boost::intrusive::list also -- ilist. Perhaps there are others who have done the same? Shalom, Brian Wood Ebenezer Enterprises http://webEbenezer.net

1 0

[bind] Move Parameters?
by Daniel Larimer 05 Jun '12

05 Jun '12

Say I have some synchronous code like this: vector<data> v; some_method( std::move(v) ) Now I want to call to make that some_method call asynchronous so what I really want is function<void()> f = bind( some_method, boost::rref( std::move(v) ) ) asio_io_service.post(f); // performs async move of v into some_method asio_io_service.post(f); // undefined, or throw bound parameter has already moved... As far as I can tell there is no current support for anything like this, and I think it could be very useful. Dan

1 0

Re: [boost] [git/modularization] Suggested names for branches?
by Sean Chittenden 04 Jun '12

04 Jun '12

> The three branches in question, with the git-flow names in parens, > were the main development branch (develop), release prep branches (?), > and the branch with actual releases (master). > > Is there a better usual convention for these names? I have a vague > memory of someone mentioning "master" for the main development branch, > "release" for the branch with the actual releases, and maybe > "beta-x.xx.x" for release prep branches. re: git flow branch names, I'd advocate for their use simply because it matches all of the external training material (videos, docs, flow charts, etc) available regarding the use of git flow (and it reduces the friction for getting initially setup). I agree that they aren't ideal and much prefer the naming convention used by the FreeBSD project (where branch names indicate a stable API, 9-STABLE, 8-STABLE, etc., vs -CURRENT), but I'd stick with the default names for now and then in a release or three consider changing from the defaults to something boost specific. -sc # Initialize default git flow branches git flow init -d # From project/.git/config [gitflow "branch"] master = master develop = develop [gitflow "prefix"] feature = feature/ release = release/ hotfix = hotfix/ support = support/ versiontag = -- Sean Chittenden sean(a)chittenden.org

1 0

folly (Facebook's open source C++ library)
by Tudor Bosman 04 Jun '12

04 Jun '12

https://www.facebook.com/notes/facebook-engineering/folly-the-facebook-open… I'm Tudor, one of the folly developers. I'll try to answer your questions or poke the appropriate people :) Re: "NO EXCEPTIONS" in the README -- the README file was intended for internal Facebook contributors (hence stray references to internal paths), and "NO EXCEPTIONS" referred to "no exceptions to the rules above", NOT "no C++ exceptions". Will fix / clarify / remove soon. -Tudor.

2 1

[Who's Using Boost?] FaceBook
by Dave Abrahams 04 Jun '12

04 Jun '12

as noted in https://www.facebook.com/notes/facebook-engineering/folly-the-facebook-open… -- Dave Abrahams BoostPro Computing http://www.boostpro.com

5 4

asio::epoll_reactor::complete_operations_and_timers() - thread saftey
by Hite, Christopher 04 Jun '12

04 Jun '12

I thought I'd take a look at the epoll_reactor implementation. I thinking of using asio proactor style code to use kernel bypass libraries. I wanted to see how you do async IO with a pool of threads. I think I see a bug. None of the operations there done outside of the lock seem thread safe. They unsafely modify linked lists. lock.unlock(); read_op_queue_.complete_operations(); write_op_queue_.complete_operations(); except_op_queue_.complete_operations(); Chris

1 0

[python] run python script from bjam
by lcaminiti 03 Jun '12

03 Jun '12

Hello all, I build a Boost.Python module and install it using bjam as follow: python-extension pydef : deduced_params_pydef.cpp : <library>/boost/python//boost_python <library>/boost/regex//boost_regex <link>shared:<define>BOOST_REGEX_DYN_LINK=1 ; install pydef_install : pydef : <install-dependencies>on <install-type>SHARED_LIB <install-type>PYTHON_EXTENSION <location>. ; I the same dir I have a python script deduced_params_pydef.py which will import the module and test it. How do I run the python script automatically from bjam so to fully compile and test the module that my code generates? Something like (this doesn't work of course): # Make sure pydef target is built first, then runs python deduced_params_pydef.py run-py pydef_install : deduced_params_pydef.py ; Thanks a lot. --Lorenzo -- View this message in context: http://boost.2283326.n4.nabble.com/boost-python-run-python-script-from-bjam… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 2

boost.unordered undocumented methods
by niXman 03 Jun '12

03 Jun '12

Hello! In the documentation for boost-1.49.0 the following methods are not documented: https://github.com/ryppl/boost-svn/blob/master/boost/unordered/unordered_ma… https://github.com/ryppl/boost-svn/blob/master/boost/unordered/unordered_ma… https://github.com/ryppl/boost-svn/blob/master/boost/unordered/unordered_ma… https://github.com/ryppl/boost-svn/blob/master/boost/unordered/unordered_ma… https://github.com/ryppl/boost-svn/blob/master/boost/unordered/unordered_se… https://github.com/ryppl/boost-svn/blob/master/boost/unordered/unordered_se… https://github.com/ryppl/boost-svn/blob/master/boost/unordered/unordered_se… https://github.com/ryppl/boost-svn/blob/master/boost/unordered/unordered_se… -- Regards, niXman ___________________________________________________ Dual-target(i686/x86_64) MinGW compilers for i686/x86_64 hosts: http://sourceforge.net/projects/mingwbuilds/

1 0

Is there interest in copyable type_info that does not require RTTI (was: Is there interest in typeid(TYPE).name() like function that does not require RTTI)
by Antony Polukhin 03 Jun '12

03 Jun '12

Hi, There is a detail/sp_typeinfo.hpp which is not documented, and has some drawbacks. This header provides type_info like class that can be used with RTTI disabled. I am proposing to refactor this header, move it to utility/template_info.hpp and document it as a separate utility. Refactored header will provide classes template_info_ptr, template_info<T>, type_info_ptr and free function get_template_info<T>() Advantages: 1) more portable and reliable than detail::sp_typeinfo (no sp_typeid_<T>::ti_ public static variable) 2) copyable type_info like classes 3) has all the type_info functions + name_demangle 4) works with disabled RTTI 5) better functionality: no need to write macros like: #if defined( BOOST_NO_TYPEID ) # define BOOST_FUNCTION_COMPARE_TYPE_ID(X,Y) ((X)==(Y)) #elif (defined(__GNUC__) && __GNUC__ >= 3) \ || defined(_AIX) \ || ( defined(__sgi) && defined(__host_mips)) # include <cstring> # define BOOST_FUNCTION_COMPARE_TYPE_ID(X,Y) \ (std::strcmp((X).name(),(Y).name()) == 0) # else # define BOOST_FUNCTION_COMPARE_TYPE_ID(X,Y) ((X)==(Y)) #endif 6) user can explicitly chose between template_info+template_info_ptr and type_info+type_info_ptr 7) no macro (get_template_info<T>() instead of &BOOST_SP_TYPEINFO(T) ) Disadvantages: 1) Does not work with variables (but you can still use BOOST_TEMPLATE_INFO_PTR(BOOST_TYPEOF(var))) 2) BOOST_CURRENT_FUNCTION produces long strings, and that could lead to code bloat when RTTI disabled Some usage examples: int main () { // Portable way that works with and without RTTI: copyable_type_info t1 = get_template_info<std::string>(); copyable_type_info t2 = get_template_info<int>(); // class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > std::cerr << t1.name_demangled() << '\n'; // int std::cerr << t2.name_demangled() << '\n'; // false std::cerr << (t1 == t2) << '\n'; // true std::cerr << (t1 != t2) << '\n'; copyable_type_info t1_copy = t1; // .?AV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@ std::cerr << get_template_info<std::string>().name() << '\n'; // class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > std::cerr << get_template_info<std::string>().name_demangled() << '\n'; // explicitly using no-RTTI methods // int>::name_begin(void) std::cerr << template_info<int>::name_begin() << '\n'; // int std::cerr << template_info<int>::name_demangled() << '\n'; // class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > >::name_begin(void) std::cerr << template_info<std::string>::name_begin() << '\n'; // class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > std::cerr << template_info<std::string>::name_demangled() << '\n'; template_info_ptr p1 = template_info<int>::construct(); template_info_ptr p2 = template_info<std::string>::construct(); std::cerr << (p1 == p2) << '\n'; std::cerr << (p1 != p2) << '\n'; } If there is interest, I can commit code to sandbox and request for review. P.S.: As I know, Boost.Function, Boost.Shared_ptr and Boost.Exception use code similar to what I am proposing. Following libraries use typeid() and can benefit from using proposed classes: Boost.MSM, Boost.Math, Boost.Test, Boost.Graph, Boost.Units, Boost.XPressive, Boost.Any, Boost.Statechart -- Best regards, Antony Polukhin

3 4

[filesystem] Linker error against std::codecvt in VS2012 RC
by Lars Viklund 02 Jun '12

02 Jun '12

Hi list, I foolishly installed the Visual Studio 2012 RC yesterday night and made an overnight build of Boost. It seems like there's something awry, as I'm getting a mysterious linker error in Filesystem's path.obj [1], even in a fresh empty testbed project. I'm linking Boost statically and the CRT dynamically. If I link the CRT statically, the linker error goes away. Has anyone else installed this software and can reproduce this problem? I'm building Boost against trunk, r78785. I dread to think of the horror that I will have go through in actually reporting a bug against the runtime itself :( [1] 1>libboost_filesystem-vc110-mt-gd-1_50.lib(path.obj) : error LNK2001: unresolved external symbol "protected: virtual int __thiscall std::codecvt<wchar_t,char,int>::do_length(int const &,char const *,char const *,unsigned int)const " (?do_length@?$codecvt@_WDH@std@@MBEHABHPBD1I@Z) -- Lars Viklund | zao(a)acc.umu.se

4 5

[msm]entry point pseudo states and events (Re: [msm] orthogonal region and event consume)
by Takatoshi Kondo 02 Jun '12

02 Jun '12

Hi Christophe, I changed the subject. Current topic isn't concerned with orthogonal region directly. On Thu, May 31, 2012 at 5:43 AM, Christophe Henry <christophe.j.henry(a)googlemail.com> wrote: > Hi Takatoshi, > > >>> I read your ticket. Note that it's not UML-conform to have 2 transitions >>> originating from Entry1 (11-08-06.pdf §15.3.8 page 551). >>> After reading the Standard again twice, I realized that no example >>> provided >>> there displays any event on both transitions, which is really bad if it's >>> what they mean. I need to have a look at other literature. > > >> I read the section that you mentioned carefully. My interpretation of >> UML specification is different from yours. >> It's really difficult to explain my interpretation. So, I draw the >> diagram. See the attached file. >> Am I misunderstanding? > > > I will not pretend I have the perfect understanding of the Standard. Here's > my take. I also saw the sentence on top of your diagram and didn't fully > understand it when reading the Standard. There is also the following > sentence in the Standard: > > "An entry pseudostate is used to join an external transition terminating on > that entry point to an internal transition > emanating from that entry point". > > Which sounds logical because on your diagram the regions would not be > orthogonal. > > This means you cannot have transitions triggered by different events leading > to the entry point, not can you have different transitions leaving it. You > will need more entry points. > > Caution: I am far from being sure I got it right. That's why I precised my > definition of it in the doc. The implemented solution has the advantage that > you have the normal transition handling, including multiple transitions and > guards, events with data, base events, etc. > What you don't have is entry in multiple regions, which only the fork > currently provides, at the cost of lesser encapsulation. > Correct or not, this is the part of the Standard I chose to implement pseudo > entries. > > To be honest, I'm not of fan of pseudo entries. I prefer the vastly superior > solution of entering a submachine the "normal" way, then letting a > templatized, enable_if'd on_entry of the submachine do something clever with > the event at compile-time. Aha! I completely overlooked such approach. For example, we can choose the initial state in submachine using mpl and initial_state typedef instead of using entry_pseudo_state. I believe that I've understood your design decisions. I also think that following the UML standard blindly is not essential. >> My goal is to improve sub-machines' re-usability. If we want to reuse >> sub-machines in another state machines, sub-machines shouldn't know >> the outside information. > > > I agree but is it the case? I mean, if you send normal events to your > submachine through your outer machine, it also needs to know them, right? > I understand this as: "hi, I'm a submachine and I provide the following > entry points: Entry1 requires Event1, Entry2 requires Event2, etc.". A bit > like function parameters. I wanted to explain that as follows: "hi, I'm a submachine and I provide the following entry points: Entry1 accepts any events. Because I don't care that. " Let me introduce more practical example that requires entry_pseudo_state. ScanFinger.png is a sub-machine. This sub-machine's primary purpose is to scan fingerprint. Before scanning, the sub-machine checks that finger is alive or not. But it's optional. To skip this check procedure, the entry point pseudo state ScanOnly is provided. FingerPrintRegister.png is the parent state machine. It uses ScanFinger as a sub-machine twice. In this scenario, alive checking is not required. So, the parent machine uses ScanOnly enty_pt. In another scenario, not mentioned here, might require the normal entry into ScanFinger to check the finger is alive. ScanFinger machine doesn't care about outer event. In FingerPrintRegister, the states RightScnning and LeftScanning have different incoming events for ScanOnly entry points. But any events are accepted. And then, it's not referred. Based on your suggestion, I introduce the base event class. As long as the incoming event of entry point is not "none", this approach works good. struct AnyEvent {}; struct Completed: public AnyEvent {}; struct StartButtonPressed: public AnyEvent {}; (See 39_FingerPrintExampleBaseEvent.cpp) If the incoming event is "none", the transition is stopped. Sometimes I want to use "none" as incoming event for entry point in the same sub-machine. And it is impossible that msm::front::none inherits user event classes such as AnyEvent. I'm trying to find better approach to solve the above problem. Thanks, Takatoshi >> See my second mail in this thread. My solution using templates >> (entry_pseudo_event_template.cpp) requires the template parameters >> same as the number of entry point pseudo states in sub-machine. It's >> acceptable but if outgoing transition would be able to use none, I >> would remove the template parameters. > > >> In the above case, it is not required to support multiple incoming >> transitions to one entry pseudo state. Because the instances of >> sub-machine are different. > > > In this case, maybe I could interest you in defining a base event class for > Event1 and Event2, then making this base event the event triggering the > inside transition. Your first example would be changed this way: > > struct BaseEvent {}; > struct Event1: public BaseEvent {}; > ... > msmf::Row < Entry1, BaseEvent, State2_2, msmf::none, msmf::none > > > > > Regards, > Christophe > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost

2 6

Interest in double-ended priority queue? (priority_deque)
by Nathaniel McClatchey 02 Jun '12

02 Jun '12

Details: Template-based container adapter. Mimics std::priority_queue interface and requirements. O(1) read and O(log n) delete of either end of queue. O(n) create and merge. Functions for unordered access and mutating of elements. Remaining development: Further optimization. Note: Implementation is similar to but independent from http://lists.boost.org/Archives/boost/2011/12/188848.php

2 2

Standardization of Boost (and other) libraries
by Beman Dawes 01 Jun '12

01 Jun '12

The C++ standards committee has set up a discussion forum (also accessible via email) to help those preparing language and library proposals. Requests for feedback, help, champions, and anything else related to proposals is on topic. https://groups.google.com/a/isocpp.org/forum/#!forum/std-proposals Note that this is a different URL than mentioned at C++Now! - language and library proposal groups have since been combined into a single group. After some false starts, discussion has started in earnest. The first two requests for feedback were on proposals for Boost.Any and Boost.Optional. If you are interested in proposing a Boost library for standardization, you probably want to check out std-proposals. --Beman

1 0

Re: [boost] [review] Multiprecision review scheduled for June 8th - 17th, 2012
by John Maddock 01 Jun '12

01 Jun '12

>>* What is the type of boost::multiprecision::number_category<B>::type for >>all the provided backends? Could the specialization for >>boost::multiprecision::number_category<B>::type be added in the >>documentation of each backend? and why not add also B::signed_types, >>B::unsigned_types, B::float_types, B::exponent_type? > > OK. On second thoughts, the members of B::signed_types etc are basically implementation details - optimizations if you will. Rather than listing the types explicitly I'd prefer some more weasel wording along the lines of "This type will interoperate natively with any signed or unsigned built in integer type no wider than a long - this means for example that multiplying by a integer literal is more efficient than constructing an mpz_int temporary from the integer and then multiplying. Likewise for the other arithmetic operations." John.

1 0

Re: [boost] [filesystem] Linker error against std::codecvt in VS2012 RC
by Stewart, Robert 01 Jun '12

01 Jun '12

Peter Dimov wrote: > Lars Viklund wrote: > > > [1] 1>libboost_filesystem-vc110-mt-gd-1_50.lib(path.obj) : > > error LNK2001: unresolved external symbol "protected: virtual > > int __thiscall std::codecvt<wchar_t,char,int>::do_length(int > > const &,char const *,char const *,unsigned int)const " > > (?do_length@?$codecvt@_WDH@std@@MBEHABHPBD1I@Z) > > Well, you could start by preparing a simple test program that > calls std::codecvt in the same way path.obj does, to eliminate > Boost as a factor. If do_length is indeed not present in the > dynamic runtime, this would probably be a showstopper bug > against the RC, so it will get noticed. :-) If that's not the problem, verify that you built Boost.Filesystem using the same CRT. _____ Rob Stewart robert.stewart(a)sig.com Software Engineer using std::disclaimer; Dev Tools & Components Susquehanna International Group, LLP http://www.sig.com ________________________________ IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

2 1