[Dev] STL for_each underwhelms me
M. Mueller (bhu5nji)
dev@trilug.org
Mon, 11 Feb 2002 13:13:51 -0500
(darn laptop and fat fingers...)
At first I though the STL "for_each" algorithm was going to be handy. Then I
tried using it.
I know very well what a "unary function" is and how they are different from
"binary functions" and "unary methods". I searched the web for advice on how
to get around the limitations of for_each only operating in unary functions.
The workarounds were studies in obuscation. Or maybe I should look deeper?
Am I missing the finer points? Here's how I understand things right now.
Why is the following code structure in need of replacement by such a limited
algorithm as for_each?
The mortal way:
map<int,int> xmap;
// load map...
map<int, int>::iterator i;
for(i = xmap.begin(), i != xmap.end(), i++)
{
// do any darn thing you want to
// in plain old un-elegant but readable
// code
}
The for_each way:
Either:
for_each(xmap.begin(), xmap.end(), unary_function_only);
Or:
for_each(xmap.begin(), xmap.end(), class_with_overloaded_operators);
Or:
for_each(xmap.begin(), xmap.end(),
magically_transformed_things_that_appear_to_be_UF);
The first way is OK, but it's limited to only unary functions. I tried to
use a unary method and kept getting "out of scope" errors during compile.
The tranformation techniques I saw on the web were so obtuse that they
probably would not have survived code reviews in places I have worked in the
past.
Someone, please turn on the light for me.
Thanks,
Mike M.