- Boost - lists.boost.org

Updating news feeds
by Martin Vuille 11 Aug '08

11 Aug '08

Hi, I am trying to update the news feed on the website by following the instructions at http://www.boost.org/development/website_updating.html In step two, bjam reports that the python script failed, but there is no error message from the script itself. In fact, if I run the script manually with the same arguments as bjam, it works fine and returns a zero exit status. Am I missing something obvious? MV

1 0

[1.36] Ready to ship
by Beman Dawes 11 Aug '08

11 Aug '08

The plan to start packaging 1.36 for release tomorrow (Saturday). The beta went smoothly enough that there seems little benefit of further betas or release candidates. Please do not may any further branches/release code commits without checking with me first. Please do not make any documentation commits after 11::00 AM UTC Saturday (6 AM US Eastern Daylight Time). Thanks, --Beman

2 2

[ANN] Boost.Proto committed to trunk
by Eric Niebler 11 Aug '08

11 Aug '08

I've just committed Boost.Proto v4 to trunk (http://svn.boost.org/trac/boost/changeset/48079) This version is represents a significant reworking from the version that was reviewed and accepted back in April. Although the code is quite stable now, I have not yet integrated all the feedback about the documentation. It is my intention to bring the docs up to Boost standards in time to get Proto into 1.37. I am leaving the old version of Proto at boost/xpressive/proto for the time being, since some other projects (Xpressive, Spirit2 Qi and Karma) are relying on it. It will be removed at the earliest opportunity. I've also updated the proto.zip archive in the Boost file vault and uploaded the latest docs to: http://boost-sandbox.sourceforge.net/libs/proto/doc/html/index.html Thanks, -- Eric Niebler BoostPro Computing http://www.boostpro.com

1 0

proposal: interval containers; boost examples and more
by Joachim Faulhaber 11 Aug '08

11 Aug '08

