To preface this question: I've been implementing various C++ utility functions and (when I have to) macros in a larger toolkit for my own use. Recently I had been making a variety of loop macros based on BOOST_FOREACH as well as iterable conscious functions.
Long story short, I ran into difficulty making an enumerate-loop which uses BOOST_FOREACH but with an additional parameter passed which is incremented on every iteration of the loop. This would function much like the enumerate command in Python which I find useful when looping over arbitrary iterators without adding a lot of boiler plate code. The macro takes the form like BOOST_FOREACH:
ENUMERATE_FOREACH(COUNT, VAR, COL)
and would effectively do this, but without relying on placing an unbalanced '}' to close (or other loop ending macro):
COUNT = 0; BOOST_FOREACH(VAR, COL) { COUNT++; ...Rest of loop...
Now before I get the accusations of trying to make a non-C++ operator in C++, I am fully aware that this is cramming a foreign concept into C++ and I'm not trying Pythonize C++ code. I am simply curious if it's cleanly possible to implement such a loop with known toolsets/boost without extreme dependencies. Having such a macro definition would eliminate a possible source of bugs for certain styles of looping where I need to count as I iterate and it disambiguates the purpose of the COUNT variable.
I thought about doing a template wrapper on the COL variable before it goes into BOOST_FOREACH, but the number of possibilities for COL makes that difficult/impossible with some combinations of iterable varibles without making different version of ENUMERATE_FOREACH and re-implementing a lot of BOOST_FOREACH -- a daunting and fool-worthy task without immense testing/time.
Doing a separate inline function could work, but then the syntax of looping becomes broken and I'm to more of a on-each style operator function passing situation (which I already have implemented).
This has left me with taking the final lines of foreach.hpp from boost's libraries and inserting my own increment operator on the additional argument. Then I become boost version dependent and worry about new updates (any syntax changes) to boost breaking my hacky custom macro.
A last option I thought about is to do a ENUMERATE_BEGIN and ENUMERATE_END to hide my iterator increment operation. This approach is more error prone than a single macro as the user must place two macros instead of one -- though that might be the only simple solution.
I tried looking around on SO and other sources to see if someone had tried this before without much luck. Hopefully someone has played with such an implementation concept successfully or has an idea about changing my approach. If there isn't a clean way of doing this I can just keep starting my loops with a count++ when I want to count. Again this is more of a curiosity and someone may propose that one of the ideas I quibbled about is a perfectly reasonable approach or as good as it will get.