I wanted to disable language extensions to be able to do some tests in my project. I found that I must set /Za compiler directive from http://msdn.microsoft.com/en-us/library/0k0w269d.aspx, but after this I have errors if I include windows headers. Is there a way to write standard compliant code(enforced by the compiler, not by other programmers/code reviews) in VS2010 and still use system headers?
Thanks you!
The windows headers have never compiled with /Za.
There are other problems as well with /Za, that has caused Microsoft to stop testing their C++ standard library with that option. As told here:
http://permalink.gmane.org/gmane.comp.lib.boost.devel/212180
The recommendation is not to use it in "real" code.
Isolate your use of <windows.h> into a source file(s) that you don't compile with /Za and use the parameter on the other files.
Related
Does someone knows what is the reason that I can't use the /clr options with the /experimental:module option with the msbuild compiler?
Is there some way to bypass it?
Thanks.
The reason is that /clr compiler option of MSVC means that what you are compiling is not C++ but a different language C++/CLI. Lot of C++ and headers will be rejected under /clr option because it is not supported as C++/CLI.
The way to bypass it is that C++/CLI can #include headers written in (subset of) C++ and call things from it. So you can write your submodules that need to use C++ modules in C++ and provide interface as header files that C++/CLI can use.
Beware, that most such projects that are written in several different languages in mix tend to turn into chimera that does not work very well. Also maintainers capable to analyse an issue in it from end to end are harder to find.
I would like to try to use the Core Guidelines checker tool on a C++11/14 project, under VS2015.
In my code I use many libraries from Boost which trigger a lot of warning. I am not concerned by those warnings, since Boost is doing a lot of very clever work and the libraries were not written with the aim of conforming to the Guidelines, which they mostly predate.
But with such a flood of warnings I am unable to find out the real issues (at least according to the tool) in my code.
Is there a way to suppress all the warnings for third party code? Maybe there is some attribute before and after #including boost headers?
I have read this page from the Visual C++ Team blog but I have been unable to find it.
There's an undocumented environment variable, CAExcludePath, that filters warnings from files in that path. I usually run with %CAExcludePath% set to %Include%.
You can also use it from MSBuild, see here for an example (with mixed success): Suppress warnings for external headers in VS2017 Code Analysis
MSVC is working on something similar to GCC's system headers that should be a more comprehensive solution to this problem.
Currently, in VS, the feature to suppress warnings from third-party libraries are still experimental but certainly coming.
VS 2017 version 15.6 Preview 1 comes with a feature to suppress warnings from third-party libraries. In the following article, they use "external headers" as a term to refer to the headers from third-party libraries.
https://blogs.msdn.microsoft.com/vcblog/2017/12/13/broken-warnings-theory/
The above article basically says that
specify external headers
specify warning level for external headers
to suppress warnings from them. For example, if we have external headers in some_lib_dir directory and want to compile our code in my_prog.cpp which depends on the external headers, the following command should do the job.
cl.exe /experimental:external /external:I some_lib_dir /external:W0 /W4 my_prog.cpp
Note that /experimental:external is required because this is still an experimental feature, and the details of this feature may change in the future.
Anyway, we need to wait for the future release of Visual Studio.
Since C++ uses headers for now, sometimes one header includes another and you fail to notice it, as a result of that the code may compile with one compiler and not with the other, or maybe one feature is implemented in one compiler but not the other, so, I was wondering if there's a way to have visual studio check if the project will compile with both VS compiler and g++ somehow? Or do I just have to manually recompile with both compilers every time? If I have to recompile with both compilers, how can I automate that process with visual studio so I don't have to do it manually?
The development cycle of gcc is faster than that of MS Visual Studio. So asking Visual Studio "will my code be compiled correctly by g++?" is meaningless - it will never know which features and bugfixes the latest version of gcc has.
Also, there is no point in asking such a question at all - if you want to know "what will happen if I do X", just do X!
What you really want to know, I guess, is something like "Are my #include directives compatible with C++ Standard?". MS Visual Studio is just an implementation - it's not a portability-checking tool. It does its best to compile the code, and do it correctly, which is a great task by itself (with c++ being so hard to compile).
gcc is yet another implementation of c++, with its own headers. Actually, from my experience, the mingw c++ headers are more "minimalistic", that is, they try to not include one-another when possible. My guess is, they try to minimize compilation time for systems that don't use precompiled headers, while MS Visual Studio regards precompiled headers as an essential feature.
So better use gcc/mingw as your "standard compliance" check.
VS2015 supports the clang compiler, which is generally the most compliant compiler of the three. You could compile your code with clang.
It's important to distinguish that a compiler and standard library implementation are not the same thing. i.e. you can mix and match compilers with the standard libraries that ship with different toolchains. So compiling with clang will not pick up issues with variance in standard library implementations.
To do that you would have to link against and supply the headers for the standard library implementation you would like to link against. Visual Studio, by default links against it's own runtime and includes msvc runtime headers, you would have to change your project configuration to achieve it but it should be possible. It would be a lot less hassle to simply compile it with the target platforms own toolchain, however.
Not sure if this is the right place to ask but here goes
From a page on the Intel website, it states:
The Intel C++ Compiler for Windows uses the Microsoft Visual C++ header files, libraries and linker. Microsoft controls the header files that define the namespace. Contact Microsoft's technical support in reference to Microsoft's conformance to the C++ standard on this issue... link
Is there a guide by Intel (or otherwise) to change the libraries from the ones governed by visual studio to ones provided by gcc (Also on my windows machine). the reason I want to do this is to make use of some of the new C++11 features that are not supported in versions of visual studio (as is generally the case)
If this is not possible because my current knowledge of the above is not correct, can somebody explain to me why not.
Thanks.
This is not a practical possibility.
The intel compiler (icl) will do nothing but moan if it cannot find VC++ binaries on the PATH, so you know it needs the VC++ toolchain at least.
Then to see what you are up against, as far as using the gcc headers is concerned, you would do the following:
Make icl suppress its own predefined macros.
Make it use gcc's predefined macros.
Make it suppress its standard include search.
Make it use gcc's standard include search.
None of this is hard, and when you have done it all and attempted to build your HelloWorld.cpp, the errors
will show you that the gcc headers are replete with builtin keywords of the gcc compiler that are
unknown to icl: __builtin_va_list, __attribute__, __cdecl__, __nothrow__ and so on.
You might attempt to successfully delete or redefine all of these by way of preprocessor macros.
Or you might give up, and I would urge the latter.
I generally program & compile under Linux with gcc and -ansi flag; but I've been forced with doing a job in Visual C++ and whenever I compile my C code I get all the Microsoft warnings like
'fscanf': This function or variable
may be unsafe. Consider using fscanf_s
instead.
I get these despite following some steps on MSDN Developer's site for setting up an ANSI C project, but all the _s ("secure") calls are not ANSI C!
Any suggestions on putting Visual C++ Studio in a strict ANSI-only mode?
Thanks.
As mentioned in another answer, #define'ing _CRT_SECURE_NO_WARNING will address the specific warnings you mentioned in your question.
If you're really looking for an ANSI-only mode, the closest thing is the /Za compiler switch. Inside the Visual Studio IDE, you can find it in the project's Properties dialog (under Configuration Properties | C/C++ | Language | Disable Language Extensions).
Note that virtually all Windows apps build with Microsoft's compiler extensions enabled; e.g., I don't think you'd even be able to consume Windows SDK headers with /Za set. If your code truly is strict ANSI, you should be OK. If you have a few Windows-specific pieces in a project that is mostly strict ANSI, you could probably isolate those sources and only build those indivudal source files with /Za unset.
These warnings can be suppressed by defining _CRT_SECURE_NO_WARNING
Go to Procect Settings -> Preprocessor and add _CRT_SECURE_NO_WARNING
This isn't forcing compiler to comply with ANSI. Just suppresses use ..._s warnings
One way to suppress specific warnings is to add something like the following to the source.
#if defined( _WIN32 )
#pragma warning(disable:4996)
#endif