Subject: Re: [boost] Case study: Boost.Local versus Boost.Phoenix
From: Hartmut Kaiser (hartmut.kaiser_at_[hidden])
Date: 2011-02-04 13:33:59
> On 2/4/11 4:35 AM, Artyom wrote:
> > I'm sorry is it only me or it would be much more readable and
> > maintainable to write:
> It isn't clear to me how writing all of that extra boilerplate makes
> things easier to understand. BOOST_LOCAL_FUNCTION is not that hard to
> understand; the name of the macro itself tells you very clearly what it
> is doing: declaring a local function. Furthermore, if anything I would
> argue that using structs to define functions makes things harder to
> understand by adding lots of extra noise that you have to go through
> before you figure out what the function actually does.
That's purely a choice based on personal taste.
> > I understand that Pheonix and boost::lambda are very useful in certain
> > situations but am I only person who thinks that if you need some
> > little bit more complicated lambda function you just create a small
> > class with operator() which would be
> > 1. Much More readable
> Again, I have to strongly disagree with this. If you have never seen
> BOOST_LOCAL_FUNCTION then it might take a small amount of time to get used
> to it, but after that it is incredibly clear what is going on at a glance,
> especially since it contains less boilerplate noise getting in the way.
Just my 2c: I find the proposed macro syntax to be ugly, unreadable and very
difficult to associate with the corresponding function definition.
> > 3. Easier to debug and see compiler's error messages
> The error messages usually aren't that bad for Boost.Local, and the syntax
> is simple enough that I found it relatively easy to figure out what went
> wrong compared to many other libraries.
Again, that's a matter of taste. I find macros to be more difficult to debug
than normal code. You normally can't step through macro code.
FWIW, I prefer using lambda/phoenix for simple expressions and I tend to
write phoenix functions for more complex things. Working with lazy PFO's has
the general advantage to allow for easy function composition, which is a
major advantage over plain adhoc 'local functions' as defined by your
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk