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.
Related
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.
I'm compiling the next simple example:
#include <iostream>
struct PP
{
inline void wInline();
}
inline void PP::wInline()
{
std::cout << "hola" << endl;
}
int main()
{
PP pp;
pp.wInline();
return 0;
}
in this way:
g++ -O0 -finline-functions -finline-functions-called-once
-finline-small-functions -Wall -Wextra -pedantic -std=c++11 -Winline
main.cpp
with gcc 4.8.2 and wInline is not being inlined.
Are the -finline-functions, -finline-functions-called-once and
-finline-small-functions flags enough?
Why am I having no warnings even with the -Winline flag enabled?
The inline keyword is a hint to the optimizer. Since you are compiling with -O0, no optimization is done.
The gcc documentation says this about -Winline:
Warn if a function that is declared as inline cannot be inlined.
There are rules for what functions can be declared inline as well as heuristics that gcc uses to decide if it should inline a function declared as inline.
You can read more about the inline keyword here.
(Edited to answer second question.)
i was just making a few changes to my program, when all of a sudden g++ complained with an internal compiler error.
Clang however compiles it without any problems and also does not give any warnings, that would indicate anything weird.
I distilled the problem down to this:
#include <functional>
template<typename T>
class A{
T someVar;
};
template<typename T>
class B {
int x;
std::function<A<double>(A<int>&)> someLambda = [&](A<int>& aInt){
int xVar = x;
A<double> aRet;
return aRet;
};
};
int main(int argc, char** argv){
B<int> a;
return 0;
}
I tried both GCC 4.9.2 and 4.8.4, with both failing (internal compiler error).
Flags I used:
g++ -std=c++11 -O0 -g -Wall main.cpp -o gccBin
clang++ -std=c++11 -O0 -g -Wall main.cpp -o clangBin
main.cpp: In instantiation of 'struct B<int>::<lambda(class A<int>&)>':
main.cpp:10:7: required from here
main.cpp:14:24: internal compiler error: in tsubst_copy, at cp/pt.c:12569
int xVar = x;
^
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
Clang++(3.5.1) compiles it without a problem, as I mentioned.
I also tried multiple machines, everywhere the same.
Is there some kind of error I overlooked? I searched a bit on the internet and the only similar problems i could find should have been fixed by now (as the bugtracker states).
Could maybe someone try and run this code on their machine or give other advice?
Thank you,
Lazarus
It's a compiler bug. Just go ahead and file a bug report to the GCC dudes!
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.
I would like to use g++ and -Werror, so I have now to disable warnings for 3rd-party libraries I have no control of. The solution provided by http://gcc.gnu.org/onlinedocs/gcc/Diagnostic-Pragmas.html works very well, allowing simply to wrap the includes of 3rd party headers with pragmas. Unfortunately, that did no longer work for me in a certain setup where templates are involved. I created the following minimal example of where this approach did not work as expected:
Source file main.cpp
#pragma GCC diagnostic ignored "-Wunused-parameter"
#include "hdr.hpp"
#pragma GCC diagnostic error "-Wunused-parameter"
int main() {
return mytemplatefunc(2) + mystandardfunc(3); // will print ONLY ONE warning
}
and the header hdr.hpp
template<typename T>
int mytemplatefunc(T t) {
return 42;
}
int mystandardfunc(int i) {
return 53;
}
compiled using Makefile
CPPFLAGS+=-Wunused-parameter -Werror
main: main.cpp
will produce the following compiler error
g++ -Wunused-parameter -Werror main.cpp -o main
In file included from main.cpp:3:
hdr.hpp: In instantiation of ‘int mytemplatefunc(T) [with T = int]’:
main.cpp:29: instantiated from here
hdr.hpp:2: error: unused parameter ‘t’
make: *** [main] Error 1
shell returned 2
Note that explicit instantiation in main.cpp directly after including the header did not work, and wrapping the call to the template function in main.cpp did not work either. What was puzzling that putting #pragma GCC diagnostic ignored "-Wunused-parameter" in front of the main function silenced the compiler, whilst then adding #pragma GCC diagnostic error "-Wunused-parameter" at the very end of the file caused the compiler to produce the error again. How to solve this puzzle?
(Note, there are dozens of threads about this pragma, but I could not find anyone
that involved such a setup)
The issue is that the instantiation of the template is compiled when you use it, not when it is parsed by the compiler in the header file so it will not issue the warning until it replaces T by int and parses it as a regular function outside the context of the pragma silencing.
The usual way to indicate that you don't intend to use a parameter is to not give it a name:
template<typename T>
int mytemplatefunc(T /* t */)
{ return 42; }
int mystandardfunc(int /* i */)
{ return 53; }