| T O P I C R E V I E W |
| Rasmuss |
Posted - Jun 14 2007 : 04:02:27 AM
We have a multitude of defines pointing to defines in our code, and VAX does nothing when using Goto Implementation.
I suspect you simply don't parse defines of defines, but it would be very helpful if you could parse 2 or maybe 3 levels.
Test code
class TestClass1
{
public:
void TestFunc();
};
class TestClass2
{
public:
TestClass1 m_pTest1;
};
TestClass1 g_Test1;
TestClass2 g_Test2;
#define TESTDEFINE1 g_Test1
#define TESTDEFINE2 g_Test2
#define MEMBERTESTDEFINE TESTDEFINE2->m_pTest1
main()
{
TESTDEFINE1->TestFunc(); // Goto works
TESTDEFINE2->m_pTest1; // Goto works
MEMBERTESTDEFINE->TestFunc(); // Goto does not work
}
Best regards,
Rasmus |
| 8 L A T E S T R E P L I E S (Newest First) |
| feline |
Posted - Jun 18 2007 : 10:16:38 AM
Somehow this does not surprise me 
I have put a note on the case about this, the alt-g menu is the most sensible solution, once VA understands what is happening here. |
| Rasmuss |
Posted - Jun 18 2007 : 03:43:51 AM
quote:
Originally posted by feline
One answer is the code:
#ifdef DAY_IS_WEDNESDAY
#define MEMBERTESTDEFINE TESTDEFINE2->m_pTest1
#else
#define MEMBERTESTDEFINE TESTDEFINE2->m_pTest2
#endif
I agree that this sort of code causes problems, and it would be good to see these bugs fixed. However some macro code presents fairly serious challenges to VA, especially since VA does not automatically know the state of DAY_IS_WEDNESDAY
Would it not be possible to present both cases in the goto drop down? Like it is done when choosing between a function with multiple parameter implementations. This would be very helpful since we have these kinds of differing defines for the various platforms. |
| feline |
Posted - Jun 16 2007 : 1:12:33 PM
The simple problem with recursive defines is they do not have to be straight forward, so a parser change to handle them is not automatically going to be straight forward either. This was all I was trying to say.
Sometimes people use macro's to achieve quite complex things, making the final code, by definition, quite complex. |
| accord |
Posted - Jun 15 2007 : 3:26:06 PM
I see.
But I am talking about recursive defines, like in Rasmuss's example:
#define TESTDEFINE2 g_Test2
#define MEMBERTESTDEFINE TESTDEFINE2->m_pTest1
Our code has a LOT of them. |
| feline |
Posted - Jun 15 2007 : 2:36:17 PM
One answer is the code:
#ifdef DAY_IS_WEDNESDAY
#define MEMBERTESTDEFINE TESTDEFINE2->m_pTest1
#else
#define MEMBERTESTDEFINE TESTDEFINE2->m_pTest2
#endif
I agree that this sort of code causes problems, and it would be good to see these bugs fixed. However some macro code presents fairly serious challenges to VA, especially since VA does not automatically know the state of DAY_IS_WEDNESDAY |
| accord |
Posted - Jun 14 2007 : 6:38:37 PM
Agree 
Flatting a lot of recursive define stuff is tiring... 
..and believe me, we have a LOT of them 
If this, and "## in defines" bug will be fixed, VAX will be able to parse any source code (without need to rewrite a lot of defines)
If someone who do not knows about the magic stdafx.h tries your trial with a code using recursive defines, will think that your product do not work.
It took half a year for me to figure out why VAX parser do not work at all on a source code with recursive defines (with a lot of ## of course... )
So I suggest you to hunt down this 2 bug asap. It may boost your sales also.
What do you think? Maybe source codes causing this 2 bugs are uncommon? |
| Rasmuss |
Posted - Jun 14 2007 : 08:55:32 AM
Thank you for your quick reply. I'll try out the method in the FAQ, but since we have _a lot_ of these defines I will hope for a speedy resolution of the case :) |
| feline |
Posted - Jun 14 2007 : 08:42:08 AM
I am seeing the same effect here. Thank you for the clear description.
case=7079
For now if you edit VA's "StdAfx.h" file as explained in this FAQ entry:
http://docs.wholetomato.com?W302
and add the entry:
#define MEMBERTESTDEFINE g_Test2.m_pTest1
at the bottom. This file is used to help VA's parser with difficult code, and can be used to work around odd effects. After modifying this file you need to rebuild the VA symbol database for the changes to take effect:
VA Options -> Performance -> General -> Rebuild symbol databases
I have tested this here, and it works for me with VA 1557. The problem here is that you need to add an entry for each problem macro, but once you have added them they are there. |
