August 2007 - Boost - lists.preview.boost.org

[x-files] the code's out there...
by Tobias Schwinger 03 Aug '07

03 Aug '07

Dear fellow Boosters, There is lots of useful, Boost-worthy utility code out there: Implementation details of existing / upcoming / (maybe even) proposed and rejected libraries that could stand alone, code on private hard disks never brought up for review, additions to existing libraries, etc. Fact is, that for small submissions the administrative overhead of (even) a formal (fast-track) review can be too high for developers' decency. Just imagine someone allocating five fast-track slots at once just for factoring out some unrelated bits of code from an existing library. So, why not group a bunch of unrelated utilities into a set of "Boost X-Files" and have them reviewed as a single library? It's completely non-intrusive to the review process and could seriously increase its efficiency. Like the idea? As a start, I stuffed my (tested and documented) "Boost candidate bits and pieces" into a common directory in the vault: http://tinyurl.com/35vlvb Feedback and more X-files welcome, of course. Regards, Tobias

3 6

Improving --layout=system
by Caleb Epstein 03 Aug '07

03 Aug '07

I sent this to the boost-build list, but I think it should have been CC'ed to this list as well. I'd like to commit this change to the SVN trunk if there are no objections. I think its a big win for anyone who uses --layout=system. This is the way BBv1 (correctly IMHO) handled --layout=system. ---------- Forwarded message ---------- From: Caleb Epstein <caleb.epstein(a)gmail.com> Date: Aug 2, 2007 2:23 PM Subject: Improving --layout=system To: "Boost.Build developer's and user's list" <boost-build(a)lists.boost.org> On systems that support shared library version numbers, I believe that these should be used even when building with --layout=system. At present, when you build Boost with --layout=system, you end up with libraries called libboost_xyz-mt.so that have this same value set at their ELF SONAME (this is the shared library version number embedded into the library itself). The problem with these libraries is that you can never have multiple versions of them installed side-by-side in the same place. Go too far down this road and you end up with Windows-style 'DLL hell'. If instead the BOOST_VERSION is appended to the target name as it is with --layout=versioned, you end up with SONAME'd libraries that can live side-by-side with earlier/later versions of Boost. For example, by adding the version number to the libraries, you end up with a lib directory that looks like: lrwxrwxrwx 1 cepstein 33 Aug 2 13:44 libboost_date_time-mt-d.so -> libboost_date_time-mt-d.so.1.35.0 -rwxrwxr-x 1 cepstein 388K Aug 2 13:44 libboost_date_time-mt-d.so.1.35.0 lrwxrwxrwx 1 cepstein 31 Aug 2 13:44 libboost_date_time-mt.so -> libboost_date_time-mt.so.1.35.0 -rwxrwxr-x 1 cepstein 52K Aug 2 13:44 libboost_date_time-mt.so.1.35.0 ... Now when you link applications using -lboost_date_time-mt, the linker records the dependency on the library's SONAME, which is libboost_date_time_mt.so.1.35.0. No other name will satisfy this runtime dependency. As a result, you can install the (hypothetical) Boost 1.36.0libs into the same directory and old applications will continue to pick up the *.so.1.35.0 libs correctly, while new applications built when the symlink points to the new library versions will pick up *.so.1.36.0. This is how Boost.Build v1 handled --layout=system and I believe this is the most correct and desirable behavior for platforms that support versioned shared libraries. Attached is my simple patch against the latest SVN trunk to make this work. -- Caleb Epstein

1 0

SVN problem with commit
by Paul A Bristow 03 Aug '07

03 Aug '07

I am unable to commit any file or files to Boost-sandbox\math_toolkit with the following message. (I have tried an update and it does it OK). Modified: I:\Boost-sandbox\math_toolkit\boost\math\policy\policy.hpp Sending content: I:\Boost-sandbox\math_toolkit\boost\math\policy\policy.hpp Error: Commit failed (details follow): Error: MERGE request failed on '/svn/boost/sandbox/math_toolkit/boost/math/policy' Error: 'pre-commit' hook failed with error output: (nothing follows error output:) Update to I:\Boost-sandbox\math_toolkit\boost\math\policy\error_handling.hpp Completed: At revision: 38396 Modified: I:\Boost-sandbox\math_toolkit\boost\math\policy\error_handling.hpp Sending content: I:\Boost-sandbox\math_toolkit\boost\math\policy\error_handling.hpp Error: Commit failed (details follow): Error: Cannot write to the prototype revision file of transaction '38396-1' because a previous representation is currently being written by this process Any suggestions? Patience and re-try? Thanks Paul --- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539561830 & SMS, Mobile +44 7714 330204 & SMS pbristow(a)hetp.u-net.com

