Whole Tomato Software Forums

Whole Tomato Software Forums

All Forums

Visual Assist

Technical Support

C++: Multiple macro's defining a single statement

You must be registered to post a reply.
Click here to register.

Screensize:

UserName:

Password:

Format:

Message:

Forum code is on.
Html is off.

[quote][i]Originally posted by ramon.verbruggen[/i]
[br]Hi all,

It's my first post to these forums so please be gentle [;)]

I'm using Visual Assist X 10.4.1624.0 with Visual Studio 2005. Our project is > 2M lines of C++ code.

In places we use a construction with macros where one macro starts a statement, then some code or parameters is specified, and another macro is used to end the statement.

In a simplified form:
[code]
#define INIT_BEGIN(nr) static void init_##nr(QInit& init); \                       static QInit init_##nr(&init_##nr); \                       static void init_##nr(QInit& reg) { reg.LazyInit (

#define INIT_END ; };
[/code]

Actual usage of these macro's:

[code]
INIT_BEGIN(4)
     "Extra parameters to LazyInit go here",
     true,
     NULL
INIT_END
[/code]

This construction seems to confuse Visual Assist very much, i.e. there is no completion available in a file after these macros have been used.

Admittedly this is very creative [:o)] use of C++ preprocessor macros, but it would be *greatly* appreciated by all our developers if this construction was handled correctly.

Best regards,

Ramon Verbruggen 
Quintiq
The Netherlands.
[/quote]

Check to include your profile signature.
Check to subscribe to this topic.

T O P I C R E V I E W
ramon.verbruggen	Posted - Jan 15 2008 : 04:50:38 AM Hi all, It's my first post to these forums so please be gentle I'm using Visual Assist X 10.4.1624.0 with Visual Studio 2005. Our project is > 2M lines of C++ code. In places we use a construction with macros where one macro starts a statement, then some code or parameters is specified, and another macro is used to end the statement. In a simplified form: #define INIT_BEGIN(nr) static void init_##nr(QInit& init); \ static QInit init_##nr(&init_##nr); \ static void init_##nr(QInit& reg) { reg.LazyInit ( #define INIT_END ; }; Actual usage of these macro's: INIT_BEGIN(4) "Extra parameters to LazyInit go here", true, NULL INIT_END This construction seems to confuse Visual Assist very much, i.e. there is no completion available in a file after these macros have been used. Admittedly this is very creative use of C++ preprocessor macros, but it would be greatly appreciated by all our developers if this construction was handled correctly. Best regards, Ramon Verbruggen Quintiq The Netherlands.
5 L A T E S T R E P L I E S (Newest First)
ramon.verbruggen	Posted - Jan 15 2008 : 10:54:33 AM quote: Originally posted by Uniwares Ramon: Just a suggestion on this really ugly (sorry, cant call that creative anymore) contruct: make it a C++ template and get rid of the macros (search and replace with RegEx will do the job automatically) Hi Andreas, I agree with you on the aesthetical aspects , but since this is static initialization code, I don't really see how to replace it with a template. Since we're using the ## operator to create names (definitions), it will IMO be especially hard to replace!
Uniwares	Posted - Jan 15 2008 : 10:43:37 AM Ramon: Just a suggestion on this really ugly (sorry, cant call that creative anymore) contruct: make it a C++ template and get rid of the macros (search and replace with RegEx will do the job automatically)
feline	Posted - Jan 15 2008 : 10:11:56 AM case=3873 is simply the bug number assigned to this in our bug tracking system. This is definitely on our list of things to fix. It seems to be behind various bugs and problems with complex macro's, so it will be nice when this is fixed. Unfortunately I don't have any estimate on when it will be done.
ramon.verbruggen	Posted - Jan 15 2008 : 09:59:26 AM Thanks for the quick reply! A quick search turned up that we those specific macros 1300 times in our code, and a search for '##' shows that we use that specific construction no less than 733 times. Interestingly not all of those constructions seem to cause problems. Is that what you mean with 'when using ## to construct names'? I have searched the wholetomato site for this case 3873 but I can't seem to find more information about this. Is this issue planned to be fixed? If so, when? Thanks again, Ramon
feline	Posted - Jan 15 2008 : 09:30:21 AM Unfortunately VA's parser is confused by macro's that use ## to construct names: case=3873 Do you only use this macro occasionally, or do you use it quite often? If it is only used occasionally it might be possible / reasonable, to add some dummy helper code that VA can understand to help it make sense of the code involved.

Snitz Forums 2000