May 2011 - Boost - lists.preview.boost.org

[1.47.0] Release schedule
by Beman Dawes 28 May '11

28 May '11

* Monday, June 6: branches/release closed for all changes, except by permission of a release manager. * Monday, June 13: branches/release frozen. Only release managers may commit. Once tests have cycled and the release managers are satisfied with stability, release candidates for the beta will be generated. * Monday, Jun 20: Beta release target date. See June in http://www.boost.org/development/index.html or https://www.google.com/calendar/embed?src=5rorfm42nvmpt77ac0vult9iig@group.… The final release date won't be set until later in the process. Thanks, --Beman

1 0

'unnamed_Path' was not declared in this scope
by Ilya Chernykh 28 May '11

28 May '11

Hi! While building a package against boost I receive the following message: /usr/include/boost/filesystem/v2/operations.hpp: In function 'Path boost::filesystem2::current_path()': /usr/include/boost/filesystem/v2/operations.hpp:534:14: error: 'unnamed_Path' was not declared in this scope Is this an error in boost and how can I overcome it?

2 1

[gsoc] heap review
by Tim Blechmann 28 May '11

28 May '11

hi all, during this `summer of code', i will do the review of two proposed libraries, boost.lockfree and boost.heap. the boost.heap review will be the first one, taking place from may 30th to june 8th. boost.heap is an implementation of different priority queue data structures. they can be found at: tarball: http://tim.klingt.org/git?p=boost_heap.git;a=snapshot;h=HEAD;sf=tgz git repository: git://tim.klingt.org/boost_heap.git documentation: http://tim.klingt.org/boost_heap/ there will be a `formal' review announcement, i want to invite people to check out code, examples and documentation ... cheers, tim -- tim(a)klingt.org http://tim.klingt.org Question: Then what is the purpose of this "experimental" music? Answer: No purposes. Sounds. John Cage

6 9

[Block Pointer] benchmark
by Phil Bouchard 27 May '11

27 May '11

Hi, Just for the records I have benchmarked block_ptr using: https://svn.boost.org/svn/boost/sandbox/block_ptr/libs/smart_ptr/example/be… And I get the following: auto_ptr: 9208870 ns shared_ptr: 22958516 ns block_ptr: 75860365 ns Which is pretty good given the complexity it goes thru. I was wondering if there is any hope in having a pool::ordered_malloc() call of O(1) instead of O(n) and a faster pool::is_from()? The latter could be just a check to see if a pointer is within reserved memory pages of the pool. I tried to talk to the author of pool but I got no response. Thanks, -Phil

10 47

[release] 1.4.7
by Thomas Heller 27 May '11

27 May '11

Hi, Now that boostcon is over, what are the dates for 1.47? Thanks, Thomas

9 11

boost.move?
by Bryce Lelbach 27 May '11

27 May '11

Has been Boost.Move been accepted already? If so, can we squeeze it in for the next Boost release? -- Bryce Lelbach aka wash boost-spirit.com px.cct.lsu.edu github.com/lll-project

1 0

Boost Steering Committee
by Beman Dawes 27 May '11

27 May '11

There was a special session Friday morning at BoostCon 2011 to announce the formation of a Boost Steering Committee. The slides from that session have been annotated to make them more comprehensible to those not present. See http://tinyurl.com/3l27o3q (There is also a link on steering.boost.org, but DNS isn't resolving that yet for me. Instead use https://sites.google.com/a/boost.org/steering/) We haven't yet decided anything beyond what is on the slides, so it will take a bit of time before details emerge. As the slides mention, the first job of the steering committee is to design of its own operating procedures and policies. Input from the Boost community will help form those procedures and policies. The steering committee is an important change in the way Boost operates! We hope it will position Boost to continue to grow and prosper. --The Boost Steering Committee Beman Dawes Dave Abrahams Hartmut Kaiser Jeff Garland Jon Kalb Marshall Clow Robert Stewart Steven Wantanabe

3 2

[tokenizer] tokenizing by strings rather than chars
by Andrzej Krzemienski 27 May '11

27 May '11

Hi, I am facing a problem, and I wonder if Boost.Tokenizer, or any other Boost library solves it already. I want to parse numbers separated by "new-lines", however, on my windows system, a "new-line" is represented by two consecutive characters: 13, 10 (or in other words by string "\n\r"). So, only if I encounter a sequence of these two chars do I want to cut the token. boost::char_separator appears to be a bad choice, because it only "cuts" on single chars. Is there a solution to that problem in Boost? Regards, &rzej

3 3

iterator_facade triggers ADL, fails to compile
by Arno Schödl 27 May '11

27 May '11

Hello, the attached file arg_names.cpp fails to compile (VS2008) when using boost::lambda::_1 or boost::phoenix::arg_names::_1. The compilation succeeds when using boost::bind. All three variations are in the attached code for illustration. The compilation fails due to the presence of a templated operator& definition which is introduced by the instantiation of a class that is declared "andable" (from boost/operators.hpp). The compilation fails because iterator_facade triggers ADL in BOOST_ITERATOR_FACADE_INTEROP and finds the aforementioned operator& when comparing iterators that carry boost::lambda::_1 or boost::phoenix::arg_names::_1 as part of their type specification. In the example, this is illustrated by using filter_iterator. It is not clear to me what exactly the mechanism is that causes this ADL problem. But the static_cast in BOOST_ITERATOR_FACADE_INTEROP can be implemented using references instead of pointers, as shown below, which makes the problem disappear. In any case, using operator& on the iterator may be problematic if the iterator overloads operator&. --- C:/Program Files (x86)/Microsoft Visual Studio 9.0/VC/boost_1_46_1/boost/iterator/iterator_facade.hpp Wed May 25 11:42:14 2011 +++ C:/Program Files (x86)/Microsoft Visual Studio 9.0/VC/boost_1_46_1/boost/iterator/iterator_facade - Copy.hpp Wed May 25 11:41:49 2011 @@ -819,8 +819,8 @@ is_interoperable< Derived1, Derived2 >::value \ )); \ return_prefix iterator_core_access::base_op( \ - *static_cast<Derived1 const*>(&lhs) \ - , *static_cast<Derived2 const*>(&rhs) \ + static_cast<Derived1 const&>(lhs) \ + , static_cast<Derived2 const&>(rhs) \ , BOOST_ITERATOR_CONVERTIBLE(Derived2,Derived1) \ ); \ } Does anyone understand better what is happening? Or can we simply adopt the change? Regards, Arno -- Dr. Arno Schödl | aschoedl(a)think-cell.com Technical Director think-cell Software GmbH | Chausseestr. 8/E | 10115 Berlin | Germany http://www.think-cell.com | phone +49 30 666473-10 | US phone +1 800 891 8091 Amtsgericht Berlin-Charlottenburg, HRB 85229 | European Union VAT Id DE813474306 Directors: Dr. Markus Hannebauer, Dr. Arno Schoedl

3 4

[local] couple questions
by Jeffrey Lee Hellrung, Jr. 27 May '11

27 May '11

1) I notice from http://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/boost_loca… that (proposed) Boost.Local has a dependency on Boost.ScopeExit. It seems that Boost.Local provides all the functionality of Boost.ScopeExit, and then some; at least, that's what seems to be implied by http://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/boost_loca… It would seem reasonable then, maybe, should Boost.Local be accepted, to remove the dependence on Boost.ScopeExit and officially deprecate Boost.ScopeExit in favor of Boost.Local's BOOST_LOCAL_EXIT: http://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/boost_loca… What are your (you = Lorenzo or anyone else) thoughts regarding that development path? 2) I haven't read through the docs in *too* much detail yet, but I would guess from, for example, http://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/boost_loca… that copying a Boost.Local functor amounts to something less than a deep copy, and possibly an entirely shallow copy. In other words, does int x = 0; void BOOST_LOCAL_FUNCTION_PARAMS( bind(int) x ) { // bind x by value, so a copy is taken... std::cout << ++x << std::endl; } BOOST_LOCAL_FUNCTION_NAME(f) boost::function< void ( ) > g(f); f(); g(); print "1" followed by "2" (my guess), or does it print "1" twice? I may have missed it entirely, but I'd like the semantics of copying a Boost.Local functor explicitly spelled out. P.S.: I noticed in http://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/boost_loca… a misspelling in the comments of the last example, s/BOOST_IDENTITY_VALE/BOOST_IDENTITY_VALUE/. - Jeff

2 1

[type_at] Variadic template utility
by tymofey 27 May '11

27 May '11

While experimenting with varidic templates of the upcoming standard i discovered that quite often one would need to extract a type from parameter pack at specified position. While the task is trivial it would be quite handy to have a ready tool for this purpose, rather that specifying one yourself every time. You can find source code consisting of a single header at Vault/Utilities/type_at.hpp The usage is simple: boost::type_at<index, some_type_0, some_type_1, some_type_2, some_type_n>::type corresponds to some_type_index where index is in range [0..n]. For example: boost::type_at<2, int, float, char, long>::type corresponds to char. I hope this will be useful.

5 6

Test results down for a little while
by Daniel James 27 May '11

27 May '11

