When I compile the code:
#include <iostream>
#include <string.h>
using namespace std;
int main(void) {
string m1;
cout<< "enter your name: "<<endl;
getline(cin,m1);
cout << "Your name is: " << m1 << endl;
return EXIT_SUCCESS;
}
It give the following warning:
type of symbol `_main' changed from 32 to 512 in >C:\Users\KDesktop\AppData\Local\Temp\cc7XPBuL.o
Secondly, the compiler does generate an .exe file, but whenever I run it, the program crashes immediately. Can someone help me with this issue.
Thank you
Your toolchain is outdated. Older versions of LLVM used the wrong value for the function symbol type; the bug was fixed in late 2010. Here's the bug report: http://llvm.org/bugs/show_bug.cgi?id=8320
You should upgrade your LLVM; the problem will go away.
Related
Can someone explain what is happening here?
#include <iostream>
#include <string>
using namespace std;
int main() {
string kek = "kek";
cout << "test" << endl;
return 0;
}
For some reason, every time I compile with g++, and I declare a string variable, I can't see any output, no compile or runtime errors, simply no output.
Now, if I change the code to be this instead:
#include <iostream>
#include <string>
using namespace std;
int main() {
// string kek = "kek";
cout << "test" << endl;
return 0;
}
then everything works.
Does anyone know what the problem is here?
I am currently on Windows 10, using gcc 8.1.0.
Edit:
same thing but using bash, linux compile
i think the version of mingw i had is bugged so trying to reinstall it
Okay so still i have no idea what that bug was about,
but when i had it, the version of MinGW i had was 32bit,
changing the MinGW installation to 64bit, fixed that issue.
i have changed nothing, except removing MinGW 32bit from my comp,
and setting the MinGW 64bit.
Swaping from MinGW 32bit to 64bit, fixed the issue.
I made a small c++ project and it was fully compiled and built it.
#include <iostream>
using namespace std;
int main()
{
cout << "Hello world!" << endl;
return 0;
}
When I run through c::b it was okay
However, it says next warnings when I run program outside of the c::b.
"programdir/bin/Debug/program.exe"
So I got "libgcc_s_dw2-1.dll" from sourceforge, pasted it next to my .exe file,
and I got 0xc000007b error with the error "cannot start the program"
What should I do in this case of problem?
I just installed mingw on my Windows 10 computer and wanted to code a program that read two files. I immediately faced a frustrating bug with ifstream: when I declare more than one ifstream, the program seems to crash (nothing is logged although the first line cout some text).
The following code compiles and logs "test" in the console:
#include <iostream>
#include <fstream>
using namespace std;
int main()
{
cout << "test" << endl;
ifstream test;
return 0;
}
The following code compiles but seems to crash at runtime, nothing is logged:
#include <iostream>
#include <fstream>
using namespace std;
int main()
{
cout << "test" << endl;
ifstream test;
ifstream test2;
return 0;
}
I tested the exact same codes on a macOS Mojave and both codes work and log "test".
I guess the issue is related to the g++ installation but I'd like to know what's really happening and how I can fix this on Windows.
I constantly have CLion editor showing me parameter type mismatch errors while during build everything is fine. For example, consider the following MWE:
#include <iostream>
#include <boost/container/flat_set.hpp>
using namespace std;
namespace bc = boost::container;
int main() {
bc::flat_set<bc::flat_set<int>> manySets;
bc::flat_set<int> oneSet({1, 2, 3});
manySets.insert(oneSet);
cout << "Hello, World!" << endl;
return 0;
}
Here flat_set is a template from boost library (description could be seen here). Editor shows me an error:
But when I build it (even from CLion), everything is compiled fine.
My system is:
Ubuntu 15.10 64bit
CLion 1.2.4
This looks like a known problem - https://youtrack.jetbrains.com/issue/CPP-6027. We hope to fix it soon.
This is really driving me crazy:
#include <iostream>
#include <vector>
#include <string.h>
#include <thread>
using namespace std;
void test() {
vector<string> myvector;
string a("Teststring");
myvector.push_back(a);
cout << myvector.begin()->length() << endl;
}
int main() {
thread(test).join();
return 0;
}
The code compiles fine with the -std=c++11 flag to the compiler and the -pthread flag to the linker.
BUT: Eclipse does either know the std::thread or the myvector.begin()->length(), even if the code runs fine eclipse warns me "Method 'length' could not be resolved".
I tried every possible solution in here: Eclipse CDT C++11/C++0x support without any success. This took me so many hours now, what am I doing wrong?!
Is there anybody getting a project setup without problems with this code?
EDIT: Other code example - same problem:
#include <iostream>
#include <vector>
#include <thread>
using namespace std;
class TestClass {
public:
void test() {
cout << "test" << endl;
}
};
void test() {
vector<TestClass> testClassVector;
TestClass x;
testClassVector.push_back(x);
testClassVector.begin()->test();
}
int main() {
thread(test).join();
return 0;
}
Compiles and runs correct, but returns in eclipse: Method 'test' could not be resolved
EDIT:
working versions:
((TestClass)*(testClassVector.begin())).test();
TestClass foo2 = *(testClassVector.begin());
foo2.test();
still not working:
testClassVector.begin()->test();
The last compiles and works like the two above, but eclipse still claims:
Method 'test' could not be resolved
Maybe I'm wrong, but I think your problem don't come from Eclypse. Juste, begin() on a vector return a std::vector<T>::iterator first, this is not a pointer and there is no method length, but you can ask for the vector size with myvector.size(); if this is what you want.
The problem could come from your #include <string.h> that is not the same as #include <string>, string.h is for string operation like strcmp, strstr, etc... juste string will define the std::string object.
I don't have Eclipse set up but the problem appears to be around std::string. Does the problem go away if you remove the threading from the example? (I also changed to #include <string> instead of string.h)
#include <iostream>
#include <vector>
#include <string>
#include <thread>
using namespace std;
#if 0
void test() {
vector<string> myvector;
string a("Teststring");
myvector.push_back(a);
cout << myvector.begin()->length() << endl;
}
#endif
int main() {
//thread(test).join();
vector<string> myvector;
string a("Teststring");
myvector.push_back(a);
cout << myvector.begin()->length() << endl;
return 0;
}
That should hopefully print out 10.
Update from comment:
Does this generate the Eclipse warning?
auto tmp = *(myvector.begin());
std::cout << tmp.length() << std::endl;
What about this?
std::string foo("abc123");
std::cout << foo.length() << std::endl;
I guess one more too:
std::string foo2 = *(myvector.begin());
std::cout << foo2.length() << std::endl;
The solution found:
I downloaded eclipse kepler Kepler
Created a new project and tried to compile this source code (like above):
#include <iostream>
#include <vector>
#include <thread>
using namespace std;
class TestClass {
public:
void test() {
cout << "test" << endl;
}
};
void test() {
vector<TestClass> testClassVector;
TestClass x;
testClassVector.push_back(x);
testClassVector.begin()->test();
}
int main() {
thread(test).join();
return 0;
}
On the first run eclipse told me, thread belongs to the new c++11 standard and I have to add -std=c++11 to the compiler flags. To use thread I also added -pthread to the linker flags. With this steps the code could be compiled, but eclipse marks the thread still as unknown. To fix this I proceeded the following step:
Under C/C++ Build (at project settings), find the Preprocessor Include Path and go to the Providers Tab. Deselect all except CDT GCC Builtin Compiler Settings. Then untag Share settings entries … . Add the option -std=c++11 to the text box called Command to get compiler specs.
Found here.
Now - unbelievable but true - it works, even without any errors marked by eclipse. The solution is using the (beta) version of eclipse, wich seems to handle this in a better way.
Thanks for all your help!