On 6/25/2012 12:21 PM, Mathias Gaunard wrote: > On 24/06/2012 01:10, Eric Niebler wrote: > >> As for what is not changing: >> >> Grammars, Transforms and Algorithms >> =================================== >> It would be wonderful if there were a more natural syntax for describing >> proto algorithms rather than with structs, function objects, proto::or_, >> proto::when, and friends. If there is one, I haven't found it yet. On >> the up side, it means that many current proto-based libraries can be >> upgraded with little effort. On the down side, the learning curve will >> still be pretty steep. If anybody has ideas for how to use C++11 to >> simplify pattern matching and the definition of recursive tree >> transformation algorithms, I'm all ears. > > There is a function which is very simple and that I found to be very > useful when dealing with expression trees. > > unpack(e, f0, f1) which calls > f0(f1(e.child0), f1(e.child1), ..., f1(e.childN)) > > I can do recursion or not with the right f1, and I can 'unpack' an > expression to an n-ary operation f0. > > Here f0 is typically a function that uses its own overloading-based > dispatching mechanism.
OK, thanks for the suggestion. Where have you found this useful? Along those lines, I've been thinking about adding a kind of transform that gives an exploded view of an expression, kind of like what evaluation contexts give you. If you tell me your use case, I can try to make the new transform support it. For the record, I'll be killing off evaluation contexts completely in proto.next. >> It needs clang trunk to compile. > > Why doesn't it work with GCC? The big missing feature is ref qualifiers for member functions (n2439). AFAIK, clang is the only compiler that has implemented it. -- Eric Niebler BoostPro Computing http://www.boostpro.com
signature.asc
Description: OpenPGP digital signature
_______________________________________________ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
