[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.