Hi, I just noticed that the server load was pretty high because someone was spidering the test results. So I removed them for a little while (I don't have time to work how to block an IP address). They'll be back soon-ish. Hopefully, whoever was doing so will understand. If you want an offline copy of the test results, you should probably ask on the testing list, I'm sure we can work something out. Daniel

1 0

[ICL] Compile error when using "is_numeric"
by sguazt 27 May '11

27 May '11

Hi, I've just checked-out the last SVN version of ICL and after compiling with gcc (GCC) 4.5.1 20100924 (Red Hat 4.5.1-4) (flags: -Wall -Wextra -pedantic -ansi) I get these errors: --- [error] --- boost-trunk/boost/icl/concept/interval_bounds.hpp:89:58: error: type/value mismatch at argument 2 in template parameter list for ‘template<class Type, class Compare, bool Enable> struct boost::icl::numeric_minimum’ boost-trunk/boost/icl/concept/interval_bounds.hpp:89:58: error: expected a type, got ‘boost::icl::is_numeric<Type>::value’ ... boost-trunk/boost/icl/concept/interval_bounds.hpp:104:58: error: type/value mismatch at argument 2 in template parameter list for ‘template<class Type, class Compare, bool Enable> struct boost::icl::numeric_minimum’ boost-trunk/boost/icl/concept/interval_bounds.hpp:104:58: error: expected a type, got ‘boost::icl::is_numeric<Type>::value’ ... boost-trunk/boost/icl/left_open_interval.hpp:52:64: error: type/value mismatch at argument 2 in template parameter list for ‘template<class Type, class Compare, bool Enable> struct boost::icl::numeric_minimum’ boost-trunk/boost/icl/left_open_interval.hpp:52:64: error: expected a type, got ‘boost::icl::is_numeric<Type>::value’ ... boost-trunk/boost/icl/open_interval.hpp:51:64: error: type/value mismatch at argument 2 in template parameter list for ‘template<class Type, class Compare, bool Enable> struct boost::icl::numeric_minimum’ boost-trunk/boost/icl/open_interval.hpp:51:64: error: expected a type, got ‘boost::icl::is_numeric<Type>::value’ --- [/error] --- To solve this problem, it seems it is sufficient to prefix the use of "is_numeric" with "typename". Here below is the diff file: --- [diff] --- Index: boost/icl/left_open_interval.hpp =================================================================== --- boost/icl/left_open_interval.hpp (revision 72177) +++ boost/icl/left_open_interval.hpp (working copy) @@ -49,7 +49,7 @@ // Only for discrete types this ctor creates an interval containing // a single element only. BOOST_STATIC_ASSERT((icl::is_discrete<DomainT>::value)); - BOOST_ASSERT((numeric_minimum<DomainT, is_numeric<DomainT>::value >::is_less_than(val) )); + BOOST_ASSERT((numeric_minimum<DomainT, typename is_numeric<DomainT>::value >::is_less_than(val) )); } /** Interval from <tt>low</tt> to <tt>up</tt> with bounds <tt>bounds</tt> */ Index: boost/icl/concept/interval_bounds.hpp =================================================================== --- boost/icl/concept/interval_bounds.hpp (revision 72177) +++ boost/icl/concept/interval_bounds.hpp (working copy) @@ -86,7 +86,7 @@ { if(is_left_closed(decl) && !is_left_closed(repr)) { - BOOST_ASSERT((numeric_minimum<Type, is_numeric<Type>::value >::is_less_than(low) )); + BOOST_ASSERT((numeric_minimum<Type, typename is_numeric<Type>::value >::is_less_than(low) )); return icl::pred(low); } else if(!is_left_closed(decl) && is_left_closed(repr)) @@ -101,7 +101,7 @@ { if(!is_right_closed(decl) && is_right_closed(repr)) { - BOOST_ASSERT((numeric_minimum<Type, is_numeric<Type>::value >::is_less_than(up) )); + BOOST_ASSERT((numeric_minimum<Type, typename is_numeric<Type>::value >::is_less_than(up) )); return icl::pred(up); } else if(is_right_closed(decl) && !is_right_closed(repr)) Index: boost/icl/open_interval.hpp =================================================================== --- boost/icl/open_interval.hpp (revision 72177) +++ boost/icl/open_interval.hpp (working copy) @@ -48,7 +48,7 @@ // Only for discrete types this ctor creates an interval containing // a single element only. BOOST_STATIC_ASSERT((icl::is_discrete<DomainT>::value)); - BOOST_ASSERT((numeric_minimum<DomainT, is_numeric<DomainT>::value >::is_less_than(val) )); + BOOST_ASSERT((numeric_minimum<DomainT, typename is_numeric<DomainT>::value >::is_less_than(val) )); } /** Interval from <tt>low</tt> to <tt>up</tt> with bounds <tt>bounds</tt> */ --- [/diff] --- Can you fix it? Thank you very much!! Best, -- Marco

2 4

Re: [boost] Mixing different versions of Boost libs in a single process
by Grund, Holger 27 May '11

27 May '11

Well, BoostCon is over. So let me try again focusing on some specific bits: > > So the next best thing would be the ability to mix different versions > of Boost in a single process. Today, linkage names will be identical > across versions, which is problematic for static libraries on Windows, > and static libs and DSOs on Linux. [..] > Also there's BCP, which supports renaming namespaces. That's great, but > I guess it could be even better -- e.g. on toolchains where we have > inline namespaces or __attribute__((strong)). On Linux targets, symbol > versioning via GNU LD version scripts might make things a bit better -- > specifically, in that things gone wrong fail earlier and with better > diagnostics. > So when I run BCP on the entire boost tree I still get linkage names that would seem to clash across versions. Specifically, there's the graphml_reader namespace in libs/graph/src/graphml.cpp. Boost.Python and Boost.MPI have symbols that could cause problems, though these would seems to come from external OpenMPI and Python headers. I haven't really looked but it seems these should be fine so long as we build against the same OpenMPI and Python versions with the same configuration. What's the policy here? Do we want BCP to address these things? Or do we want libraries to not use namespaces outside of ::boost (or use linkage/symbol visibility to hide symbols from other DSOs)? Are there any tools to detect this kind of problem? I have a few things check two binaries for potential conflicts by walking debug info and symbol tables -- it's far from perfect and I can't just upload this to Boost, but I'd be happy to help out, if there's interest to get something into the regression tests. Thoughts, anyone? Thanks! -hg -------------------------------------------------------------------------- NOTICE: Morgan Stanley is not acting as a municipal advisor and the opinions or views contained herein are not intended to be, and do not constitute, advice within the meaning of Section 975 of the Dodd-Frank Wall Street Reform and Consumer Protection Act. If you have received this communication in error, please destroy all electronic and paper copies and notify the sender immediately. Mistransmission is not intended to waive confidentiality or privilege. Morgan Stanley reserves the right, to the extent permitted under applicable law, to monitor electronic communications. This message is subject to terms available at the following link: http://www.morganstanley.com/disclaimers. If you cannot access these links, please notify us by reply message and we will send the contents to you. By messaging with Morgan Stanley you consent to the foregoing.

2 2

[random] recent changes causing failures in accumulators tests
by Eric Niebler 27 May '11

27 May '11

Many accumulators tests are now failing on both trunk and release. I have tracked it down to recent changes in Boost.Random. I don't know for how long this has been happening. The accumulators tests use the lagged_fibonacci607 random number generator. The tests work by sending a large amount of random data through various statistical accumulators and checking that the results are within a certain tolerance of what they would be if the data were actually random. In Boost 1.45 and previous versions, this worked. (I haven't tested 1.46.) Trunk and release are hosed, leading me to suspect that this random number generator is no longer producing sufficiently random data. I have verified this by replacing boost/random on trunk with the one from 1.45. With this change, the accumulators tests pass. Steven, this seems like a regression. Can you look into this? -- Eric Niebler BoostPro Computing http://www.boostpro.com

2 1

[pimpl] Modularity thoughts
by Gregory Crosswhite 27 May '11

27 May '11

Hey everyone, As I have stated I think that it pimpl is acceptable enough as is even though it might contain "too much" for advanced users. Nonetheless, having reflected on some of the other reviews I do have some thoughts on some changes that could be made to it to make it more modular, while still preserving a default "all-in-one" option for ordinary users. Take the pimpl struct: =========================== template<class Interface> struct pimpl { struct implementation; template<class> class value_semantics_ptr; template<template<class> class> class pimpl_base; typedef pimpl_base<value_semantics_ptr> value_semantics; typedef pimpl_base<boost::shared_ptr> pointer_semantics; static Interface null(); }; =========================== and replace it with something roughly like =========================== template<template<class> class> equality_ops; template<template<class> class> ordering_ops; template<template<class> class> null_ops; template<template<class> class> bool_ops; template<class Interface> struct pimpl { struct implementation; template<class> class value_semantics_ptr; template<template<class> class> class pimpl_base; typedef pimpl_base<value_semantics_ptr> value_semantics_base; typedef pimpl_base<boost::shared_ptr> pointer_semantics_base; struct value_semantics: public equality_ops<value_semantics_base>, public ordering_ops<value_semantics_base>, public null_ops<value_semantics_base>, public bool_ops<value_semantics_base> {}; struct pointer_semantics: public equality_ops<pointer_semantics_base>, public ordering_ops<pointer_semantics_base>, public null_ops<pointer_semantics_base>, public bool_ops<pointer_semantics_base> {}; static Interface null(); }; =========================== Now take out all of the operations from pimpl_base and put them in separate subclasses like so: =========================== template<typename pimpl_base_type> struct equality_ops : public virtual pimpl_base { bool operator==(equality_ops const& that) const { return (impl_ == that.impl_); } bool operator!=(equality_ops const& that) const { return !(impl_ == that.impl_); } }; template<typename pimpl_base_type> struct ordering_ops : public virtual pimpl_base { bool operator<(ordering_ops const& that) const { return pimpl_base_type::impl_ < that.pimpl_base_type::impl_; } }; template<typename pimpl_base_type> struct bool_ops : public virtual pimpl_base { operator safebool_type() const { return safebool(pimpl_base_type::impl_.get()); } }; template<typename pimpl_base_type> struct null_ops : public virtual pimpl_base { typedef typename pimpl_base_type::interface T; static T null() { return pimpl<T>::null(); } }; =========================== Now the user can mix and match whatever operations he or she likes like, or simply take the full package by default. Note that I have intentionally left out constructors in the above classes because they aren't needed: since we are using virtual inheritance, the user of this library will be calling the constructor of pimpl_base directly, so we don't even have to worry about generating lots of boilerplate to forward the constructor arguments up to the base. In fact, this actually makes using this library simpler in one respect: normally a downside of using virtual inheritance in general is that every derived class needs to call the constructors of all bases, but in the particular case of this library this turns out to be a feature rather than a bug! The documentation discussed how when initializing a derived class you essentially have to call the constructor of the immediate base class and then undo it by resetting the pointer and then filling it with the correct type, but since we are using virtual inheritance now we no longer need this awkward procedure since we can just skip over the constructor of the immediate base class and call the constructor of pimpl_base directly! This also further removes the need for implementations to support a "null" value. Finally, and most importantly, a strong advantage of this design is that it is extensible so users and library writers can define their own operation that they would like to add to classes and mix them right in. Anyway, these are just some thoughts that I had. :-) Cheers, Greg

1 0

[pimpl] Preliminary Review
by Gregory Crosswhite 27 May '11

27 May '11

