| Author |
 Topic  |
|
|
Dolphiniac
New Member
4 Posts |
 Posted - Oct 12 2021 : 11:32:10 AM
|
Posted - Oct 12 2021 : 11:32:10 AM Show Profile Reply with Quote
I'm working in C and have a set of "template" wrapper functions for a container type, implemented with a macro. As the container has grown in functionality, of course, I've needed to add more functions, and I've noticed something relatively strange. At a certain point, VAX seems to completely give up on the macro and takes out all of the autocomplete suggestions.
It looks a little like this:
#define QULIST_IMPLEMENT_TYPE( prefix, type, handle )
QU_DEFINE_HANDLE( handle );
typedef struct prefix##_CopyElementFunctor_t {
void ( * CopyFunc )( type * const dst, const type * const src, void * const param );
void * param;
} prefix##_CopyElementFunctor_t;
typedef struct prefix##_FindFunctor_t {
quBool ( * FindFunc )( const type * const elem, void * const param );
void * param;
} prefix##_FindFunctor_t;
typedef struct prefix##_ForEachFunctor_t {
void ( * DoFunc )( type * const elem, void * const param );
void * param;
} prefix##_ForEachFunctor_t;
typedef struct prefix##_SortFunctor_t {
void ( * CompareFunc )( const type * const elemA, const type * const elemB, void * const param );
void * param;
} prefix##_SortFunctor_t;
inline static handle prefix##_Create( quList * const sys, quMemory * const memorySystem ) {
return QU_CONVERT_HANDLE( sys->Create( sys, sizeof( type ), memorySystem ), handle );
}
inline static handle prefix##_CreateFromListRangeWithFunctor( quList * const sys, const handle list, const U32 startIndex, const U32 count, const prefix##_CopyElementFunctor_t * const functor ) {
return QU_CONVERT_HANDLE( sys->CreateFromListRangeWithFunctor( sys, QU_CONVERT_HANDLE( list, list_o ), startIndex, count, ( const quList_CopyElementFunctor_t * )functor ), handle );
}
// contd.
Beyond the types, I've implemented 17 wrapper functions; just the signature and a passthrough on the provided interface pointer. It doesn't seem ridiculous to me to expect not only what is there, but quite a bit more, to be recognized.
But as I added the last function (and the sort functor type), everything stopped being parsed; the existing calls I had in other source files turned back to white as the syntax highlighter stopped recognizing the symbols, and suggestions stopped working. The kicker, though, was when I did a find and replace in the macro, changed "prefix" to "p", "type" to "t", and "handle" to "h" and everything (including the new function and type) worked again. But I can only do this so much. Is there anything I can do to not run afoul of what appears to be a character-based parsing limit?
EDIT: Formatting. There are escape backslashes at the end of each line in the original, but it seemed to break stuff here. |
Edited by - Dolphiniac on Oct 12 2021 11:42:42 AM |
|
|
feline
Whole Tomato Software
United Kingdom
19066 Posts |
Posted - Oct 12 2021 : 1:12:35 PM
|
There are some limits in our parser about how long a "thing" we will process, and it looks like this is what you are running into. This is partly done for performance reasons. The compiler can take a "long" time, but we need to produce usable, if not perfect, results as fast as possible.
Is this macro fairly stable, or constantly in flux? Assuming it is fairly stable, at least in terms of the symbols you would like VA to know about, my first thought here is to work around the problem using the "va_stdafx.h" file. Wen rebuilding its symbol database, if a file with this name is found in the same directory as your SLN or VCXPROJ file then VA parses this file first, and uses the information in the file to help its parser make sense of your code.
This can also be done to tell VA that certain symbols exist in your solution.
Which symbols is VA having problems picking up from this? I ask, since there is a known limitation that VA doesn't "expand" macros that use # to join two strings together to make a new symbol name. This is related to the fact that we are parsing your code "as is" and not getting to preprocess it and expand all of the macros.
Assuming that the following would be useful to tell VA:
struct struct list_CopyElementFunctor_t {
void ( * CopyFunc )( type * const dst, const type * const src, void * const param );
void * param;
};
struct list_FindFunctor_t {
quBool ( * FindFunc )( const type * const elem, void * const param );
void * param;
};
create a new text file called "va_stdafx.h", place it in the same directory as your SLN file, paste this code into the file, making sure the file ends with a blank line and save it out.
To make sure VA picks up the file press the button:
VA Options -> Performance -> Rebuild symbol databases
and restart your IDE. |
zen is the art of being at one with the two'ness |
 |
|
|
Dolphiniac
New Member
4 Posts |
Posted - Oct 12 2021 : 1:33:18 PM
|
It didn't seem to have any trouble picking up the concatenated versions before I hit the limit. As it stands, the macro only changes when I update the list interface, which is relatively seldom, so I wouldn't mind if I needed an extra step for proper tooling copying the changes to the stdafx.h. However, the instantiations are arbitrary and happen about as often as a template declaration would in C++ (as it is the rough equivalent of what I'm doing). That would be quite a bit more cumbersome to copy.
I did look into using va_stdafx.h before (I ran into the same problem earlier when "prefix" was called "listPseudoTypename") and it didn't seem to affect anything, though if the expectation would be to instantiate the type explicitly in this file, that would explain it. |
|
|
|
Dolphiniac
New Member
4 Posts |
Posted - Oct 12 2021 : 2:07:20 PM
|
After a little more digging, I was able to use va_stdafx.h to help out a little bit. I reimplemented the macro for it using the shortest names I could (p, t, h), eliminating as much whitespace as possible, and providing the shortest version of the function signatures, which would still allow the suggestion box to have the correct information while leaving the full implementation unchanged in the proper place, making room for more things, and it seems to patch up the problem.
If it should get a lot longer, it will probably break again, and if I might make a request for future versions, I would suggest a) unbounded macro parsing in at least the va_stdafx.h, b) an option to increase the limit, even if only in the registry, or c) some way to opt into unbounded parsing for whitelisted macros. |
|
|
|
feline
Whole Tomato Software
United Kingdom
19066 Posts |
Posted - Oct 13 2021 : 09:39:44 AM
|
Thank you for the update, and I am glad you have this working for now.
Would it be possible to get a copy of the macro, purely for testing purposes? It would save me constructing a suitably long macro. Putting in some form of allowance for longer macros is reasonable, the trick is to try and do it without to many performance side effects.
If it is possible to get the full macro you can send me the files via email:
[email protected]
including this thread ID or URL in the description, so we can match it up. This way no need to post it here. |
zen is the art of being at one with the two'ness |
Edited by - feline on Oct 13 2021 09:40:26 AM |
|
|
| |
Topic |
|
|
|
Macro text length limit
