Does anybody know how to switch off exception handling option in MSVC? I tried to set the option 'Enable C++ exceptions' to 'NO' and I got warning:
warning C4530: C++ exception handler used, but unwind semantics are not enabled. Specify /EHsc.
I would like to switch off the exception handler, too, but I don't know how.
In my application I basically need more speed than stability, therefore I chose switching off the exception handling. I do not have any try/catch blocks, but I do use STL. When I switch the option 'Enable C++ exceptions' to 'NO' is there any way how to get rid of those warnings?
Most likely you're including one or more standard C++ headers that contain try/catch. The most typical case would be <iostream> - you will get this error on a file which consists of a single line that just includes that. Any other stream header will also do, as will locales.
If you look closely at the error message, it should reference two filenames, not one - your file, and the included file with the error. E.g. in my sample case of #include <iostream>, I get this:
except.cpp
C:\Program Files\Microsoft Visual Studio 9.0\VC\INCLUDE\xlocale(342) : warning C4530: C++ exception handler used, but unwind semantics are not enabled. Specify /EHsc
If you really don't want exceptions in the STL that will be linked to your program, define _HAS_EXCEPTIONS=0 in your whole project. Better than compiling your code with /EHsc if you don't plan on adding exception handling.
That warning means that you told the compiler you're not going to use exceptions yet you have a try {} catch() {} block in the code. It informs you that although you have that block, if an exception is thrown no desctructors are going to be executed. Turning exceptions off means exactly that - the compiler doesn't produce code for automatic destruction when the stack is unwound in the event of an exceptions.
In Visual Studio, /EH is found at Configuration Properties ➔ C/C++ ➔ Code Generation ➔ Enable C++ Exceptions.
Switching off exceptions is quite hard, as you're dealing with C++ here. It's really in the same category as switching off NULL pointers - how are you going to handle memory allocation failure, for instance?
That said, /EH specifies which exception handling model you want, and "none" is not an option. You can pick /EHa, /EHs, /EHac and /EHsc - [a]ynchronous with or without support for throwing extern "C" functions.
Do you still have try/catch block(s) in your code?
The first thing to do when you get stuck is look up the error on MSDN and/or Google for it. That usually helps. This is what MSDN says:
When the /EHsc option has not been enabled, an object with automatic storage in the frame, between the function doing the throw and the function catching the throw, will not be destroyed. However, an object with automatic storage created in a try or catch block will be destroyed. [...]
Using MSVC aka CL one can simply use the /kernel switch or not have any /EH switch. Windows C/C++ MSVC builds always have SEH. SEH is inbuilt in Windows.
If #if _HAS_EXCEPTIONS == 0 , MS STL will simply switch to SEH.
Is that standard C++? No it is not. Three keywords will be missing: try, throw and catch. And you need to learn about SEH.
So is that a "good thing"? Well for Windows low level C++, SEH is a good thing.
ps: It is not advisable to use /kernel switch, outside of kernel developments.
Related
I swear I saw a new feature in a recent set of GHC release notes - but now I can find no reference to it. Am I delusional, or does this feature actually exist?
It was to do with loading incomplete modules. As best as I can remember, it allows you to turn off compilation errors due to undefined variables. (Naturally, at run-time this causes an exception to be thrown if you try to actually use the undefined variables for anything.) Does that sound familiar? Or is my mind making this up?
You are looking for a compile time option, vs a language extension, of "defer errors to runtime". That is, compile with -fdefer-type-errors.
When compiling my project as a 64bit target (this isn't considered a warning on 32bit target) I get this warning:
5 enumeration values not handled in switch: 'kCreated', 'kLoaded', 'kConnected'...
I have somehow managed to turn off the error/warning message numbers, so I don't know what number to suppress in my code with #pragma warn.
I need to use #pragma warn because I only want to suppress approved places in my code (turning the warning off and on again).
Bonus question: Does anyone know how to get back the error/warning numbers again?
The 64bit compiler is based on CLang, which does not use warning numbers, which is why you do not see them. The following info comes from Bruneau Babet, one of C++Builder's chief developers, in the Embarcadero forums:
How do I suppress 64bit XE3 warnings?
Warnings in clang, hence bcc64, don't have the Wxxxx numbers. Behind the
scene there is a unique id generated for each warning but it's
auto-generated and cannot be assumed to remain constant across builds.
Instead each warning has a group. Related warnings are often in the same
group. Some groups have just one warning. To disable warnings of a group
you can use "-Wno-" on the command line, or via something like
the following in code:
#pragma clang diagnostic ignored "-W<groupname>".
For example, the first warning you listed is under the group "float-equal".
So, "-Wno-float-equal" should disable that warning. And to disable the one
about an enumerator not handled in the switch you can use the following in
code:
#pragma clang diagnostic ignored "-Wswitch"
So the next obvious question is how to find out about each group. The
"-fdiagnostics-show-option" should trigger the compiler to display the
option but unfortunately the IDE does not honor that option. So you must
either use the command line to find out about the group ach warning belongs
to, or you can peek at the Warning declarations here:
https://github.com/llvm/llvm-project/tree/main/clang/include/clang/Basic
The *.td files declare the various warnings. The ones mentioned above are
https://github.com/llvm/llvm-project/tree/main/clang/include/clang/Basic/DiagnosticSemaKinds.td
Oddly, #pragma clang is still not documented on the Embarcadero DocWiki.
I am writing a managed DLL in VC2010 (i.e. /CLR is enabled for a VC++ DLL project). Following code wouldn't compile:
System::Collections::Generic::List<int>^ my_list;
for each(auto elem in my_list)
{
}
It raises error C3539: 'auto': a template-argument cannot be a type that contains 'auto'.
I don't understand the reason. I tried compiling the same in VS2012, and it raises same error (which is not appropriate error).
Why compiler fails to deduce the type for a colleciton? The same type of code would work in C# with var keyword.
First, the most importand point from the comments:
presented code does compile in VS2013 c++/cli dll .net 4.5 (Zee, 2014-05-03)
When you compile C++/CLI, which is the .NET binding for C++, you are using a different feature set of the Microsoft compiler. Whether something works either
when /clr is in effect
or, additionally, when you're using a "managed" construct (as in your code)
has nothing to to with if the "normal", native, MSVC compiler accepts it.
So as for "why": It would simply appear that auto type deduction did not work for the managed handle types in VS2010 and VS2012, but, according to Zee's comment, has then been implemented in VS2013. (A quick Search Engine check didn't find any official statement wrt. this, so I may be wrong.)
dllmain.cpp(16): warning C4447: 'main' signature found without threading mode
l. Consider using 'int main(Platform::Array<Platform::String^>^ args)'.
Above is a warning I got from building a Windows Store App DLL project. I didn't change anything in that default dllmain.cpp file except for including my own version of pch.
The documentation for this warning (along with many VS2012 errors/warnings) is nowhere to be found on MSDN and here is the only relevant link I can find:
http://social.msdn.microsoft.com/Forums/en-US/vssetup/thread/6daa9587-fe54-4e84-a8b9-0e5c52c2f6e8/
and the op there didn't get an answer.
If anyone knows what it means and how to fix it, it would be great!
As far as I can tell, you can safely ignore the warning. The compiler cribs when it sees a Win32-style DllMain being compiled using the /ZW flag (Consume Windows Runtime Extensions). However, the function gets called as you'd normally expect.
Alternatively, you can work around the warning by compiling dllmain.cpp without /ZW. You might need to adjust the PCH settings for this to properly work. This is the path taken by the DLL (Windows Store apps) C++/CX project template in Visual Studio.
Incidentally, the reason you do not get the warning when you're trying to build a Windows Runtime Component project (which builds everything using /ZW) is that a Windows Runtime Component doesn't declare a DllMain. This is not to say that it can't; it just picks up the dummy DllMain that the CRT defines (which basically turns off per-thread initialization and reports success).
I have a new project where I cannot use boost::format. I get a compiler error complaining that boost's override of a virtual function, ~basic_altstringbuf, lacks a "throw()". Even the most trivial attempt to use boost::format does that.
I have other projects where it works fine. I have verified that the new project uses the same include-paths for boost, and for the VC++ includes. All the projects have "Enable C++ Exceptions" set to Yes. The only explanation I can come up with is that the projects that work have some #DEFINE or some setting that disables those vile exception specs in the std:: include-files. But I have no idea what or where it might be. Any ideas?
Error 1 error C2694: 'boost::io::basic_altstringbuf::~basic_altstringbuf(void)': overriding virtual function has less restrictive exception specification than base class virtual member function 'std::basic_streambuf<_Elem,_Traits>::~basic_streambuf(void) throw()
EDIT: Corollary question: Is there a Properties-item in VS++ 2012 that will cause the std:: header files to be included without exception-specs? - short of turning off exceptions, that is?
At the request of the original owner of the green check-mark, I am submitting this summary.
The bugs are on the Microsoft side, in header-files for C++ standard library interfaces, and in the VC++ compiler when "Disable Language Extensions" is NOT set. The header files contain exception-specifications that the standard does not call for. When "language extensions" are not enabled, the compiler accepts invalid code. I have filed a bug report.
Boost could work around the problem in this specific case by adding seven characters to a nested include-file, i.e. "throw()" at line 65 in alt_sstream_impl.hpp. I filed a report with boost also, although I made it clear that the bug is not in their code. I am just suggesting a workaround.
All the tedious details are in the two reports linked above.
Check the preprocessor defines.
You might turn on and inspect verbose logging to see the exact flags that are passed to cl.exe
You could keep the preprocessed source and compare the version from the old (working) project with the new (failing) project.
My gut says, something else is being #defined/passed using -D in the old project that is not being defined in the new project, of differently (think of WINVER type macros)
See new answer posted: VC++ 2012 and Boost incompatibility - `throw()` specifications in library headers
EDIT by OP, Jive Dadson - It turned out to be /Za, which enables/disables "Microsoft language extensions." It is the contention of Visual Studio that the C++ standard requires that a program shall not compile if it has a virtual function override that is less restrictive in the "throw()" category than the function it overrides. Boost has a class that derives from basic_streambuf, and has a virtual destructor that lacks "throw()". The original destructor has that evil festoon. My new project will compile boost::format if I turn MS language extensions ON.
So the question becomes, who is wrong, and how? Is it standard-complying to put throw() on that destructor or not? Is the desired behavior (desired by me, that is) actually an "extension"? I seem to recall that MS considered some standard C++11 features to be "extensions," but I am not sure I remember correctly. Anyway, I will leave it to the boosters to decide, if they are interested. https://svn.boost.org/trac/boost/ticket/7477