Hey everyone, Here are my preliminary thoughts regarding the pimpl library. First, I like the idea of having it or something similar to it be part of Boost because the functionality seems like it would be useful in a lot of cases. One of the strengths of including such a library in boost in my opinion is that it will appear in the "Libraries" list, which means that more people will be exposed to the idiom and will think of it as a possible option than they would otherwise. Put another way, Boost is both a collection of libraries and of best practices, so a good pimpl implementation belongs in boost even if it is a relatively small one. Now the question is whether this particular implementation itself is good enough. Honestly, I have trouble figuring out exactly what it does except by reading through the code since the documentation itself doesn't say what it does behind the scenes except to say vaguely that it implements "pointer semantics" or "value semantics". So one thing that the documentation really needs (among the many others that have been mentioned) is a section that clearly lists the features that it offers. One objection that Artyom reasonably raised is that this implementation may try to do too much, and doesn't offer much in the way of customization. However, people like Artyom are most likely going to be rolling their own implementation of the pimpl idiom anyway. I think that it is sufficient that a implementation be "good enough" for an ordinary user's needs that they won't have to think about any of the ugly details since it does all of that work for them, and to the extent that this is true of the current implementation Now for my thoughts on the code itself. Two of the classes in the implementation should probably be reviewed separately and put in different Boost libraries rather than the Pimpl library, namely safebool and value_semantics_ptr. safebool is an interesting solution to the problem that implicit conversions to the "bool" type implies implicit conversions to hosts of other types such as integers which can result in all sorts of unexpected behaviors that will bite you when you least expect it. safebool solves this problem by providing a convenient way for you to implement an effective "bool()" by instead implementing an operator that returns a special function-pointer that is specialized to your class and thus is equal neither in type nor value to a safebool for any other class; a minor cost that is presumably incurred by this is that a small amount of code will be added to the binary for this special no-op function, since I don't see how this can be optimized away. The implementation looks straightforward and the comments contain good documentation explaining both the usage and the rationale. I would recommend that safebool be accepted into boost and added to the utilities library on its own merits. value_semantics_ptr is a class that contains a pointer to data (or possibly a null pointer) and has the semantics that upon assignment it copies the data from another pointer, allocating (or freeing) its internal pointer if necessary. I think that this is a good idea and that something like this belongs in boost, but I suggest that the current implementation should be changed at least as follows before being accepted: First, it should be taken out of the pimpl<> class and made independent. Second, the traits struct member should be changed from a derived class to a second parameter in the list of template arguments to the value_semantics_ptr type, with the deep_copy member being pulled outside and being made the default value of the new second template argument. Alternatively, a type function --- e.g., copy_traits<T> --- could be used instead. Third, if Boost::Move is going to be ready soon it would be ideal if this class could be modified to support it in order to potentially save some extraneous copies. Fourth, one of the methods confuses me and apparently also the author: bool operator<(value_semantics_ptr const& that) const { return this->impl_ < that.impl_; // Should it be "*this->impl_ < *that.impl_" instead? } so this should be finalized. Fifth, the implementation will need to be fleshed out. operators such as * (dereference) and -> will need to be added, as well as some additional typedefs such as value, pointer, reference, etc. Operator safebool() will also need to be added. In conclusion, if pimpl is accepted I think it would be better for there to be a polished value_semantics_ptr that we feel comfortable having be directly tested and exposed to users be the back-end of this class than something hidden away, so when value_semantics_ptr is ready I think that it should ultimately be accepted to the Smart Ptr library. So much for safebool and value_semantics_ptr, now on to pimpl itself. The code looks straightforward and the comments document it reasonably well --- in fact, the ratio of comments to code in the main pimpl class is roughly 2:1, and in that count I was lazily including whitespace and single { and } lines as code lines, so that gives you a sense of how heavily it is commented. I have only taken a quick glance through it since this is a pre-review, but it all looks simple and straightforward to me, and it does a good job of generating tedious boilerplate so the user doesn't have to, exactly as it claims. On a side note, one additional set of semantics that I would recommend adding is move semantics, which could be implemented using the Boost::Move library. In conclusion, I think that this library should be broken into parts with safebool being put in utilities, value_semantics_ptr (and we can bikeshed over the name here of course :-) ) being put in smart ptr, and pimpl being put in a separate library. After this is done pimpl will be quite small, but I think that it pulls enough weight that it is nonetheless useful. To repeat what I said earlier, boost is not just a repository of libraries but of C++ best practices, so even if pimpl is small if it does a good job of capturing the pimpl idiom I still think that it should be accepted into Boost. Cheers, Greg

1 1

Library Review Tool (paging Jeff Garland) -- was : Re: [xint] Formal Review Result
by Michael Caisse 27 May '11

27 May '11

