| Author |
 Topic  |
|
|
znakeeye
Tomato Guru
379 Posts |
 Posted - Jan 12 2008 : 7:54:51 PM
|
I remember sending a post about this before, but then I didn't know what was going on. Take a look!
// Compile with /Zc:forScope (default in VS 2005 and later)
for (std::vector<CMyClass1>::iterator iter = V.begin(); iter != V.end(); ++iter)
{
iter->MyClassMethod1();
}
for (std::list<CMyClass2>::iterator iter = L.begin(); iter != L.end(); ++iter)
{
iter->MyClassMethod2();
}
MyClassMethod2 is not recognized! I've also seen another variant, where both MyClassMethod1 and MyClassMethod2 are recognized even though MyClassMethod1 is invalid in this context. |
|
|
feline
Whole Tomato Software
United Kingdom
19022 Posts |
Posted - Jan 14 2008 : 2:14:21 PM
|
the comment:
// Compile with /Zc:forScope (default in VS 2005 and later)
bothers me quite a bit. Anything that is based around picking up project settings can be "tricky", since the settings can change between release and debug mode.
Also what about people who do not have a real project? Anyone compiling under Linux, or using a different compiler / build chain, will have these settings set somewhere completely different, and inaccessible to VA. |
zen is the art of being at one with the two'ness |
 |
|
|
znakeeye
Tomato Guru
379 Posts |
Posted - Jan 14 2008 : 7:01:57 PM
|
Sorry, I won't give up on this one ;)
From MSDN: "Standard behavior is to let a for loop's initializer go out of scope after the for loop."
Hence, you assume non-standard behavior when parsing. I mentioned the switch just to let you decide if you should support the old style too. |
|
|
|
gmit
Whole Tomato Software
Croatia
90 Posts |
Posted - Jan 15 2008 : 05:56:43 AM
|
This could probably be fixed by putting
#define for if(false) {} else for
into misc/stdafx.h (or misc/stdafxed.h?), since it enforces conformant behaviour on non-conformant compilers.
However, it certainly won't depend on compiler switch setting.
|
|
|
|
feline
Whole Tomato Software
United Kingdom
19022 Posts |
Posted - Jan 15 2008 : 3:12:56 PM
|
From memory at my last job, when we moved from VS2003 to VS2005 we were told about this change, since some of the existing code relied on the variable being in scope after the loop. It was never clear if this effect in our code was design or not.
Which means we have to start knowing which compiler you are using, and how it is configured, in order to work out how to parse the code. There are a lot of times when this information is not really available to us.
Can you see why I am wary about this? The alternative is adding an option to VA for this, but does this then open the door to any other optional compiler behaviours people are using? |
zen is the art of being at one with the two'ness |
|
|
|
gmit
Whole Tomato Software
Croatia
90 Posts |
Posted - Jan 15 2008 : 5:04:13 PM
|
If you ask me, VA should have fool proof parsing in a way that if an identifier is declared twice, second declaration overrides first.
A *a;
a->autocomplete_A_members
B *a;
a->autocomplete_B_members
I think it would cover both for cases in a good way.
|
|
|
|
mwb1100
Ketchup Master
82 Posts |
Posted - Jan 15 2008 : 5:04:48 PM
|
FWIW, if you want there to be no configuration/option for this my vote is to have VA follow the current standard even if it's 'wrong' with older environments. VA's justification for this would be that it had to keep up with the times (just like MS eventually did).
One other possible way to avoid an option is to follow the default of the compiler version (VS2005 or later use the standard, otherwise use the Microsoft default of having the var stay in scope after the for statement).
|
|
|
|
znakeeye
Tomato Guru
379 Posts |
Posted - Jan 16 2008 : 01:08:48 AM
|
| I agree with gmit. This is a general problem in VAX. Like gmit said; all declarations should override the previous ones. This is part of C++. |
|
|
|
feline
Whole Tomato Software
United Kingdom
19022 Posts |
Posted - Jan 17 2008 : 3:22:18 PM
|
For *valid* code I tend to agree. My concern is that a lot of the time while editing we are asking VA to work on "invalid" code. Missing brackets, statements half written, etc. Re-using the same variable name in different conditional blocks / functions is common practice...
The more I think about this, the more sense this makes. I have put in a feature request for this.
case=11502 |
zen is the art of being at one with the two'ness |
|
|
| |
Topic |
|
Force Conformance In For Loop Scope
