Whole Tomato Software Forums

Whole Tomato Software Forums

All Forums

Visual Assist

Technical Support

#pragma push/pop blocks hide members

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

Screensize:

UserName:

Password:

Format:

Message:

Forum code is on.
Html is off.

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

T O P I C R E V I E W
Kram	Posted - Dec 06 2021 : 10:09:28 AM Hello Support, List of methods for the following example code does not show f2. class t1 { void f1() { } #pragma warning (push) #pragma warning (disable : 26434) void f2() #pragma warning (pop) { } #pragma warning (push) #pragma warning (disable : 26434) void f3() { } #pragma warning (pop) };
5 L A T E S T R E P L I E S (Newest First)
feline	Posted - Dec 16 2021 : 07:29:39 AM Ah, an interesting work around, than you for posting this It makes sense when you see it, but I am not sure I would have thought of that in a hurry. Hopefully this will help you in the cases you need to do this, until we get this bug in VA fixed.
Kram	Posted - Dec 16 2021 : 01:33:58 AM As a workaround, placing the pragma at the top of the function body statement block works, see f4: class t2 { void f1() { } #pragma warning (push) #pragma warning (disable : 26434) void f2() #pragma warning (pop) { } #pragma warning (push) #pragma warning (disable : 26434) void f3() { } #pragma warning (pop) #pragma warning (push) #pragma warning (disable : 26434) void f4() { #pragma warning (pop) } };
feline	Posted - Dec 15 2021 : 09:11:24 AM I have a work around for a macro version of this bug, where it is a macro between the function signature and the start of the body, but trying to use a macro to replace the #pragma warning (pop) line is refusing to compile for me. Apparently #pragma lines are considered before macros are expanded, which is stopping this otherwise nice idea from working.
Kram	Posted - Dec 14 2021 : 1:21:25 PM 30 or 40. It's project containing a lot of legacy MFC code. The MFC class construction and default usage generates these warnings when compiled with newer toolchains. They are related to the function definition and inheritance / polymorphism. The problem is that 26434 is a very generic. This is the reason why I placed it is round on the function definition part of the implementation. I do no want to blanket supress 26434 warnings in the rest of the code.
feline	Posted - Dec 14 2021 : 11:56:54 AM I am seeing the same effect here. Thank you for the clear description. case=11545 Are you seeing a lot of cases like this in your code, or just a few? Basically VA's parser does not expect there to be anything between the signature line and the actual body of the function, and gets confused when there is.

Snitz Forums 2000