Empty program so large?

[Keith H Duggar]

When I compile the simplest possible c++ program:

int main ( int , char** ) { return 0 ; }

using gcc 2.95 on OS X the executable is about 9.5 kilobytes. Using
gcc 3.2 it rocks in around 10 kilobytes. By the way, I used -O3 with
no debugging symbols or profiling code.

Now, I'm no compiler or assembler expert and this question is pure
curiosity. Why is this empty program so large? Roughly speaking, what
are those two thousand or so machine instructions for? What file sizes
do you get with your compiler/platform?

I've seen Hello World programs in PowerPC assembly that are less than
20 instructions. Does this empty program really need to be one hundred
times larger?

 

[Artie Gold]

When I compile the simplest possible c++ program:

int main ( int , char** ) { return 0 ; }

using gcc 2.95 on OS X the executable is about 9.5 kilobytes. Using
gcc 3.2 it rocks in around 10 kilobytes. By the way, I used -O3 with
no debugging symbols or profiling code.

Now, I'm no compiler or assembler expert and this question is pure
curiosity. Why is this empty program so large? Roughly speaking, what
are those two thousand or so machine instructions for? What file sizes
do you get with your compiler/platform?

I've seen Hello World programs in PowerPC assembly that are less than
20 instructions. Does this empty program really need to be one hundred
times larger?

It's boilerplate startup code, library code linked in by default etc. --
all of which is decidedly off topic here.

<OT>
When you compile, add whatever flag your compiler uses for `verbose';
all the stuff the compiler goes through (or is gone through on its
behalf) to create an executable will be enlightening.
</OT>

Cheers,
--ag

 

[E. Robert Tisdale]

When I compile the simplest possible c++ program:

int main(int argc, char* argv[]) { return 0; }

using gcc 2.95 on OS X the executable is about 9.5 kilobytes.
Using gcc 3.2 it rocks in around 10 kilobytes.
By the way, I used -O3 with no debugging symbols or profiling code.

cat smallest.cc

int main(int argc, char* argv[]) { return 0; }

g++ -Wall -ansi -pedantic -Os -s -o smallest smallest.cc
./smallest
ls -l smallest

-rwxr-xr-x 1 edwin hpcc 2692 Feb 13 21:46 smallest

g++ --version

g++ (GCC) 3.2 20020903 (Red Hat Linux 8.0 3.2-7)

 

[Phlip]

When I compile the simplest possible c++ program:

int main ( int , char** ) { return 0 ; }

using gcc 2.95 on OS X the executable is about 9.5 kilobytes. Using
gcc 3.2 it rocks in around 10 kilobytes. By the way, I used -O3 with
no debugging symbols or profiling code.

The FAQ covers this under the topic "Why is my executable so large?"

http://www.parashift.com/c++-faq-lite/class-libraries.html#faq-36.8

Checking the FAQ before posting is always good.

But the FAQ doesn't say that implementations balance their libraries to
reduce the size of large apps, not small apps.

 

[Keith H Duggar]

But the FAQ doesn't say that implementations balance their libraries to

reduce the size of large apps, not small apps.

Maybe so but then GCC and others seem to completely diregard the "pay
for what you use" design principle of C++.

In fact, in many threads (not necessarily C/C++ related) I have found
people stating that such behavior is :

"result of sloppy linker"
"a bad compiler"
"(not) a decent optimizing compiler"

Thus, would you say that those statements apply to GCC and others?

Doesn't this also make it rather impratical to write tight utilities
using these C++ compilers? Do you know of any way to force them to
write better code for small utility programs? Or any alternative C++
compilers that are a little more careful?

Many others posters constantly tout the "excellent optimizing
compilers" and say "don't bother with hand optimization the compiler
will do much better that you ever could" etc. These statements do not
seem to be justified considering this example as well as many others
discussed in the forum regarding various C++ implementations.

 

[Carl Muller]

When I compile the simplest possible c++ program:

int main ( int , char** ) { return 0 ; }

using gcc 2.95 on OS X the executable is about 9.5 kilobytes. Using
gcc 3.2 it rocks in around 10 kilobytes. By the way, I used -O3 with
no debugging symbols or profiling code.

Now, I'm no compiler or assembler expert and this question is pure
curiosity. Why is this empty program so large? Roughly speaking, what
are those two thousand or so machine instructions for? What file sizes
do you get with your compiler/platform?

I've seen Hello World programs in PowerPC assembly that are less than
20 instructions. Does this empty program really need to be one hundred
times larger?

IIRC when I tried writing hello world on a Sun computer back in the
1980s, it came to 300Kbytes, and a simple graphical game of life came
to 600Kbytes (which would not even have fitted into memory of the PCs
of the time) so you are getting off lightly!

 

[Karl Heinz Buchegger]

Maybe so but then GCC and others seem to completely diregard the "pay
for what you use" design principle of C++.

In fact, in many threads (not necessarily C/C++ related) I have found
people stating that such behavior is :

"result of sloppy linker"
"a bad compiler"
"(not) a decent optimizing compiler"

Thus, would you say that those statements apply to GCC and others?

No.
In real life it is very uncommon that you write a program just like the
one you presented.

Doesn't this also make it rather impratical to write tight utilities
using these C++ compilers?

Don't think so. Even in small utilities you need at least
a few things: startup code, I/O facilities, termination code, probably
some dynamic memory allocations.

So even if the 'smallest program' takes some size, you will find that
this size does increase slowly as you add code to your program.