- Boost - lists.preview.boost.org

How about a call for bug-fix volunteers?
by Jim Bell 05 Nov '10

05 Nov '10

Library authors shouldn't have to bear the burden of bug reports for their libraries alone. Even maintaining their regression tests across all platforms isn't realistic (and isn't being done). So what if we try to recruit a couple helpers for each library? I see two avenues where we can use some volunteer help to improve boost's quality. 1. Dandelion pickers: look at failed/yellow regression tests and try to fix them. Volunteers could pick a platform they have access to, and try to work across all libraries. You might be surprised at how easy many are to fix. 2. Ticket triage: pick a library and go through all open tickets. Change severity, resolve, request more information, try to map to an existing regression test, interact with the submitter in the comments. (I think Trac needs a "requesting more information" state.) Even a brief 'triage' on each would be helpful, and help users feel they're being heard. (Trac needs to track this, too.) Write new regressions from legitimate issues. Recruiting pitch: it's a great way to improve your skills--troubleshooting, C++, platform-specific expertise, communication. Not so glamorous, but important and great experience. Perhaps we could assign a little of each to each SoC person. Maybe put the word out on Slashdot. See previous topic threads (http://lists.boost.org/Archives/boost/2010/10/index.php) "Report # 29 (aka 1.45 blockers) is too narrow" "[1.45] Beta final schedule" "[1.45] Thread issues"

14 18

Named subexpressions using \k<name>
by Chris Dragon 04 Nov '10

04 Nov '10

I have a user who says they have a bunch of expressions written for the Oniguruma regex library that use \k<name> syntax. According to http://www.boost.org/doc/libs/1_44_0/libs/regex/doc/html/boost_regex/syntax… Boost.regex should also support that syntax, but it does not seem to work. For example: boost::regex_replace( std::string("xyyz"), boost::regex(".*(?<first>x)(?<second>y).*", boost::regex_constants::perl), std::string("$+{second}\\k<first>"), boost::match_default | boost::format_all | boost::match_extra); results in "yk<first>" This result shows that $+{second} evaluated to "y" but \k<first> evaluated to "k<first>". I thought maybe the \k<name> syntax was only supported as a backreference within the first regex instead of the replace string, but this doesn't work either: boost::regex_replace( std::string("xyyz"), boost::regex(".*(?<first>x)(?<second>y)\\k<second>.*", boost::regex_constants::perl), std::string("$+{second}"), boost::match_default | boost::format_all | boost::match_extra); The result is "xyyz" meaning nothing was replaced (the regex did not match). However, if modify the regex to use \\g{name} syntax, it works: boost::regex_replace( std::string("xyyz"), boost::regex(".*(?<first>x)(?<second>y)\\g{second}.*", boost::regex_constants::perl), std::string("$+{second}"), boost::match_default | boost::format_all | boost::match_extra); The result is "y". Am I doing something wrong or have I found a bug? I'm using the latest stable 1_44_0 release compiled from source in VC9 and I also tried the pre-compiled library (http://sourceforge.net/projects/boost/files/boost-binaries/1.44.0/libboost_…) The OS is Windows 7. Thanks for the help!

2 2

[Boost.Timer] Why timer doesn't have a specific windows version using QueryPerformanceCounter() and QueryPerformanceFrequency()?
by dlaugt＠free.fr 04 Nov '10

04 Nov '10

Hi, Boost.Timer is based on the C function clock(). On windows, this function gives a precision of 1 millisecond only as CLOCKS_PER_SEC is equal to 1000. Why Boost.Timer doesn't use for windows QueryPerformanceCounter() and QueryPerformanceFrequency()? These functions give a precision around 2 microseconds. Daniel.

3 2

[build][doc] Testing section and run rule
by Mateusz Loskot 04 Nov '10

04 Nov '10

Hi, I'm looking for reference about run rule and the only thing I can find is this short reference: http://www.boost.org/doc/tools/build/doc/html/bbv2/reference/rules.html pointing to the Testing section which is currently blank: http://www.boost.org/doc/tools/build/doc/html/bbv2/tutorial/testing.html Would there be any chance to get this part updated? I'm looking for details about the run rule arguments: rule run ( sources + : args * : input-files * : requirements * : target-name ? : default-build * ) I'd appreciate if someone could explain what is the differences: sources vs input-files or args vs input-files. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org Member of ACCU, http://accu.org

2 2

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

Get PID from local socket?
by Rush Manbert 01 Nov '10

01 Nov '10

I am using boost ASIO to do socket communications between an app and a daemon running on the same machine. The communications go through a Unix Domain Socket on the Mac and a named pipe on Windows. I'm looking for a way that the client app could obtain the PID of the daemon process, starting with the connected socket. I have tried calling local_endpoint() and remote_endpoint(), but the only information there seems to be the socket path (at least on the Mac). My google searches have turned up nothing, and they actually suggest that there is no way to achieve this on the Mac, even if I were using the "normal" socket API. Does anyone know whether this is possible and how to do it? Thanks, Rush

2 1

[gsoc] Boost.Process done
by Boris Schaeling 31 Oct '10

31 Oct '10

Here are the results of the Boost.Process project within this year's Google Summer of Code program: We have a complete library to manage system processes now! If you like to play around with the library download the ZIP file from <http://www.highscore.de/boost/gsoc2010/process.zip>. As it's a header-only library simply copy the files to your Boost folder. If you like to quickly check the documentation click on <http://www.highscore.de/boost/gsoc2010/>. The library is now complete and basically ready for a review. As there have been so many Boost.Process drafts before (after all the first version was created 2006) this library's version number is 0.4. This will somehow make it possible to refer to the various drafts if it's necessary. For now I would appreciate if the library's test cases are run on as many platforms as possible. After copying the files from the ZIP file to the Boost folder change to libs/process/test/ and run bjam - that's all! What has been changed? * All previous Boost.Process drafts including Ilya's 2008 version from the vault have been thoroughly studied to create a better version. From the multiple Boost.Process drafts which have been floating around since 2006 we took the best ideas and created a new unified version. * The design and implementation of the library have been simplified. The library's API is smaller, and the implementation is easier to understand. It should be possible to benefit from this library as quickly as possible. Even developers who have no experience in managing system processes should be able to do so easily. * There are no POSIX and Windows specific classes anymore (posix_context, posix_child, win32_context, win32_child etc. have been dropped). Instead of trying to support each and every feature platforms provide extension points have been defined. They enable library users to "link in" those platform specific features they are interested in. * For the first time there is full support for synchronous and asynchronous operations. While asynchronous operations are built on top of Boost.Asio synchronous operations can be utilized without that library. Developers don't need to include any Boost.Asio headers and don't need to learn about Boost.Asio if they don't need asynchronous operations. * Stream behaviors define if and how standard streams can be used by a child process. While the various stream behaviors were defined as an enumeration or a boost::variant in previous Boost.Process drafts they are now implemented as classes. This makes it possible for developers to create new stream behaviors. * The code to start child processes on POSIX platforms has been carefully adapted to support multi-threaded applications (it turned out that this code was wrong in all Boost.Process drafts so far). The documentation explains what you need to take care of if you want to create child processes in a multi-threaded application on POSIX platforms. * The documentation is new and has been shortened and simplified. There is a user guide which can be read in 10 minutes and introduces all the major features of the library. The documentation is now also based on Quickbook. * The test cases have been restructured to simplify them. They can now be run without patching Boost.Test and without setting a path to a helper executable in the source files - it's now all automatic. They are all passed successfully with MSVC 9 (2008) and g++ 4.2.1. What is currently missing? * Pipelines are not (yet) supported. If you have been using boost::process::launch_pipeline() there is nothing in this Boost.Process draft you can use instead. Depending on feedback this feature will be added again (there was simply no time yet to do this). We hope that after four years, two Google Summer of Code programs and countless drafts this new version will finally become the official Boost.Process library so many have been waiting for. Boris and Felipe

18 182

[rational] PATCH: Use ordered_euclidean_ring_operators
by Mario Lang 30 Oct '10

30 Oct '10

Hi. Below is a patch which makes rational.hpp use grouped arithmetic operators. While we are at it, use ordered_euclidean_ring_operators instead of just ordered_field_operators. While it might sound strange at first, mod can make sense even for rational numbers. For instance, Common Lisp, which has a native rational type, works fine if mod is used on rational numbers... template <typename IntType> rational<IntType>& rational<IntType>::operator%= (const rational<IntType>& r) { return *this -= r * floor(rational_cast<double>(*this / r)); } I am aware that the use of floor() is probably problematic. I am all open for comments and suggestions for improvements. -- Thanks, ⡍⠁⠗⠊⠕

1 0

[graph] PATCH to eliminate gcc 4.2 warnings when compiling boost/graph/read_dimacs.hpp
by Daniel Trebbien 30 Oct '10

30 Oct '10

Attached is a patch that changes the definition of `err_message` in boost/graph/read_dimacs.hpp@66260 from: static char *err_message[] to: static const char *err_message[] This will eliminate the warnings that were recorded at: http://www.boost.org/development/tests/trunk/developer/output/Sandia-gcc-4-… Daniel

2 1

Is it time for another bug sprint? (Post 1.45 release, I mean)
by Marshall Clow 30 Oct '10

30 Oct '10

What do people think? -- Marshall

11 17

[regex] Disabling ICU check when building with bjam, 1.44
by Cliff Green 30 Oct '10

30 Oct '10

This is on Boost 1.44, g++ 4.1.2 on Linux (RHEL 5.x, can't remember the x at the moment), although it applies generally to building regex. I can't find a way to easily "disable" the "ICU installed" check and resulting functionality / build. I chatted on IRC, and the only way some (experienced Boost) developers could come up with was to change: alias icu_options : : : : [ check-target-builds has_icu : $(ICU_OPTS) : ] ; to alias icu_options : : : : ; in Jamfile.v2. My situation / use case: Our build system has ICU installed. Our deployment system has exactly the same OS and runtime environment, except that the ICU package is not installed. I would like to build regex without the "check that ICU is installed to determine whether the enable ICU" logic in the jamfiles. The regex documentation has an: "-sHAVE_ICU=1" example, but "-sHAVE_ICU=0" doesn't work, and tracing through the jamfiles / boost build I couldn't find where that option is honored / processed. There's also a BOOST_HAS_ICU macro that is defined or undefined in various ways, but adding define=BOOST_HAS_ICU 0 to bjam also didn't appear to do anything (and I tried some other ways to undefine BOOST_HAS_ICU, including in the jamfile, but nothing seemed to work). The docs also mention that the default is to not enable / build with ICU, but that doesn't seem to be the case (with 1.44). (From the first line of ICU build section: "A default build of this library does not enable Unicode support via ICU. There is no need to enable ... ".) So I'm confused (as well as some other regulars on IRC), and either the documentation needs updating, jamfiles need updating, or my understanding needs updating. For now, the workaround mentioned above works fine, and the resulting regex.so file does not have any ICU external library dependencies (which is what is desired for our deployment environment). Thanks! Cliff

2 2

[assign] list_inserter regression test failure on VC10 / release branch
by Richard Webb 30 Oct '10

30 Oct '10

Another minor regression test fix: The list_inserter regression test (libs\assign\test\list_inserter.cpp) was fixed for VC10 on the Trunk in revision 62737, but hasn't yet been merged to the release branch. (the change also fixes one of the errors from GCC/C++0x, but the test still fails for other reasons).

1 0

[1.45] Beta next week?
by Beman Dawes 30 Oct '10

30 Oct '10

I've been too busy to do much on 1.45, but don't see any reason we can't get a beta out next week more or less as scheduled. If anyone know of any showstoppers, please let us know what the problem is. Thanks, --Beman

11 35

[mpl] anyone fancy merging the for_each test to the release branch?
by Richard Webb 29 Oct '10

29 Oct '10

Does anyone feel like merging libs/mpl/test/for_each.cpp (revision 65167) to the release branch? It's only a minor change to the test itself, but it clears a failure on VC10 and various C++0x GCCs.

3 2

[quickbook] Code links not working
by Edward Diener 29 Oct '10

29 Oct '10

I can not seem to get the quickbook code links to work. Nothing is being generated from the code link. As an example, to test them out I have in quickbook: This is a test of a macro reference - [macroref VMD_DATA_SIZE Test Macro reference] . and in my doxygen generated XML I see: <library-reference id="variadic_macro_data_reference"> <title>Variadic Macro Data Reference </title> <header name="boost/variadic_macro_data/VariadicMacroData.hpp"> <macro name="VMD_DATA_SIZE" kind="functionlike"> etc. but the output shows: This is a test of a macro reference - . Any ideas to get this to work would be appreciated.

12 20

[Thread][Release] Boost.Thread and 1.45 release
by Anthony Williams 29 Oct '10

29 Oct '10

Hi, I've fixed all the outstanding "showstopper" bugs in boost.thread on trunk (including the thread interruption issue, #2330), apart from #3847 (https://svn.boost.org/trac/boost/ticket/3847) - "Unable to statically link thread lib on ia64" I don't know how to fix this, and this platform doesn't appear to be actively tested. Is it OK to merge the other fixes to the release branch? Anthony -- Author of C++ Concurrency in Action http://www.stdthread.co.uk/book/ just::thread C++0x thread library http://www.stdthread.co.uk Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk 15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976

3 8