Is there a way to know if exceptions have been disabled? - c++

Is there a way to know if exceptions have been disabled in C++?
I'm developing an application that uses exceptions and I want to avoid having the user compile the application with exceptions disabled, like a warning that you need exceptions.

The standard certainly does not entertain such a functionality.
Assuming you are using a modern and competent compiler to compile code that contains a throw, then the compiler will error. But you can of course compile one part of the code WITH exceptions, and another without, in which case you still get exceptions thrown, but no way of catching them (since there is no catch either). So the program will probably terminate on first exception being thrown.
If you supply headers, you could just add a dummy function in an unnamed namespace:
namespace {
inline void dummy_dummy_my_thing_to_check_exceptions()
{
throw 123;
}
}
and never even call that function, it will still fail to compile.
I doubt that any compiler that lets you turn off exceptions will accept code that does this - I have tried with g++ 4.8.2, g++ 4.6.3, clang++ 3.6.0 (as of three weeks ago) and clang++ 2.9. All give an error for the above function inside a headerfile. If I remove -fno-exceptions, the code compiles and runs (with a terminate becuase the code does throw 1 in a function.
Total code:
x.h:
extern int func();
namespace {
inline void dummy_dummy_my_thing_to_check_exceptions()
{
throw 123;
}
}
x.cpp:
int func()
{
throw 1;
}
except.cpp:
#include "x.h"
int main()
{
func();
}
Compiles with:
g++ -c except.cpp && g++ except.o x.cpp
or
clang++ -c except.cpp && clang++ except.o,
but won't compile with:
g++ -c except.cpp -fno-exceptions && g++ except.o x.cpp
or
clang++ -c except.cpp -fno-exceptions && clang++ except.o.

Related

C++: Template Specialization causes different result in Debug / Release

In the following code, I create a Builder template, and provide a default implementation to return nothing. I then specialize the template with int, to return a value 37.
When I compile with -O0, the code prints 37, which is the expected result. But when I compile using -O3, the code prints 0.
The platform is Ubuntu 20.04, with GCC 9.3.0
Can anyone helps me understand the behavior?
builder.h
class Builder {
public:
template<typename C>
static C build() {
return 0;
}
};
builder.cc
#include "builder.h"
template<>
int Builder::build<int>() {
return 37;
}
main.cc
#include "builder.h"
#include <iostream>
int main() {
std::cout << Builder::build<int>() << '\n';
}
makefile
CXX_FLAG = -O0 -g
all:
g++ $(CXX_FLAG) builder.cc -c -o builder.o
g++ $(CXX_FLAG) main.cc builder.o -o main
clean:
rm *.o
rm main
You should add a forward declaration for build<int>() to builder.h, like so:
template<>
int Builder::build<int>();
Otherwise, while compiling main.cc, the compiler sees only the generic template, and is allowed to inline an instance of the generic build() function. If you add the forward declaration, the compiler knows you provided a specialization elsewhere, and will not inline it.
With -O3, the compiler tries to inline, with -O0 it will not inline anything, hence the difference.
Your code actually violates the "One Definition Rule": it will create two definitions for Builder::build<int>(), but they are not the same. The standard says the result is undefined, but no diagnostics are required. That is a bit unfortunate in this case, as it would have been helpful if a warning or error message was produced.

How can I make GCC/Clang warn about the use of uninitialized members?

I am compiling the code behind
class Test {
public:
Test() {}
int k;
};
int main() {
Test t;
std::cout << t.k << "\n";
}
like
g/clang++ main.cpp -Wall -Wextra --std=c++14 -o exe; ./exe
Why neither of the compilers does not warn me about indeterminate value of the integer is not it a very serious potential bug? How to enable a warning for indeterminate initializations?
For this example, GCC gives me the desired warning when I give it -O1 (or higher).
Presumably whatever mechanism it uses to detect this is tied into the optimisation effort level somehow. It's a notoriously hard thing to do.
Ensure that you heed your release-build warnings as well as debug-build warnings.

C++: error: exception handling disabled, use -fexceptions to enable

I am trying to compile simple code with -fno-exceptions flag. Its giving error.
Please let me know how to suppress this. I am using gcc version 4.6.3
Code
#include <iostream>
using namespace std;
int main () {
try
{
throw 20;
}
catch (int e)
{
cout << "An exception occurred. Exception Nr. " << e << '\n';
}
return 0;
}
Log
> g++ throw.cc -o out -fno-exceptions
throw.cc: In function ‘int main()’:
throw.cc:10:11: error: exception handling disabled, use -fexceptions to enable
throw.cc:14:56: error: ‘e’ was not declared in this scope
Edit
I have a client code which have lot throws like this. I have to integrate this in my project and I can't control compilation flags to build(which will come from config which has -fno-exceptions enabled). I wanted a quick work around that I can suggest.
EDIT
I found a workaround see below for my answer.
You cannot use -fno-exceptions flag with program, that use exceptions (try/catch/throw).
Quote from gcc manual
Before detailing the library support for -fno-exceptions, first a
passing note on the things lost when this flag is used: it will break
exceptions trying to pass through code compiled with -fno-exceptions
whether or not that code has any try or catch constructs. If you might
have some code that throws, you shouldn't use -fno-exceptions. If you
have some code that uses try or catch, you shouldn't use
-fno-exceptions.
You can't compile a program with this flag if you throw exceptions in your own code. The -fno-exceptions flag does the following:
All exception handling in STL libraries are removed; throws are replaced with abort() calls
Stack unwind data and code is removed. This saves some code space, and may make register allocation marginally easier for the compiler (but I doubt it'll have much performance impact). Notably, however, if an exception is thrown, and the library tries to unwind through -fno-exceptions code, it will abort at that point, as there is no unwind data.
This will, effectively, turn all exceptions into abort()s, as you would like. Note, however, that you will not be allowed to throw - any actual throws or catchs in your code will result in a compile-time error.
I found a workaround. Except for the "e" in the catch block the code can be rewritten like
#include <iostream>
using namespace std;
int main () {
__try
{
__throw_exception_again 20;
}
__catch (int e)
{
cout << "An exception occurred." << '\n';
}
return 0;
}
and can be compiled with
g++ throw.cc -o out -fno-exceptions.

different behavior depending on the optimization options

I found an example where the output is different depending on the optimization settings (-O3 vs none), yet GCC 4.8.2 produces no warnings, even with the -std=c++11 -Wall -pedantic options.
In this particular case, I'm assuming that "forgetting" the commented line in header.h is a mistake, and with -O3, c<int>::get() gets inlined.
However, is there any way to protect yourself against these kinds of mistakes -- a compiler or linker option perhaps?
header.h:
#ifndef HEADER_H
#define HEADER_H
template<class T>
struct c
{
int get() { return 0; }
};
// template<> int c<int>::get();
#endif
imp.cpp:
#include "header.h"
template<>
int c<int>::get()
{
return 1;
}
main.cpp:
#include <iostream>
#include "header.h"
int main()
{
c<int> i;
std::cout << i.get() << '\n'; // prints 0 with -O3, and 1 without
}
build:
c++ -std=c++11 -pedantic -Wall -O3 -c imp.cpp
c++ -std=c++11 -pedantic -Wall -O3 -c main.cpp
c++ -std=c++11 -pedantic -Wall -O3 imp.o main.o
What you get if you have the line in your header-file, is a declaration of an explicit specialization for that member-function.
Thus, main.cpp is assured of a definition in some other compilation-unit, and things work.
If you leave it out, you have a violation of the ODR:
That specific instantiation of your class-template is different in the compilation-units. Resulting in "ill-formed, no diagnostic required", so anything goes.
And there is (currently?) no compiler-option to force gcc to diagnose it.
The true mistake here is the way you're laying out your source files and building them. When c<int>::get() is used, its definition should be available in order to instantiate the template. To fix this, header.h should #include "imp.cpp" rather than the other way around. You may want to rename imp.cpp to imp.inl or something else.
When you define templates which are used outside of a single .cpp file, those definitions should be visible to anyone who includes their header.
As an aside: I don't think there's any way to make the compiler or linker warn you about what you've done here. But if you structure your project as I've described, this problem won't happen, because the forward declaration will be unnecessary.

Forcing GCC 4.x to treat -Wreturn-type as an error without enabling -Werror?

Suppose we have the following code:
#if !defined(__cplusplus)
# error This file should be compiled as C++
#endif
#include <stdio.h>
#include <string>
//#define USE_CXX_CLASS
#ifdef USE_CXX_CLASS
class SomeClass
{
public:
SomeClass() {}
~SomeClass() {}
std::string GetSomeString()
{
// case #1
}
};
#endif // USE_CXX_CLASS
int foo()
{
// case #2
}
int
main (int argc, char *argv[])
{
(void)argc;
(void)argv;
#ifdef USE_CXX_CLASS
SomeClass someInstance;
someInstance.GetSomeString();
#endif // USE_CXX_CLASS
foo();
return 0;
}
And suppose that it were to be compiled the C++ compiler (and not the C compiler) from GCC version 4.2.1 with the options -Wreturn-type -Werror=return-type. If the above code is compiled as is without first uncommenting the //#define USE_CXX_CLASS line above, then you will see a warning but no error:
.../gcc-4.2.1/bin/g++ -g -fPIC -Wreturn-type -Werror=return-type test.cpp -c -o test.o
test.cpp: In function 'int foo()':
test.cpp:26: warning: control reaches end of non-void function
But if the //#define USE_CXX_CLASS line is uncommented, then the warning is treated as an error:
.../gcc-4.2.1/bin/g++ -g -fPIC -Wreturn-type -Werror=return-type test.cpp -c -o test.o
test.cpp: In member function 'std::string SomeClass::GetSomeString()':
test.cpp:18: error: no return statement in function returning non-void [-Wreturn-type]
gmake: *** [test.o] Error 1
Yes, one is a non-member function (case #2), and the other is a C++ function (case #1). IMO, that should not matter. I want both conditions treated as an error, and I don't want to add -Werror or -Wall at this point in time (probably will do so later, but that is out of scope of this question).
My sub-questions are:
Is there some GCC switch that I am missing that should work? (No I do not want to use #pragma's.)
Is this a bug that has been addressed in a more recent version of GCC?
For reference, I have already poured through other similar questions already, including the following:
Why does flowing off the end of a non-void function without returning a value not produce a compiler error?
C question: no warning?
Is a return statement mandatory for C++ functions that do not return void?
It has been fixed, it works well with g++ 9.3: both member functions and free functions are treated as error with -Wall -Werror=return-type
I do see an error even w/o the USE_CXX_CLASS flag. i.e. g++ is consistent with the error for both class member functions and non member functions.
g++ (GCC) 4.4.3 20100127 (Red Hat 4.4.3-4)
It seems to me that what you need is a shell script wrapper around gcc.
Name it something like gcc-wrapper and g++-wrapper.
In your Makefile set CC and CXX to the wrappers.
Have the wrapper invoke GCC and pipe its output to another program which will search for your desired warning strings.
Have the search program exit with an error when it finds the warning.