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

[1.45] Where are we in the release process?
by John Maddock 14 Nov '10

14 Nov '10

I'm asking because someone's just assigned a Boost.Interval issue to me: https://svn.boost.org/trac/boost/ticket/4799#comment:1 Seems like there is a trivial fix in Trunk, but as the library appears not to have been maintained for while, it looks like none of the patches that some folks have applied to Trunk have been merged to release :-( On a related note, I believe there are quite a few old and unmerged changes to the Utility lib as well. We really need to figure out a better way of dealing with this... John.

6 13

[optional] swap not a member of boost::optional
by Eric Niebler 10 Nov '10

10 Nov '10

It seems like boost::optional has a swap member function on trunk but not on release, and it's been this way for a few releases already. Can we get this inconsistency resolved? I've been bitten by it a few times already when merging things to the release branch. -- Eric Niebler BoostPro Computing http://www.boostpro.com

1 1

[function] new implementation
by Domagoj Saric 09 Nov '10

09 Nov '10

Hi, <...those that followed the latest function related discussions can skip the first paragraph...> For about a year and half now (or even more but that's about how long I've been involved in the matter) there have been repeated discussions/requests/complaints about various aspects of Boost.Function. Most of those fall into one or more of these categories: - overall code speed overhead - overall code bloat overhead - lack of configurability - dependencies on RTTI and exception handling with the most frequently brought up specific issue being the various implications (in all of the above mentioned areas) of the hardcoded throw-on-empty behaviour... Unfortunately Boost.Function code remained virtually unchanged (except for the added RTTI emulation for platforms w/o RTTI support) with all of the issues still remaining... The new implementation proposal @: https://svn.boost.org/svn/boost/sandbox/function/boost/function http://www.boostpro.com/vault/index.php?&direction=0&order=&directory=Funct… Objects solves or at least provides drastic improvements for all of the mentioned issues. It is intended as a drop in replacement for the current implementation and as such I have so far tested it in the following ways: - compiling some real world code: VC10, GCC 4.2.1, LLVM-GCC 4.2.1, GCC 4.5.1, GCC 4.6, Clang 2.0, Clang 2.8 - compiling and running a real world project: VC10, Clang 2.8 - building Boost trunk: VC10, GCC 4.2.1, GCC 4.5.1, Clang 2.0 - running Boost regression tests for Function, Signals, Signals2, Thread, Program Options and Graph libraries: VC10, GCC 4.2.1, Clang 2.0. (All of the tests passed except for two bogus assertion failure boxes that pop up with VC10 and the Program Options tests during the automated regression test procedure that OTOH do not popup when I run the same tests manually through the VC10 IDE, i.e. the tests finish successfully...I tried to make sure all the relevant compiler switches were the same in both cases so I am out of ideas what else can make the difference.....) Next, let me give you a comparison of for-size-optimized code generated by VC10 with both the current and the proposed implementation for a short code snippet demonstrating invocation, construction and assignment: struct X { int foo( int const x ) const { return x + y; }; int y; }; int main( int /*argc*/, char * * /*argv*/ ) { using namespace boost; X x; function<int(int)> foof( boost::bind( &X::foo, &x, _1 ) ); foof( 0 ); function<int(int)> barf; barf = foof; barf( 1 ); return 0; } Notice in new_function_code_listing.txt how all of the wrapper code in the new Function was completely transparent to the compiler and was completely inlined to relatively simple machine code with direct calls to/through the vtable pointers...while OTOH in current_function_code_listing.txt the code generated for the "barf = foof;" assignement alone is several times larger than the entire code generated for the new Function implementation. The small asm snippet of the generated invoker/'thunk'/'trampoline' code also demonstrates the effects of various tweaks done to minimize or all together remove the need for any stack adjustment on the invoker side... The new implementation of course has the same semantics and exception safety guarantee levels as the original/current one. Listing all of the improvements and detailed implementation changes here in the first post would be quite cluttering as they are quite numerous. Those that desire more tests and details right now, can follow this trail: http://lists.boost.org/Archives/boost/2010/01/160908.php As for the dependencies issue this is solved in several ways: - use of exception handling: new code uses guard objects instead of explicit exception handling and provides a way to change on-empty-behaviour so that the EH code/dependency can easily be removed/disabled - use of RTTI (for getting the type of the stored function object): this can be globally disabled with the BOOST_FUNCTION_NO_RTTI macro. BOOST_NO_RTTI is not used for this purpose for backward compatibility reasons: in the current implementation it actually turns on RTTI emulation...The idea is to also add per instantiation RTTI on-off configurability... 'Configurability' will probably be the most controversial issue/change because it required the addition of an extra template parameter through which an MPL list of policies can be specified at compile-time. This parameter is properly defaulted to allow existing code to compile without changes while providing current Boost.Function behaviour (e.g. on-empty- behaviour). As all the performed tests showed this to also be true in practice the proposed code should IMO go in as a straight drop-in replacement but, of course, I might have missed some important higher level detail/concern so this is open to discussion... Currently two policies are supported: - on throw behaviour (with throw-on-empty, nop-on-empty and assert-on-empty handlers provided) - whether the function instantiation should mark itself (i.e. its operator()) as nothrow. Additional policies my be added later, for example: - sizeof and/or alignment of the SBO buffer - default allocator - per instantiation RTTI on/off ... Finally, there is one more addition, somewhat 'unholy' as it brings in the concept of binding into Boost.Function but considering its efficiency and/or verbosity benefits (and the fact that the first issue can be 'explained away' by saying that this is not actually 'binding' but a workaround for the lack-of-delegates-support C++ language deficiency). The addition is in the form of two more assign() member function overloads (one for a free function that has the exact signature as the Boost.Function instantiation, and one for a member function that has a matching signature with the addition of a this pointer) that allow assignment of (suitably typed) plain (free or member) functions specified as non-type-template parameters. This allows for the removal of the extra indirect-call-through-function-pointer otherwise incurred by traditional assignment of function pointers (not functors), which is actually a rather common use case. For example, in the above example given, one can now write: foof.assign<X, &X::foo>( x ); and get a trivial invoker with the X::foo() target function inlined straight in... -- "What Huxley teaches is that in the age of advanced technology, spiritual devastation is more likely to come from an enemy with a smiling face than from one whose countenance exudes suspicion and hate." Neil Postman

7 27

[build] print test failing on release
by Eric Niebler 06 Nov '10

06 Nov '10

Volodya, can you investigate the failure of the Boost.build "print" test on the release branch? It's currently failing across all platforms. Thanks, -- Eric Niebler BoostPro Computing http://www.boostpro.com

2 3

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

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

[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

[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