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

License on Interprocess Containers
by Hal Finkel 07 Apr '10

07 Apr '10

Hello, boost/interprocess/containers/container/vector.hpp contains the following in the license header (directly underneath the BSL header): ////////////////////////////////////////////////////////////////////////////// // // This file comes from SGI's stl_vector.h file. Modified by Ion Gaztanaga. // Renaming, isolating and porting to generic algorithms. Pointer typedef // set to allocator::pointer to allow placing it in shared memory. // /////////////////////////////////////////////////////////////////////////////// // Copyright (c) 1994 // Hewlett-Packard Company // // Permission to use, copy, modify, distribute and sell this software // and its documentation for any purpose is hereby granted without fee, // provided that the above copyright notice appear in all copies and // that both that copyright notice and this permission notice appear // in supporting documentation. Hewlett-Packard Company makes no // representations about the suitability of this software for any // purpose. It is provided "as is" without express or implied warranty. [ With a similar license statement under the SGI copyright ] In my view, one of the strengths of the BSL is that it specifically does not require notice in "supporting documentation." It is possible that this portion of the license is no longer in effect, since the header on the STLport vector header now reads: * Copyright (c) 1994 * Hewlett-Packard Company * * Copyright (c) 1996,1997 * Silicon Graphics Computer Systems, Inc. * * Copyright (c) 1997 * Moscow Center for SPARC Technology * * Copyright (c) 1999 * Boris Fomitchev * * This material is provided "as is", with absolutely no warranty expressed * or implied. Any use is at your own risk. * * Permission to use or copy this software for any purpose is hereby granted * without fee, provided the above notices are retained on all copies. * Permission to modify the code and to distribute modified code is granted, * provided the above notices are retained, and a notice that the code was * modified is included with the above copyright notice. And in this case, perhaps the affected files can be updated to reflect the less-onerous STLport license. Otherwise, the files could be replaced with STLport-derived files, or HP and SGI could be asked to provide permission. Any opinions? Thanks again, Hal

2 3

Important: Server Upgrade Wednesday, April 7
by Doug Gregor 07 Apr '10

07 Apr '10

The main Boost server will be down for a Trac upgrade on Wednesday, April 7 from 8am-9am Eastern time. The following services will be affected: Web server (boost.org) Subversion Trac Mailing list archives Mailing lists should still function as normal. My apologies for the late notice. - Doug

1 0

[move] pre-review comments
by Jeffrey Lee Hellrung, Jr. 07 Apr '10

07 Apr '10

