May 2009 - Boost - lists.boost.org

[interprocess][circular_buffer] specialized containers should have container template argument
by Thorsten Ottosen 05 May '09

05 May '09

Hi Ion and Jan, I often use these containers: flat_set, flat_map and circular_buffer. They are great. However, we can make them faster if you allow a new template argument. For example template < class T, class Alloc, class Buffer = /* some default */ > class circular_buffer; template < typename T, typename Pred, typename Alloc class PushBackContainer = /* some default */ > class flat_set; My motivation is that these can perform somewhat better e.g. with an array (for circular_buffer), or auto_buffer (for flat_set/flat_map). I think even some very simply array wrapper would be useable with flat_set. The EA STL implementation has this features. What do you think? -Thorsten

4 5

Re: [boost] The noexcept Specifier & Block
by Anders Dalvander 04 May '09

04 May '09

Posted the following to std.lang.c++, cross-posting here, mostly directed to David Abrahams: After reading N2855 - Rvalue References and Exception Safety (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2855.html) I'm still not confident that a new keyword `noexcept` would be optimal. Especially when the proposal combines this new keyword with a somewhat enhanced version of the already existing exception specification `throw(...)` to explicitly indicate that a move constructor or a destructor may throw exceptions. And at the same time propose to deprecate exception specifications altogether. I think that it would be better to use a simplified exception specification: - `throw()` to indicate that a function does not throw any exception, which is statically checked by the compiler. This would behave as `noexcept` in the N2855 proposal. - `throw(...)` to indicate that a function may throw any exception. Main use for throwing move constructors and throwing destructors. - Any other exception specification would be ill-formed and thus would require a compiler diagnostic. Update the new exception specification to behave as `noexcept` in N2855, where needed. Unfortunately I don't have a really good idea to implement something similar to the `noexcept` block as described in N2855. Perhaps a `try` block without a `catch` handler, perhaps someone else has a better idea? double sqrt(double); // may throw exceptions void f(double &x) throw() { if (x > 0) { x = sqrt(x); // ill-formed: sqrt(x) might throw an exception! } } void g(double &x) throw() { if (x > 0) { try { x = sqrt(x); } // okay: if sqrt(x) throws, invokes undefined behavior } } Rationale: - Exception specification as of C++98/C++03 are considered broken and discouraged. No need to deprecate, remove it entirely. - `throw()` is already used by a lot of libraries, for example boost, to indicate nothrow functions. With this proposal these functions would behave as `noexcept` with no change. - No new keywords are needed. Remove the following: exception-specification: throw ( [type-id-list]opt ) type-id-list: type-id type-id-list , type-id Add the following: no-throw-exception-specification: throw ( ) any-throw-exception-specification: throw ( ... ) What do you think? Regards, Anders Dalvander

1 0

[Review Results] Range.Ex library accepted into boost
by Thorsten Ottosen 04 May '09

04 May '09

