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
Related
I'm using Visual Studio Code for c++ with MinGW and g++. My code uses a couple of g++ predefined macros. These work in the compiler without any problem, but Intellisense doesn't know about the macros and that causes some misdiagnosed errors (and other Intellisense problems) in the editor.
I can get all the predefined macros for my particular configuration of g++ with this command:
g++ -dM -E foo.cpp > defines.h
And this allows me insert them into the "defines" property of the c_cpp_properties.json file. This solution is a hack though, and if I'm not careful it could completely undermine the purpose of these macros. I want the compiler and Intellisense to cooperate across multiple development platforms, and that's looking like a pretty complicated setup.
Is there a better way to let Intellisense know about the g++ predefined macros?
From what I can tell, Intellisense's ability to properly handle preprocessor macros is still limited. If you are using CMake for Makefiles, it appears that you can tell Intellisense what macros you have, as seen here: auto-defined macros. I have not played with this personally, but it would be worth investigating.
If you can't get this to work, I found a feature to just turn off the macro-based highlighting. In settings, set"C_Cpp.dimInactiveRegions" to false. This isn't ideal, because it stops all graying out, including debug blocks like if(0) {...}, but it could be a temporary fix and you might find it less irritating.
Apart from that, look closely for added features in future updates. I'll try to update this post when I find any new discoveries on the matter.
The property in c_cpp_properties.json called compilerPath allows IntelliSense to query the compiler for default include paths and defines. It may be necessary to set intelliSenseMode to gcc-x64 for this to work, as that is not the default on Windows. (I currently do not have a Windows setup so I can't test this for the time being)
I use two C++ compilers / IDEs. (1) g++ in Code::Blocks and (2) Visual C++ in Visual Studio.
I have some question on how to set up the compiler in the way I want it to be.
Code::Blocks: I want to make G++ follow standard C++. For example:
int x;
cin >> x;
int arr[x];
...wouldn't work in standard C++.
In standard C++, one has to use dynamic allocation. For example, the Visual C++ compiler would reject this code. However, this code would work in Code::Blocks.
How do I make g++ reject this code?
Also, how do I tell g++ and Visual C++ 2013 to follow and only follow C++11 standard? It seems to me the default one is still C++98/03.
Compiler options for standard-conformance.
With g++ you want, at minimum,
-std=c++11 for the C++11 standard.
-pedantic to warn about use of language extensions.
-Wall -Wextra to up the warning level to reasonable.
With Visual C++ you want, at minimum,
/nologo to turn off a verbose version and copyright message,
/EHsc to turn on exception support,
/GR to turn on RTTI support, Run Time Type Information such as dynamic_cast,
/W4 to up the warning level to reasonable.
With Visual C++ there is no special option to indicate the C++ standard version.
How to preset options for command line use.
MinGW g++ generally (one exception is the Nuwen distribution) defaults to producing executables that rely on DLLs that reside in the mingw\bin directory, which means that you generally need that in your PATH environment variable.
This means that it's not such a good idea to add options via a batch file or shortcut or command intepreter macro. Instead use option -dumpspecs and redirection to create a specs file (with that name) in the directory specified by this Windows command:
g++ --print-search-dirs | find "install:"
Read up on how to edit that file, then fix it. ;-)
You might want to set the CPATH environment variable to your general include directory.
With Visual C++:
Compilers options can be preset in the CL environment variable.
Include paths in the INCLUDE variable.
Library paths in the LIB variable.
Linker options can be preset in the LINK variable.
For the linker options you may want to have /entry:mainCRTStartup to support ordinary standard main startup function also when producing a GUI subsystem executable. However this conflicts a little with MFC. It's been many years since I did anything MFC so if you want details or solution please post a separate question which others can answer.
How to set options in each IDE (Code::Blocks, Visual Studio).
This is as simple as reading each IDE's documentation. ;-)
Note that options can be set both globally and per project.
MSVC defines _DEBUG in debug mode, gcc defines NDEBUG in release mode. What macro can I use in clang to detect whether the code is being compiled for release or debug?
If you look at the project settings of your IDE, you will see that those macros are actually manually defined there, they are not automatically defined by the compiler. In fact, there is no way for the compiler to actually know if it's building a "debug" or "release", it just builds depending on the flags provided to it by the user (or IDE).
You have to make your own macros and define them manually, just like the IDE does for you when creating the projects.
Compilers don't define those macros. Your IDE/Makefile/<insert build system here> does. This doesn't depend on the compiler, but on the environment/build helper program you use.
The convention is to define the DEBUG macro in debug mode and the NDEBUG macro in release mode.
You can use the __OPTIMIZE__ flag to determine if optimization is taking place. That generally means it is not a debug build since optimizations often rearrange the code sequence. Trying to step through optimized code can be confusing.
This probably is what those most interested in this question really are attempting to figure out.
There is no such thing as a debug mode in a command line compiler. That is a IDE thing: it just sets up some options to be sent to the compiler.
If you use clang from the command line, you can use whatever you want. The same is true for gcc, so if with gcc you use NDEBUG you can use just the same.
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 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.