I have some (long overdue) comments concerning Ion Gaztanaga's proposed Boost.Move library. First, Ion, great job on the documentation and implementation. Both are very readable and usable. These comments stem from my own use and perceived deficiencies in the current state of affairs, but they might also lead to a more complex library. So take them however you want, and you (Ion) and others may respond at your own convenience. In below, when I refer to "C++03 compilers", I mean compilers without rvalue rferences; when I refer to "C++0x compilers", I mean compilers that do have rvalue references. Also, some details are lacking, as I'm writing this kind of haphazardly and over a couple hours while watching the Jazz-Lakers game... -------- boost::rv<T> ------------ The library should clearly define what requirements a class needs to satisfy to work with the library's facilities, specifically when rvalue references are not available. For C++03 compilers, this will involve defining boost::rv<T>, conversion operators to boost::rv<T>& and (if copyable) const boost::rv<T>&, and what constructors and assignment operators there should be and their semantics. I think this interface specification is of primary importance, and the remaining facilities are of secondary importance. boost::is_movable<T> -------------------- This should evaluate to a Boost.MPL integral constant, and it should still work for builtin types (and return false). BOOST_FWD_REF( T ) / boost::forward<T>(x) ----------------------------------------- I think there should be 2 forwarding mechanisms. One is BOOST_FWD_REF( T ) (paired with boost::forward<T>(x)), which expands to const T& on C++03 compilers and is able to capture rvalues. The other I've called BOOST_PERFECT_FWD_REF( T ) (paired with boost::perfect_forward<T>(x)), which expands to T& and will *not* capture rvalues, but will correctly forward lvalue references to non-const. I'm open to alternative names. The intent is that you can use BOOST_PERFECT_FWD_REF( T ) if you know you will never need to capture rvalues (e.g., it will only receive the result of a boost::forward or boost::perfect_forward). I think it might also be useful to provide metafunctions boost::forward_param<T> and boost::perfect_forward_param<T> that strips off any {const} boost::rv<T>&'s for use with Boost.ResultOf. BOOST_MOVABLE_BUT_NOT_COPYABLE / BOOST_COPYABLE_AND_MOVABLE ----------------------------------------------------------- I don't use these. Instead, I've created no fewer than 10 macros to enable move emulation, depending on the particular application: BOOST_BASIC_MOVABLE_COPYABLE( T ) BOOST_MOVABLE_NONCOPYABLE( T ) BOOST_MOVABLE_COPYABLE_DEFINE_COPY_ASSIGN_FROM_MOVE( T ) BOOST_MOVABLE_COPYABLE_DEFINE_COPY_ASSIGN_FROM_SWAP( T ) BOOST_OPTIMAL_MOVABLE_COPYABLE( T ) BOOST_FRIENDLY_MOVABLE_COPYABLE( T ) BOOST_OPTIMAL_MOVABLE_COPYABLE_IF( T, Cond ) BOOST_FRIENDLY_MOVABLE_COPYABLE_IF( T, Cond ) BOOST_OPTIMAL_MOVABLE_COPYABLE_IF_MOVABLE( T, U_seq ) BOOST_FRIENDLY_MOVABLE_COPYABLE_IF_MOVABLE( T, U_seq ) BOOST_BASIC_MOVABLE_COPYABLE provides a move constructor and a move assignment operator, but does not provide a mechanism to move assign automatically from rvalues. I typically use this in base classes. BOOST_MOVABLE_NONCOPYABLE should be self-explanatory. BOOST_MOVABLE_COPYABLE_DEFINE_COPY_ASSIGN_FROM_MOVE( T ) defines a by-value copy assignment via copy-and-move. Similarly, BOOST_MOVABLE_COPYABLE_DEFINE_COPY_ASSIGN_FROM_SWAP( T ) defines a by-value copy assignment via copy-and-swap. Implementing copy assignment to receive by value captures rvalues optimally via copy RVO. BOOST_OPTIMAL_MOVABLE_COPYABLE* and BOOST_FRIENDLY_MOVABLE_COPYABLE* differ in how rvalues are captured for assignment on C++03 compilers. OPTIMAL declares an operator=(T&) that forwards to the copy assignment operator, and an operator=(const rv<T>&) to move assign. As has been discussed previously, this has undesirable consequences if you rely on the compiler to generate the copy assignment operator in a class enclosing an "optimal movable" type. FRIENDLY declares an operator=(T) (on C++03 compilers) and implements it in terms of the move assignment operator. On C++0x compilers, both use an operator=(T&&) and operator(const &). BOOST_*_MOVABLE_COPYABLE_IF( T, Cond ) enables movability if Cond is true, and does not define a move constructor and move assignment operator if Cond is false. Similarly, BOOST_*_MOVABLE_COPYABLE_IF_MOVABLE( T, U_seq ) will enable movability if any type in the Boost.PP seq U_seq is movable (as determined by boost::is_movable). "The rest of the stuff" ----------------------- I'd consider iterator's and algorithm extensions to be of tertiary importance, and I haven't yet used them. - Jeff

2 6

[gsoc] heaps & queues
by Cezary Bartoszuk 06 Apr '10

06 Apr '10

