It is not even a "hello world", it is simply:
#include <iostream>
int main()
{
return 0;
}
which weighs 1080 kb. When I remove the iostream inclusion in the program to get
int main()
{
return 0;
}
the executable's size becomes only 49 kb.
I just want to include iostream and maybe use only std::cout, but the size will be the whole megabyte again. So, where is the trouble and how do I fix it?
PS: I am using wxDevCpp with mingW and debugging info feature is off.
Thank you.
So, where is the trouble and how do I fix it?
Including <iostream> instantiates the global variables std::cout, std::cin and std::cerr, and thus links in the whole c++ I/O library.
The only way to fix this, is not including <iostream>, if you don't need anything from there.
Related
I'm using the g++ compiler and used the https://code.visualstudio.com/docs/languages/cpp guide to install everything. Never had any sort of problem.
I can initialise a vector from the standard library, but as soon as I attempt to initialise it with values, or add to it, or print its size after adding to it, I get a blank line in the console. There is no compilation error and i've tried compiling with the -std flag as 'c++11' and 'c++17'. The odd thing is that even if I put a cout statement before I add to the array, then it won't even output anything - it's like it just halts the whole program.
I am using vscode, and I've read of vaguely similar issues but none of the problems are identical and none of the solutions have worked. My code is below:
Imports:
#include <iostream>
#include <limits>
#include <vector>
#include <string>
Main function:
int main()
{
std::cout << "BEFORE";
std::vector<int> data;
std::cout << data.size(); // Sometimes outputs 0 if the vector is not modified but prints nothing if it is(even after the statement)
data.push_back(20);
std::cout << data.size();
std::cout << "AFTER";
}
Output:
UPDATE: Flushing the buffer and updating mingw haven't changed anything.
Thanks to #n. 1.8e9-where's-my-share m. I was able to find an answer. The problem was to do with Vscode not being able to display the vector. I ran the compiled .exe using the mingw64 console (outside of vsc, not the internal one) and it produced the correct output.
I have been coding for quite a few years now, but have only just recently started getting into C++.
I have already made quite a few programs in it, but have recently started running into some odd behaviour. The cases are simple enough that I expect this to be an error with my environment, and not the language itself, but I have run into a dead end.
Consider this simple program:
#include <iostream>
using namespace std;
int main() {
cout << "Test" << endl;
return 0;
}
If I compile that and run it, I get, as expected, "Test", in my console.
Now, if I add a vector to it:
#include <iostream>
#include <vector>
using namespace std;
int main() {
cout << "Test" << endl;
vector<double> whatever;
return 0;
}
For some reason, I do not get any output from that.
I have tried initalizing the vector as an empty vector aswell as with predefined values.
I tried adding a for loop running from 0 to 2^32 to see if the program failed entirely, or if it is just the output. This is where things got even weirder.
At first, I placed the loop before defining the vector; that caused the cout to suddenly work again (i.e. "Test" was printed in the console), aswell as stalling the program as expected. I then moved the for loop to after the vector definition, and then it broke entirely; I received no output, and the program exited almost instantly without error.
The issues persist when I remove the using namespace std; and prefix my cout and vector with std::
I use the g++ v6.3 compiler from MinGW. I am running Windows 10.
I am aware that this problem is probably extremely hard to reproduce, but I'll try my luck here before throwing my computer out the window.
Thanks in advance.
Edit: I fixed the issue by using Cygwin instead of MinGW. I will leave the question open in case someone has encountered a similar issue and has a fix that doesn't involve abandoning MinGW
I am running Linux and ran the code, and it ran successfully.
So this must be a compiler issue.
Maybe try using a different compiler like Cygwin / Microsoft Windows SDK.
Recently I'm working on my toy final c++ project, which will read content from a file at the begining and then process it.
Here's the simplified code.
#include <iostream>
#include <fstream>
//using namespace std;
struct command{
int a;
};
command read[1];
int main() {
std::ifstream fin;
fin.open("123.txt");
if (!fin){
std::cout << "failed" << std::endl;
return 0;
}
char c;
fin >> c;
std::cout << c;
return 0;
}
It works fine with Visual Studio 2019. However, when I'm trying to use devc++ 5.11 TDM-GCC 4.9.2, a strange bug happens. I get a segmentation fault on line fin>>c;, with return code 3221225477.
With great effort, the easiest way to make this code works is changing the identifier read to names like reading or whatever. Besides, moving the line command read[1]; into main function also helps.
My questions are:
Is it a behavior related to the compiler? MSVC is fine but GCC 4.9.2 is a little bit old or ...?
Does the identifier read conflict with something in my code? Why does it not a compile error but a segmentation fault?
Why does moving the declaration of read into main function help?
Update:Thanks for tips and I removed using namespace std. I think it has something to do with ifstream, because just std::cout<<"hello world"; works.
-Wall -Wextra provides no warnings.
GCC compiler is stricter than other compiler.
According to tadman's describe, we can guess there's read symbol in namespace std.
So you put it out of main,it's a conflict, you put in the main, it become a local symbol.
There is very likely a collision happening between your read and another in the global namespace. Not all compilers handle this situation the same way, but you can always avoid it if you are careful.
Visual Studio's Intellisense (or whatever alternative you prefer) can help you identify what symbol your read is colliding with. To do that, scope or comment out your code, then start typing "read". If there's another read in your scope, you'll likely see it and be able to get information about it.
This is one of the reasons I don't like using namespace std;. It pollutes your global namespace with a bunch of stuff and increases your chance of collision with a standard library identifier.
I have some basic code that runs in a loop and writes to file. It looks along the lines of:
std::ofstream myFile;
myFile.open("file.txt", std::ofstream::out);
while (true)
{
if (myFile.is_open() && myFile.good())
{
myFile << "test" <<std::endl;
}
if (myFile.fail())
{
std::cout << "Error\n";
}
}
Everything works fine and errors if I manually insert a myFile.setstate() and set it to fail.
However, if I have the program writing to a file in a loop and then I manually go ahead and delete the file... The program appears to continue writing to file as if it still exists. No error is thrown. I thought maybe using flush() would work since I expected it to set the failbit, but the behaviour didn't seem to change. What am I doing wrong?
Is there a way to check if the file suddenly went missing, without resorting to trying to call open() again? (I'm trying to avoid .open() and .close() in a loop. Rather open at start, and then have it closed when it goes out of scope.)
I don't believe there's a portable way to do this. Many operating systems are designed so that if you delete a file that's being written to, the file appears deleted but still exists until the last program writing to it closes. Others don't even let you delete files that are being written to at all. The C++ standard doesn't have any guarantees about what should happen in this case, so I think you'll need to use a platform-specific API to test for whether the file still exists as you're writing to it.
C++17 has std::filesystem that includes an exists method. Or you can use boost::filesystem with an older compiler.
#ifdef __cpp_lib_filesystem
#include <filesystem>
namespace FS = std::filesystem;
#else
#include <boost/filesystem.hpp>
namespace FS = boost::filesystem;
#endif
At the start of your loop:
if(myFile.is_open() && !FS::exists("file.txt"))
{
myFile.close();
myFile.open("file.txt", std::ofstream::out | std::ofstream::app);
}
boost::filesystem::exists uses ::stat() which according to https://stackoverflow.com/a/12774387/69231 takes just over a 1 microsecond, so is not likely to cause much impact on speed.
I do not understand why this C++ program will not build and run using Codeblocks and the GNU CC compiler.
#include <iostream>
using namespace std;
int main()
{
string firstName;
firstName = "Brandon";
cout << "Hello " << firstName << endl;
return 0;
}
Want to use strings? You'll need to #include it.
#include <string>
In general, when you use a class, function or such, you should look up (unless you have memorised it from using it many times) what header the class or type should.
For example, this page is the first hit in google for C++ string:
http://www.cplusplus.com/reference/string/string/
On this particular page, it shows <string> on the left-hand side of the page, to indicate that <string> is the header for this particular class.
Occassionally it is possible to use a class or function without including its correct header. It is, however, very bad form to RELY on such behaviour (unless you are in direct control of that header, of course). It appears that your example, when it does #include <iostream>, is indeed relying on that also doing #include <string>. It would then appear that this is not the case in your combination of OS & Compiler, hence you get an error.
And unfortunately, the error messages when you use << for output of unknown types or otherwise make a mistake in that type of code, can be extremely unhelpful and often quite verbose as well (e.g. I missed out the << between the actual output stream and some text the other day, and I got a good page full of error messages, none of which made much sense at all - but it gave me which line was wrong, and that was enough for me to eventually spot the error).