I don't necessarily see how this problem in VC would affect a standards-compliant compiler; in fact, wouldn't the converse hold true, ie. code that compiles in a standards-compliant compiler would break VC, at least in regard to this kind of scoping? For example:
for (int i = 0; i < 8; i++)
;//... fun stuff in here
for (int i = 0; i < 8; i++)
;//... even more fun stuff
This would compile correctly in a standards-compliant compiler, but VC would complain that this involved some sort of redeclaration of 'i'.
Now, if I was working in VC and needed to do a quick workaround, couldn't I just wrap these in their own independent set of braces? Or maybe, in a more hackish fashion, declare some sort of macro that attached 'if (true)' to the beginning of 'for' loops? Even if I did the old VC standby, for example:
int i; for (i = 0; i < 8; i++)
;//... stuff
for (i = 0; i < 8; i++)
;//... more stuff
The only code I could imagine that this would break, at least in a standards-compliant compiler, would be code involving a previous declaration of 'i' (before or after this example section of code), but this would also break the code within VC, so it would have been caught beforehand, correct?
This would compile correctly in a standards-compliant compiler, but VC would complain that this involved some sort of redeclaration of 'i'.
Now, if I was working in VC and needed to do a quick workaround, couldn't I just wrap these in their own independent set of braces? Or maybe, in a more hackish fashion, declare some sort of macro that attached 'if (true)' to the beginning of 'for' loops? Even if I did the old VC standby, for example:
The only code I could imagine that this would break, at least in a standards-compliant compiler, would be code involving a previous declaration of 'i' (before or after this example section of code), but this would also break the code within VC, so it would have been caught beforehand, correct?