On 05/03/2011 09:12 AM, Matthew Chambers wrote: > On 5/3/2011 11:02 AM, Marsh Ray wrote: >> On 05/02/2011 03:04 PM, Barend Gehrels wrote (in another order): >>> >>> There was somebody who recently mentioned a scoreboard on this list >>> and I now think this is a good idea, because the review manager can >>> check if all reviews are taken into account. >> >> Yes, please. >> >> It would also make it more practical for an observer like me to sit >> down and simply read the reviews >> in an orderly way. >> >>> I understand that the traffic was really high, that review managers >>> do this voluntary, everybody don't have all the time, etc. >>> >>> Reviews are usually carefully written. People spend several hours on >>> it, sometimes days. Skipping these reviews is a sad thing. Writing a >>> library cost weeks, sometimes months or more. Forgetting reviews is >>> a very sad thing. >> >> Honestly, I would be more likely to help review libraries if I felt >> like it wouldn't be buried in >> the volume of the list. > > This where mailing lists fall to pieces. With proper forum software, > moderators could easily organize threads and change subject lines so > that it would be trivial to separate actual reviews from discussion. > And in fact, users would quickly adjust their behavior to fit the > paradigm. Instead, we have hundreds of messages with "review" in the > subject and only some of them are actual reviews, most being > discussion (like this one!). :( > > -Matt > _______________________________________________ Some time ago we all had a discussion like this and I believe Jeff Garland had mentioned Smart Bear's CodeCollaborator to aid in Boost Reviews. I used their product for a short time and was just taking a look at their web site again: <http://smartbear.com/products/development-tools/code-review/features/> I know there are other tools also (like Crucible) but CodeCollaborator also allows reviews of html docs which will obviously be handy. IIRC Jeff had mentioned that SmartBear might be willing to provide licensing for Boost (or opensource .. it is all fuzzy). I believe Jeff was in contact with them... but my memory might be failing (Jeff?? Are you there?) I would be willing to investigate this path further, including the administration and such of the tool, if it is of interest to the community. michael -- In the Sacramento/Folsom area? ** Profesional C++ Training mid-May ** http://www.objectmodelingdesigns.com/boostcon_deal.html Michael Caisse Object Modeling Designs www.objectmodelingdesigns.com

8 13

[network] Review Manager - Volunteer
by Michael Caisse 27 May '11

27 May '11

Review Wizards - Dean Michael Berris and I spoke today about his Network library submission that is in the review queue. I am willing to act as Review Manager for the library which is also acceptable to Dean. If there are no objections, please sign me up. Thank you - michael -- Michael Caisse Object Modeling Designs www.objectmodelingdesigns.com

1 0

Re: [boost] [Math and numerics] interest in Circular values math and statistics library ?
by Greg Rubino 26 May '11

26 May '11

I like that idea. An integer version of this lib would be a good start for a boost lib that supports arbitrary finite groups (you get cyclic and dihedral for free). I think such a thing would probably be more generally described in terms of permutations though. Greg Rubino On May 26, 2011 5:18 PM, "Krzysztof Czainski" <1czajnik(a)gmail.com> wrote:

1 0

[pre-review] Pimpl submission in the review queue
by Vladimir Batov 26 May '11

26 May '11

I have a Pimpl generalization submission getting close to the top in the review queue. Rob Stewart suggested I'd post it to the new Boost Code Collaborator site for a pre-review. That's what I did with the following link to the pre-review (Review #5): http://demo.smartbear.com/boost/go?page=ReviewDisplay&reviewid=5 Your participation in that pre-review is most welcome. Best regards, Vladimir.

8 14

[phoenix] conflicts between result_of namespace and result_of class.
by Vicente Botet 26 May '11

26 May '11

Hi, I have found an error when we define new phoenix expression inside boost namespace. The following #include <boost/phoenix/core/limits.hpp> #include <boost/phoenix/core/call.hpp> #include <boost/phoenix/core/expression.hpp> #include <boost/phoenix/core/meta_grammar.hpp> #include <boost/phoenix/object/detail/target.hpp> #include <boost/proto/transform/lazy.hpp> #include <boost/phoenix/core/is_actor.hpp> BOOST_PHOENIX_DEFINE_EXPRESSION( // line 19 (boost)(convert_to) , (proto::terminal<boost::phoenix::detail::target<proto::_> >) (boost::phoenix::meta_grammar) ) results in darwin.compile.c++ ../../../bin.v2/libs/conversion_ext/test/builtins.test/darwin-4.2.1/debug/builtins.o builtins.cpp:19: error: ‘namespace boost::result_of { }’ redeclared as different kind of symbol ../../../boost/utility/result_of.hpp:35: error: previous declaration of ‘template<class F> struct boost::result_of’ builtins.cpp:19: error: ‘template<class F> struct boost::result_of’ used without template parameters builtins.cpp:19: error: expected unqualified-id before ‘<’ token It seems that the Phoenix result_of protocol and the utility result_of conflicts. Is this a real issue? Best, Vicente -- View this message in context: http://boost.2283326.n4.nabble.com/phoenix-conflicts-between-result-of-name… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 3

Re: [boost] [ICL] some improvement proposals. Making selectors return const reference
by Joachim Faulhaber 26 May '11

26 May '11

Hi Denis, list, thanks for your interest in Boost.ICL and for your input. First a side note on the subject line: You did what is stated in the boost discussion policy http://www.boost.org/community/policy.html which says: Put the Library Name in the Subject Line [ICL] some improvement proposals. Actually as you can see on the list the convention that is actually established is [boost][Libraryname] bla bla for the developers list and [Boost-users][Libraryname] bla bla for the user's list. *Would someone update the web page accordingly?* Next I'd like to refer to a suggestion you've sent in off-list: 2011/5/16 Denis <denis(a)camfex.cz>: > Hi Joachim > > I also think that the functions upper() lower() first() last() have to > return const reference to domain_type instead of domain_type. > It is the same for int/double/time but has sense for my blobs. > Returning domain_type implies copying. > Same logic as std::vector's at(). This is interesting. With first() and last(), I don't think it is possible, because, dependent on the type of interval, we may generate a local temporary object via increment (++) or decrement (--), which can not be referred to. On the contrary for upper() and lower(), we should always be able to pass the constant reference of the member variables of the interval as return value. As you say, this avoids copying operations that might decrease efficiency, if domain_type objects are large. I think a modification to the code can be done without breaking existing code, at least I hope so. We could use typedef boost::call_traits<domain_type>::param domain_return_type as return type of lower() and upper(), so pass by value can be kept for built in types. Still I am kind of reluctant when I think of implementing this optimization: (1) Return by value works well and fast for the majority of applications where domain_type is built-in or small (2) Return by value allows for compiler optimizations that are taking care for copy elision in many cases. (3) It would be nicer if all selectors had the same signatures (simplicity). (4) Customization of intervals will become more obscure, less understandable by the new domain_return_type. (5) We'd increase expert-friendliness for a concern that is relatively local: Using ICL::intervals and interval_containers with large domain objects is unfavorable anyway. If efficiency is a mayor issue, we would have to consider not using the large objects directly in intervals but introducing a level of indirection. We may refer to them through (smart)pointers or iterators which are small and use an induced ordering for the interval containers for the Compare template parameter. x < y <=> (*x) < (*y) So I'm not shure what to do. Currently I tend to consider an implementation of the proposal. Thoughts? Joachim -- Interval Container Library [Boost.Icl] http://www.joachim-faulhaber.de

2 2

Re: [boost] [Boost-commit] svn:boost r72166 - trunk/libs/thread/src/pthread
by Juergen Hunold 26 May '11

26 May '11

Hi Anthony, On Wednesday, 25. May 2011 23:19:01 anthony(a)justsoftwaresolutions.co.uk wrote: > Author: anthonyw > Date: 2011-05-25 17:18:59 EDT (Wed, 25 May 2011) > New Revision: 72166 > URL: http://svn.boost.org/trac/boost/changeset/72166 > > Log: > extern "C" functions are static > > Text files modified: > trunk/libs/thread/src/pthread/once.cpp | 4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) > > Modified: trunk/libs/thread/src/pthread/once.cpp > =========================================================================== > === --- trunk/libs/thread/src/pthread/once.cpp (original) > +++ trunk/libs/thread/src/pthread/once.cpp 2011-05-25 17:18:59 EDT > (Wed, 25 May 2011) @@ -22,12 +22,12 @@ > pthread_key_t epoch_tss_key; > pthread_once_t epoch_tss_key_flag=PTHREAD_ONCE_INIT; > > - extern "C" void delete_epoch_tss_data(void* data) > + extern "C" static void delete_epoch_tss_data(void* data) At least gcc-4.5.2 does not like this combination and bails out with: error: invalid use of 'static' in linkage specification gcc version 4.5.2 (Ubuntu/Linaro 4.5.2-8ubuntu4) Please find a patch fixing this attached. Okay to commit? Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! Ingenieurgesellschaft für * voice: ++49 511 262926 57 ! Verkehrs- und Eisenbahnwesen mbH * fax : ++49 511 262926 99 ! Lister Straße 15 * juergen.hunold(a)ivembh.de ! www.ivembh.de * * Geschäftsführer: ! Sitz des Unternehmens: Hannover * Prof. Dr.-Ing. Thomas Siefer ! Amtsgericht Hannover, HRB 56965 * PD Dr.-Ing. Alfons Radtke !

1 0

[review][autoindex] AutoIndex review result
by Daniel James 25 May '11

25 May '11

The AutoIndex reviews were unanimously in favour of inclusion so it has been accepted into Boost. Reviews were submitted by: Edward Diener, Paul A. Bristow, Barend Gehrels and Hartmut Kaiser. Artyom also took part. Some of the general issues that were raised: The name should be more consistent. There was a little confusion about installation, but this should be easier once it's part of boost. Since it works at the docbook level it can be a bit confusing for a pure quickbook user. We might need to add extra support to quickbook - possibly in the form of a template library. There was some confusion about the integration of the different documentation tools, e.g. the use of <quickbook-define> to optionally include content in quickbook, using 'xinclude' to include doxygen documentation in quickbook. I think this is more of a weakness of the quickbook documentation. A few reviewers wanted finer grained control over where index terms are inserted. It isn't clear how this could be done without adding too much complexity. Adding processing instructions to the xml is one possibility. The C++ header scanner picks up too many symbols for spirit (and will possibly do so for other libraries), some kind of annotation or configuration might help. Thanks to everyone who participated in the review, and to John Maddock for developing AutoIndex, Daniel James

2 1

Boost.Conversion: functors namming
by Vicente BOTET 25 May '11

25 May '11

Hi, during the Boost.Convert after review discussion there were some proposals to use Boost.Phoenix to build the functors. My question is what should be the name of the function that builds the functor. Some possibilities: short s=1; long l=3; using boost::phoenix::placeholders::_1; A- Use a different name: make_converter_to? s=boost::make_converter_to(*short*)(_1)(l) ; B- Use the same name in a different namespace. What about using "fp" as namespace (functional programming). s=boost::conversion::fp::convert_to(*short*)(_1)(l) ; C- Use the same name in the same namespace and use SFINAE/enable_if to select the correct implementation depending on the parameter. s=boost::convert_to(*short*)(_1)(l) ; Which are your preferences? Best, Vicente

5 12

[type traits] issue with operator traits and volatile qualifier
by Frédéric Bron 25 May '11

25 May '11

Sorry for being absent during the last month but it was very hard to find any time to work on the addition of the operator traits. I have not yet had the time to deal with the naming issue... But I found something more tricky while trying to solve the issue of reference types (& was just ignored). I never used the volatile qualifier but I found that the following behaviour breaks the code that detects if an operator returns void or not. Could someone tell me why the following code does not compile? bool f() { } void g(const volatile bool &) { } int main() { g(f()); return 0; } Many thanks, Frédéric

3 2

Re: [boost] [Lambda] Handling Bind/Lambda name clashes.
by Max Sobolev 25 May '11

25 May '11

On 25.05.2011 15:49, Eric Niebler wrote: > (fixing attribution...) > > On 5/23/2011 11:42 PM, Robert Jones wrote: >> On Thu, Apr 7, 2011 at 3:01 PM, Steven Watanabe wrote: >>> At some point in time, Eric Niebler wrote: >>>> And what is wrong with leaving bind in the boost namespace as I was >>>> suggesting and define boost::function like this: >>>> >>>> namespace boost { >>>> namespace function_adl_block { >>>> template<class Sig> >>>> struct function {...}; >>>> } >>>> using function_adl_block::function; >>>> } >>>> >>>> Now the "boost" namespace is no longer associated with >>>> boost::function, >>>> and boost::bind won't be found by ADL. > > It's probably a good general policy to move most/all types in Boost into > ADL-blocking namespaces like above, except those for which there is > reason to keep boost as an associated namespace. cool technique (for building more modular software / libs)!

1 0

[chrono, trunk] linux compile fix
by Tim Blechmann 25 May '11

25 May '11

today's trunk does not compile correctly. this trivial patch fixes the issue: thanks, tim Index: boost/chrono/detail/inlined/posix/thread_clock.hpp =================================================================== --- boost/chrono/detail/inlined/posix/thread_clock.hpp (revision 72154) +++ boost/chrono/detail/inlined/posix/thread_clock.hpp (working copy) @@ -21,6 +21,7 @@ thread_clock::time_point thread_clock::now( ) { + struct timespec ts; #if defined CLOCK_THREAD_CPUTIME_ID // get the timespec associated to the thread clock if ( ::clock_gettime( CLOCK_THREAD_CPUTIME_ID, &ts ) ) @@ -31,7 +32,6 @@ clockid_t clock_id; pthread_getcpuclockid(pth, &clock_id); // get the timespec associated to the thread clock - struct timespec ts; if ( ::clock_gettime( clock_id, &ts ) ) #endif { @@ -49,6 +49,7 @@ } thread_clock::time_point thread_clock::now( system::error_code & ec ) { + struct timespec ts; #if defined CLOCK_THREAD_CPUTIME_ID // get the timespec associated to the thread clock if ( ::clock_gettime( CLOCK_THREAD_CPUTIME_ID, &ts ) ) @@ -59,7 +60,6 @@ clockid_t clock_id; pthread_getcpuclockid(pth, &clock_id); // get the timespec associated to the thread clock - struct timespec ts; if ( ::clock_gettime( clock_id, &ts ) ) #endif {

2 1

Re: [boost] [pre-review] Pimpl submission in the review queue
by Sean Chittenden 25 May '11

25 May '11

> I have a Pimpl generalization submission getting close to the top in the review > queue. Rob Stewart suggested I'd post it to the new Boost Code Collaborator site > for a pre-review. That's what I did with the following link to the pre-review > (Review #5): > > http://demo.smartbear.com/boost/go?page=ReviewDisplay&reviewid=5 > > Your participation in that pre-review is most welcome. Fantastic! I signed up and am anxious to see this library accepte^Wreviewed^Waccepted. I've been using the Boost.Pimpl interface for nearly a year now and have been very successful and happy with its use in my projects. Second to ASIO, Boost.Pimpl has done more to impact the design, structure and maintenance of my projects than any other library (the benefits of a stable ABI are understated). Its use in maintaining clean interfaces and projects can't be understated. Historically I'd always saved implementing Pimpl for external facing bits and had always rolled my own interface, now I use it for everything internal or external because of how easy it is to thump out a Boost.Pimpl based interface. As I said on the review site, I've moved the Pimpl implementation in to "boost/pimpl" directory with success, though was not able to move the Pimpl library under the boost namespace. Actually... let me post a quick example that I wrote to both learn and quickly teach how to use Pimpl: https://github.com/sean-/Boost.Examples/tree/master/pimpl It takes about 60sec-3min for most people to have their "ah ha!" moment with that example (those unfamiliar with Pimpl would be wise to check it out, imnsho). I didn't dive in to the why, but in the implementation it is necessary open your namespace after you have defined your private implementation (see pimpl/pimpl_example_pointer_impl.cc:35). It would be nice to know why this is the case (or if it's a bug). Pre-review feedback: The examples used in the Pimpl unit tests are very very good, but it takes a few minutes to wade through the polymorphism and to tease out the most basic requirements for starting to use Pimpl. Walking through 1K of code to do something very simple is a bit daunting despite the obvious and nearly immediate dividends. Whenever I started using this, it was one of the best few hours I've ever spent learning something new. I'm very pleased to see this library move forward and look forward to its formal review. -sc -- Sean Chittenden sean(a)chittenden.org

4 3

Re: [boost] [date_time] Time zone improvements
by Rutger ter Borg 25 May '11

25 May '11

Jeff Garland wrote: > Very cool :-) One question -- is there a portable solution where a user > could deploy a files onto a Windows system or is it a Unix only solution? > I'm fine with incorporating a *nix only solution because what your > suggesting will be a nice solution for *nix platforms, but it will need to > be clear that it's not portable. I don't see why it wouldn't be possible to deploy the (big-endian) binary files to any platform. Getting it into this binary form (using zone info compiler zic) may be harder to do cross-platform, but cygwin may help here. [snip] > As the primary maintainer of Boost date-time I can say with certainty that > there is interest in this functionality -- it's long been on my todo list > and I haven't had time to get to it. You can email me privately and we > can discuss all the details of how to get your code incorporated. I'll do! Regards, Rutger

5 9

Re: [boost] [ICL] some improvement proposals
by Joachim Faulhaber 25 May '11

25 May '11

Hi Denis, thanks for your input again. You're a good analyzer of code. Maybe you want to consider writing a code review for libraries that are submitted for formal review on the boost developer's list from time to time :) 2011/5/19 Denis <denis(a)camfex.cz>: > Hi > > 1. (questionable because it changes the visible interface): rename > `left_open` and `right_open` to `right_closed` and `left_closed`. > > Reason: interval_bounds is used in bitwise operations with bit=1 means > `closed`. (1) I tried to consider common usage of naming of intervals that is known from math. There seems to tendency to assume closedness as default, while openness is indicated by naming: [x, y] an interval (also closed interval) [x, y) a right open interval (x, y] a left open interval (x, y) an open interval. (2) The bits are chosen so closedness is indicated by 1 and openness is indicated by 0 11 [x, y] an interval (also closed interval) 10 [x, y) a right open interval 01 (x, y] a left open interval 00 (x, y) an open interval. > `left_closed() | open()` resulting in `left_closed()` is more readable than > `right_open() | open()` resulting in `left_closed()`. > > Also, there are checkers `is_left_closed()` and `is_right_closed()` but not > for *_open ... again following common usage [see (1)]. > I had to use `class bounded_value` in my program (as in Icl details: > calculating lower and upper bound of interval separately, then constructing > the interval, bitwise or'ing bounds) > and I commented every usage of `right_open()` as `left closed` in order to > explain why I use `interval_bounds::right_open()` in constructing the left > `bounded_value` of the interval. > This resulted in the idea of renaming. > > Maybe making bit=1 mean `open` would be less painful for other users ? You see me inconsolable to hear that you are suffering pain from my library =( There is an concept "interval_bound" http://svn.boost.org/svn/boost/trunk/boost/icl/concept/interval_bounds.hpp that allows you to combine and-ing or-ing etc. of interval_bounds directly. I think that'll reduce your suffering, at least I hope so. Yes, it's missing from the docs. Would you create a ticket? BTW, you may locally extend the concepts in the way you desire and add functions according to you naming rational. > 2. define `contains(interval, elt)` as `!below(interval, elt) && > !above(interval, elt)` allowing the user to use `below()` and `above()`. > Sometimes it is useful. (3) Thanks for this suggestion. The design of the icl::interval's interface is done under the general requirement of minimality. The concept approach allows you always to add own function templates locally to the concept if you need them. > Anyway, all the versions of `contains()` are made of checking for both > bounds. If you found a suboptimal function implementation, please refer them specifically. I'd appreciate a suggestion for an optimization. You can also create a ticket. > 3. It would nice if the functions taking two intervals will have versions > taking an element as second argument. > I mean functions like `left_subtract`, `operator &`, etc. (I cannot tell all > the list at the moment) > Constructing temporary `close_interval` object in order only to pass it into > those functions is cheap with ints but would be expensive with > heap-allocated domains (blobs, strings, etc). This is worth considering. In my own use of intervals within the implementation of interval containers I never encountered the need for such functions ... yet they may be useful in other situations. What do others think? Best regards, Joachim -- Interval Container Library [Boost.Icl] http://www.joachim-faulhaber.de

2 2

[Iterator] Constness of transform_iterator's dereference operator
by Michel MORIN 24 May '11

24 May '11

(In the previous mail, "function call operator" should be "dereference operator". Sorry for this, I fix it and resend a mail.) A long-standing request that transform_iterator should use boost::result_of will be resolved in Boost 1.47. This is really nice news, but I have a concern related to this. In the new code, transform_iterator uses result_of<UnaryFunc(typename std::iterator_traits<Iterator>::reference)> to determine the return type of a functor. However, since transform_iterator's dereference operator is const, result_of<const UnaryFunc(typename std::iterator_traits<Iterator>::reference)> should be used instead. There is a patch for this fix in #5127: https://svn.boost.org/trac/boost/ticket/5127 Alternatively, to remove this inconsistency, we can strip the constness of transform_iterator's dereference operator by either A. Make UnaryFunc member data mutable as suggested in #4969: https://svn.boost.org/trac/boost/ticket/4969 or B. Add non-const overloads to - transform_iterator's dereference() function - iterator_core_access' dereference() function - iterator_facade's operator*() Patches for A (make_mutable.patch) and B (add_nonconst_overloads.patch) are attached in this mail. Comments? Regards, Michel

1 0

Re: [boost] [pre-review] Pimpl submission in the review queue
by Jeff Garland 24 May '11

24 May '11

Mostafa wrote: >> If you want to use the Code Collaborator site to examine the library, you must create an account. The good news is that there are other libraries there that you can review, too. If you wish to avoid creating an account, then you can follow the link on the review schedule to the code in the sandbox. > > Some may just want to follow a review without necessary participating in one. Requiring a user account discourages such activity, and in my opinion, creates an artificial barrier to further engagement between newcomers, or even existing Boost watchers, and Boost, even if it is a one-sided engagement. > > My thoughts, > > Mostafa This is all getting a bit ahead of my post-boostcon report on the library in a week review activities, but to answer this particular issue I'd say 1) you need a login to participate in the mailing list, 2) it's essential for spam prevention, and 3) data can be periodically put to the list to mitigate this issue. Below is a report (minor formatting tweaks) of the pimpl review generated from code collaborator. I think in all likelihood using one of the modern review tools is going to create a better environment overall. Jeff ************* Overview ID: 5 Status: Inspection Title: Pimpl idiom generalization. Creator: Vladimir Batov Created On: 2011-05-23 15:13 Finished On: 2011-05-24 11:55 Total Person Time: 01:27:06 Wall-Clock Time: 20:34:38 Total Reviewer Time: 00:46:00 LOC All Versions (Uploaded/Changed): 2997/0 LOC Final Versions (Uploaded/Changed): 2997/0 Document Pages (All): 0 Document Pages (Final): 0 Number of Defects: 16 Number of Comments: 8 ************* Overview: Support for value and pointer semantics. Support for boost::serialization. Support for separate -- interface and implementation -- class hierarchies (the Bridge pattern in GoF). Support for internal (implementation-only) run-time polymorphism (Non-Virtual Interface Idiom). Support for delegating constructors. Tutorial. Doxygen-generated docs. Linux and VS2008. ************* Participants Name Role Person-Hours Vladimir Batov Author 00:13:17 Robert Stewart Reviewer 00:46:00 Sean Chittenden Observer 00:06:13 ************* Defect Log ID Creator File Location Type Severity Text D22 Robert Stewart pimpl.hpp Line 25 Interface Major Names with two consecutive underscores are reserved for the implementation D23 Robert Stewart pimpl.hpp Line 25 Style Minor This macro name should start with "BOOST_PIMPL_" D24 Robert Stewart pimpl.hpp Line 54 Interface Minor pimpl<T>::xxxx_semantics is interesting, but xxxx_pimpl<T> is simpler and more direct. D25 Robert Stewart pimpl.hpp Line 157 Interface Major Names with double underscores are reserved for the implementation D26 Robert Stewart pimpl.hpp Line 158 Interface Major Names with double underscores are reserved for the implementation D27 Robert Stewart pimpl.hpp Line 159 Interface Major Names with double underscores are reserved for the implementation D28 Robert Stewart pimpl.hpp Line 160 Interface Major Names with double underscores are reserved for the implementation D29 Robert Stewart pimpl.hpp Line 244 Interface Major Names with double underscores are reserved for the implementation D30 Robert Stewart pimpl.hpp Line 49 Interface Minor What about Pimpl support for classes with a base class? Your design requires multiple inheritance. You could, instead, do the following: class Book : public value_pimpl<Book, Base> { }; template <class T, class Base = null_type> class value_pimpl : public Base { }; template <class T> class value_pimpl<T,null_type> { }; D31 Robert Stewart pimpl.hpp Line 291 Interface Minor This exposes too much of the implementation to the user. A construct() member function set, like the set of constructors your macro now generates, with perfect forwarding (and variadic support, when available), would be better. construct() can call the new operator and save the pointer, thereby hiding those details from the user. D32 Robert Stewart pimpl.hpp Line 57 Interface Minor This exposes the pseudo-smart pointer semantics. It shouldn't be public and it should probably be named "nil" rather than "null." The idea is that nil() returns an object with no implementation rather than a null pointer. D33 Robert Stewart pimpl-use-cases.html Line 346 Documentation Minor "It is not but not a 100% kosher" is nonsensical. Presumably, you mean something like, "This design has some problems." D35 Robert Stewart pimpl-use-cases.html Line 357 Documentation Minor s/nut shell/nutshell/ D36 Robert Stewart pimpl-use-cases.html Line 364 Documentation Minor s/More,/What's more,/ D37 Robert Stewart pimpl-use-cases.html Line 385 Documentation Minor s/for vast majority/for the vast majority/ D38 Robert Stewart pimpl-use-cases.html Line 386 Documentation Minor You can avoid the subsequent "he/she" awkwardness by rephrasing this sentence: "However, putting both <i>book1</i> and <i>book2</i> in a <i>std::set</i> results in two elements rather than one, despite the fact that they are supposed to represent the same <i>Book</i>." Overall Review Conversation Sean Chittenden I've been using Boost.Pimpl for almost a year now with great success (using it in conjunction with MSM, ASIO and Spirit). This has been an incredibly useful library for minimizing the interfaces exposed across components. There are three things that I'd like to see but are largely trivial: 1) a set of clean-room examples of the two implementations (i.e. split out the unit tests from a set of examples for pointer and value semantics), and an example of how to use Pimpl once it has been moved in to the boost namespace (I took a crack at this and was never successful at moving Pimpl in to the boost namespace).

