13 Mar, 2009, tphegley wrote in the 21st comment:
Votes: 0
Banner said:
Patronization now. Awesome.


Not hardly.
13 Mar, 2009, David Haley wrote in the 22nd comment:
Votes: 0
Lobotomy said:
Under the above setup, the iterator name has to be given every time. However, if I had the __COUNTER__ macro, I could then safely omit the iterator argument and let it handle that under the hood without it presenting an issue to nesting as each loop would be given its own uniquely-named iterator to use.

Huh, I guess I shouldn't be surprised that you're working on an area that is a particular pain point in the language. :wink:

Here's something you could try. The loop variable – 'thing' in this case, the variable that contains the element of the list being traversed – is presumably unique within its scope of "nested loops". That is, you won't be nesting a loop that assigns to that variable. Since the user has to pass that in, why not simple use the name <loopvariable>__iter__ or something like that? E.g., when you call:
loop_list( some_list, thing )

it will create, instead of "iter", thing__iter__.
You could also throw in the list name, so that would be thing__some_list__iter__.

This should work in macros that expand to loops etc. (but IMO those are getting complex enough to warrant functions).

It might give you trouble if you reuse the same variable in two loops on the same level, because it would try to declare the same iterator variable twice. In that case you could through __LINE__ in, and this should still work in the macros-that-have-loops case (unless those also have macros on the same level with the same loop var, etc. – but then I really think they shouldn't be macros anymore).
13 Mar, 2009, Lobotomy wrote in the 23rd comment:
Votes: 0
I very much appreciate those ideas, DavidHaley. For the time being, I'll try putting those methods to use in place of the counter macro and see if I still somehow manage to have any problems. At the very least (in the test I just ran), the compiler complains if there is more than one loop being called in a macro (or series of macros) with the same list and element names (shadowed local declaration warnings), so it won't exactly be something that can slip by silently. :thinking:

Also, tphegley, I appreciate your offer to be hosted with your (LooHosting, right?) service. I will be keeping that host in mind should unresolvable complications of not having access to a higher version of GCC arise in the future.
13 Mar, 2009, tphegley wrote in the 24th comment:
Votes: 0
Lobotomy said:
Also, tphegley, I appreciate your offer to be hosted with your (LooHosting, right?) service. I will be keeping that host in mind should unresolvable complications of not having access to a higher version of GCC arise in the future.


No problem.
14 Mar, 2009, Guest wrote in the 25th comment:
Votes: 0
Drop the EvilEye advertisment subject. You've all made your point. Move on.
14 Mar, 2009, Fizban wrote in the 26th comment:
Votes: 0
Samson said:
Drop the EvilEye advertisment subject. You've all made your point. Move on.


I thought other administrators were supposed to be moderating the forums.
14 Mar, 2009, David Haley wrote in the 27th comment:
Votes: 0
Please, let's not start that. Besides I think that anybody has a right to ask that this discussion just die already. So let's all work together, what say you? :wink:
14 Mar, 2009, Guest wrote in the 28th comment:
Votes: 0
Sorry, we're not going down this road again.
20.0/28