| T O P I C R E V I E W |
| StefanEgo |
Posted - Jan 02 2012 : 07:44:59 AM
Hi,
steps to reproduce the issue:
1. Create a new sample project using VS 2005 (SP1) - tested with VAX build 1862
2. copy paste the sample code into a single file in that project
namespace XLib
{
template<class T> class Foo
{
private:
T* PointTo;
T* operator->() const { return PointTo; }
}
}
namespace U
{
class Bar
{
void foo() {}
};
#define RAWCOMPONENTCLASS \ LOOKUPTEXT("bar", COMPONENTCLASS_BAR, Bar)
#define LOOKUPTEXT(key,value,Class) class Class;
RAWCOMPONENTCLASS
#undef LOOKUPTEXT
#define LOOKUPTEXT(key,value,Class) \ typedef XLib::Foo<Class> Class##Ptr;
RAWCOMPONENTCLASS
#undef LOOKUPTEXT
}
namespace U
{
BarPtr test()
{
BarPtr p;
p->
return nullptr;
}
}
3. Wait until VAX finished parsing the file.
Actual result:
see screenshot and note that:
1) is only displayed in black
2) does not display a tooltip when writing ->
further issues:
- moving the cursor on-top of BarPtr (in line 33) and pressing ALT+G does not jump to the definition of the Player class
- Right-clicking on BarPtr and choosing "Refactor -> Find references" reports "Find References is not available because the symbol is unrecognized."
Expected result:
1) BarPtr should be displayed in blue
2) should display foo() in the selection box when writing ->
Note that when commenting-out the code block in line 20-22 (marked as no 3) in the screenshot), everything seems to work just fine.
This sample is a stripped-down code snippet to present the (or at least one of the) issue(s) we'r dealing with in a larger project.
If this is an issue caused by VAX failing to parse our code structure, would there be a workaround we could use?
Regards,
Stefan |
| 7 L A T E S T R E P L I E S (Newest First) |
| accord |
Posted - Jan 06 2012 : 10:01:10 AM
Sorry for this. It seems, there is no workaround for this problem. I added a comment to case=63704 with our experiences with the workaround experiments. |
| StefanEgo |
Posted - Jan 06 2012 : 04:48:27 AM
The problem here is that our defines are mostly located in different header files. Since you mentioned that VA parses defines in headers as global definitions, I guess that won't work for us (actually I've just tried to play around with that idea, but failed to get VAX to better parse our source). |
| accord |
Posted - Jan 04 2012 : 8:18:31 PM
I have an another idea. If you start using a non-existing macro like VA_HELPER_CODE, you can do the following:
#ifdef VA_HELPER_CODE
#define LOOKUPTEXT(key,value,Class) \ typedef XLib::Foo<Class> Class##Ptr;
#endif
#define RAWCOMPONENTCLASS \ LOOKUPTEXT("bar", COMPONENTCLASS_BAR, Bar)
#define LOOKUPTEXT(key,value,Class) class Class;
RAWCOMPONENTCLASS
#undef LOOKUPTEXT
#define LOOKUPTEXT(key,value,Class) \ typedef XLib::Foo<Class> Class##Ptr;
RAWCOMPONENTCLASS
#undef LOOKUPTEXT
}
(the black code is added)
It will help if you have different definitions in different files, but a similar structure like your posted code snippet.
VA_HELPER_CODE is just a "random" name, the point is to use something that is not already defined in your solution. So the compiler will skip this part, but VA will parse it and stick to the definition. (VA parses inactive codes so, for example, it can help in release codes when you use a debug config, etc.)
This will work if your defines are in cpp files, since VA handles defines as per-file in cpps and as a global definition in headers, as far as I know.
I wasn't able to convince this solution previously. |
| StefanEgo |
Posted - Jan 04 2012 : 03:10:49 AM
Thanks for the suggestion. Unfortunately, as you already guessed this won't be a viable option for us, since the LOOKUPTEXT-macro is scattered alot through our code base with several different definitions.
I guess I'll have to wait for the case to be taken care of in an upcoming VAX build then. |
| accord |
Posted - Jan 03 2012 : 6:41:50 PM
Since VA only accepts one define per session AND #undef don't seem to work, you can use a workaround here.
When VA is (re)building its symbol databases, it always starts the parsing with a special file, that is seen only by VA. If you put here you own #define, it will help VA. For example, it would be the following for your posted test code:
#define LOOKUPTEXT(key,value,Class) \ typedef XLib::Foo<Class> Class##Ptr;
So when your code tries to redefine LOOKUPTEXT, it won't be able to. The given definition will be used in you whole source. So it may not be viable for you depending on how you use the define.
The location, the name and additional helpful info about this first-to-be-parsed VA file can be found here:
http://docs.wholetomato.com?W302
Tricks like VA_HELPER_CODE won't help here, I think. |
| StefanEgo |
Posted - Jan 02 2012 : 08:28:04 AM
It works in this sample project, but is unreliable in our larger project. By unreliable I mean that sometimes it works and sometimes (i.e. in most cases) it won't. So this isn't a usable option for us unfortunately.
Would using the VA_HELPER_CODE macro somehow help VAX to parse that construct? I've tried to enacapsulate line 20-23 in an ifndef-VA_HELPER_CODE-block without much success, though. |
| accord |
Posted - Jan 02 2012 : 08:22:41 AM
It seems VA is having problems with the #undef directive. I have put in a bug report for this:
case=63704
For now, can you please try turning on
VA Options -> Advanced -> Listboxes -> Get content from default intellisense
as a workaround to see if it helps? If Visual Studio's intellisense can understand the code, the listbox after p-> should work, at least. |
|
|