1 0

Implicit cast rules
by Gregory Crosswhite 24 May '11

24 May '11

Hey everyone, Would someone please explain to me the implicit cast rule that prevents the following from compiling, and/or if there is a way around it? #include <boost/optional.hpp> #include <iostream> using namespace boost; using namespace std; struct C { operator optional<int>() { return none; } }; int main() { C c; cout << static_cast<optional<int> >(c) << endl; return 0; } Error message: In file included from /usr/include/boost/optional.hpp:15, from cast-to-optional.cpp:1: /usr/include/boost/optional/optional.hpp: In member function ‘void boost::optional_detail::optional_base<T>::construct(const Expr&, const void*) [with Expr = C, T = int]’: /usr/include/boost/optional/optional.hpp:262: instantiated from ‘boost::optional_detail::optional_base<T>::optional_base(const Expr&, const Expr*) [with Expr = C, T = int]’ /usr/include/boost/optional/optional.hpp:559: instantiated from ‘boost::optional<T>::optional(const Expr&) [with Expr = C, T = int]’ cast-to-optional.cpp:13: instantiated from here /usr/include/boost/optional/optional.hpp:392: error: cannot convert ‘const C’ to ‘int’ in initialization I can tell what is happening; it would seem that the implicit cast rule selects the optional() constructor before it even looks at my more specific cast operator. I'm just confused about why this should be, since I see no reason why constructor casts should be prioritized over operator casts. Is this just the way it is, a GCC quirk, something I'm doing wrong, etc? Thanks! Greg

