- Boost - lists.boost.org

[Phoenix] Some questions and notes...
by Giovanni Piero Deretta 30 Sep '08

30 Sep '08

Hi all, I'm writing a review of phoenix, but first I have a some questions and notes. * First of all, it is not clear to me how 'lambda' works. I would have thought that it just introduced a new scope, but it seems that it does something more: 1: int i = 10; 2: cout << arg1(i) <<endl; 3: cout << lambda[ arg1 ](i) <<endl; // doesn't compile 4: cout << lambda[ arg1 ]()(i) The use of lambda at line 3 is completely superfluous, nevertheless, I prefer that syntax because it makes it clear that I'm using a lambda expression (always using lambda will also allow some other tricks I'll discuss later). Surprisingly, line 3 doesn't compile. lambda::operator[] actually returns a nullary stub that must be evaluated to actually get our unary function. Is this really necessary? can it be fixed? * non-standard result<> protocol. IMHO for Phoenix to become a first class boost library, it should support result_of out of the box. I understand that this is not done for backward compatibility, but I think that there are three solutions: 1) old users will still be able to use the Phoenix inside spirit if they have a large codebase that uses the old protocol. 2) phoenix could provide a wrapper that converts from the old to the new protocol and viceversa. This would require some changes in the client code. 3) phoenix could detect the protocol used by the user function and switch between the old and new 'result'. This is hard to do in a robust way, but breaks no user code. I would prefer the first option. * Perfect forwarding. I'm used to the perfect forwarding in boost lambda (which, contrary to what the documentation states, perfectly forwards up to 3 args). Personally have little use for lambdas that take their arguments by non const reference as I strive for referential transparency. I know that implementing this feature has an high compile time cost, but there should at least be an option to enable it. I would vote for two additional 'lambda' syntaxes: clambda and plambda (better names are wellcome). The first one would work like boost lambda const_arguments and should have no compile time cost, while the second will do perfect forwarding up to some parameter number. This would require the lambda[] syntax to actually return the wrapped function object, not a stub (as per first question). * operator->*. I sometimes use this operator with boost lambda, as a short hand for binding member functions, but, as in phoenix, it requires it lhs to be a pointer. Would it possible to extend it to any functions? for example: struct foo { int bar; }; std::vector<foo> in =...; std::vector<int> out; std::transform(in.begin(), in.end(), std::back_inserter(out), (&arg1)->*&foo::bar); The parenthesis, and ampersand are ugly, it would be great if this worked: std::transform(in.begin(), in.end(), std::back_inserter(out), arg1->*&foo::bar); I think this would interfere with foo implementing its own operator->*. Which brings the question... * ... how do I implement type deduction for the my own overloaded operators? I.e. what is the phoenix equivalent of http://tinyurl.com/4botne ? By reading of the documentation I couldn't figure out an easy way to do it. Well, that's all for now, those questions are mostly to get the discussion rolling, more to come. -- gpd

3 10

Re: [boost] [Review] Phoenix review starts today, September 21st
by dan marsden 30 Sep '08

30 Sep '08

Daniel Walker wrote: <snip> >Of course not. :-) But going in-depth into V2's implementation is not >the same as going in-depth into V3. The design may be the same, but >simple diffing and greping shows the implementations are not. And >that's to be expected. As I understand, whole components were gutted >and replaced with Proto, which is a good thing. So let's continue that >effort and spend our energy on V3 and not look back! > >Now, how that relates to the review formalities and the fact that >apparently V2 is under review, I am not sure. As far as I can tell, >all the reviews thus far have assumed the V2 implementation. I would >suggest withdrawing V2 from consideration (leaving it as is in >Boost.Spirit), finishing V3 (which becomes the new Boost.Lambda), and >then resubmitting for review, but I'm no expert on this process. > It is my understanding that Boost authors retain the "rights" to modify and upgrade their libraries once accepted, both in terms of implementation and interface changes. Boost.Xpressive has seen many changes iirc, including the sorts of changes that we're discussing (reimplementing in terms of proto + I believe some smaller interface changes). Many other libraries have similar history. If the authors of these libraries had stated their development plans, in advance of review, should they have been rejected until they were "finished"? Joel has been very open in stating his future plans, but what he plans has happened many times before to accepted libraries. Obviously the rather fluid state of the libraries does muddy the purpose of the review. I'd suggest we review libraries as is, answer all the usual questions about interface, quality of implementation, docs etc. There seems to be some implicit assumption that the author will act in the spirit of Boost, and reimplement + extend to the same level of quality as seen in the review. I think Joels track record in this area speaks for itself. On your other comment about Phoenix2 remaining under Spirit if it were not to be accepted, that is obviously true, but at some employers/organizations passing the review process and being an official part of a Boost release is a prerequisite to using a library. Cheers Dan

