| Author |
 Topic  |
|
|
krismorness
Junior Member
11 Posts |
 Posted - Mar 17 2004 : 12:41:43 PM
|
Given the following code snippets...
//objectstatusbits.h
enum StatusType
{
#define __STATUS__(x) STATUS_##x
#include "statusbitslist.h"
#undef __STATUS__
STATUS_COUNT
};
const char* StatusBits::s_bitNameList[] =
{
#define __STATUS__(x) #x
#include "statusbitslist.h"
#undef __STATUS__
NULL
};
//statusbitslist.h
__STATUS__(COLD)
__STATUS__(HOT)
__STATUS__(SCARED)
//somefile.cpp
if( object->getStatus( OBJECT_STATUS_COLD ) )
{
printf( "%s", s_bitNameList[ OBJECT_STATUS_COLD ] );
...
}
Now VisualAssist doesn't recognize OBJECT_STATUS_COLD as an enum. We use the macro to also build a string value for INI parsing so everything is ensured to be in sync. We do this for several of our enums throughout our project. It would be great if we could get support for this!
|
|
|
support
Whole Tomato Software
5566 Posts |
Posted - Mar 17 2004 : 1:54:40 PM
|
Not possible. Unlike a top-down parser, VA X cannot #define and #undefine on the fly. VA X runs while you edit. It tries to remember every #define found, regardless of #undefining,
Your example is rather complex. Macros get #defined and #undefined. They make sense only if you process the file from top to the bottom. VA X does not process from top to bottom alone since you move all over the place and edit.
VA X assumes you want assistance when you are writing code that uses each of the #defines. Gasp. Take this simple example:
#ifdef FOO
int x;
#else
float x;
#endif
VA X remember both definitions of "x" since you need later to write the code when FOO is defined and when it is not. VA X does not refrain from helping when you write the #else code. |
Whole Tomato Software, Inc. |
 |
|
|
Uniwares
Tomato Guru
Portugal
2321 Posts |
Posted - Mar 17 2004 : 3:04:18 PM
|
But surprisingly the following macro works just fine:#define DEFINE_BOOL_VAL(x) \ private: bool m_b##x; \ public: bool x () { return m_b##x; }Thats a kind of simple Get and VA properly recognizes the variables defined with DEFINE_BOOL_VAL(SomeVal) as containingclass::m_bSomeVal. I'm using the same with various types of data members and VA never disappointed me.
|
|
|
|
support
Whole Tomato Software
5566 Posts |
Posted - Mar 17 2004 : 3:35:26 PM
|
DEFINE_BOOL_VAL() works because you do not #undef it and #define it differently in your code. VA X does not keep a list of the lines to which each version would apply. Instead, VA X would remember both versions, ie both #defines, and use the first regardless of subsequent #undefs and/or references.
VA X does not keep a list of lines because the ranges change as you edit. Ugly.
In cases where a macro is #defined multiple times yet one version, perhaps an entirely different version, adequately gives VA X the information it needs to provide reasonable Intellisense, we add the definition to Misc\\stdafx.h in the VA X installation directory and rebuild symbol database. The #defines in our stdafx.h are read before any other header is parsed. The definitions in our stdafx.h are used by the VA X parser in lieu of others in your code.
We have not looked at __STATUS__ example to see if one can create a different, non-changing #define to create the enums. Probably need more of the example, and some time. |
Whole Tomato Software, Inc. |
|
|
|
krismorness
Junior Member
11 Posts |
Posted - Mar 17 2004 : 6:16:16 PM
|
quote:
We have not looked at __STATUS__ example to see if one can create a different, non-changing #define to create the enums. Probably need more of the example, and some time.
What more info would you need? PS: I did miss the comma after the __STATUS__(x) lines!
I'm just imagining implementing a recursive parser that would build the VA enums. When looking at the wrapped header file, it seems reasonable that you could open up the include header, build the list and pop back out to the original header. Obviously this would have performance issues if you weren't doing parsing in such a manner.
But this could be overcome by having some custom Visual Assist tag in an include that would trigger such behavior:
//objectstatusbits.h
enum StatusType
{
#define __STATUS__(x) STATUS_##x,
#include "statusbitslist.h" //VA_RECURSIVE_PARSER_INCLUDE
#undef __STATUS__
STATUS_COUNT
};
Does that seem too hackish?
Even better... specifying a list of "recursively parsed headers" in some option area. |
Edited by - krismorness on Mar 17 2004 6:27:10 PM |
|
|
|
support
Whole Tomato Software
5566 Posts |
Posted - Apr 01 2004 : 08:41:02 AM
|
Much too hackish.
VA X will not try that hard to resolve your macro. In a sense, VA X considers the help it offers while you write the macro to be of some value. Consider it a bonus if VA X can resolve the macro, in a single pass, and use it to learn definitions of other symbols.
We imagined adding something on this order to our stdafx.h:
enum StatusType {
COLD,
HOT,
SCARED
};
|
Whole Tomato Software, Inc. |
|
|
| |
Topic |
|
Topic Locked