Dear all, It is my pleasure that Neil Groves' RangeEx library has been accepted into boost. Congratulations Neil! There are quite a number of minor issues that need to be resolved before the library is release ready, see below for a summary. Review statistics ----------------- Full Reviews: 8. Discussion: extensive. I had the clear impression that everybody that participated in the discussion were in favor of this library, albeit they did not have time to submit a full review. I did not hear a single statement saying that this library should be rejected. Thanks to everybody that participated in the review and its discussions. Issue Summary ------------- Below is given a list of topics that must be adressed before the library can be included into boost. In general, we should try to discuss them one at a time in seperate threads. Many people suggested various extensions, new algorithms (e.g. from adope), etc. **In general we should not require Neil to add all these if he does not have the time currently: the basic infrastructure, the concepts, the naming and organization of the library is much more important. Then we can add all these things later.** 1: documentaion =============== The documentation should clearly reflect if an algorithm delegates to a standard algorithm. If the algorithm is new, then it should state complety and exception-safety. More examples would be welcome. Sometimes the rationale and explanations could be improved, e.g for operator|(). 2: return type specification for find() etc =========================================== There where no major objection to the mechanism, but some found the syntax ugly. I believe the suggested syntax (e.g.) boost::find[_f,_e]( range, x ) boost::find[_f+1,_e]( range, x ) was considered good by most. 3: namespace organization ========================= Currently the library uses the namspaces boost boost::adaptors Some raised concern about putting the algorithms straight in the boost namespace before we have a general agreement on where to put algorithms (e.g. in boost::algorithm or boost::ranges or whatever). I think it will make sense to put each algorithm in its own header, since we might have to include additional standard library headers for calling algorithms that are implemented as member functions (but see 7 below). Feedback is most welcome. 4: naming convention for adaptors ================================= The following have been proposed throughout the review (here examplified with "transform"): | transformed( fun ) | transform( fun ) | transform_view( fun ) | view::transform( fun ) There where no consensus during the review. Other libraries seem to use the _view suffix, which is a strong argument for that candidate (in that case, I suggest to drop the adaptors namespace). 5: naming convention for the adaptor generators =============================================== Many people like to be able to say make_transform_range(r,fun) instead of r | transformed( fun ). There was no concensus on how to name these functions. Here are some candidates: make_transform_range( r, fun ) transformed( r, fun ) transform( r, fun ) (*) transform_view( r, fun ) (*) was dislike by some because it has exactly the same spelling as the algorithm transform. Many felt that the confusion is too big if view generators are not named different from the actual algorithms. 6: reintroducing _if variants of algorithms =========================================== An important problem with the suggested approach was the the iterator returned by an algorithm after applying | filtered( pref ) are now filtered iterators and so one needs to manually unwrap the return iterator. This provided enough justification for reintroducing these algorithms. (One could imagine that this unwrapping was done automatically by a conversion operator such that iterator i = boost::find( r | boost::filtered( pred ), x ); "just worked". However, the syntax is still slightly worse than just using the original algorithm). Generic programming is concerned with the use of orthogonal concepts which put together yields all possible combinations of algorithms. If we reintroduce all _if algorithms, we have to aks ourselves "when does it end?". Should all new algorithms then simply add _if variants? This seems very much against the spirit of generic programming. The problem with the iterators being changed (as in the find example) seems to suggest the following guideline: "If the algorithm returns an iterator, it makes sense to provide an _if overload. Otherwise it does not." Under this guideline, find_if() should be there, but count_if() should not be provided. 7: should algorithms call member function when possible? ======================================================== I heard one strong voice against this. The reason was that the algorithm implemented as member function often has quite different guarantees w.r.t. complexity, reference and iterator stabililty. I think this is a very strong argument. Also, we can add this later if good arguments appear, but it is much harder to take away. We also have to remember Scott Meyers item "Beware of container independent code" which also suggest that this is a bad idea. At the very menimum, the original algorithm and the member function should have similar semantics. This seems to suggest that we can call set::lower_bound() from boost::lower_bound(). In that case, the best way would probably be to add these as overloads in the boost namespace: template< class T, class A > typename std::set<T,A>::iterator lower_bound( std::set<T,A>& s ); template< class T, class A > typename std::set<T,A>::const_iterator lower_bound( const std::set<T,A>& s ); 8: making return values of algorithms consistent/intuitive ========================================================== For example, sort(r) returns the sorted range, but sort_heap(r) does not. Similar issues for partial_sort(). Please go through all algorithms to see if this done correctly. 9: output range concept? ========================= It appears that the only use for an output iterator in the library was for boost::copy(rng,iter), and the only use for that function was for "sinks" like std::ostream_iterator<T>(...). This seems to be the only safety hole left in the library. Here's an idea to how we might remove that: create a new "copy sink" concept: struct array_copy_sink { ... template< class Iterator > copy( Iterator begin, Iterator end ) { ... } }; Then we might imagine boost::copy( rng, boost::ostream_sink(std::cout) ); boost::copy( rng, boost::array_sink(an_array) ); boost::copy( rng, boost::ptr_sink(begin,end) ); boost::copy( rng, boost::front_insert_sink(a_deque) ); ... For optimal performance, we also need a "nonoverlapping copy sink" concept, and an algorithm that expects that sink (or that boost::copy() determines the type of the sink automatically). 10: automatic projection ======================= Adope has algorithms overloaded such that projection is very easy: struct my_type { int member; double another_member; }; //... my_type a[] = { { 1, 2.5 }, ... }; // sort the array by the first member: sort(a, less(), &my_type::member); my_type* i = lower_bound(a, 5, less(), &my_type::member); We should be able to express this well, albeit not as concise, with my_type* i = boost::lower_bound( a | project( &my_type::member ), 5, less() ); where project( ... ) could simply return a transform iterator constructed with boost::bind(). There is another problem, however, because now the return value is a tranform_iterator of some form. Appending .base() would solve it, albeit it is somewhat ugly. Again this might raise the question of an implicit conversion. I just want to say this is not a critical issue as we can always add these overloads. --- End of Issues ---- Again, I would like to thank everybody that participated in the review. best regards Thorsten, review manager

