simple compile question

[Threshold]

I was testing if MinGW was setup correctly so i tried to compile a simple command line program, in Windows XP SP2. The compiler and linker show no errors but the exe file that i'm getting has a size of 500 kilobytes. Isn't it huge for a hello world application?

[Ceniza]

If that's a C++ hello world application, then that's just normal. MinGW's g++ (I don't know about their latest 4.2.x snapshot) always links statically against the C++ library, causing it to include a lot of stuff in the executable. You could try stripping the executable (use the -s linker option or use the strip program), using UPX or downloading one of those GCC 4.x.x builds that are around in the forums that come with a dynamic library version of libstdc++.

[ingenuus]

I recently started looking into CodeBlocks and MinGW again and I'm considering this issue of size and C++ libstdc++ linkage.

CodeBlocks itself is compiled with MinGW, isn't it?  So, each of its 30+ dlls and 3 exes has a 300-500KB libstdc++ statically linked?  Have the CB devs considered using a libstdc++ dll for win32?

Also, it looks like it is possible to switch MinGW to use msvcr71 or msvcr80 instead of msvcrt.dll for the C runtime, but it looks like g++ can only use its own libstdc++ for the C++ runtime.  Is this correct?  Or is there a way to make g++ use msvcp60, msvcp71, etc.?

Thanks!

[thomas]

Luckily, in most cases, it is not exactly as bad as this sounds. The one really bad thing is <iostream>.

For example, if you include <algoritm>, or <vector>, or <map>, this adds about 50kB of symbols to your code. If you include all of them, it only ever adds about 55kB total (due to overlap). After stripping, this works out to exactly zero (except for code that you actually instantiate).

Now, unluckily, <iostream> is an ugly fat pig. It's not just a bunch of templates, but it's some real binary code in some library that is linked against, and it includes, references, and instantiates pretty much everything, too.
As Ceniza pointed out correctly, MingW-gcc links statically against libstdc++, and unluckily the linker is not particularly good at dead-stripping the unused code here.

Thus, by including <iostream>, you actually add 500+kB of (dead) code to your application. The good side of the story is that a big part of the remaining standard library is pretty much "free" after you have paid that blood tithe, as most everything is in the executable either way.

Being a stream-hater, this isn't much of an issue for me, personally. I never understood why people have such a hype about streams, or why Mr. Stroustrup added them in the first place. At the very least, a better operator could have been found. But well... I'm going off-topic.

Whenever <iostream> bites you, use good old printf(), it's so much nicer anyway

So, each of its 30+ dlls and 3 exes has a 300-500KB libstdc++ statically linked?

cb_console_runner.exe is 21.5kB, and 7 of the 11 core plugins are under 500kB as well, so this obviously isn't the case (luckily).
The only component in the Code::Blocks package that uses streams is the autorevision tool (which is not even part of Code::Blocks, technically). That's mostly out of lazyness from my part, as I couldn't be bothered to write 5 extra lines of tokenizer code when the standard library could as well do the job, and size really didn't matter.

[ingenuus]

Thus, by including <iostream>, you actually add 500+kB of (dead) code to your application. The good side of the story is that a big part of the remaining standard library is pretty much "free" after you have paid that blood tithe, as most everything is in the executable either way.

Thanks for clarifying that for me, Thomas!  I guess the C++ iostream "Hello World!" is just a terrible first example in terms of size.

Do you have any insight on linking to msvcp60, msvcp71, etc. as the C++ runtime instead of libstdc++?

Thanks again.