I have the following (completely useless) test code that I'm running through gprof.
#include <iostream>
using namespace std;
int doFunc(int x)
{
return x + 9;
}
int main()
{
return 0;
}
The function doFunc is never used, but a _GLOBAL__SUB_I_Z6doFunci mangled name version shows up as being called once. When I actually call the function, it just shows up as Z6doFunci, which gets called the appropriate amount of times, and the _GLOBAL_SUB version doesn't get called.
I noticed that, by removing iostream in the above code, the function never gets called (no _GLOBAL__SUB_ version). So, I suspect that it has something to do with the initialization of the global objects contained in iostream, but other than that I'm stumped. What is going on?
Related
#include <iostream>
#include <vector>
using namespace std;
int main()
{
vector<int> big_vector = {5,12,4,6,7,8,9,9,31,1,1,5,76,78,8};
vector<int> a = sub(big_vector);
cout<<a.size();
return 0;
}
vector<int> sub(vector<int> big_vector){
return {big_vector.begin() + 7, big_vector.end() - 2};
}
I get this error and do not know why
main.cpp:18:21: error: ‘sub’ was not declared in this scope
debugging and running different test
In C++ all objects must be declared before they are used.
vector<int> a = sub(big_vector);
Your reliable compiler reads this, and it has absolutely no clue, whatsoever, what this mysterious sub function is all about.
Human eyeballs that are owned by a carbon-based life form can easily see this function, later in the file. But your compiler is a beast of logic. It hasn't read that far ahead, into the source file. That's why, in C++, in this situation the function must be declared:
vector<int> sub(vector<int>);
Put this before the main function. The compiler reads this first, and learns all about this amazing function called sub(), which has one vector<int> parameter, and returns a vector<int> itself. So when it reads the contents of main(), which calls this function, it knows exactly what it's all about, and can proceed further.
Or, you can simply put the entire sub() function before the main() function. That'll work, too.
I have a program which nearly immediately finishes with -O0 on gcc, but hangs forever with gcc and -O3. It also exits immediately if I remove the [[gnu::pure]] function attribute, even though the function does not modify global state. The program is in three files:
thread.hpp
#include <atomic>
extern ::std::atomic<bool> stopthread;
extern void threadloop();
[[gnu::pure]] extern int get_value_plus(int x);
thread.cpp
#include <thread>
#include <atomic>
#include "thread.hpp"
namespace {
::std::atomic<int> val;
}
::std::atomic<bool> stopthread;
void threadloop()
{
while (!stopthread.load())
{
++val;
}
}
[[gnu::pure]] int get_value_plus(int x)
{
return val.load() + x;
}
main.cpp
#include <thread>
#include "thread.hpp"
int main()
{
stopthread.store(false);
::std::thread loop(threadloop);
while ((get_value_plus(5) + get_value_plus(5)) % 2 == 0)
;
stopthread.store(true);
loop.join();
return 0;
}
Is this a compiler bug? A lack of documentation for the proper caveats to using [[gnu::pure]]? A misreading of the documentation for [[gnu::pure]] such that I've coded a bug?
I have a program which nearly immediately finishes with -O0 on gcc, but hangs forever with gcc and -O3
Yes, because the program gets compiled down to an infinite loop when optimizations are enabled.
Is this a compiler bug? A lack of documentation for the proper caveats to using [[gnu::pure]]? A misreading of the documentation for [[gnu::pure]] such that I've coded a bug?
It isn't a compiler bug. get_value_plus is not a pure function:
[[gnu::pure]] int get_value_plus(int x)
{
return val.load() + x;
}
since the return value can change at any time (for the same x), because val is expected to be modified by the other thread.
The compiler, however, thinking that get_value_plus will always return the same value, will perform CSE and therefore will assume this:
while ((get_value_plus(5) + get_value_plus(5)) % 2 == 0);
can be written as:
int x = get_value_plus(5);
while ((x + x) % 2 == 0);
Which, indeed, it is an infinite loop regardless of the value of x:
while (true);
Please see the GCC documentation on pure for more details.
In general, avoid using optimization hints unless they are well understood!
In this case, the misunderstanding is that pure functions are allowed to read global memory, but not if that memory is changing from call to call by someone else than the caller:
However, functions declared with the pure attribute can safely read any non-volatile objects, and modify the value of objects in a way that does not affect their return value or the observable state of the program.
As it turns out, I misread the documentation. From the online documentation about the pure attribute in gcc:
The pure attribute prohibits a function from modifying the state of the program that is observable by means other than inspecting the function’s return value. However, functions declared with the pure attribute can safely read any non-volatile objects, and modify the value of objects in a way that does not affect their return value or the observable state of the program.
and a different paragraph:
Some common examples of pure functions are strlen or memcmp. Interesting non-pure functions are functions with infinite loops or those depending on volatile memory or other system resource, that may change between consecutive calls (such as the standard C feof function in a multithreading environment).
These two paragraphs make it clear that I've been lying to the compiler, and the function I wrote does not qualify as being 'pure' because it depends on a variable that might change at any time.
The reason I asked this question is because the answers to this question: __attribute__((const)) vs __attribute__((pure)) in GNU C didn't address this problem at all (at the time I asked my question anyway). And a recent C++ Weekly episode had a comment asking about threads and pure functions. So it's clear there's some confusion out there.
So the criteria for a function that qualifies for this marker is that it must not modify global state, though it is allowed to read it. But, if it does read global state, it is not allowed to read any global state that could be considered 'volatile', and this is best understood as state that might change between two immediately successive calls to the function, i.e. if the state it's reading can change in a situation like this:
f();
f();
Considering the following example:
#include <wx/bitmap.h>
int main()
{
wxBMPHandler h;
wxImage::AddHandler(&h);
wxBitmap bm = wxBitmap(200, 200);
bm.SaveFile("file.bmp", wxBITMAP_TYPE_BMP);
return 0;
}
Since I'm only using h to call AddHandler() and not for anything else, I'd like to avoid defining it altogether and do the whole thing in one line. So I thought about replacing that with:
wxImage::AddHandler(&wxBMPHandler());
which compiles fine, but calling SaveFile() won't work then; WxWidgets will present an error stating "No image handler for type 1 defined" at runtime.
I guess the object created inside the function call is temporary, but I'm not sure about that. If not, what am I missing, and how can I avoid defining h?
It's worth noting that AddHandler() has the following signature:
static void AddHandler( wxImageHandler *handler );
[Update]
In response to M.M's comment saying:
wxImage::AddHandler(&wxBMPHandler()); should fail to compile, unless
that class has overloaded operator& for rvalues
Since I couldn't find a definition for operator& in WxWidgets' source code, I created this test project:
#include <iostream>
#include <string>
using namespace std;
string* address = nullptr;
void testing(string* input)
{
*input = "Something else entirely";
address = input;
}
int main()
{
testing(&string("Life is a test"));
cout << *address << endl;
cin.get();
return 0;
}
It compiles fine, and runs without any "hard error" - the only caveat is that nothing is shown in the screen - (*address).empty() returns true.
I even defined my own class to test with, instead of std::string and yielded the same behavior (no compiler error, no runtime error, but no output).
I also tried this one-liner, as suggested by aichao, without success:
wxImage::AddHandler(shared_ptr<wxBMPHandler>(new wxBMPHandler()).get());
I've never used wxWidgets before, but according to the wxWidgets version 3.1.1 API docs here, you should call wxImage::AddHandler using a heap-allocated handler object:
wxImage::AddHandler(new wxBMPHandler);
Therefore, there is no need for defining h. Also according to the docs, the memory for this handler object is managed by the wxWidgets framework. Specifically, the docs says that the handler is a
heap-allocated handler object which will be deleted by wxImage if it is removed later by RemoveHandler() or at program shutdown.
There is also the static member function wxImage::CleanUpHandlers() to delete all registered image handlers. According to the docs:
This function is called by wxWidgets on exit.
Therefore, you do not have to delete the handler yourself unless you specifically want to (i.e., to free up some memory).
Hope this helps.
In wxImage::AddHandler(&wxBMPHandler());, the lifetime of the temporary stop at the end of the expression, so you have dangling pointer.
In
wxBMPHandler h;
wxImage::AddHandler(&h);
wxBitmap bm = wxBitmap(200, 200);
bm.SaveFile("file.bmp", wxBITMAP_TYPE_BMP);
h outlives the call bm.SaveFile("file.bmp", wxBITMAP_TYPE_BMP);.
You will have similar issue with
{
wxBMPHandler h;
wxImage::AddHandler(&h);
} // End of life time of h
wxBitmap bm = wxBitmap(200, 200);
bm.SaveFile("file.bmp", wxBITMAP_TYPE_BMP);
I was just experimenting with C++. I was trying to write a small macro so that all the functions that I define are automatically stored in a map so that I can query, at run time, what functions exist and run them too. The code is as follows:
#include <map>
using namespace std;
typedef void (*funcPointer)();
map <char*, funcPointer> funcList;
#define Function(x) void x() { funcList[#x] = x;
#define End }
I was used funcPointer and End only for easy readability and implementation. Now, I can define a function as
Function(helloWorld)
cout << "Hello World";
End
Now, to read the function names as a list and run all the functions, I use the following code:
int main() {
//helloWorld();
for (map<char*, funcPointer>::iterator I = funcList.begin(); I != funcList.end(); I++) {
printf(I->first);
I->second();
}
getchar();
return 0;
}
The problem is, if I keep the first line of main() (helloWorld();) commented, the compiler doesn't compile the function and skips it for optimization, as according to the compiler, it is never used. So, the function list turns up empty. If, instead, I call the function once, every thing works perfectly, except that it prints "Hello World" twice. Also, I wrote the macro specifically so I do not have to do that.
So, is there any way that I can force the compiler to compile a function even if it is not used?
The problem is that the code to register the function is inside the function, so won't happen unless you call the function. You might instead register it by initialising a global variable, which will happen automatically before main begins. This might look something like
struct funcRegistration {
funcRegistration(char * name, funcPointer func) {funcList[name] = func;}
};
#define Function(x) \
void x(); \
funcRegistration x##_registration(#x, x); \
void x() {
The compiler compiles the function, however your map won't be populated unless its called.
Because funcList[#x] = x; comes inside the function block { } after macro expansion.
I made a header file sampleheader.h with following code:
namespace sample_namespace
{
int add(int n1,int n2)
{
return (n1 + n2);
}
}
Now my main.cpp file is:
#include <iostream>
#include "sampleheader.h"
using namespace std;
int add(int n1, int n2)
{
return (n1 + n2);
}
int main(void)
{
using namespace sample_namespace;
//cout<<add(5,7);
}
The project is built with no warning if i leave that line commented.It is understandable because the local add() function is defined in the global scope and add() function is made visible in the scope of main(). So no name conflict happens.
However, if I remove the comments, I get the following error:
"Ambiguous call to overloaded function"
First of all there should be no name conflict at all as explained by me above (if I'm right). But, if at all there is a name conflict why is it that it is notified by compiler only when I call the function. Such type of error should be shown as soon as a name conflicts (if at all).
Any help is appreciated.
Well, you explained it yourself.
When you have both int add() and int sample_namespace::add() in scope, the call is ambiguous. The statement add() could mean either of them.
There is no conflict in the functions co-existing because one is int add() and the other is int sample_namespace::add(). This is the entire purpose of namespaces.
You just have to be clear when you write code that uses them. If you get rid of your using namespace directives and always write explicit code, then you won't run into a problem:
#include <iostream>
namespace sample_namespace {
int add(int n1, int n2) {
return (n1 + n2);
}
}
int add(int n1, int n2) {
return (n1 + n2);
}
int main() {
std::cout << sample_namespace::add(5,7);
}
(Also, defining non-inline functions in headers is A Bad Idea™.)
"using namespace" does not hide other implementations. What it does in this case is make it ambiguous.
You have both sample_namespace::add and ::add with the same signature. Since you don't explicitly say which one to use, the compiler can't tell.
Declaring both functions is legal and unambiguous (which is why the compiler only complains when you use the function).
The reason why it's legal to declare both functions like that is because you can call both unambiguously, by qualifying them. That's why you get an error only when you make an unqualified call. Up to that point, there is not even a theoretical problem.
Intentionally, using namespace X; shouldn't introduce ambiguity errors by itself. That would very much defeat the purpose of namespaces. The common using namespace std; introduces many names that you'd reasonbly define yourself as well.
You cannot shadow symbols like that, only variable names (which is a warning on most compilers, i.e. a bad idea). using directives aren't precise in any sense, which I think is the assumption that most people make.
using directives will import a symbol into the scope. for instance, you can do things like this:
namespace foo {
using namespace std;
}
foo::string val;
This sort of practice leads to some very annoying compiler errors to track down. Your simple example is clear where the error is. If you try doing it in a few hundred thousand lines of code, you will be much less pleased.
I would advise you not to acquire the habit of relying on the using directive. If you must, just do one type at a time.
using std::string;
Basically, this keeps you honest. And if there is a naming conflict, grep will take 30 seconds to uncover where the problem is.
If you just spend a couple weeks typing std:: in front of your types, you will get used to it. I promise that the amount of time you think you are saving is greatly exaggerated.
I think this is because of compiler-optimisation. When your string is commented - he saw, that there are some function, but you don't use it, so he discard it. And when he saw that function useful - he want to insert function call, but can't chose which one you want.