Subject: Re: [boost] Case study: Boost.Local versus Boost.Phoenix
From: Gregory Crosswhite (gcross_at_[hidden])
Date: 2011-02-04 12:57:38
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.
> 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
> 2. Clear for source code maintainers who not familiar with some boost toolkits
True, but on the other hand this will always be true of any library that
one chooses to use that is not standard C++.
> 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.
> 4. Be friendlier to less experienced C++ programmers who would
> have to maintain this horrible code?
I strongly object to you repeatedly calling my code horrible just
because it does not follow your personal aesthetics.
> I do like and use boost::bind, boost::lambda and some other simple
> construction that can be written in a single like and what is
> most important improve programmer's productivity but I really
> fail to see it in this case.
Yes, but all of the arguments you have just made could be applied
equally well against boost::bind and boost::lambda, so this isn't a
matter of keeping things simple so much as a matter of personal
preference. In particular, I think that BOOST_LOCAL_FUNCTION is much
clearer than boost::bind because there isn't actual line noise getting
in the way of you seeing what is making the function call.
> - maintainer happy to be able to actually understand what
> does the code do without reading Boost.Pheonix or Boost.Local
> manuals for 5 hours.
If you saw BOOST_LOCAL_FUNCTION for the first time and had to look at
the manual, there is no way that it would take you over even one hour to
understand what it does unless you are very slow. In fact, it would
take much closer to 5 minutes than 5 hours.
In conclusion, while I agree that over-use of alien looking constructs
can cause more trouble than it is worth I think that you are greatly
exaggerating how hard it is to understand BOOST_LOCAL_FUNCTION.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk