Compile filesize

[PC_Nerd]

Hi,

I've just been looking at Hello World applications for programmign CGI's - and ive discovered that:

#include <stdio.h>
int main(void) {
  printf("Content-Type: text/plain;charset=us-ascii\n\n");
  printf("Hello world\n\n");
  return 0;
}

Compiles to about 15.4 kb, compared to:

#include <iostream>
using namespace std;
int main()
{
	cout<<"Content-type: text/plain"<<endl<<endl;
	cout<<"Hello World!"<<endl;
 
	return 0;
}

which compiles to about 458kb

Can anyone explain why the two peices of code compiel to such different sizes (Is it the differnet IO library in which case which one is better?)
Thanks

[Salem]

Different languages, and different libraries.

> Is it the differnet IO library in which case which one is better?
The C++ one.
There are many more things to worry about than the size of an executable for a small program.

Stuff which would require a lot of code (or more libraries) in C come for "free" in the C++ standard library.

The point is, the executable doesn't grow to 1MB by outputting a 3rd line of text.

As most real-world programs are many 1000's (or millions) of lines of code, the initial hit from the standard library is irrelevant.

Or it could simply be down to debug vs. release, or whether static / dynamic libraries are used, or whether debug information is in the .exe or a separate database.

[PC_Nerd]

Hmmm ok.

both were compiled with the command:
g++ test1.cpp
then they were created into a.exe.

which library is the C++ as opposed to the C?.

Also - is there a specific library list that you would recomend over another set of libraries/files so that filesize is kept to a minimumn ( Im attempting to get as small a filesize as possible...)

Thanks!

[grumpier]

std::cout and the streaming to it involve functions from the C++ standard library.

As to libraries to use/avoid to minimise executable size, there's no single correct answer. As Salem said, when you write a substantial program, the size of the executable is more often influenced by the code you write than the libraries you use.

Unless you have severe constraints on available disk space (which is unlikely for people writing a 5 line program) your time would be better spent worrying about getting the program functionality correct than in optimising its performance or disk usage.

Once you've got your program doing what it needs to do, you can turn your attention to optimisation concerns (executable size, runtime speed, etc etc). It is generally more productive to do such optimisations in one hit, after you've got your program working, because the real "hot spots" (the things you need to focus attention on to productively optimise) are not easy to predict without the aid of tools like profilers. One of the most effective and, unfortunately, common ways to become an unproductive programmer is to spend lots of time worrying about optimisation before you need to.

[MosaicFuneral]

If you're desperate for small code, and you're in Windows there's MASM; but that's obviously a very different language from C++.

There's also the -s option and -Os, in GCC.
The manual:
http://gcc.gnu.org/onlinedocs/gcc-4.3.2/gcc/
And a quick primer:
http://tfc.duke.free.fr/coding/gcc-en.html

[William Hemsworth]

>If you're desperate for small code, and you're in Windows there's MASM; but that's obviously a very different language from C++.

And you can use an executable compressor like nPack, see the attachment.

Just another option :icon_rolleyes:, but i've used it for compressing some programs/games before, and it works surprisingly well.

[grumpier]

And you can use an executable compressor like nPack, see the attachment.

You need to be careful with executable compression. Compressed executables have some characteristics associated with self-modifying code (the decompression stub unpacks code and data into memory). Because of this, they can trigger false positives from anti-virus and anti-malware scanners. Also, to make it worse, a few products out there have actually carried virus or trojan horse payloads.

They can also make some programs run very inefficiently on operating systems that work with virtual memory (eg windows, unix). On those systems, executable compression is not a good idea if multiple instances of an executable are likely to be run concurrently.

If you accept these limitations, one that I've found rather useful is UPX.