[Effective-cpp] Item 1: Uses and Abuses of vector

[Balog Pal]

> > > Facilities such as Boost.Lambda may help here.

Yeah, they may help. Provided 1) your environment can incorporate Boost, and
2) people working with the code are familiar with Boost.Lambda.

> > Eh? Lambda doesn't improve _readability_ and certainly isn't intuitive.
> :-)

My pick here is it *becomes* intuitive, afer you grokked it. For that you
must learn its specific ways.

Also there may be another issue I can't see clearly: one may be unfamiliar
with the whole lamba concept, especially if he never met lisp or a course on
that topic.  That knowledge is pretty blinding to how other people read,
understand or not understand such code.
Lambda is not included and not supported by C++ so we can't expect any
random user of C++ will know it.    (I'm interesed in oters' view on this.)

> I assumed that Balog referred to the kinds of expressions you may get if
you
> use a complicated expression e.g. as the function object for for_each, or
> some predicate. Since this is the effective-cpp list (reuse is good. ;) ),
I
> refer to the kind of expressions that Scott Meyers have in "Effective STL"
> Item 47: "Avoid producing write-only code", such as (to quote part of the
> expression at page 206):
>
> vector<int> v;
> int x, y;
> ...
> find_if(v.rbegin(), v.rend(), bind2nd(greater_equal<int>(), y));

Yeah, this is the beast I was talking about.  It is nice and straightforward
code to one able to read it, and wild magic to everyone else.   I;d guess
even those who know it can get in trouble if there's a little typo
somewhere.

> This may be written using BLL as:
>
> find_if(v.rbegin(), v.rend(), _1 >= y);
>
> Do you still not find this clearer than the first example?

Yeah, that is great, for all the cases where it actually works, and does
what was the intention. :-)     It is even wilder pack of magic.

Baut the real-world problem is not in these shiny exalmles.  There thongs
are generally a bit more complicated, and that little just prevents the use
of either the std:: predictates or simple expressions.  Or it is possible,
but the cure gets worse than the disease.
Or the stuff starts with that simple one, then next day the predictate gets
another constraint, and you must rearrange the whole code.  Or hack in the
new stuff somehow.  In that incremental development things can get really
nasty wrt readability. :)

> BLL is
> definitively about improving readability. It's also intuitive to use (at
> least for relatively simple expressions), at least if you know how to use
> it.

If C++ had local functions, even without environment-access support, or at
least I could pass local classes to templetes thus creating the one-shot
iteration or predictate function in place life would be so much easier.

The for loop is not abstract enough, and only idioms tell you it really does
'for_each' or something,  but at least the body is straightforward for even
the casual readers.

What is a good balance depends on the actual code and environment, IMHO.