Hi, I looked at APIs at https://svn.boost.org/svn/boost/sandbox/libs/pri_queue/ The interfaces are quite well designed, but I don't understand one point: Why are there function templates used in methods providing mutability (for example change_top, change, decrease, increase for the lazy Fibonacci heap: https://svn.boost.org/svn/boost/sandbox/libs/pri_queue/l_heap.html)? I think K stands there for "key", but there's already comparison functor (which defaults to std::less) provided, so we don't store key-value pairs (with key being the priority), do we? Why then K is used? The second key point I would like to ask about is the implementation. Are there any priority queues already implemented in BGL? If so, it would be nice for us to stay compatible with interfaces implemented already. Besides few doubts listed above I would like to propose implementing at least pri queues listed in https://svn.boost.org/svn/boost/sandbox/libs/pri_queue/, so: * D-ary Heap (with standard - binary - heap as a special case) * Fibonacci Heap (btw, I thought, the Fibonacci heap is already lazy - maybe there's an discrepancy in the names) * Pairing Heap (didn't ever hear about them, but there are lots of references in the net) * Splay Heap (think it's a gret idea - simple implementaion and quite nice performance) * Radix Heap (also didn't hear about them, but the intuition is, that's a dara structure implementing radix-sort?) Speaking about stable priority queues (FIFO- or LIFO- stable) i have no fresh ideas for now, but I think it's quite useful, and would be happy to implement it. I have read that there are lots of people submitting proposals for the project; could any partition of work or time estimation be a part of the proposal (because there will surely be at least few of us working on the Heaps & Queues)? Best regards, Cezary Bartoszuk P.S. As I read threads about heaps & queues, I think also that the interfaces are a little bit too complicated. Quite good idea is implementing methods push, min, pop, decrease_key. Personally I don't see any algorithms using both decrease_key and increase_key. Usually there is intention of pushing priority "to the front" rather than "to the back". And there is also thing with iterators: I haven't seen any implementation iterating through pri_queue. So are interfaces based on push, min, pop, decrease_key accurate?

2 1

GSoC 20010: Boost.Thread towards the C++0x standard proposal
by vicente.botet 06 Apr '10

06 Apr '10

Hi, Is someone interested in adapting the current Boost.Thread interface to the C++0x stardard proposal? Best, _____________________ Vicente Juan Botet Escribá

4 5

GSoc Proposal - Crypto Suite
by Chad Seibert 06 Apr '10

06 Apr '10

Hi, I was looking through previous GSoC ideas and I was interested in doing a crypto suite as described here: http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Google_Summe… I was wondering if this was still in high demand, as I've been tied between doing this and the BigInt library proposed on the ideas page. The only reason I ask is because I'd like to do the most good for this project and wonder which project that might be. Thank you for any input, Chad Seibert _________________________________________________________________ Hotmail is redefining busy with tools for the New Busy. Get more from your inbox. http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:…

3 2

[GSoC] Patterns - interest check
by Kornel Kisielewicz 06 Apr '10

06 Apr '10

