[Dev] STL for_each underwhelms me

[Tanner Lovelace]

--=-489kCt963Oi8Z+gNsVDs
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Mon, 2002-02-11 at 16:07, M. Mueller (bhu5nji) wrote:
> Nice description.  That's one light.  The David Musser STL Tutorial only=20
> talks about functions, never about function objects that have state.  So,=
 now=20
> I can envision that the function object is "sent in" to the for_each=20
> algorithm.  =20

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=20
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,=20
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=20
> havine the hardest time learning why I would choose to overload operators=
 to=20
> create a way to squeeze in two parms where the design called for one.  I =
keep=20
> hearing the cries of those following my code, "what the heck is going on=20
> here?".  Why not choose (what I think is) the simpler way - write a funct=
ion=20
> or method and call it in a for loop?  Perhaps this is just a more explici=
t=20
> way.  It is not obvious to me that using the for_each will produce better=
=20
> 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=
=20
> pleased with STL.  I practically think in sets and maps these days.  I'll=
=20
> never write another linked-list.
>=20
> I suspect one of my problems with for_each is a poor understanding of=20
> 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*. =20
Addison-Wesley, Reading, MA, 1992.

I'm sure there are others...
=20
Tanner
--=20
Tanner Lovelace | lovelace@wayfarer.org | http://wtl.wayfarer.org/
--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--
GPG Fingerprint =3D 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=20
 order, will lose both and deserve neither.  --  Benjamin Franklin=20

 History teaches that grave threats to liberty often come in times
 of urgency, when constitutional rights seem too extravagant to=20
 endure.  --  Justice Thurgood Marshall, 1989=20

--=-489kCt963Oi8Z+gNsVDs
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQA8aDvrzglPjt52OdQRAplWAJ45v1+/KNO/YWFuh4WT3B/il+tc9gCgmBQ7
Hm60sh9Y93NCu9bJfxRykuQ=
=sLVB
-----END PGP SIGNATURE-----

--=-489kCt963Oi8Z+gNsVDs--