March 2011 - Boost - lists.preview.boost.org

[type_traits] extension has_operator_xxx - cv qualifiers and references
by Frédéric Bron 06 Mar '11

06 Mar '11

New version of the type_traits extension available here: - vault unix newlines: http://www.boostpro.com/vault/index.php?action=downloadfile&filename=type_t… - vault dos newlines: http://www.boostpro.com/vault/index.php?action=downloadfile&filename=type_t… - sandbox: http://svn.boost.org/svn/boost/sandbox/type_traits/ This version now handles correctly cv qualifiers and references, which was not the case before. Frédéric

4 33

[xint] Performance of fixed-size large integers
by Phil Endecott 06 Mar '11

06 Mar '11

Dear All, I've never needed to use arbitrary-precision integers, but I have sometimes wanted large fixed-size integers like uint128_t, and so I've had a quick look at that aspect of the proposed Xint. The docs' front page has a link under "Detailed Usage Information" to "Fixed-Length Integers" - which is not really very detailed, and has examples in the notes like "integer_t<8>" that don't work. I established quickly enough that the correct syntax is integer_t<fixedlength<8>>. Also I noted that the conventions here don't match the built-in (u)intN_t types, i.e. int64_t vs. int63_t and the "wrap-around" behaviour. Perhaps there is some rationale for this, but I would be happier to see it consistent with the built-in types. (It might also be appropriate to think about how this could work with the existing Boost.Integer.) I have done a quick test of the performance of a 96-bit type as follows: typedef boost::xint::integer_t< boost::xint::options::fixedlength<96> > uint96_t; uint96_t a = 0; uint96_t b = 0; for (int i=1; i<loops; ++i) { a = a + a + (a & b) + i; b = b + i; } This is an entirely contrived example, but the point is to minimise the work that I have to do to create something to compare it with; by using only operator+ and operator&, I can quickly hack together this: struct uint96_t { uint32_t top; uint32_t mid; uint32_t bottom; uint96_t() {} uint96_t(uint32_t val): top(0), mid(0), bottom(val) {} }; uint96_t operator&(uint96_t a, uint96_t b) { uint96_t r; r.top = a.top & b.top; r.mid = a.mid & b.mid; r.bottom = a.bottom & b.bottom; return r; } uint96_t operator+(uint96_t a, uint96_t b) { uint96_t r; __asm__( "adds %0, %3, %6\n" // Add and set carry flag "adcs %1, %4, %7\n" // Add with carry-in and set carry flag "adc %2, %5, %8\n" // Add with carry-in. : "=r" (r.bottom), // %0 "=r" (r.mid), // %1 "=r" (r.top) // %2 : "r" (a.bottom), // %3 "r" (a.mid), // %4 "r" (a.top), // %5 "r" (b.bottom), // %6 "r" (b.mid), // %7 "r" (b.top) // %8 : "cc" ); return r; } It seems to me that that is several hundred times faster than the Xint code (on my 1.2 GHz ARM test system). Yes, it requires assembler in order to do multi-word addition with carry, but we can write a less efficient portable version of that: uint96_t operator+(uint96_t a, uint96_t b) { uint96_t r; r.bottom = a.bottom + b.bottom; int carry0 = r.bottom < a.bottom ? 1 : 0; r.mid = a.mid + b.mid + carry0; int carry1 = r.mid < a.mid ? 1 : 0; // hmm, not totally sure about that... r.top = a.top + b.top + carry1; return r; } This is about half the speed of the assembler, but still hundreds of times faster than the Xint code. Based on that, I think the claim that the library is "fast" on its front page needs substantiating. I encourage anyone with experience of arbitrary-precision variable-length numbers to run some quick benchmarks. (Or, maybe I'm doing something horribly wrong here. I haven't even checked that I get the right answer.) Other reviews have reported that in this fixed-length case the library still stores some overhead in addition to the actual data. That's unfortunate as I would like to be able to, for example, store values in a memory-mapped file, or to use them in e.g. Beman's proposed b-tree library. I don't want to write a review that says "This library doesn't do what I want, therefore it should be rejected". No doubt others will find applications where it will be useful. But I think the performance when used for fixed-size integers should be investigated. Regards, Phil.

10 21

[xint] Review
by Mathias Gaunard 05 Mar '11

05 Mar '11

I would like to vote against acceptance of the XInt library in Boost. The various comments I have written in other threads should be enough to justify that vote.

2 1

[Locale] Version 2.93 released
by Artyom 05 Mar '11

05 Mar '11

