Author |
Topic |
|
khb
Tomato Guru
Germany
337 Posts |
Posted - Apr 09 2017 : 4:27:16 PM
|
I used Code Inspection to replace all occurrences of NULL by nullptr in my MFC code. However, I then noticed that still some occurrences are left. All those occurrences are within ASSERT macros, for example:
ASSERT(pointer != NULL); Are macros ignored by design or can this be fixed?
Kind regards, Marcus |
|
accord
Whole Tomato Software
United Kingdom
3287 Posts |
Posted - Apr 09 2017 : 7:53:52 PM
|
I was able to fix an ASSERT like this with my code.
- Are the instances underlined but not fixed or they aren't even underlined? - If you remove the ASSERT part from an instance where it fails, just for testing, does it start working? - What version of Visual Studio and Visual Assist are you using? - Can you please try creating a clean new win32 project and paste the below code to see if you can reproduce the problem there?
void func()
{
int* a;
a = NULL;
ASSERT(a != NULL);
}
|
Edited by - accord on Apr 09 2017 7:58:38 PM |
|
|
khb
Tomato Guru
Germany
337 Posts |
Posted - Apr 10 2017 : 12:38:44 PM
|
I'm sorry for being unclear.
quote: Are the instances underlined but not fixed or they aren't even underlined?
The NULL instances in the ASSERT statements are not even underlined.
quote: If you remove the ASSERT part from an instance where it fails, just for testing, does it start working?
If I remove the ASSERT, but leave its argument in the code, then the contained NULL gets properly underlined.
quote: What version of Visual Studio and Visual Assist are you using?
VS 2012, VA 2212.
quote: Can you please try creating a clean new win32 project and paste the below code to see if you can reproduce the problem there?
If I do that, then your code snippet works for me. However, it doesn't work if I copy it into my real project. I copied your code snippet at different locations in my project, but the NULL macro inside the ASSERT statement still doesn't get underlined. (The NULL in a = NULL; get properly underlined everywhere, though.)
I have no idea what might trigger this. If I can try out something more, please let me know.
Kind regards, Marcus |
|
|
feline
Whole Tomato Software
United Kingdom
19074 Posts |
Posted - Apr 10 2017 : 1:43:54 PM
|
If you add a new, empty cpp file to your main solution, what happens when you add the test code to this file? I am wondering if the problem is file or solution dependent. From this thread:
https://forums.wholetomato.com/forum/topic.asp?TOPIC_ID=12897
some checks are dependent on your toolset / IDE. So if this is indeed solution specific, this might help to explain why. |
zen is the art of being at one with the two'ness |
|
|
khb
Tomato Guru
Germany
337 Posts |
Posted - Apr 10 2017 : 4:08:53 PM
|
I added an empty new cpp file to my project. I pasted accord's code into it. I didn't see the blue underlines, because I got some red wiggly lines. I fixed those by adding #include "stdafx.h" to that file. Then the same problem occurred again.
I wasn't sure whether something in my stdafx.h could cause the problem, so I added accord's code into that file, directly behind #include <afxwin.h>. Still, the problem remained.
I have no idea what could make my solution so special. My project is a rather straight-forward dialog-based MFC application.
Kind regards, Marcus |
Edited by - khb on Apr 10 2017 4:11:44 PM |
|
|
accord
Whole Tomato Software
United Kingdom
3287 Posts |
Posted - Apr 11 2017 : 06:31:50 AM
|
What is the definition of your ASSERT? Can you please press F12 to go to the definition of the ASSERT's #define and then copy-paste it here? Which file is it inside? A general library or are you using your own/custom ASSERT code, defined inside the solution? |
Edited by - accord on Apr 11 2017 06:32:21 AM |
|
|
khb
Tomato Guru
Germany
337 Posts |
Posted - Apr 11 2017 : 12:38:01 PM
|
The ASSERT macro is defined in afx.h:
#define ASSERT(f) DEBUG_ONLY((void) ((f) || !::AfxAssertFailedLine(THIS_FILE, __LINE__) || (AfxDebugBreak(), 0))) So, it should be the standard MFC ASSERT.
Kind regards, Marcus |
|
|
holedigger
Whole Tomato Software
145 Posts |
Posted - Apr 11 2017 : 1:09:55 PM
|
Is your active configuration Debug or Release? If it is Release then the ASSERT is preprocessed away so Code Inspection doesn't see it. |
Whole Tomato Software |
|
|
khb
Tomato Guru
Germany
337 Posts |
Posted - Apr 11 2017 : 2:54:36 PM
|
Before I misunderstand what you mean by "active configuration", it's what I have selected in the following toolbar, right?
It doesn't seem to matter, what I enter here. Also Debug Win32 doesn't show the underlines.
Do I have to trigger some kind of reparsing after changing the configuration?
Kind regards, Marcus |
Edited by - khb on Apr 11 2017 2:55:44 PM |
|
|
accord
Whole Tomato Software
United Kingdom
3287 Posts |
Posted - Apr 12 2017 : 12:06:18 PM
|
quote: Do I have to trigger some kind of reparsing after changing the configuration?
No, it is automatically triggered.
Yes, this is what holedigger means by active configuration.
I was able to reproduce the problem when I've chosen "Release": the underline disappears and it reappears when I switch back to "Debug". x64 was a good tip on your screenshot, but unfortunately it is not the trigger, x64 works for me in Debug.
From what I see, it's like Code Inspection has found a different ASSERT. I'll ask internally if there is a way to find out which ASSERT did it find. |
|
|
khb
Tomato Guru
Germany
337 Posts |
Posted - Apr 12 2017 : 12:33:52 PM
|
I don't know whether this is helpful, but if I hit Alt+G, then I get the following options:
Kind regards, Marcus |
|
|
khb
Tomato Guru
Germany
337 Posts |
Posted - May 22 2017 : 2:26:51 PM
|
The problem seems to be fixed for me with VA version 2217.
Kind regards, Marcus |
Edited by - khb on May 22 2017 2:27:43 PM |
|
|
|
Topic |
|