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

[Paul Grenyer]

Hi Mark

> >The three main problems I have using algorithms and my own predicates
> >are:
> >
> >1. Coming up with a good descriptive name that describes what the
> >predicate does in order to remove the need for the maintainer to look
> >for its implementation.
>
> This isn't a problem with naming your own function objects - the problem
> is that it's just hard to come up with meaningful names for things in
> all but the simplest situations.

That's the same thing isn't it?

> A great advantage of making the effort to name your own function objects
> is that you capture a single level of abstraction within a piece of
> code. For example:
>
> for_each(c.begin(),           c.end,write
>
> This simply tells you that each element in the range is being written to
> cout,

It does? How? Write could be writing to anywhere. A file, a database, a log,
etc. Therefore in this instance, it would still mean going off to find the
write functor to see what is actually happening.

> whereas (assuming the presence of suitable typedefs):
>
> for (const_iterator i = c.begin(); i    !=c.end  ++i)
> {
> }
>
> combines what you're trying to do, with how you're doing it. For someone
> trying to understand what this code does, the code in the braces is more
> noise than signal.

I don't agree. Everyone is familiar with what a for loop does, so assuming
it isn't more than a few lines long there shouldn't be too much noise. I'f I
had a huge amount to do in the for loop, or I needed to reuse the for loop
in other paces, I'd use a functor.

> Note that I personally would use for_each and code up a function object
> called "write" rather than copy to an ostream_iterator, because it leads
> to the code effectively being its own comment.

Yes, that is one way of looking at it. Another could be that the functor is
unnecessary as the code already says exactly what it is doing.

> >2. Where to put the predicate so it's easy for the maintainer to find.
> >If it's in an anonymous namespace at the top of the file the maintainer
> >has to scroll up for it, if it's above the (for arguments sake) member
> >function definition, it's untidy.
>
> First, the problem here disorganised thinking more than anything else.
> You're trying to understand too much at once. Understand first what the
> code does, then delve into how it does it if necessary.

That depends entirely on your point of view and your level of patience. You
know, as much as anyone on this list, just how impatient I am.

> Second, use the available tools effectively. One simple approach is to
> print off the function object(s) (presumably located in the unnamed
> namespace), and use the hard copy for reference (if necessary) while
> working on the code that uses them.

Again, it comes down to patience. It makes little difference whether I am
scrolling up the same source file or having to look away to a printout.

> >3. Often using a predicate results in more code.
>
> Yes, but traded against better organised and more expressive code!

Possibly.

I still use functors for most of the reasons you suggest, except in trivial
cases such as calling a particular function on all the elements in a
container.

> Just my view of the world :-)

As with yours, my comments are based on my personal experience and what I
prefer and find easier.

Regards
Paul

Paul Grenyer
email: paul at paulgrenyer.co.uk
web: http://www.paulgrenyer.co.uk
articles: http://www.paulgrenyer.dyndns.org/articles/

Jensen should have gone to Williams.
Ecclestone is killing the sport.