Hello All, New version 2.93 of Boost.Locale was released: ============================================== Documentation: http://cppcms.sourceforge.net/boost_locale/html/index.html Downloads: https://sourceforge.net/projects/cppcms/files/boost_locale/ What is Boost.Locale ==================== Boost.Locale is a library that provides high quality localization facilities in a C++ way. It uses std::locale facets to provide localization in transparent and C++-aware manner. Changes in this version ======================== Breaking changes: ----------------- - The default locale's narrow encoding under Microsoft Windows is now UTF-8. It can be reverted back to ANSI encoding by using boost::locale::generator::use_ansi_encoding() for compatibility with legacy applications - The default encoding of "add_messages_path" (location of message catalogs) on Windows is now locale's encoding. Removed wide path API as inconsistent and too Windows specific. New Features: ------------- - Added date_time and calendar support for non-ICU based backends. It is limited to the Gregorian calendar only but fully supports local start of week and OS specific local time handling. Enhancements: ------------- - Major performance optimizations for ICU backend. It uses TLS for caching of collation and formatting objects. Boost.Thread is now required dependency when using ICU or using Boost < 1.43 - Performance optimizations for std collation backend - Added support of checking if current time is in daylight savings time - Tutorial is converted to Doxygen format and now much easier to navigate. - Language corrections of the tutorial by Chad Nelson. Thanks! - Workaround of ICU bug in detection of the OS timezone on Linux for ICU versions 4.0-4.4 - Numerous bug fixes. TODO: ----- Currently Boost.Build is not supported only CMake is valid build option. It would be fixed in next release before the formal review. Regards, Artyom Beilis. ----------------------------------------------------------------- My other projects: CppCMS - C++ Web framework: http://cppcms.sourceforge.net/wikipp/en/page/main CppDB - C++ SQL Connectivity Library: http://cppcms.sourceforge.net/sql/cppdb/

1 0

SVN slow again?
by John Maddock 05 Mar '11

05 Mar '11

I've been trying and failing to check out a copy of the release branch the last two days - I keep getting SVN timeouts. Looking at svn.boost.org I see the server load has gone up to 23.92 which seems crazy high compared to where it was before? Any ideas? Thanks, John.

7 19

Knapsack problem
by Dávid Tóth 05 Mar '11

05 Mar '11

Would it be useful to have a library that would be able solve Knapsack problem?

3 2

[DynamicAny] Feedback
by Daniel Larimer 05 Mar '11

05 Mar '11

I recently ran into a problem where I wanted to retrieve the value stored in a boost::any by casting to a base class. Unfortunately, boost::any requires you cast out the exact type as that held. Boost.DynamicAny is a vairant on Boost.Any which provides more flexible dynamic casting of the underlying type. Whereas retreiving a value from Boost.Any requires that you know the exact type stored within the Any, Boost.DynamicAny allows you to dynamically cast to either a base or derived class of the held type. Boost.DynamicAny passes all of the same unit tests as Boost.Any, but additionally supports the following test: #include <boost/dynamic_any.hpp> using boost::dynamic_any_cast; struct base { int a; }; struct base1 { int a1; }; struct derived : base, base1 { int b; }; struct other {}; void test_dynamic_cast() { derived d; dynamic_any a(d); derived & ra = dynamic_any_cast<derived&>(a); base & b = dynamic_any_cast<base&>(a); base1 & b1 = dynamic_any_cast<base1&>(a); const base1 & cb1 = dynamic_any_cast<const base1&>(a); TEST_CHECK_THROW( dynamic_any_cast<other&>(a), bad_dynamic_any_cast, "dynamic_any_cast to incorrect reference type"); For scalar types, Boost.DynamicAny works just like Boost.Any. This means that it currently does not support dynamic casting of pointers stored within the any, but that should not be too hard to add. https://github.com/bytemaster/Boost.DynamicAny

6 9

[PATCH v2] [exception] Replace C cast with static_cast for Metrowerks C++
by Joshua Juran 05 Mar '11

05 Mar '11

Metrowerks C++ 2.4.1 thinks the type of (T*)0 is T, rather than T*. But static_cast works fine. --- This patch doesn't affect the compilation of g++ 4.0.1. diff --git boost/exception/exception.hpp boost/exception/exception.hpp index adaac68..afb2008 100644 --- boost/exception/exception.hpp +++ boost/exception/exception.hpp @@ -334,7 +334,7 @@ boost struct enable_error_info_return_type { - typedef typename enable_error_info_helper <T,sizeof(exception_detail::dispatch_boost_exception((T*)0))>::type type; + typedef typename enable_error_info_helper < T ,sizeof (exception_detail ::dispatch_boost_exception(static_cast<T*>(0)))>::type type; }; }

1 0

[PATCH] [exception] Replace C cast with reinterpret_cast for Metrowerks C++
by Joshua Juran 05 Mar '11

05 Mar '11

Metrowerks C++ 2.4.1 thinks the type of (T*)0 is T, rather than T*. But reinterpret_cast works fine. --- This patch doesn't affect the compilation of g++ 4.0.1. diff --git boost/exception/exception.hpp boost/exception/exception.hpp index fd516dd..87063af 100644 --- boost/exception/exception.hpp +++ boost/exception/exception.hpp @@ -334,7 +334,7 @@ boost struct enable_error_info_return_type { - typedef typename enable_error_info_helper <T,sizeof(exception_detail::dispatch_boost_exception((T*)0))>::type type; + typedef typename enable_error_info_helper < T ,sizeof (exception_detail ::dispatch_boost_exception(reinterpret_cast<T*>(0)))>::type type; }; }

2 2

[chrono] [thread] Incorporating Chrono into Boost.Thread implementation
by David Deakins 05 Mar '11

05 Mar '11

During the review of the Boost.Chrono library and earlier, there was some discussion about how Boost.Thread might adopt the Chrono-based interfaces once Chrono was formally accepted and merged into the trunk. I believe that Vicente even had proposed code for some of the possible changes. Now that Ratio and Chrono are officially part of Boost, is there still an intention to do this? If so, is there any timeline for when these Boost.Thread changes might begin appearing in the trunk? I know this depends on Anthony and others' availability, but I was just curious. Thanks, -Dave

2 1