5 4

Towards a plan to reduce active tickets
by Vicente BOTET 24 May '11

24 May '11

Hi, I've inspected the number of tickets since the las Bug Sprint and we ca see that we are having a mean of 18 additional active tickets each month. month created closed diff 01/05/10 99 107 8 01/06/10 122 316 194 // Bug Sprint 01/07/10 103 56 -47 01/08/10 115 120 5 01/09/10 85 34 -51 01/10/10 105 91 -14 01/11/10 109 80 -29 01/12/10 83 92 9 01/01/11 98 79 -19 01/02/11 98 71 -27 01/03/11 161 107 -54 01/04/11 105 145 40 MEAN 106,2 87,5 -18,7 * MEAN is calculated since the last Bug Sprint, that is for the last 10 months. I don't know what could be done to instead of having more active tickets each month having less. While the Bug Sprints are useful I think that we need to have a plan to reduce them is a regular way. I know that a lot of people would be at BoostCon. It would be great if this subject could be discussed in one of the general sessions. if you have any suggestion, please replay to this post and share your view with the Boost community. Best, Vicente

7 7

[Iterator] Constness of transform_iterator's function call operator
by Michel MORIN 24 May '11

24 May '11

A long-standing request that transform_iterator should use boost::result_of will be resolved in Boost 1.47. This is really nice news, but I have a concern related to this. In the new code, transform_iterator uses result_of<UnaryFunc(typename std::iterator_traits<Iterator>::reference)> to determine the return type of a functor. However, since transform_iterator's function call operator is const, result_of<const UnaryFunc(typename std::iterator_traits<Iterator>::reference)> should be used instead. There is a patch for this fix in #5127: https://svn.boost.org/trac/boost/ticket/5127 Alternatively, to remove this inconsistency, we can strip the constness of transform_iterator's function call operator by either A. Make UnaryFunc member data mutable as suggested in #4969: https://svn.boost.org/trac/boost/ticket/4969 or B. Add non-const overloads to - transform_iterator's dereference - iterator_core_access' dereference - iterator_facade's operator() Patches for A (make_mutable.patch) and B (add_nonconst_overloads.patch) are attached in this mail. Comments? Regards, Michel

1 0

BoostCon 2011 in German IT news
by Boris Schaeling 24 May '11

24 May '11

I got BoostCon 2011 into the German IT news on http://www.heise.de/developer/artikel/developer_artikel_1247894.html. If someone wants to contact IT websites in other countries (after all as a C++ developer I want to read about things like BoostCon), have a look at the article. This should give you an idea how you could get in contact with websites and provide them the kind of news they want to publish. As the conference ended last week, it maybe makes sense to send out "press articles" again when the videos of the presentations are online. Boris

3 2

How to determine if a function with a given signature is declared?
by andrew.beck＠astc-design.com 24 May '11

24 May '11

Hi, Newbie question follows... I've used BOOST_MPL_HAS_XXX_TRAIT_DEF in the past but recently needed to determine if a function was defined with a given signature. Searching boost::mpl, stackoverflow etc, I couldn't find anything to do what I needed. I've attached my solution below. Basically, I'm wondering if there is a boost::mpl solution or some other more elegant solution. thanks, andrew #include <boost/mpl/bool.hpp> #include <boost/mpl/assert.hpp> #define XXX_DEFINED(symbol) \ template <typename T, T* = symbol> \ struct check_ ## symbol \ { \ typedef void type; \ }; \ \ template <typename T, typename enable = void> \ struct symbol ## _defined : \ boost::mpl::false_ \ { }; \ \ template <typename T> \ struct symbol ## _defined<T, typename check_ ## symbol<T>::type > : \ boost::mpl::true_ \ { }; // declare a some_func(int) so we can see if its declared... void some_func(int) {} // defines some_func_defined template XXX_DEFINED(some_func); BOOST_MPL_ASSERT(( some_func_defined<void(int)> )); // some_func(double) hasn't been declared BOOST_MPL_ASSERT_NOT(( some_func_defined<void(double)> ));

5 7

[function] Problem copying when constructed with a functor
by Edward Diener 24 May '11

24 May '11

This simple code: #include <boost/detail/lightweight_test.hpp> #include <boost/function.hpp> struct p_functor_class_int { p_functor_class_int() : data(50) { } int operator()() const { return data; } void operator()(int d) { data = d; } int data; }; int main() { boost::function<int ()> bfun(p_functor_class_int()); boost::function<int ()> bfun2(bfun); return boost::report_errors(); } gives compiler errors. On gcc-4.6 I get: "In file included from C:\Programming\VersionControl\boost/boost/function/detail/maybe_include.hpp:13:0, from C:\Programming\VersionControl\boost/boost/function/detail/function_iterate.hpp:14, from C:\Programming\VersionControl\boost/boost/preprocessor/iteration/detail/iter/forward1.hpp:47, from C:\Programming\VersionControl\boost/boost/function.hpp:64, from test_function_bug.cpp:2: C:\Programming\VersionControl\boost/boost/function/function_template.hpp: In static member function 'static R boost::detail::function::function_invoker0<FunctionPtr, R>::invoke(boost::detail::function::function_buffer&) [with FunctionPtr = boost::function<int()> (*)(p_functor_class_int (*)()), R = int]': C:\Programming\VersionControl\boost/boost/function/function_template.hpp:907:60: instantiated from 'void boost::function0<R>::assign_to(Functor) [with Functor = boost::function<int()> (*)(p_functor_class_int (*)()), R = int]' C:\Programming\VersionControl\boost/boost/function/function_template.hpp:722:7: instantiated from 'boost::function0<R>::function0(Functor, typename boost::enable_if_c<boost::type_traits::ice_not<boost::is_integral<Functor>::value>::value, int>::type) [with Functor = boost::function<int()> (*)(p_functor_class_int (*)()), R = int, typename boost::enable_if_c<boost::type_traits::ice_not<boost::is_integral<Functor>::value>::value, int>::type = int]' C:\Programming\VersionControl\boost/boost/function/function_template.hpp:1042:16: instantiated from 'boost::function<R()>::function(Functor, typename boost::enable_if_c<boost::type_traits::ice_not<boost::is_integral<Functor>::value>::value, int>::type) [with Functor = boost::function<int()> (*)(p_functor_class_int (*)()), R = int, typename boost::enable_if_c<boost::type_traits::ice_not<boost::is_integral<Functor>::value>::value, int>::type = int]' test_function_bug.cpp:15:37: instantiated from here C:\Programming\VersionControl\boost/boost/function/function_template.hpp:95:39: error: too few arguments to function C:\Programming\VersionControl\boost/boost/function/function_template.hpp:96:9: warning: control reaches end of non-void function [-Wreturn-type] " I am sure I must be doing something wrong but I can not see it.

3 5

Review Wizard Report for May 2011
by Ronald Garcia 23 May '11

23 May '11

