Warning message printed to console not failing the build - c++

I have warnings as errors turned on and the warning level cranked up to the max. I've integrated VLD in my unit tests. When I purposefully create memory leaks, VLD prints a warning in the Visual Studio output console and the warnings console.
The warning is formatted like warning : Visual Leak Detector detected memory leaks!
However, Visual Studio reports that the build succeeds. Is warnings as errors limited to Visual Studio generated warnings?

Yes, the "warnings are errors" is a compiler setting, which basically says "If (error_level == warning) error_level = error;" inside the compiler.

Related

Visual Studio 2019 not underlining errors in C++ projects

I would like VS2019 to underline errors in real time, so when I compile, I do not get errors that could have otherwise been detected before the build process.
Currently, I have to build to get the errors, and nothing gets underlined; I have to use the ErrorList to find the errors. It is messing with my workflow. Android Studio and Eclipse both underline errors in real time, and I would like to know how to get Visual Studio 2019 to do the same for C++ projects.
I have checked settings in Tools->Options->TextEditor->C++->Acvanced. The settings look correct.

Static assertion failed with "Windows headers require the default packing option..."

When I'm trying to compile my C++ project in Visual Studio, I keep getting the 2 following errors:
E1574: Static assertion failed with "Windows headers require the default
packing option. Changing this can lead to memory corruption. This diagnostic
can be disabled by building with WINDOWS_IGNORE_PACKING_MISMATCH defined."
and
C2338: Windows headers require the default packing option. Changing this can
lead to memory corruption. This diagnostic can be disabled by building with
WINDOWS_IGNORE_PACKING_MISMATCH defined.
I think the issue has to be something in my Visual Studio settings, cause the project compiles fine on my other PC, and I just installed Visual Studio on this PC.
From doing some searches look like the issue stems from a mismatch of Windows packages, however when installing Visual Studio I tried to install all the C++ and Windows 10 modules I saw.
Also, I'm only including windows.h in order to use ShellExecute(), so if there's a better way to use ShellExecute() I'm open to that. Thanks!
As 1201ProgramAlarm mentioned above, the solution was disabling the /Zp (structure packing) compiler option.

memory problems when migrating to Visual Studio 2017 from 2015

i have a relative big C++ project which i can compile in vs2015 with no problems at all,
when i tried to compiled it in vs2017 i get the problem:
fatal error C1060: compiler is out of heap space
when monitoring the cl.exe process it gets to 3.5G and then crush with this message,
the compiled application is x64 but the compiler is by default 32bit
after some googling i added this flag:
set PreferredToolArchitecture=x64
devenv.exe
and its used the 64bit compiler which works but suck all my memory (30G+) and make compilation super slow... :(
why its happening and what can i do ? in vs2015 exactly same project was compiling at no time and almost no memory consumption at all (relatively)
thanks for any help!
(P.S i tried the /zm200 /zm1000 /zm2000 flags, doesnt seems to change anything)

Why might the "fatal error C1001" error occur intermittently when using msbuild?

Possibly related to my last question (note: different error code):
Why might the "fatal error C1075" error occur intermittently when using msbuild?
On our nightly 64-bit build, we see this error appear intermittently:
Generating Code...
c:\program files\microsoft visual studio 9.0\vc\include\xtree(944) : fatal error C1001: An internal error has occurred in the compiler.
(compiler file 'f:\dd\vctools\compiler\utc\src\p2\main.c[0x51120030:0x000E00AB]', line 182)
To work around this problem, try simplifying or changing the program near the locations listed above.
Please choose the Technical Support command on the Visual C++
Help menu, or open the Technical Support help file for more information
Internal Compiler Error in c:\Program Files\Microsoft Visual Studio 9.0\VC\bin\x86_amd64\cl.exe. You will be prompted to send an error report to Microsoft later.
Build log was saved at "file://c:\Buildbot\synergy\1.4-win64\build\bin\synergy.dir\Release\BuildLog.htm"
See full log output.
I get the feeling that this error will be much harder to solve (if this is even possible) than the error from my last question, since it could be a bug in the compiler (but I'm hoping this isn't the case).
Is there anything that can be done to work around this problem? Maybe there's a hotfix that I can't find? Perhaps I should just contact Microsoft through connect?
Replacing the RAM fixed this (as with my other question with the different error code).
I get this error too (sometimes/rarely on all my systems x86 and x64). Just rebuild and if that doesn't work restart Visual Studio and it probably it's gone. (Nothing too serious ,at least not with my systems)

Are standard library warnings normal?

I'm learning my way around visual studio at the moment. If I've turned set /Wall I'll be greeted with a seemingly unhealthy amount of warning messages although my application will compile just fine.
Is this normal? Changing the error level will stop the messages. It looks as if they are all related to the C++ STL or its header files - same thing?
If I build the program using code::blocks (GCC) then no errors are reported despite the same warning level.
What's going on here?
update:
visual studio /Wall output: http://pastebin.com/FBGLd2Hb
visual studio /W4 output: http://pastebin.com/YuWKVS9G
The code is actually from Wrox Professional C++.
I could be wrong about my usage of the word warnings?
With g++ -Wall does not turn on all warnings, just a practical subset. I suspect that with MSVC /Wall turns on more warnings than is practical. MSVC is very enthusiastic about warnings.
With MSVC use /W4 for high warning level.
You'll have to turn off MSVC sillywarnings; you can use my anti-MSVC-sillywarnings header for that.
Cheers & hth.,