10 24

[threadpool] new version with work-stealing
by k-oli＠gmx.de 30 Sep '08

30 Sep '08

Hi, I've uploaded a new version of threadpool lib (http://www.boostpro.com/vault/index.php?action=downloadfile&filename=boost_…) changes: - support of work-stealing strategy - task can be interrupted an waited for its termination - thread management strategies lazy and adaptive removed - channel rendezvous removed regards, Oliver

1 0

[config] BOOST_HAS_THREADS with libstdc++
by Frank Mori Hess 30 Sep '08

30 Sep '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 It looks like the gcc bug (pr 11953) that inspired the workaround in boost/config/stdlib/libstdcpp3.hpp that goes: #ifdef __GLIBCXX__ // gcc 3.4 and greater: # if defined(_GLIBCXX_HAVE_GTHR_DEFAULT) \ || defined(_GLIBCXX__PTHREADS) // // If the std lib has thread support turned on, then turn it on in Boost // as well. We do this because some gcc-3.4 std lib headers define _REENTANT // while others do not... // # define BOOST_HAS_THREADS was fixed for mainstream gcc 4.1.2 and later versions in December of 2006. So can we change the first line to something like: #ifdef __GLIBCXX__ && __GLIBCXX__<20070101 so detection of whether gcc is in multi-threaded mode or not works again? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFI4Rim5vihyNWuA4URAs/NAJ45aP24OAUerZUaV48Y1faYt0GsSACeOoJi eiWSbyfmjW8653luxIe0U/s= =HySJ -----END PGP SIGNATURE-----

2 1

Phoenix review
by Peter Dimov 30 Sep '08

30 Sep '08

I apologize in advance that I could not dedicate the appropriate amount of time for my evaluation of the library. * Design - The placeholders probably belong in namespace phoenix::placeholders instead of arg_names, for consistency with std::placeholders. - It is very odd to include phoenix_bind.hpp and not have the placeholders available. For that I need phoenix_core.hpp. - The decision to capture the left side of @= and = by value is debatable. It is indeed not clear which one is 'better', but we do have Lambda in Boost, and to deviate from it one needs a stronger supporting argument than that. - In general, the subtle differences between Bind, Lambda and Phoenix need an explanation, even if its only purpose is to clearly show that the deviation is deliberate and not an accident. - bind<R> is not supported. - Smart pointers do not seem to be supported well in conjunction with bind, even though they seem to work in other contexts. - What is the equivalent of boost::unlambda in Phoenix? I think I agree with Giovanni Piero Deretta that lambda[] is an intuitive way to put a 'wall' between the inside lambda expression and the outside world. It doesn't seem to; the following fails: px::bind( px::lambda[ arg1 + arg2 ], 0, 1 )(); - It is not clear what introspection facilities are provided. Users sometimes want to derive a signature from a bind expression, or to compute the minimum arity of a lambda expression. They ought to be able to implement these queries themselves via a documented introspection interface that will not break when V3 arrives. * Implementation - Phoenix objects do not take rvalues. This is a very common stumbling block for people wanting to experiment with lambda libraries. - boost::is_placeholder needs to be specialized for the placeholder types. It might be interesting to see Phoenix respecting is_placeholder in the other direction, too, if possible. - The test coverage seems relatively sparse. I know very well how painful it is to write tests (for arities from 0 to 9 inclusive), but Phoenix 2.0 needs and deserves more of them. Take this, for example: test::x x_; bind(&test::x::m, x_)() = 123; bind(&test::x::m, arg1)(x_) = 123; BOOST_TEST(x_.m == 123); It doesn't test whether the first bind worked, and doesn't try to read from a member using bind. * Documentation - The examples assume a number of using directives without this being stated. - I believe that it would be better to leave the std:: names qualified. As it stands, it is not immediately obvious whether cout is std::cout or phoenix::cout (a plausible assumption would be for a phoenix::cout to be defined as phoenix::ref(std::cout) to avoid capture by value). - The val(3) example stresses that it returns a nullary function, but val(3) happily accepts (and discards) arguments - as it should. - The relationship between phoenix::ref and boost::ref is not made clear, or even mentioned. Can one use boost::ref instead? In what contexts? std::ref? (As an aside, there is a slight tendency in the documentation to be a bit too independent of the rest of Boost for my taste. It mentions Lambda in passing, but doesn't go into any details; it completely ignores boost::bind.) - The "Forwarding Problem" paper is so 2002. :-) - The note that the binders are monomorphic should probably be fixed. - It might be instructive to add an introspection example to the final chapter that returns the (minimum) arity of a Phoenix expression. - The documentation is missing a reference section, or at least an index of the identifiers in the phoenix namespace. * Vote This is hard. On the one hand, it is ridiculous to include <boost/spirit/include/phoenix_bind.hpp> for phoenix::bind instead of <boost/phoenix/bind.hpp>, as one would reasonably expect. As Phoenix is already in Boost, the review merely needs to formally acknowledge the facts. And the library certainly meets the criteria for acceptance. On the other hand... I sense from the state of the documentation that Phoenix being under the Spirit umbrella and not an "official top level" library has led to a somewhat isolated development. It is very high quality, above the Boost median, but somehow doesn't yet feel like a top level library. Still being on the other hand... We know that having two libraries with overlapping goals, overlapping syntax, overlapping identifiers and placeholders, and subtle differences is confusing and a continuous source of recurring questions. Now we will have three. But the fair thing to do is vote for acceptance. Which I will.