============================================== Review Wizard Status Report for May 2011 ============================================== News ==== 1. Process Library Rejected 2. Phoenix Library Accepted 3. XInt Library Rejected 4. Type Traits Extensions Accepted 5. Locale Library Accepted 6. Convert Library Withdrawn 7. Conversion Library Accepted Provisionally 8. Context Library Accepted Provisionally 9. Boost 1.46.1 Released Revised Libraries: Asio, Filesystem, Fusion, Graph, ICL, Math, Polygon, Proto, Property Tree, Signals2, TR1, Unordered Revised Tools: Quickbook Open Issues =========== The following libraries have been reviewed and await reports from their review managers: * AutoIndex(Tool) - reviewed May 2011; review manager: Daniel James. The following libraries have been accepted to Boost, but have not yet been submitted to SVN: * GIL.IO - accepted January 2011; author: Christian Henning. * Type Traits Extensions - accepted March 2011; author: Frederic Bron. The following libraries have been accepted and submitted to SVN, but have not yet appeared in a release: * Phoenix - accepted March 2011; author: Joel de Guzmann. * Move - accepted February 2011; author: Ion Gaztanaga. * Geometry Library - accepted November 2009; author: Barend Gehreis et al. * Ratio - accepted October 2010; author: Vicente Botet. * Chrono - accepted January 2011; author: Vicente Botet. The following libraries have been accepted provisionally to Boost, but have not been submitted for mini-review and full acceptance: * Switch - accepted provisionally January 2008; author: Steven Watanabe. * Log - accepted provisionally March 2010; author: Andrey Semashev. * Context - accepted provisionally May 2011; author: Oliver Kowalke. General Announcements ===================== As always, we need experienced review managers. The review schedule has grown substantially but we have few volunteers, so manage reviews if possible and if not please make sure to watch the review schedule and participate. Please take a look at the list of libraries in need of managers and check out their descriptions. In general review managers are active boost participants, including library contributors, infrastructure contributors, and other mailing list participants with a substantial track record of constructive participation. If you can serve as review manager for any of them, email Ron Garcia or John Phillips, "rxg at cs dot cmu dot edu" and "phillips at pacific dot mps dot ohio-state dot edu" respectively. We are also suffering from a lack of reviewers. While we all understand time pressures and the need to complete paying work, the strength of Boost is based on the detailed and informed reviews submitted by you. If you are interested in reviewing a library but won't have time during the review period, you can always prepare your review ahead of time. No rule says you can only work on a review during the review period. A link to this report will be posted to www.boost.org. If you would like us to make any modifications or additions to this report before we do that, please email Ron or John. The review schedule is an unordered list of the libraries awaiting review. As such, any library on the schedule can be reviewed once the developer is ready, a review manager has been secured, and the manager, developer, and wizards agree on a date to schedule the review. Review Schedule =============== * Join (M) * Pimpl (M) * Endian * Conversion * Sorting (M) * AutoBuffer * Containers * Lockfree * Fiber (M) * Quaternions, Vectors, Matrices (M) * Stopwatches * Variadic Macro Data (M) * Type Traits Introspection * Block Pointer (M) * Heaps * Assign v2 * Network (M) * Algorithm * Local (M) ``(M)`` marks libraries that need review managers. -------------------- Join ---- :Author: Yigong Liu :Review Manager: Needed :Download: http://channel.sourceforge.net/ :Description: Join is an asynchronous, message based C++ concurrency library based on join calculus. It is applicable both to multi-threaded applications and to the orchestration of asynchronous, event-based applications. It follows Comega's design and implementation and builds with Boost facilities. It provides a high level concurrency API with asynchronous methods, synchronous methods, and chords which are "join-patterns" defining the synchronization, asynchrony, and concurrency. Pimpl ----- :Author: Vladimir Batov :Review Manager: Needed :Download: | `Boost Vault <http://www.boost-consulting.com/vault/index.php?action=downloadfile&fil…>`__ | http://www.ddj.com/cpp/205918714 (documentation) :Description: The Pimpl idiom is a simple yet robust technique to minimize coupling via the separation of interface and implementation and then implementation hiding. This library provides a convenient yet flexible and generic deployment technique for the Pimpl idiom. It's seemingly complete and broadly applicable, yet minimal, simple and pleasant to use. Endian ------ :Author: Beman Dawes :Review Manager: Joel Falcou :Download: http://svn.boost.org/svn/boost/sandbox/endian/ :Description: Conversion ---------- :Author: Vicente Botet :Review Manager: Gordon Woodhull :Download: `Boost Vault <http://www.boostpro.com/vault/index.php?action=downloadfile&filename=co…>`__ :Description: Generic explicit conversion between unrelated types. Boost.Conversion provides: * a generic ``convert_to`` function which can be specialized by the user to make explicit conversion between unrelated types. * a generic ``assign_to`` function which can be specialized by the user to make explicit assignation between unrelated types. * conversion between ``std::complex`` of explicitly convertible types. * conversion between ``std::pair`` of explicitly convertible types. * conversion between ``boost::optional`` of explicitly convertible types. * conversion between ``boost::rational`` of explicitly convertible types. * conversion between ``boost::interval`` of explicitly convertible types. * conversion between ``boost::chrono::time_point`` and ``boost::ptime``. * conversion between ``boost::chrono::duration`` and ``boost::time_duration``. Sorting ------- :Author: Steven Ross :Review Manager: Needed :Download: `Boost Vault <http://www.boostpro.com/vault/index.php?action=downloadfile&filename=al…>`__ :Description: A grouping of 3 templated hybrid radix/comparison-based sorting algorithms that provide superior worst-case and average-case performance to std::sort: integer_sort, which sorts fixed-size data types that support a rightshift (default of >>) and a comparison (default of <) operator. float_sort, which sorts standard floating-point numbers by safely casting them to integers. string_sort, which sorts variable-length data types, and is optimized for 8-bit character strings. All 3 algorithms have O(n(k/s + s)) runtime where k is the number of bits in the data type and s is a constant, and limited memory overhead (in the kB for realistic inputs). In testing, integer_sort varies from 35% faster to 2X as fast as std::sort, depending on processor, compiler optimizations, and data distribution. float_sort is roughly 70% faster than std::sort. string_sort is roughly 2X as fast as std::sort. AutoBuffer ---------- :Author: Thorsten Ottosen :Review Manager: Robert Stewart :Download: http://www.cs.aau.dk/~nesotto/boost/auto_buffer.zip :Description: Boost.AutoBuffer provides a container for efficient dynamic, local buffers. Furthermore, the container may be used as an alternative to std::vector, offering greater flexibility and sometimes better performance. Containers ---------- :Author: Ion Gaztanaga :Review Manager: John Maddock :Download: `Boost Vault <http://www.boostpro.com/vault/index.php?action=downloadfile&filename=bo…>`__ :Documentation: `Boost Sandbox <http://svn.boost.org/svn/boost/sandbox/move/libs/container/doc/html/index.h…>`__ :Description: Boost.Container library implements several well-known containers, including STL containers. The aim of the library is to offers advanced features not present in standard containers or to offer the latest standard draft features for compilers that comply with C++03. Lockfree ------------------ :Author: Tim Blechmann :Review Manager: Hartmut Kaiser :Download: `Boost Vault <http://www.boostpro.com/vault/index.php?action=downloadfile&filename=bo…>`__ :Documentation: http://tim.klingt.org/boost_lockfree/ :Description: Lockfree provides implementations of lock-free data structures. Lock-free data structures can be accessed by multiple threads without the necessity of blocking synchronization primitives such as guards. Lock-free data structures can be used in real-time systems, where blocking algorithms may lead to high worst-case execution times, to avoid priority inversion, or to increase the scalability for multi-processor machines. Lockfree provides: * boost::lockfree::fifo, a lock-free fifo queue * boost::lockfree::stack, a lock-free stack Fiber ----- :Author: Oliver Kowalke :Review Manager: Needed :Download: `Boost Vault <http://www.boostpro.com/vault/index.php?action=downloadfile&filename=bo…>`__ :Description: C++ Library for launching fibers (micro-threads) and synchronizing data between the fibers. Quaternions, Vectors, Matrices ------------------------------ :Author: Emil Dotchevski :Review Manager: Needed :Download: http://www.revergestudios.com/boost-qvm/ :Description: QVM defines a set of generic functions and operator overloads for working with quaternions, vectors and matrices of static size. The library also defines vector and matrix data types, however it allows users to introduce their own types by specializing the q_traits, v_traits and m_traits templates. Stopwatches ----------- :Author: Vicente Botet :Review Manager: Anthony Williams :Download: `Boost Vault <http://www.boostpro.com/vault/index.php?action=downloadfile&filename=st…>`__ :Description: On top of the standard facilities of Boost.Chrono, Stopwatches provides: * Stopwatches: A facility to measure elapsed time with the ability to start, stop, suspend, or resume measurement. * Stopwatch concept * Scoped helper classes allowing to pairwise start/stop operations, suspend/resume and resume/suspend a Stopwatch. * stopwatch, model of Stopwatch capturing elapsed Clock times. * stopwatch_accumulator, model of Stopwatch capturing accumulated elapsed Clock times. * Stopclocks: a complete time reporting package that can be invoked in a single line of code. * stopwatch_reporter, convenient reporting to an output stream (including wide char streams) of the elapsed time of models of Stopwatch results. * stopclock<Clock> shortcut of stopwatch_reporter<stopwatch<Clock>> Variadic Macro Data ------------------- :Author: Edward Diener :Review Manager: Needed :Download: `Boost Sandbox <http://svn.boost.org/svn/boost/sandbox/variadic_macro_data/>`__ :Description: The variadic_macro_data library adds support and functionality for variadic macros to Boost as well as integrating variadic macros with the Boost PP library without changing the latter library in any way. Type Traits Introspection ------------------------- :Author: Edward Diener :Review Manager: Joel Falcou :Download: `Boost Sandbox <http://svn.boost.org/svn/boost/sandbox/tti/>`__ :Description: The TTI library, which is an abbreviation for the 'Type Traits Introspection' library, allows a programmer to introspect at compile time the inner elements of a C++ type. The introspection process depends on specifying the name of the inner element by different macros for different types of elements, and then using a generated metafunction to determine whether that element exists within the enclosing type. The inner elements which can be introspected are type, class template, member data, member function, static member data, and static member function. Block Pointer ------------- :Author: Phil Bouchard :Review Manager: Needed :Download: `Boost Sandbox <https://svn.boost.org/svn/boost/sandbox/block_ptr/>`__ :Description: Deterministic memory manager of constant complexity capable of handling cyclic collections. Heaps ----- :Author: Tim Blechmann :Review Manager: Andrew Sutton :Download: http://tim.klingt.org/git?p=boost_heap.git;a=snapshot;h=HEAD;sf=tgz :Description: The Heap library is an implementation of priority queues, data structures that order their elements priority. They are useful in a number of different applications especially graph search algorithms and queuing systems. Whereas the STL provides a class template std::priority_queue, Boost.Heap implements data structures with different features and performance characteristics. One key feature is the inclusion of "mutable" heaps, which allow the priorities of enqueued objects to modified and their position in the queue updated. The heaps in the library also support merging, stable sorting, and equality and less-than comparison. Assign v2 --------- :Author: Erwann Rogard :Review Manager: John Bytheway :Download: `Boost Sandbox <http://svn.boost.org/svn/boost/sandbox/assign_v2>`__ :Description: This library is an upgrade of Boost.Assign 1.0 that redefines its functionality, with optional C++0x support and new features. It expresses repetitive statements for assigning or inserting elements via a basic grammar. Network ------- :Author: Dean Michael Berris :Review Manager: Needed :Download: http://cplusplus-soup.com/2011/04/18/cpp-netlib-0-9-0-released/ :Description: This is a library that provides application layer protocol support using modern C++ techniques. It is light-weight, fast, cross-platform and is intended to be as easy to configure as possible. Algorithm --------- :Author: Marshall Clow :Review Manager: Dave Abrahams :Download: `Boost Sandbox Vault <http://www.boostpro.com/vault/index.php?action=downloadfile&filename=Boost.…>`__ :Description: Boost.Algorithm is a collection of general purpose algorithms. While Boost contains many libraries of data structures, there is no single library for general purpose algorithms. Even though the algorithms are generally useful, many tend to be thought of as "too small" for Boost. An implementation of Boyer-Moore searching, for example, might take a developer a week or so to implement, including test cases and documentation. However, scheduling a review to include that code into Boost might take several months, and run into resistance because "it is too small". Nevertheless, a library of tested, reviewed, documented algorithms can make the developer's life much easier, and that is the purpose of this library. Local ----- :Author: Lorenzo Caminiti :Review Manager: Needed :Download: `Boost Sandbox <http://svn.boost.org/svn/boost/sandbox/local/>`__ :Description: This library supports local functions, local blocks, and local exits Libraries under development =========================== See http://svn.boost.org/trac/boost/wiki/LibrariesUnderConstruction for a current listing of libraries under development.

