Jump to content
  • Advertisement
Sign in to follow this  
DaBono

fstream and exe-size

This topic is 4834 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Before I ever coded something in C++, I had quite some experience in C. In my current project the only I/O was really simple, and I used the <stdio.h>-type IO. In an attempt to shed my C-legacy programming, I decided to look into fstreams. No problem there, it works and all, but my simple test (write one string) is 258 kB in size! (Yes, it is in release mode) Now, I found some threads about the use of fstream, but they tend to become religious debates between C- and C++-programmers. My only question here is this: is the large executable the price you have to pay for convenience, or am I doing something wrong? I am using MinGW/GCC. The code of my test application is this:
#include <fstream>
#include <string>

using std::ofstream;
using std::ios;
using std::string;

int main( int argc, char *argv[] )
{
    ofstream out( "out.txt", ios::trunc );
    string text = string( "This is a test string" );

    out << text;
    out.close();
    return 0;
}

Share this post


Link to post
Share on other sites
Advertisement
a) Strip the executable (-s flag (I think) or run strip on the output). The C++ standard library contains lots and lots of symbols which are kept in your program for debugging (yes, even in 'release' mode).
b) The C standard library is a shared library - their code exists outside of your program. Many C++ standard library components are provided as header files - their code is added to your program, making it larger by a fixed amount if you use the library (one-time cost regardless of how much you use the library). Some library components (including, in particular, iostreams) are sometime provided in a hybrid fashion, with the common template specializations (such as std::basic_string<char> a.k.a std::string) living in a library, while other specializations are instanciated in your code.

Share this post


Link to post
Share on other sites
MinGW has it's own copy of the STL, and the executables contain the pieces of it that they use, making them huge.

On the bright side, the size increase is mostly constant. Writing a bunch more code won't increase the size by much.

Share this post


Link to post
Share on other sites
Well, there's many solutions if you want smaller binary files. First you can set your compile to optimise for smaller files. Also, I don't remember the exact settings but you can change the library to use dynamically linked dll for multithreading, this is much of your .exe size right there. Then if that's not enough, you can use an executable packer.

Edit: Ah sorry, I forgot that this is mingw, I'm guessing the dynamic linking trick isn't going to work eh?.

Share this post


Link to post
Share on other sites
Quote:
Original post by Blizzard999
Probaly is the string that create a larger code. This is common when you use stl

Sorry, that's not it. Using string (and other container-classes) expands the exe by about 40 kB. So, using fstream seems to pull in about 210 kB.

Quote:
Original post by Fruny
a) Strip the executable (-s flag (I think) or run strip on the output)

Before posting, I indeed used strip to make sure it wasn't something like that.

Your explanation at b) actually explains a lot about what's happening. Since, ostream is heavily templated, a lot of the instantiation will have in my own executable.
So, as I understand, the executable increase is indeed the price you have to pay, then. (Although I find this a much worse trade-off then the very worthwile container- and string-classes).

EDIT: Looking at the symbols in a debug build actually gave away what takes up all the space. To output numbers etc, all the locale-stuff is exported too.

[Edited by - DaBono on August 20, 2005 12:10:09 PM]

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!