- Boost - lists.boost.org

[range] transform surprise
by Neal Becker 07 Mar '11

07 Mar '11

I'm surprised that boost::range::transform args are template< class SinglePassRange1, class OutputIterator, class UnaryOperation > OutputIterator transform(const SinglePassRange1& rng, OutputIterator out, UnaryOperation fun); I would have expected: template< class SinglePassRange1, class SinglePassRange2, class UnaryOperation > OutputIterator transform(const SinglePassRange1& rng, SinglePassRange2& out, UnaryOperation fun); Why the asymmetry?

3 2

[network] 0.9-devel and BOOST_NETWORK_NO_LIB
by Dean Michael Berris 07 Mar '11

07 Mar '11

Hi Everyone, I just recently finished a consulting project that tied me up good the past three months. Now that I'm pretty much free again to work on cpp-netlib, I went for the things that have been brought up most recently on the list (and the Boost developers mailing list): 1. The server tests that used a different port each, configurable at the command-line with a default. This is already in 0.9-devel. 2. An option to turn off the required external library to be linked with a macro (BOOST_NETWORK_NO_LIB). With this macro defined before any cpp-netlib headers are included (or on the command line) the functions that were made extern or just free functions at namespace level are marked 'inline' and have their definitions pulled in accordingly in each translation unit. This addresses Jeff Garland's and others' concern of the need for an external library when using cpp-netlib when it's always been header-only until 0.9. I'm still wrestling with the thought of making the header-only behavior a default, but I'm not married to the "external library as default" decision either. 3. A consistent look/view between server-side request/response objects and client-side request/response objects. Now they can be dealt with using the same directives and modifiers. 4. Starting to change the library name to Boost.Network (after the suggestions). #2 is still undocumented, but I am going to be including a Doxygen-Sphinx bridge that would allow us to write documentation in-line on the types and have Doxygen invoked when the Sphinx documentation is built. I found a Sphinx extension to do that and it looks like it can be bundled with cpp-netlib as well (because it's under a BSD license) -- it's called "breathe" and can be found here: http://michaeljones.github.com/breathe/ #3 has been in the branch for a while already and it should be doable to back-port some of the things to the 0.8 line. #4 is largely a documentation matter. I have decided that in order for the development of the network library to scale, that I would spear-head a mini-community effort that would be called "The C++ Network Library Project" taking in a diplomatic and consensus-building approach. This way those willing to contribute to the effort can help with setting the direction of the library, the design decisions, etc. with me starting as the "benevolent dictator" and letting more people jump into the fray and becoming co-maintainers and regular contributors. There are already a couple of people (Oleg Malashenko and Emre Turkay) who have recently contributing to the project that I would like to thank, and also give the chance to get a bigger role in the development of the library going forward. So for now the focus is still to get a review-ready library for inclusion in Boost that would be called Boost.Network. I think 0.9 will be ready in a couple of days and will be a the pre-1.0 snapshot that will be submitted for review, getting all the required documentation in place. At this time I'm still looking for able and willing review managers. Feedback would be most definitely appreciated. -- Dean Michael Berris http://about.me/deanberris

1 0

[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