2 1

[Review] Phoenix
by John 30 Sep '08

30 Sep '08

First, the big question I vote for a second fast track review of the v3 implementation. The reasoning is simple, if a little painful. I have a lot of sympathy for the view that we should be reviewing the version that is actually going to be released (or at least something close to it). Joel is right that some libraries have been admitted with the condition of large changes. In general, given the exceptional quality of his work to date, I also consider him quite trustworthy when he says that is what he plans to do. However, I have problems with how I'm supposed to review the implementation of a library that won't be implemented the same way when it goes into Boost. That said, even the v2 edition is an exceptional library. It has been pointed out elsewhere that there are some current details missing from v2, and Joel has already promised their inclusion in v3. Aside from those artifacts of its history, it is a very nice piece of work. I have used it in a few projects and I find it clear to use, well documented and largely well behaved (except for afore mentioned problems). It works on compilers that live close enough to the standard, and that happens to be what I currently use. It is well documented (I also vote for the return of the section on FP.), and I enjoy the style. There is a lot to learn to use the library well, but that is partially because it is a powerful library in a programming idiom that many of us have only learned we need recently. It is practical, and so provides a gentler step into functional programming than would be the case if it stressed purity. However, it allows clearly functional constructs and has well thought out abstractions underlying the interface The reasoning is painful because it has me voting against immediate inclusion for a library I obviously like and respect. However, I think this review is valuable for what it accomplishes. In my following of the discussion so far, I haven't seen anyone who has issues with the need for the library, with the basics of the interface, or with the abstractions it embodies. I think this is the 85% good stuff (I may be remembering the wrong number here.) that Joel spoke of. That allows us to focus the fast track I am voting for on the implementation and compliance with a few specific changes. v2 will be available, and the small breaking changes in v3 will be the first boost release (since I'd be very surprised if Joel didn't do all requested and more for v3), so there will be a minimal legacy code base issue. As for the naming, I would also like to see the release version become the new Lambda v2. Though I appreciate creative names for some things, it seems to cause problems for software libraries. John Phillips

2 1

request for interest: stable vector
by JOAQUIN M. LOPEZ MUÑOZ 29 Sep '08

29 Sep '08

I recently wrote up the implementation of a *stable* vector, a container mimicking the interface of std::vector except that it provides iterator and reference stability at the expense of losing memory contiguity: http://bannalia.blogspot.com/2008/09/introducing-stablevector.html If there is interest in the community this could be grown into a full-fledged proposal for Boost (either by me or by any other interested colleague). Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

9 22

[interprocess] atomic_write32, etc. -> public?
by k-oli＠gmx.de 29 Sep '08

29 Sep '08

Hello, interprocess provides in its detail namespace atomic ops like atomic_write32, atomic_cas32 etc. Is it possible to move this functionality to a public namespace? I'm using interprocess::detail::atomic_write32 for instance in an work-stealing queue and I'd like to use 'official' functions instead from a detail namespace. regards, Oliver

2 1

[Phoenix] review reminder
by Hartmut Kaiser 29 Sep '08

29 Sep '08

All, this is just a gentle reminder for all of you willing and planning to write a review for Joel de Guzman's and Dan Marsden's library Phoenix V2. The review ends tomorrow, September 30th. If you are for some reason not able to write the review before tomorrow night, please get in contact with me directly, so we can work something out. Regards Hartmut Review Manager

1 0

[threadpool] work-stealing support
by k-oli＠gmx.de 29 Sep '08

29 Sep '08

Hello, I've the work-stealing strategy ready - I'd like to know if it is desired to remove lazy and adaptive strategy from the lib (as Vicente Botet and Johan Torp mentioned)? So only fixed an work-stealing will be supported?! thx, Oliver

2 3