Dear boost developers, after encouraging feedback by Paul A Bristow, Vicente Botet and Luke Simonson to my proposal on interval containers from end of May (http://lists.boost.org/Archives/boost/2008/05/137301.php) I started to boostify my interval template library (ITL). Even though there is a lot left to be done for the ITL to become fully boost compliant I'd like to report on some aspects of my current work. (1) As suggested by Paul A Bristow I have prepared some new examples that are using boost::date_time as instance types for the interval containers. * Example boost_party.cpp is a boostified instance of the introductory example party.cpp that demonstrates the 'aggregate on overlap' mechanism of interval maps (see: http://www.herold-faulhaber.de/itl/boost__party_8cpp.html) * Example month_and_weeks_grid.cpp demonstrates how different time grids can be merged in split_interval_sets by intersection (see: http://www.herold-faulhaber.de/itl/month__and__week__grid_8cpp.html) * Example man_power.cpp shows how calculations on interval_sets and maps can be obtained using set type operations. In the example the available man power in a small company is calculated accounting for weekends, holidays vacations etc. (see: http://www.herold-faulhaber.de/itl/man__power_8cpp.html) * Example user_groups shows how interval maps can be unified or intersected (see: http://www.herold-faulhaber.de/itl/user__groups_8cpp.html) (2) In the course of boostification of my code I have reviewed the design and completed the interval container classes as follows: * interval_set * split_interval_set * separate_interval_set (added) * interval_map (added) * split_interval_map You can see an overview these interval containers and some basic characteristics in the ITL's documentation here: http://www.herold-faulhaber.de/itl/interval__container__conduct_8h.html The major addition here is the class template interval_map. In contrast to a split_interval_map that preserves all interval borders that may emerge due to insertion and intersection operations, an interval_map keeps itself always minimal: Whenever two neighbouring interval-value pairs ([a,b), v), ([b,c),v) emerge, they will be joined to ([a,c),v). (3) Reviewing the overall design of the interval containers I have separated the meaning of insert/add and erase/subtract, which had been confounded in the previous version of the ITL. This has consequences especially for interval maps: As a design decision I'd like to choose that interval maps are addable and subtractable objects having operators += and -= that implement these properties. Addition and subtraction is then defined via element addition (add(value_type&)) and element subtraction (subtract(value_type&)). At a general level I can define add<inplace_op>(value_type&) and subtract<inplace_op>(value_type&)as member function templates, that implement aggregation on overlap (aggovering) not only for inplace_plus (+=) but also for arbitrary aggregate operations (inplace_op). It turned out, that function insert (std::insert semantics) can be expressed by the general add template (as well as erase can expressed by the subtract member function template): add<inplace_identity>(value_type&) is equivalent to insert(value_type&) subtract<inplace_erasure>(value_type&) is equivalent to erase(value_type&) In addition we can also define 'plain' element add and subtract by means of these templates: add(value_type&) can be defined as: add<inplace_plus>(value_type&) subtract(value_type&) can be defined as: subtract<inplace_minus>(value_type&) So for the ITL container classes I do provide now insert and erase that covers the std::semantics and I provide add and subtract that is the basis for addability and subtractability of itl::maps and itl::interval_maps. You can find an overview over all insert/erase and add/subtact functions and their relationships to std::semantics in the ITL's documentation here: http://www.herold-faulhaber.de/itl/interval__container__design_8h.html I find these design and semantical questions quite rich, and sometimes surprising ;-) and I have found many more aspects and properties while reviewing the ITL's design. I am planning to prepare a more detailed article about these topics in the next months to come. (4) I have prepared a new release 2.0.1 of the ITL for the current state that can be downloaded from: http://www.sourceforge.net/projects/itl Documentation is availabe online also from here: http://www.herold-faulhaber.de/itl The code is well tested using the Law Based Test Automaton (LaBatea) and is protabel for gcc 3.4.4 and msvc 8.0 sp1. I am sorry the ITL is still not in the boost standard directory structure. This will be one of the next steps on my todo list. (5) Concerning boostification of ITL there is still a lot to be done. Besides reviewing of the overall design reported above, I have removed virtual functions from all interval container classes using the curiously recurring template pattern (CRTP). To prevent you repeating advices that already found their way into my todo list I am listing it roughly as appendix to this posting. Cheers Joachim Faulhaber --- Boostification todo list: - Extracting a subset of the ITL as boost proposal - Providing the code in boost directory structure - Replacing own metaprogramming code by boost::mpl,fusion etc. - Using boost::value_initialized for generic initialisations - Further minimizing of class template interfaces and... - Providing more operators and functions as itl::global algorithms - Providing as much std::semantics as possible for interval containers (viewed as set<interval<T>> or map<interval<T>,U>) - Adapting testcode to boost testing standards - Improving documentation especially for issues of design and complexity - Providing boost style documentation - Preparing a proposal on the addition of open interval bounds to boost::interval

4 6

[GIL] read/write PNG/JPEG to/from istream/ostream
by Daniel Pfeifer 11 Aug '08

11 Aug '08

Hello Boosters, Find a modified version of the IO extension of Boost.GIL uploaded to the vault where I added functionality to read from std::istream& and write to std::ostream& for both PNG and JPEG files. Get it from http://tinyurl.com/gil-iostream Cheers, Daniel

3 2

Crypto in Vault...
by Dean Michael Berris 11 Aug '08

11 Aug '08

Hi Guys, Is anybody actively developing the Crypto library implementation in the vault? I ask because I'd like to know if there would be a possibility to make it a header-only implementation. This should make it a better/easier fit for adding cryptographic hash support to Boost. Have a good day everyone. -- Dean Michael C. Berris Software Engineer, Friendster, Inc.

2 4

operator safe-bool?
by Isaac Dupree 11 Aug '08

11 Aug '08

I'm looking at all these "operator unspecified_bool_type"s in Boost. They vary: It's hard to get all of these right, and various Boost libraries have made changes in the past that got it wrong: type-safety compiler workarounds zero runtime overhead (a.k.a. more compiler workarounds) In fact I haven't previously seen an implementation that obviously achieves safety in the general case. Even pointer-to-members have an operator== and operator!=, which will cause trouble if the boolean-convertible type doesn't have its own operator== and operator!= (although it often does). But it is possible! I thought it required macros at first, but it actually works better(in some ways) with the Curiously Recurring Template Pattern. If you, the user, make a class C (such as shared_ptr) that you want to have an operator safe-bool, derive from a boost::convertible_to_bool<C> (and define a member of C "bool operator_bool() const"). Boost shall have, in order to generate errors for invalid operations, the following: template<typename T>operator==(boost::convertible_to_bool<T>const&, boost::unspecified_bool_type); template<typename T>operator==(boost::unspecified_bool_type, boost::convertible_to_bool<T>const&); and similar for operator!=, and (when unspecified_bool_type is a function pointer) for <, >, <=, >=. (The return type is something clever like boost::TYPES_MAY_NOT_BE_COMPARED_IMPLICITLY_VIA_BOOLEAN_CONVERSIONS to improve error messages.) When the compiler has support for the C++0x "explicit operator bool", none of these hacks are needed, and the library can adjust to that too. There are several more details I've been looking at too... ADL, base-chaining like Boost.Operators, writing tests/docs for weird inheritance situations... :-) Perhaps this should be provided as a Boost library in its own right, and Boost should use it everywhere that Boost currently uses idiosyncratic operator safe-bools. Are there any pitfalls I'm missing? (are there important compilers that can't deal with the overhead or correctness of using a base class for this purpose?) Does this sound like a good idea? I can post my code soon if there's interest. -Isaac

3 4

Re: [boost] [Boost-testing] out of date release results?
by David Abrahams 10 Aug '08

10 Aug '08

on Wed Aug 06 2008, Beman Dawes <bdawes-AT-acm.org> wrote: > Eric Niebler wrote: >> >> Beman Dawes wrote: >>> Eric Niebler wrote: >>>> Just spoke with Rene about this ... >>>> >>>> Eric Niebler wrote: >>>>> How come the "report time" on nearly every page of release test >>>>> results is dated July 15th? >>>>> >>>>> For example: >>>>> http://www.boost.org/development/tests/release/developer/summary_release.ht… >>>>> >>> >>> AFAIK, that's the wrong page to be looking at. The page I use to >>> make decisions is >>> http://beta.boost.org/development/tests/release/developer/summary.html >> >> Whew, thanks Beman! How do you get to that page? I go to boost.org, >> click on "Development", and then on "Release Summary". > > I don't look at www.boost.org, because I assume it applies to the > current release. > > Instead I look at beta.boost.org, because I assume it applies to the > release under development. Can we expect developers (and other interested parties) to figure out that they need to look at a hidden site to find this information? And doesn't the fact that it's a beta mean that it could churn and make the results unavailable or wrong without warning? Shouldn't our most important testing results be hosted in a stable environment? It's common to have a "development" or "developers" link that takes you to materials about the unreleased code on the front page of a project's site. Sounds like the current arrangement is not very user-friendly. Can we change it? -- Dave Abrahams BoostPro Computing http://www.boostpro.com

3 4

[interprocess][general] Perfect forwarding through functors
by Ion Gaztañaga 10 Aug '08

10 Aug '08

Hi to all, These days I've been thinking about adding perfect forwarding benefits to Boost Interprocess: 1)Adding "emplace" functions to containers 2)Interprocess has several functions taking an "arbitrary" number of parameters (e.g.: to construct an object in shared memory forwarding all constructor parameters). Currently, I've just used the preprocessor or manual repetition to implement some of those features, but now I want to take advantage of compilers (such as gcc 4.3 with -std=gnu++0x) that have both rvalue references and variadic templates. One solution would be write new functions with variadic templates, just as most containers use templatized range insertion functions. One option to avoid code duplication between range and emplace code is just to pack both range insertion and variadic construction logic in a function object that packs the needed code (function) and data (arguments). However, I also want to minimize both compilation time and code size. This can be achieved encapsulating those object function calls behind virtual functions, so that the main code is not heavily templatized and calls virtual functions that perform the parameter dependent job. An example: class container { struct insert_callbacks { //One possible callback virtual copy_all_to_pos(iterator pos) = 0; } template<class FwdIt> struct fwd_it_callbacks : public insert_callbacks { fwd_it_callbacks(FwdIt first, FwdIt last) : first_(first), last_(last) {} virtual copy_all_to_pos(iterator pos) { std::copy(first, last, pos); } private: FwdIt first_, last_; } template<class ...Args> struct emplace_callbacks : public insert_callbacks { emplace_callbacks(Args&& ...args) : packed_args_(args...) {} virtual copy_all_to_pos(iterator pos) { *pos = T(unpack_somehow(packed_args_)); } private: something_to_pack packed_args_; } template<class FwdIt> void insert(iterator pos, FwdIt first, FwdIt last) { this->insert_impl(pos, fwd_it_callbacks(first, last); } template<class ...Args> void insert(iterator pos, Args &&...args) { this->insert_impl (pos, insert_callbacks(std::forward<Args>(args)...); } void insert_impl(iterator pos, insert_callbacks &cb) { //Make room for new data //... //Prepare exception handling rollbacks.. //... //Call, input-dependent code: cb.copy_all_to_pos(pos); //More code //... } }; Using this approach insert_impl avoids template arguments, generating exactly the same code for all foward iterator types and emplace functions. However, we need a function object that somehow packs arguments and forwards them perfectly to implement emplace functions this way. Since bind() copies arguments (and boost::bind does not use variadic templates yet) and reference_wrapper does not support rvalue references (at least not the latest std draft n2691), I've just started playing with gcc and using Doug Gregor's variadic templates papers' code. I've come up with a solution but that does of calling another function passing the arguments perfectly (code attached). You can use std::tr1::tuple to pack references and the expansion operator (...) to convert those packed arguments again to a function call. In the attached code we can avoid using std::tr1::tuple with a define (a compiler might have perfect forwarding but maybe the standard library is not updated yet, so I shouldn't rely on std::tr1::tuple). All this effort has been very useful to me to start playing with variadic templates, tuples, etc... but I think many boost library implementers will try to do something similar (perfect forwarding through an object function) in the future. The aim of this post is to know if any other boost library writer is playing with variadic templates and he/she has solved this issue in a simpler way. Regards, Ion P.S.: To compile attached code you need gcc 4.3 and activate c++0x support.

1 0

[1.36][ublas] VC8/SP1 with ADL problem?
by Markus Werle 09 Aug '08

09 Aug '08

Hi! Posting to devel, since I believe sucking ADL may be the cause ... I have a headache problem with VC8/SP1 which leads to some questions. 1. Can you confirm this behaviour? 2. Do you have a quick fix workaround for this? 3. Can this be fixed in future versions of boost The following innocent looking piece of code (boiled down within 2 days -sigh) ---snip--- #include <boost/numeric/interval.hpp> #include <boost/numeric/ublas/traits.hpp> #include <boost/numeric/ublas/vector.hpp> namespace ublas = boost::numeric::ublas; void trigger_ublas_compile_error() { ublas::vector<double> boom = ublas::zero_vector<double>(5); } ---EOF--- compiled with VC8 SP1 in DEBUG mode with a command line similar to (some private include paths ripped off) /Od /I "PATH_TO\boost_1_36_beta" /D "WIN32" /D "_WINDOWS" /D "_DEBUG" /D "_CRT_SECURE_NO_WARNINGS" /D "_SCL_SECURE_NO_WARNINGS" /D "BOOST_PYTHON_STATIC_LIB" /D "_MBCS" /Gm /EHsc /RTC1 /MTd /Fo"Debug\\" /Fd"Debug\vc80.pdb" /W3 /nologo /c /ZI /TP /errorReport:prompt /bigobj bails out with ------ Build started: Project: XXXX, Configuration: Debug Win32 ------ Compiling... TestBoostUblasError.cpp [...]\boost_1_36_beta\boost\numeric\ublas\traits.hpp(97) : error C2784: 'boost::numeric::interval<T,Policies> boost::numeric::sqrt (const boost::numeric::interval<T,Policies> &)' : could not deduce template argument for 'const boost::numeric::interval<T,Policies> &' from 'const double' [...]\boost_1_36_beta\boost\numeric\interval\arith2.hpp(198) : see declaration of 'boost::numeric::sqrt' [...]\boost_1_36_beta\boost\numeric\ublas\traits.hpp(93) : while compiling class template member function 'double boost::numeric::ublas::scalar_traits<T>::type_sqrt(const double &)' with [ T=double ] [...]\boost_1_36_beta\boost\numeric\ublas\traits.hpp(151) : see reference to class template instantiation 'boost::numeric::ublas::scalar_traits<T>' being compiled with [ T=double ] [...]\boost_1_36_beta\boost\numeric\ublas\traits.hpp(97) : fatal error C1903: unable to recover from previous error(s); stopping compilation [...] ========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ========== Ugly as it is: it will compile in any release mode, be it static or dynamic linkage :-(

2 3