| T O P I C R E V I E W |
| endgame |
Posted - Oct 10 2006 : 12:54:07 PM
All,
I don't know if this is a known issue, but here goes.
The following code causes parsing issues for VAX (all versions I tried):
#define TRY try {
#define TRY1 TRY
#define CATCH } catch(...)
void foo(int arg)
{
int var1 = arg;
TRY1
{
int var2 = arg;
}
CATCH
{
int var3 = arg;
}
int var4 = arg;
int var5 = var1;
}
VAX fails to understand where arg and var1 came from in the last three code lines. This is due to use of #define in depth of two.
If I use the macro TRY directly, all is well.
Thanks,
Ofer |
| 6 L A T E S T R E P L I E S (Newest First) |
| feline |
Posted - Oct 25 2006 : 12:56:48 PM
From the point of view of the parser, once it has lost context all bet's are off, since the code is "invalid" and will not compile.
In my experience VA is remarkably reliable while writing new code, even when the brackets do not match, but in the middle of a new function with unbalanced brackets I expect lots of things to be underlined as mistyped symbols. This helps to remind me to go and fix my brackets before starting a long compile  |
| endgame |
Posted - Oct 25 2006 : 07:32:48 AM
Fair enough.
Nulling through stdafx.h works for me as well.
Isn't this still a bug? failure to parse is one thing, making all the code afterward to lose context is another thing.
|
| support |
Posted - Oct 12 2006 : 1:42:10 PM
We retried the example and get the behavior you get. Not sure what happened the first time we tried.
We get around the problem by "nulling" the macros that effect context in our stdafx.h and rebuilding symbol databases:
#define PR_TRY
#define PR_TRY1
#define PR_CATCH
The example then works fine. |
| feline |
Posted - Oct 12 2006 : 07:41:36 AM
endgame I am seeing the same thing as you on your first example. I will ask support, I am not sure what the difference is either. |
| endgame |
Posted - Oct 11 2006 : 09:50:20 AM
Hi,
To start off, using parens solves the problem.
On my machine, manual reparsing doesn't solve the problem, and arg and var1 aren't recognized.
I can't change the code and although the stdAfx.h solution works, it is far from perfect.
I tried a slightly different code, but still no good. Do you have any idea why VAX fails on my machine and succeeds on yours?
#define PR_TRY try {
#define PR_TRY1 PR_TRY
#define PR_CATCH } catch(...)
void foo(int arg)
{
int var1 = arg;
PR_TRY1
{
int var2 = arg;
}
PR_CATCH
{
int var3 = arg;
}
int var4 = arg;
int var5 = var1;
}
|
| support |
Posted - Oct 10 2006 : 1:42:29 PM
As you've discovered, there is a limit to the depths of parsing VA X does to resolve symbol definitions and scope. (Much of this is by design since you rarely want to know the final C version of a definition that uses macros.)
Macros the end in parens are parsed to a deeper level, even if there aren't any arguments within the parens.
You might also want to see the paragraph titled "Errant Context" at the bottom of:
http://www.wholetomato.com/products/features/context.asp
We assume you're using VC++ 6.0 since CATCH is already #defined in VS.NET 2003 and VS2005.
We try your example as-is and VA X recognized the reference to var1 after we copied, press Enter and waiting for parsing. (Manual reparse also did the trick.)
We tried also an example with parens that got resolved quicker, i.e. without the manual reparse.
More importantly, when you need to deal with macros in code you don't own or can't change, you might add definitions that supercede all others to StdAfx.h in the Misc subdirectory of the VA X installation directory. Typically, you #define your complex macros to nothing to make VA X ignore them during edit.
Make sure you press Rebuild on the performance node of the VA X options dialog and restart your IDE after changing StdAfx.h, and to reapply your changes after installing a new build of VA X.
|