2 1

[signals2] documentation on signals vs signals2
by Ross Levine 04 May '09

04 May '09

Is there documentation on when signals2 should be used over signals? If there is any time that signals is a better choice than signals2? I presume either signals2 is incompatible with code written for signals, or signals2 is inferior to signals in some cases, but this is not documented anywhere.

2 1

[move] New version with move-aware containers library
by Ion Gaztañaga 03 May '09

03 May '09

Hi to all, Sorry for the delay, but finally I've found some time to uploaded a new version of Boost.Move: Sandbox: https://svn.boost.org/trac/boost/browser/sandbox/move ZIP file with docs: http://www.drivehq.com/web/igaztanaga/move.zip Online docs: http://www.drivehq.com/web/igaztanaga/libs/move/ Changes: -> Changed folder from boost/move_semantics to boost/move. -> I've extracted all the containers from Boost.Interprocess, put them in boost/container and they only depend on official Boost SVN code (I haven't tested it, but it should be also nice with Boost 1.38). There is no documentation for these containers. -> Fixed a bug with EDG-based compilers. -> Note: I haven't applied yet the patch for non-sfinae compilers. With this changes, I think move emulation is quite portable (at least MSVC, EDG and GCC). Now that containers are independent from Boost.Interprocess, I would like to ask about the next step. If the move library is added, where should we put those containers? I would like to just drop common (vector, list, ...) Boost.Interprocess containers and just maintain these move-aware ones. If move emulation is considered mature enough, we should also plan when could we port all custom move-emulations present in several boost libraries to the "official" move library. Best, Ion

8 20

[ANN] Boost 1.39.0
by Beman Dawes 03 May '09

03 May '09

Boost 1.39.0 is available for download from SourceForge. See http://sourceforge.net/project/showfiles.php?group_id=7586&package_id=8041&… New Libraries: Signals2. Updated Libraries: Asio, Flyweight, Foreach, Hash, Interprocess, Intrusive, Program.Options, Proto, PtrContainer, Range, Unordered, Xpressive. Updated Tools: Boostbook, Quickbook. Plus the usual bug fixes to numerous libraries. Please report any problems to the Boost users or developers mailing list. Thanks, --Beman Dawes, Daniel James, and all the other Boosters who help get releases out

2 1

[gil] Google analytics script tags
by Daniel James 02 May '09

02 May '09

Hi, If you've missed it, there was a recent thread about using google analytics in offline copies of boost and the consensus was firmly against them. The gil documentation includes the google analytics javascript but doesn't seem to use it. So I assumed that their inclusion was a mistake and went ahead and removed them on trunk. I hope that wasn't presumptuous. But I did this on the generated documentation as I couldn't work out how it is generated. It'd useful to have some brief instructions and any necessary files. Ideally we should be able to generate them with boost build but a manual doxygen call is fine. thanks, Daniel

3 4

[chrono] monotonic_clock ofr cygwin
by vicente.botet 02 May '09

02 May '09

Hi, The Boost.Chrono do not compiles on cygwin. The MONOTONIC_CLOCK is not available. I have just defined the monotonic_clock as system_clock and all works right. Attached the patch. Do you agree to commit it? Best, Vicente

2 1

Intentions of Boost.TR1
by David Abrahams 02 May '09

02 May '09

I just saw this post on comp.lang.c++.moderated. I wonder if the Boost.TR1 documentation shouldn't clarify its intended use or degree of conformity. I don't think TR1 conformity is something we have been paying much attention to, is it? -- Dave Abrahams BoostPro Computing http://www.boostpro.com

5 4

German Boost book updated
by Boris Schaeling 02 May '09

02 May '09

For those who know German: I've added five more chapters to my Boost book at http://www.highscore.de/cpp/boost/. There are now altogether 16 chapters covering 29 Boost libraries. The book does not try to replace the documentation but is written in a tutorial style to give developers a kick start. It explains what the numerous libraries are good for and how they are used without going too much into detail. Any feedback is, as always, appreciated! Boris

2 2