Hey, I really enjoy using BOOST_FOREACH on containers, saves a ton of typing. However, one semi-annoying problem that I've ran into is that nesting instances of BOOST_FOREACH causes the gcc argument -Wshadow to complain quite a bit. A useless example of this behavior is as follows: #include <vector> #include <iostream> using namespace std; #include <boost/foreach.hpp> int main() { vector < vector <int> > array; BOOST_FOREACH( vector<int>& i1, array) BOOST_FOREACH( int i2, i1) cout << i2; } And you get the following warnings: g++ -Wshadow shadowtest.cpp -o shadowtest shadowtest.cpp: In function ‘int main()’: shadowtest.cpp:13: warning: declaration of ‘_foreach_col’ shadows a previous local shadowtest.cpp:12: warning: shadowed declaration is here shadowtest.cpp:13: warning: declaration of ‘_foreach_cur’ shadows a previous local shadowtest.cpp:12: warning: shadowed declaration is here shadowtest.cpp:13: warning: declaration of ‘_foreach_end’ shadows a previous local shadowtest.cpp:12: warning: shadowed declaration is here shadowtest.cpp:13: warning: declaration of ‘_foreach_continue’ shadows a previous local shadowtest.cpp:12: warning: shadowed declaration is here Now, I know that some people don't believe in getting rid of warnings just for warnings sake, but the fix for this would be extremely trivial and useful (given the amount of noise that it generates) -- just add a new macro, BOOST_FOREACH_NESTED, which has a third parameter denoting the level of nesting. That parameter would be token-pasted onto the end of the variable name, and get rid of the warnings. One could define up to N more macros of the form BOOST_FOREACH_NESTED_N that get rid of the third parameter, by calling that macro appropriately. This wouldn't break any existing code, and would allow those that choose to get rid of the warnings. There are a number of arguments against such a change: (a) -Wshadow is gcc specific and isn't enabled by default, (b) If you don't like the warning, don't nest BOOST_FOREACH statements, or don't use -Wshadow. However, my feeling (and this is probably just a matter of personal preference) is that given the triviality of the fix, theres no reason to not fix it. Granted, I could easily just make my own and stick it in a header file, but it seems like it would make more sense to be in boost itself. I could create a patch and post it if so desired. Thanks! Dustin -- Innovation is just a problem away -- Innovation is just a problem away