Thread: mingw32-g++ size concerns

Is C++'s iostream, compared to C's stdio.h, really that much bigger? If it's possible, does MinGW have a compiling method of compiling only what's actually used in the application, or is it already doing that and C++ just uses that much more in size?

Read the MinGW Wiki on Reasons for 'large' objects, libraries and executables.

I mean, small example is of course not that big a deal, but when I go into more complex projects, that will probably make a difference.

As noted on that wiki page, the overhead is usually fixed, so the relative difference in executable size will actually decrease as your project becomes more complex.

I did use the strip command and I didn't use the -g parameter. It's still large.

Yes, and that is the overhead and I was talking about, which is also mentioned in that wiki page:

When you use template classes such as the Standard Template Library, the compiler generates code separately for each instantiation (e.g. vector<int> and vector<string>) so the total code size can increase significantly. Other elements of the standard library such as iostreams, exception handling and std::string can seem large compared to small "Hello World" type programs but this overhead is generally constant so it will not be significant in more realistic applications.

In other words, you usually can ignore this in a real project, though it may seem disturbing for "Hello world".

Originally Posted by Chris87

Besides, VC9, in some cases, has required C++ language differences that don't apply to cross platform compilers. Like, in some C++ books I've read there was commented code with the note "Uncomment if using VC++"

That should not be true.
At least not anymore. It's true that VC9 has language extensions, but it should compile standards compliant code fine.
Do you have an example of somewhere you've heard/seen that?

By default, MinGW dynamically links to the C runtime that is available on most versions of Windows.

For the longest time however, it statically linked to libstdc++, and it is very likely that this is why you are seeing such an executable size difference.

Here is a snippet from the latest release notes however:

NEW FEATURES SINCE MINGW GCC 3.4

Windows-specific:

....

-Shared libstdc++: Add -lstdc++_s to your link flags to link against a DLL
version of libstdc++.

....

So make sure you have one of their V4 releases and try that. It should significantly decrease your executable size, at least for a simple hello world app. For example, here's a little test I did with a simple hello world app (my source code was in test.cpp):

Code:

CommandLine                          Executable Size

g++ test.cpp                         844kb
g++ -Os -s test.cpp                  437kb
g++ test.cpp -lstdc++_s              16kb
g++ -Os -s test.cpp -lstdc++_s       5kb

That look about right to you?
(Keep in mind the runtime dependency this creates though)

Maybe you aren't understanding the meaning of "New Features Since MinGW 3.4". It's a list of features they've added since version 3.4. I honestly can't think of another way to express that -- oh wait... how bout:

Code:

SELECT *
FROM   dbo.Features
WHERE  VersionAdded > 3.4

[edit]
By the way, I feel sad to report that even though MinGW allows you to use a dynamically linked version of the standard C++ library, it is in fact broken. Despite the fact that my examples compiled, the dynamically linked ones crashed immediately upon running them. This is to be expected though, the current MinGW release is an alpha build. Also, a bug has been filed on their SourceForge tracker.
[/edit]