November 2010 - Boost - lists.preview.boost.org

gcc-4.5.1 warnings (ISO C++ 1998 does not support ‘long long’)
by Neal Becker 03 Nov '10

03 Nov '10

boost-1.44.0 + gcc-4.5.1: Lots of these warnings ./boost/config/suffix.hpp:497:18: warning: ISO C++ 1998 does not support ‘long long’

2 1

Will 1.45 incorporate active regression tickets?
by Jim Bell 03 Nov '10

03 Nov '10

Will 1.45 incorporate active regression tickets? I.e., report {30} <https://svn.boost.org/trac/boost/report/30> Several of these could be incorporated without too much work. I think a scan of these would be worth the release managers' time.

3 9

Unicode Library
by Emery Denuccio 02 Nov '10

02 Nov '10

Hey guys, about three years ago I mentioned I was working on a unicode library for boost and there was some interest then. I guess professional work got in the way and I never got around to polishing it up and submitting for review. I was digging through an old hard drive and found the source. It still lacks a few features, but is pretty damn cool. I threw up on on github if anyone wants to take a look and possibly help me get rolling on it again. Here: http://github.com/imori/boost.unicode Thanks, -em

3 2

[chrono] review version
by vicente.botet 02 Nov '10

02 Nov '10

Hi, I have made some modifications to Boost.Chrono before the review (Version 0.7.0). The library can be downloaded from http://www.boostpro.com/vault/index.php?action=downloadfile&filename=chrono… and the documentation is online on the sandbox http://svn.boost.org/svn/boost/sandbox/chrono/libs/chrono/doc/html/index.ht… or in PDF format http://svn.boost.org/svn/boost/sandbox/chrono/libs/chrono/doc/chrono.pdf Boost.Chrono depends on Boost.Ratio http://www.boostpro.com/vault/index.php?action=downloadfile&filename=ratio.… and optionaly Boost.System Header Only http://www.boostpro.com/vault/index.php?action=downloadfile&filename=system…. Next follows the major changes: [*Features:] * Boost_Chrono is now a configurable header only lib that allows the user to choose in addition if the windows file is included or not. * Added clock_string<> traits. * Define chrono_io for all the clocks * Add input of process_times representation [*Implementation:] * Moved some details to static_integer directory. * Use of detail/win files to avoid the use of windows.h file. * Completed the error_code handling. * Works now with BOOST_SYSTEM_NO_DEPRECATED. [*Fixes:] * Fix some warnings. * Fix original error on Mac * Don't fix the link with boost_system to static. [*Test:] * Added test on process and thread clocks. * Moved to lightweight_test.hpp. * Able to test multiple configurations. [*Doc:] * Removed some not useful parts as the history, the test and the tickets. Best, _____________________ Vicente Juan Botet Escribá http://viboes.blogspot.com/

2 2

[iostreams] Inconsistency of "faiture" of writes in Sinks and filters
by Artyom 02 Nov '10

02 Nov '10

Hello, I implement the sink device that sometimes may fail on writes. When Sink is implemented it should throw an exception on fault. To notify the stream on error. However it is not always works this way. I've got the exception to "leak" to the main program when I combine in the filter gzip_comressor() filter that writes to output device that its Sink is full. When I call reset on the filter the exception in leaking to the program instead of being caught. Is it bug or (accidental) feature? On the other hand, if I don't throw but rather return 0, I get into infinite loop in the boost::iostreams::non_blocking_adapter::write when I call filter.reset(). So I how can I write a sink device that reports errors? In following example the exception is caught when filter.reset() is called: #include <boost/iostreams/stream.hpp> #include <boost/iostreams/filtering_stream.hpp> #include <boost/iostreams/filter/gzip.hpp> #include <boost/iostreams/tee.hpp> #include <iostream> class my_small_device : public boost::iostreams::sink { int count; public: my_small_device() : count(1000) {} std::streamsize write(char const *d,std::streamsize n) { if(count < n) throw std::runtime_error("Device is full"); count-=n; return n; } }; int main() { try { using namespace boost::iostreams; boost::iostreams::stream<my_small_device> output(my_small_device(),10); { boost::iostreams::filtering_ostream filter; filter.push(gzip_compressor()); filter.push(output); for(int i=0;i<10000000;i++) { if(!(filter << i << '\n')) { std::cerr << "Fail!" << std::endl; break; } } std::cout << "Closing filter" << std::endl; filter.reset(); } std::cout << "ok" << std::endl; return 0; }catch(std::exception const &e) { std::cerr << "Catched " << e.what() << std::endl; return 1; } } Thanks, Artyom

1 2

Issues with intel's compiler and newer builds of GCC
by Bryce Lelbach 02 Nov '10