5 9

Missed 1.34.1 announcement site?
by Daryle Walker 03 Aug '07

03 Aug '07

Our SourceForge project page at <http://sourceforge.net/projects/boost/> doesn't (yet) have an announcement about 1.34.1. -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

1 0

[multi_index][ann][rfc] Preview of Boost.MultiIndex 1.35 release
by Joaquín Mª López Muñoz 03 Aug '07

03 Aug '07

Hello, I've uploaded a preview version of Boost.MultiIndex as planned for shipping with Boost 1.35 --I don't think there'll be time to include more major features. Download at the Vault: http://www.boost-consulting.com/vault/index.php?&direction=0&order=&directo… (file multi_index.zip) You can try the preview with Boost 1.34.x; if you want to test the newly added interoperability with Boost.Interprocess, you'll have to use a snapshot of Boost CVS, where this library currently lies. The new important features: * New global_fun predefined key extractor. * Added iterator_to facility. * Included support for non-standard allocators such as those of Boost.Interprocess, which makes multi_index_containers placeable in shared memory. Don't miss example #12 at the examples section, which fully exercises this new capacity. * New versions of modify and modify_key with rollback, as described in the tutorial. * Indices provide the new cbegin, cend and, when applicable, crbegin and crend member functions, in accordance with the latest drafts of the next revision of the C++ standard. A longer list of changes can be consulted at the release notes page. I'd be extremely grateful if you can try this preview version and report any problems you find. As we're still in time to discuss the new features, do not hesitate to comment on these and bring forward your proposals for improvement. Thank you very much for your interest in Boost.MultiIndex, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 4

[Accumulators]multiple statistic instances
by Hugo Duncan 02 Aug '07

02 Aug '07

I am trying to create an IIR filter (see e.g., http://en.wikipedia.org/wiki/IIR) using the delay buffer implementation recently discussed. To do this I need two delay buffers for my filter, one for the samples and one for the computed outputs. I have tried templating my delay buffer with a discrimating type, but I can't get more than one buffer instantiated. ie the following creates only one buffer instantation. accumulator_set<int, stats< tag::delay<>, tag::delay<my_other_delay> > > acc( tag::delay<>::cache_size = 3, tag::delay<my_other_delay>::cache_size = 4 ); Is this worth perservering with? any hints? or would it be better to wait for the next version of accumulators?

2 3

Re: [boost] [Subversion] Library authors, please read
by dan marsden 02 Aug '07

02 Aug '07

The Fusion files were all resurrections as well. They're removed again now. Thanks for the heads up Dan ___________________________________________________________ Yahoo! Mail is the world's favourite email. Don't settle for less, sign up for your free account today http://uk.rd.yahoo.com/evt=44106/*http://uk.docs.yahoo.com/mail/winter07.ht…

1 0

Cast free NULLs in algorithms
by Michael Marcin 02 Aug '07

02 Aug '07

Hello, I have something like: class A; boost::array<A*,10> the_array; std::fill( the_array.begin(), the_array.end(), NULL ); Which wont compile (at least under Visual Studio 2005) without a cast for NULL... I've had this problem before and decided to try to find an easy cast free expressive solution for it. After a few minutes I came up with: namespace detail { struct null_ptr_impl { template< typename T > operator T* () const { return static_cast<T*>(0); } }; } // end namespace detail const detail::null_ptr_impl null_ptr; std::fill( the_array.begin(), the_array.end(), null_ptr ); Does this exist somewhere already? Is it a good solution? Thanks, Michael Marcin

12 24

[type_traits] missing boost::is_complex<T>
by dherring＠ll.mit.edu 02 Aug '07

02 Aug '07

Whatever happened to boost::is_complex<T>? It looks like the idea was accepted back in 2005, but nobody ever added it to trunk... http://thread.gmane.org/gmane.comp.lib.boost.user/13692/focus=13696 http://svn.boost.org/trac/boost/ticket/492 Thanks, Daniel

1 0

about: tutorial for using boost 'Unit Test Framework'
by Jagsir Singh 02 Aug '07

02 Aug '07

Hi All, I am sure, this might allready be answered here on the list. Is there a simple step by step tutorial for using the Unit Test Framework, and the bjam,(simplest jam file). It will be highly appreciated. Is there a searchable mailing list for boost some place ? in other words, --can you search through the mailing list archives ? -- /*/Jagsir /*/////////////

3 4