3 3

[exception] warnings on top of trunk
by Bryce Lelbach 23 May '11

23 May '11

/opt/boost/trunk/stage/gcc-4.4.4-release/include/boost/exception/detail/exception_ptr.hpp: In function ‘void boost::rethrow_exception(const boost::exception_ptr&)’: /opt/boost/trunk/stage/gcc-4.4.4-release/include/boost/exception/detail/exception_ptr.hpp:458: warning: ‘noreturn’ function does return Is it cool for me to remove this attribute? -- Bryce Lelbach aka wash boost-spirit.com px.cct.lsu.edu github.com/lll-project

5 5

[Review] Type Traits Extension by Frederic Bron - Review summary and decision
by Joel Falcou 23 May '11

23 May '11

Hello all, Frederic Bron's type traits extension proposal review ended up last week. In so far, we received SEVEN reviews which are all voting YES for the inclusion of Type Traits extension in Boost. So the result is that the Type Traits Extension is ACCEPTED into Boost. Suggestions include: - some clean-up in the implementation like "Renam[ing] the detail classes inside the specific namespace without using number, i.e. with a clear meaning. The use of tag, tag 2 could be renamed check_pass, check_fail or something like that." - Sensibility on cv-ref qualifiers in traits call is important. This is being addressed by Frederic. - Frederic is OK to keep the detection of void as a valid return type by using some dont_check type as default. - small comprehensive example of some of the traits like a "maybe_print function, which prints a value if the appropriate operator<< ostream overload exists, else prints "<NOT PRINTABLE>". [...] a small example like this would show a practical use of the library, and how to make use of enable_if, or some other overload method." - The main recurring suggestions found was the choice of name for the operator traits with respect to the standard naming, naming in proto and other boost libraries. This topic is still hot and alive. An alternative to the naming scheme consensus was proposed in the form of alias of commonly used operator traits. This issue is I think beyond bikeshed-color argumentation and I think it is a good point if Frederic could step up and provide a definite and rationalized answer to this point. The current status is : * the namespace options is out casue the standard didnt choose this way; * Frederic and a few other seems to favor the proto naming scheme (more or less the negate issue and the pre/post operator) * the question of a common prefix is still open * the std:: like naming seems limited as not all operators are there. Thanks to all reviewers and people participating to the discussions. Thanks to Frederic for his work.

18 67

Small nitpick in boost::iterator
by Joel Falcou 23 May '11

23 May '11

Seems boost.Iterator pass some parameter by value in the make(Reference r) function. However, MSVC 2010 and I suspect below dont like passing value which alignment is greater than 8 ( **cough** SIMD vector **cough** ) The fix is trivial, adding const & to this function. Should I go ahead and commit this to trunk ?

4 4

[pool] pool-based allocators and order of destruction
by John Maddock 23 May '11

23 May '11

I'm looking for second opinions on this bug report: https://svn.boost.org/trac/boost/ticket/5526#comment:1 The issue is this: if you use singleton_pool either directly or indirectly (via [fast_]pool_allocator), there is a potential order-of-destruction issue if you use it from within globally declared objects. I *think* it's OK, if the global object directly uses the singleton pool - or is it? But, things get really nasty if it's used indirectly as in the bug report via a thread_specific_ptr - the latter gets destructed very late - much later than the pool which is used by the object it points to, so the result is a program crash on exit. In general though, anything that uses indirection and "late initialization, late destruction" will cause problems. I see a number of solutions: * Document the limitation and leave it at that. * Make the singleton eternal and leak the pool's memory at program exit. * Use some kind of complex reference counting scheme so the pool is only destroyed when all it's memory has been released *and* main has exited. To be honest, I'm not thrilled by any of the above, but any opinions? Thanks in advance, John.

3 3

Boost.Log status
by Vicente BOTET 23 May '11

23 May '11

Hi, what is going on Boost.Log? The library was accepted provisionally on March 2010 * Log - accepted provisionally March 2010; author: Andrey Semashev. Best, Vicente

7 18

[review][autoindex] AutoIndex review ends tomorrow
by Daniel James 23 May '11

23 May '11

Hello everyone, Just a quick reminder that Saturday 21st May is the final day for the AutoIndex review. I'm going to wait for one final review before announcing the result, but other than that you need to contact me by then. thanks, Daniel James AutoIndex Review Manager

2 3

Re: [boost] [ICL] some improvement proposals
by Joachim Faulhaber 23 May '11

23 May '11

2011/5/23 Denis <denis(a)camfex.cz>: > Hi Joachim. > I think, I explained badly and unclear the issue about contains(). > If you will have look at its implementation, you will find there a few > specialized versions of contains(), but all of them have structure of > handmadely inlined code `!below(interval, elt) && !above(interval, elt)`. So > it looks like those two functions are part of the minimal set, and > contains() made on top of them. I propose to have there the specialized > below() and above() and the general implementation of contains(). I understand. That would be a good refactoring making the code smaller and more concise. Good proposal :) Cheers, Joachim -- Interval Container Library [Boost.Icl] http://www.joachim-faulhaber.de

1 0

Fwd: [Boost-users] condensed overview of boost
by Joachim Faulhaber 23 May '11

23 May '11

---------- Forwarded message ---------- From: Joachim Faulhaber <afojgo(a)googlemail.com> Date: 2011/5/23 Subject: Re: [boost][Boost-users] condensed overview of boost To: boost(a)lists.org, boost-users(a)lists.boost.org Hi Olaf, Hallo Dresden, 2011/5/12 Olaf Krzikalla <olaf.krzikalla(a)tu-dresden.de>: > Hi @boost, > > recently I've given some lectures about some selected boost libraries. Thank you for teaching boost! (boo to the community for not answering for so long ;) > After > that the audience expressed the wish to get an overview over all current > boost libraries. Thus for my next lecture I sat down and digged through the > complete 1.46 for several day. I found a lot of useful stuff, but I also > found a lot of obsolete, superseded, replaced or will-be-superseded stuff. > Some libraries seems to be sub-libs of other libs. Is there an overview of > inner lib relations and the actual lib state wrt. to the overall > development? There is an overview on the boost web-site www.boost.org of course in an synoptic quality with short descriptions of each library. As far as I know there is no single documentation on inter library relationships that is maintained, correct me if I'm wrong. Generated dependency graphs were provided by Chrisoph Heindl in December 2008. http://lists.boost.org/Archives/boost/2008/12/146290.php http://picasaweb.google.com/christoph.heindl/BoostDependencies1370 for boost-1.37 but not updated later. > The issues I've found so far: > > - Compatibility: very narrow. Is it still needed as a public lib? > - Functional, MemFun: superseded by Bind > - Call Traits, Functional/Forward, Lambda: will be superseded by C++0x > - Interval: can this become a sub-lib of ICL? boost::numeric::interval is closed interval on numeric types with a focus on interval arithmetic. It is also suitable handle numeric precision problems AFAIK, but I'm not an expert for that. In contrast ICL has a focus on the set character of intervals and their composition in interval containers. Non numeric intervals are possible as long as there is an ordering on the domain_type. I think it is unfortunate that ICL and numeric::interval do not interplay well. One of the main obstacle are the fixed closed borders of numeric::intervals, that lead to problems when adding or subtracting intervals to and from interval containers. There were discussions on this on the list but the authors of numeric::interval seemed not to be active at the time. Since numeric::intervals serve numeric purposes and icl::interval serve more general pusposes I think they can coexist happiely. As long a numeric::interval is not actively maintained, I don't think there is a chanche for change. > - Meta State Machine / Statechart: whats the actual difference? I.e. Meta State Machine is a library that generates finite state machines completely at compile-time from meta code. MSN is more expensive at compile time but may generate even faster code than a "traditional" FSM. Maybe Christophe can comment on this. > which problem is solved by one lib but not by the other? > - Fusion & Tuple: how are these related? Could boost::tuple become a > typedef to boost::fusion::vector. > > I know that most of these relations are there for historical reasons and > won't be changed. However I wish it had been documented somewhere. That > would make an in-depth introduction of boost a lot easier. There is no ready made structure or institution within boost for this. But definitely there are people who have similar thoughts, concerns and intentions. It depends if someone is going to contribute and/or is taking the lead for an effort like this. As mentioned above Chrisoph Heindl provided generated dependency graphs. Boris Schäling wrote an online book http://www.highscore.de/cpp/boost/index.html that has been translated by others. Paul Bristow cares on documentation quality for the math stuff. Robert Ramey, Dean Berris and others had initiatives about redesigning the boost web-site, just to mention a few things. So your effort on creating an overview and document on inter library relationships could be an own contribution and other could join in. Thanks again, Joachim -- Interval Container Library [Boost.Icl] http://www.joachim-faulhaber.de

1 0

[ICL] interval_map::find(const domain_type_comparable&) instead of interval_map::find(const domain_type&)
by Denis 23 May '11

23 May '11

Hi Joachim One small note about Icl maps. I think would be useful to make interval_map::find()'s function accept any type comparable to map's key. For example, the key type is std::string and the user want to search using a 0-terminated string or a string defined as arbitrary pointer and a length. Then the user will have to allocate the temporary string only to pass it to interval_map::find() You may argue that the std::map works same way. But there is the difference. If I want to do the trick above, I can use boost::multi_index or at least instead of std::map<std::string, ValueT> I can define something like std::map<tuple<const char*, size_t>, tuple<std::string, ValueT>> with key's const char* and size_t pointing to the data hosted in value. This is not possible with interval_map, where the values can be joined

3 3