Hello all, I'm (obviously) interested in joining boost as part of GSoC 2010. Apart from a repeated try of generating interest in the Boost.Matrix library I proposed last year (I'll probably post about it later), I'll share an idea of mine that has been around in my head since I was introduced to boost several years ago. It all began with the singleton pattern -- we were writing a project, and needed a singleton base class quick, hence the first place we turned to was boost. There, two surprises awaited us -- not only wasn't there a singleton library easily available, but in the boost sources there were several singleton base class implementations, few of them even exact the same. True it is that singleton implementations differ - we want to be able to sometimes control the initialization time and initialization order, we sometimes need thread safety, and sometimes not, we'd like to control how to handle creation, and how to handle referencing to a dead singleton -- obviously a bloated master-class is not the solution -- a policy based singleton template however would be. Once that came into my mind, I couldn't shake the idea of a general Boost.Patterns library. While indulging in a discussion of whether Patterns are beneficial or not isn't my goal, we must admit that they are commonly used, and several of those are already present in Boost in one form or another (signals and flyweight comes up to mind as an obvious example). Boost.Patterns would serve as a library for collecting those patterns that aren't big enough for their own library, and encompass the smaller class traits (like boost::noncopyable) too. Apart from the singleton, one obvious candidate for such a library that I'd like to code are the factory patterns, including the abstract factory pattern. A policy based implementation of those might provide a nice benefit for boost users not wanting to reinvent the wheel. Further out, there are a few more commonly used patterns that would be beneficial for a boost::patterns user. The way I see it, for the more complex solutions, some framework of base classes to be used would have to be designed, and then used between the patterns. Mind you, I'm not trying to convince anyone to the creation of a new Boost.Patterns library (although I'd really like to do that if possible), instead I'd like to ask you if there's a viable GSoC proposal in this post, one that one day might turn into a useful part of boost. -- regards, Kornel Kisielewicz http://chaosforge.org/

2 2

Re: [boost] [msm] new version available
by Christophe Henry 06 Apr '10

06 Apr '10

> On Monday 05 April 2010 09:12:14 Christophe Henry wrote: >> I just finished the newest MSM version. Unfortunately, I'm afraid I'm >> a bit late to get it shipped with boost v1.43 but at least it will >> give us time to have a look at it. > > You are still within the merge window and given that your documentation seems > to be in excellent shape, there is no reason to delay it past 1.43. Here's the > calendar for 1.43.0: > http://www.boost.org/development/index.html > > Regards, > Ravi Really? I thought Monday was deadline. What I am missing are regression tests, but if the Release managers allow it, I could write them this week (I never wrote a jamfile but for the sake of the argument, let's suppose I get this right). Release managers, is it still possible to ship MSM with 1.43? Christophe

2 1

[utility/result_of] decltype-based implementation breaking valid code on msvc-10
by Eric Niebler 06 Apr '10

06 Apr '10

I recently looked into some proto failures on msvc-10 and traced them back to the use of decltype in the implementation of boost::result_of. The program below demonstrates the problem: // Uncomment the next line to make the problem go away //#define BOOST_NO_DECLTYPE #include <boost/utility/result_of.hpp> template<class X, class Y> struct pair {}; template<class Base> struct S; struct wrapper { template<class T> struct result; template<class This, typename That> struct result<This(That)> { typedef S<That> type; }; template<typename That> typename result<wrapper(That)>::type operator()(That) const { return 0; } }; template<class T> struct S { S(int = 0) {} typename boost::result_of<wrapper(pair<T, T>)>::type foo() { return 0; } }; int main() { S<int> s; } The use of decltype in result_of causes the compiler to recursively instantiate templates until it blows its stack. To make the problem go away, you must #define BOOST_NO_DECLTYPE. I suspect the real problem is in a buggy implementation of decltype on msvc-10. For the upcoming boost release, I suggest that we stick with the non-decltype implementation of result_of on msvc-10, or risk massively breaking users' code, not to mention proto, spirit and xpressive on that compiler. -- Eric Niebler BoostPro Computing http://www.boostpro.com

5 7

Re: [boost] [utility/result_of] decltype-based implementation breaking valid code on msvc-10
by Eric Niebler 06 Apr '10

06 Apr '10

On 4/5/2010 6:05 PM, Daniel Walker wrote: > On Mon, Apr 5, 2010 at 6:39 PM, Eric Niebler<eric(a)boostpro.com> wrote: >> https://svn.boost.org/trac/boost/ticket/4072 >> >> A patch is attached to the ticket. I've confirmed that it un-breaks proto on >> msvc-10, but have not tested it further. > > Good catch. Seems reasonable to me. In general, if some vendor > releases an inadequate std:result_of or decltype, it would be good to > have boost::result_of as a functional fallback, which is yet another > reason to resolve the lambda/result_of issue. Enabling lambda to > support boost::result_of's signature protocol, as in ticket 864, would > do the trick. That way msvc-10 users would be able to enjoy > lambda/result_of compatibility, even if msvc-10 still has some > wrinkles. Daniel, I don't necessarily disagree, but I'm not really interested in getting this small issue mixed up with the larger issue of lambda/result_of compatibility. I just want result_of to work on msvc-10. -- Eric Niebler BoostPro Computing http://www.boostpro.com

3 4