| T O P I C R E V I E W |
| kennyl |
Posted - Jan 06 2014 : 03:46:15 AM
In the following example, the test_func is under #ifdef in its declaration. The problem is that another function underneath it (do_helloworld()) is not recognized by VA, you won't be able to find it in function list, in navigation bar it is shown as "test_func.do_helloworld".
#define TEST_MACRO
#ifndef TEST_MACRO
void test_func(int aa)
{
printf("old code");
// Uncomment the following #ifdef then this problem is gone
#ifdef SOME_OTHER_MACRO
printf("blablabla");
#endif // SOME_OTHER_MACRO
#else
void test_func(int aa, int bb)
{
printf("new code");
#endif
}
void do_helloworld()
{
printf("Hello World");
}
Kenny |
| 6 L A T E S T R E P L I E S (Newest First) |
| feline |
Posted - Jan 07 2014 : 1:13:14 PM
Currently VA parses all #ifdef blocks, which is by design. case=42316 is to add an option to turn off this behaviour, so VA is only considering and active in the active code, but I am not sure if / when this will be done.
Normally it is fairly clear which is the active and inactive code, but there are some interesting edge cases. I have seen header files where the first block is active in a.cpp, while the second block is active in b.cpp, both in the same project. Thankfully situations like this seem to be fairly rare.
Hopefully you have been able to apply the work around without any problems to your code, and are not seeing any problems now. |
| kennyl |
Posted - Jan 07 2014 : 09:12:59 AM
OK, I thought VA shouldn't parse branches in #ifdef block separately (if that's what you meant), in the perspective of a compiler/developer, there is no "invalid code" in my example.
Of course I understand that this could be really difficult to fix, and there is workaround anyway, it's acceptable.
Kenny |
| feline |
Posted - Jan 06 2014 : 8:49:00 PM
It depends on what you mean by fix this. If we continue to parse both sides of the #ifdef then we are going to see invalid code in this situation. Once we have hit invalid code, its not clear what the "fix" is. VA does try to recover from invalid code, but some types of invalid are harder to recover from than others.
An alternative fix would be to stop parsing all branches in a #if block, which we are considering adding an option for:
case=42316
but doing so would stop VA from helping you when working in inactive code. So that might help sometimes, but cause problems other times.
Or am I missing something, and you are thinking of some other type of fix? |
| kennyl |
Posted - Jan 06 2014 : 8:15:15 PM
quote:
Originally posted by feline
Dusan is correct, this problem is happening because VA is parsing both the #ifndef and #else blocks, so it is seeing unmatched curly braces, and getting confused.
This happens so that VA is active in, and can help you when writing code that is currently inactive, but it can cause problems in situations like this.
I actually know the workaround, thank you for providing this information anyway.
So you guys are not going to fix this? |
| feline |
Posted - Jan 06 2014 : 11:28:48 AM
Dusan is correct, this problem is happening because VA is parsing both the #ifndef and #else blocks, so it is seeing unmatched curly braces, and getting confused.
This happens so that VA is active in, and can help you when writing code that is currently inactive, but it can cause problems in situations like this. |
| Dusan |
Posted - Jan 06 2014 : 10:58:31 AM
If you just need workaround, try to place closing bracket } into each # block.
In other words, do not split function by macros as:
#if
void fnc(a, b)
{
#else
void fnc(a, b, c)
{
#endif
}
but do this:
#if
void fnc(a, b)
{
}
#else
void fnc(a, b, c)
{
}
#endif
HTH
|
|
|
