On Mon, 2002-02-11 at 16:07, M. Mueller (bhu5nji) wrote: > Nice description. That's one light. The David Musser STL Tutorial only > talks about functions, never about function objects that have state. So, now > I can envision that the function object is "sent in" to the for_each > algorithm.
Hmm... It doesn't talk about function object? What a major omission. I assume you already have an STL book, since you mention the Musser (& Sanni) one, but I'll just plug my personal favorite.. :-) I looked at a lot of STL books (and granted, the 2nd edition of Musser et all wasn't out when I did, but..) and the one I liked the best, for writing style, information, understanding and examples was, by far, Nicolai M Josuttis's *The C++ Standard Library, A Tutorial and Reference*. That's where I got the example I showed you. It talks a lot about function objects... > This is where I cannot clearly see the benefits of using for_each. I am > havine the hardest time learning why I would choose to overload operators to > create a way to squeeze in two parms where the design called for one. I keep > hearing the cries of those following my code, "what the heck is going on > here?". Why not choose (what I think is) the simpler way - write a function > or method and call it in a for loop? Perhaps this is just a more explicit > way. It is not obvious to me that using the for_each will produce better > performance that using the for-loop. Well, here, the obvious answer is code reuse. I gave a generic function object that would calculate the mean value. If you compute the mean value in only one place then a for loop is probably ok. If you do it in more than one place, then abstracting the code out so that you only have to write it once makes more sense. > I am saying that STL does not create simpler code. In general, I am very > pleased with STL. I practically think in sets and maps these days. I'll > never write another linked-list. > > I suspect one of my problems with for_each is a poor understanding of > operator overloading, especially for the "function call" That might be. Try looking up functor. The Design Pattern book gives this reference for a use of the operator() in making a functor: James O. Coplien, *Advanced C++ Programming Styles and Idioms*. Addison-Wesley, Reading, MA, 1992. I'm sure there are others... Tanner -- Tanner Lovelace | [EMAIL PROTECTED] | http://wtl.wayfarer.org/ --*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*-- GPG Fingerprint = A66C 8660 924F 5F8C 71DA BDD0 CE09 4F8E DE76 39D4 GPG Key can be found at http://wtl.wayfarer.org/lovelace.gpg.asc --*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*-- Those who are willing to sacrifice essential liberties for a little order, will lose both and deserve neither. -- Benjamin Franklin History teaches that grave threats to liberty often come in times of urgency, when constitutional rights seem too extravagant to endure. -- Justice Thurgood Marshall, 1989
signature.asc
Description: This is a digitally signed message part