02 Nov '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 While working on getting icc to not choke on Serialization (the Boost test boxes indicated that icc was failing to build with the addition of my changes), I came across a very nasty bug the occurs when using icc with version 4.5 or higher of GNU's standard library - GNU's <iomanip> uses what are either illegal or C++0x semantics which icc doesn't support. Serialization uses <iomanip>, and icc seems to select the latest version of libstd++ installed on a Linux machine as it's default standard library (I have been unable to find an Intel standard library - I'm assuming such a thing doesn't exist). When using an older version of libstd++, icc + Serialization compiled fine. I removed all uses of IO parameterized manipulators in Serialization (there were only maybe half a dozen cases)*, and got icc to compile Serialization with libstd++ v4.5. Is there any chance the linux/darwin Intel build bots can be set up to use libstd++ v4.4, if they're not already using it? Intel is apparently aware of this issue, but it won't be fixed until their next major release (http://software.intel.com/en-us/forums/showthread.php?t=74691) If the build bots aren't using v4.5 of GNU's standard library, then I'm at a loss as to why Serialization is failing to build on them. My only other thought is that the timeout for the build cycle is too low - the failures indicate that the error is a timeout after 300 seconds. On a more general note, is Intel on Linux/Darwin a "supported" Boost compiler? Unless I've missed something, Intel doesn't provide a standard library, and I find it a bit troubling that they ship their compiler to use GNU's standard library by default. Intel is far behind GCC in C++0x support, and newer versions of the GNU standard library have been making increasing use of GCC's C++0x support. Unless icc starts shipping with an older version of libstd++/use a compiler neutral standard library such as the Apache standard library/starts to catch up with GCC's C++0x support, I imagine that using icc to compile C++ code that makes use of the standard library will become increasing difficult. * I also had to modify proto/debug.hpp to not use <iomanip>. Eric, when I was having an issue with typeinfo in proto/debug.hpp a couple days ago, you mentioned that proto/debug.hpp shouldn't be included by proto/proto.hpp? If that's accurate, is there any chance that change could be made, and if not, can I commit my changes to proto/debug.hpp or send them to you as a patch for review? - -- Bryce Lelbach aka wash http://groups.google.com/group/ariel_devel -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAky+c7cACgkQO/fqqIuE2t4DZQCfUnhGAsqX4GDZu3Ze7BvrPBRL XRkAn33vWcTm1RuXk2iuQWH0+bp+RVUf =mHwK -----END PGP SIGNATURE-----

7 9

[build_extensions][patch] General update and minor fixes
by Mateusz Loskot 02 Nov '10

02 Nov '10

Hi, First, I'm not sure if this is the right place to send patch to the build_extensions which live in the sandbox, I'm continuing to have complete build of Boost.GIL tests on Linux with 3rd-party dependencies configured using the build_extensions. It's trial and error process during which I've applied number of updates to .jam scripts for raster support libraries. The patch summary: zlib: added/removed .c source files jpeg: added/removed .c source files libtiff: - added missing tif_unix.c for <target-os>linux (not sure why <target-os>unix: could not kick in) - configure #define integral types required by tiffiop.h - added tiffxx target with C++ wrapper library (tif_stream.cxx) I have successfully used the extensions with the following libraries: jpeg-8a libpng-1.4.1 tiff-3.9.2 zlib-1.2.4 with GCC 4.4.5 on Linux 64-bit. I'm quite sure some of the changes could be mastered in much better way, but I lack of Boost.Build zen. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org Member of ACCU, http://accu.org

1 0

[gil][io_new] Problems with templates
by Christian Henning 01 Nov '10

01 Nov '10

Hi there, problems have been resolved. Thanks to everyone who tried helping! Regards, Christian

1 0

[range] - Proposal to change the indexed range adaptor
by Neil Groves 01 Nov '10

01 Nov '10

Fellow maintainers and developers, Having gained experience using the Boost.Range library changes I submitted for Boost 1.43, I have become dissatisfied with my indexed adaptor. Currently the underling index_iterator has a return type identical to the wrapped iterator, and the index is extracted via a method call on the iterator. While this works for the case where one is writing algorithms to explicitly utilise the underlying iterator, it is clearly a poor design choice since it severly limits the interoperation with other algorithms. I feel that I have made a mistake. I propose that a breaking change is made to the index range adaptor so that it returns a pair<original_reference_type, index_type>. How do you feel about this change? Do you have alternative suggestions? Regards, Neil Groves

5 7

boost::optional - rvalue references
by Daniel Larimer 01 Nov '10

01 Nov '10

I have been looking to optimize my code using rvalue references when they are supported; however, I currently use boost::optional which does not know how to handle / forward rvalue references. In fact even the in_place() utilities do not work to forward the rvalue into the proper constructor. My latest profiling shows that assigning a large vector to an optional is eating up 5% of my CPU time and I could replace this with a std::move() if boost::optional supported it. I have attached an updated optional.hpp with the minimum changes necessary to support the following: test v ( 99 ); test A ( 400 ); boost::optional<test> i2(std::move(v)); i2 = std::move(A); Such that if test were a vector and 99 and 400 were the sizes, the end result is v & A are of size 0 and i2 is of size 400 and no copy constructors are called (only moves). What is the plan for updating more of boost to take advantage of rvalue references?

2 1