- Boost - lists.boost.org

[mpl] int_<INT_MIN> fails to compile under gcc 4.6
by Stirling Westrup 06 Mar '11

06 Mar '11

I'm not actually sure if this is a gcc regression, or a bug in mpl, but the following code, which compiles under gcc 4.5, doesn't do so under gcc 4.6: #include <climits> #include <boost/mpl/int.hpp> typedef boost::mpl::int_<INT_MIN> Foo; Foo f; It produces the errors: /usr/local/include/boost/mpl/aux_/integral_wrapper.hpp: In instantiation of ‘mpl_::int_<-0x00000000080000000>’: test_test.cpp:8:27: instantiated from here /usr/local/include/boost/mpl/aux_/integral_wrapper.hpp:73:96: error: ‘2147483647’ is not a valid template argument for type ‘int’ because it is a non-constant expression /usr/local/include/boost/mpl/aux_/integral_wrapper.hpp:73:96: error: overflow in constant expression [-fpermissive] I've already created a trak ticket for this (#5268), but was wondering if anyone had any insights as to its cause and/or any workarounds. My guess is that its related to gcc rewriting parts of its constant folding code to support constexpr. -- Stirling Westrup Programmer, Entrepreneur. https://www.linkedin.com/e/fpf/77228 http://www.linkedin.com/in/swestrup http://technaut.livejournal.com http://sourceforge.net/users/stirlingwestrup

4 6

TR1 and BOOST_HAS_GCC_TR1
by Mathias Gaunard 06 Mar '11

06 Mar '11

With GCC, TR1 only calls the native TR1 implementation if BOOST_HAS_GCC_TR1 is defined. Isn't it time we get rid of this macro?

2 3

[regex] embed string/char in regex w/o escaping?
by Arno Schödl 06 Mar '11

06 Mar '11

As far as I can see, there is no way to embed a plain string into a regex, without escaping the string. Same with characters. Isn't that a bad omission for a library that becomes the new C++ standard? Escaping something just to unescape it on the other end of the function call seems unnecessary, and it opens up the possibility of ills like regex code injection if someone forgets to escape or does it wrong. I know about Boost.Xpressive, but that won't be the new standard. This is not a lobbying effort for Boost.Xpressive. I have never used it precisely because I wanted to stick to the standard. Now I am a bit worried about pouring something into C++ standard concrete that has a pretty obvious omission in it. Arno -- Dr. Arno Schödl | aschoedl(a)think-cell.com Technical Director think-cell Software GmbH | Chausseestr. 8/E | 10115 Berlin | Germany http://www.think-cell.com | phone +49 30 666473-10 | US phone +1 800 891 8091 Amtsgericht Berlin-Charlottenburg, HRB 85229 | European Union VAT Id DE813474306 Directors: Dr. Markus Hannebauer, Dr. Arno Schoedl

4 5

[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