Size of source vs. compiled files

D

dave.harper

I started learning C++ a few days ago, and I've run into a couple
questions regarding what is included in the executable when the source
is compiled... I've written a simple, 1-D rocket predicting program
that's under 2K prior to compiling, but about 540k after compiling.
Does it include functions (or something else?) from the header/include
files even if they aren't used in the actual program?

Pasted below is the program.

Thanks in advance!
Dave


#include <cstdio>
#include <cstdlib>
#include <iostream>
using namespace std;

double interpolate(double t, double INDEX[], double TABLE[])
{
int count = 0;

do
{
count = count + 1;
} while (t>INDEX[(count)]);

double i1 = INDEX[(count-1)];
double i2 = INDEX[(count)];
double t1 = TABLE[(count-1)];
double t2 = TABLE[(count)];
double result = ((t-i1)/(i2-i1)*(t2-t1))+t1;
return result;
}

int main(int nNumberofArgs, char* pszArgs[])
{

double TIME[5];
double THRUST[5];
double t=0;

TIME[0]=0;
TIME[1]=.1;
TIME[2]=3;
TIME[3]=3.1;
TIME[4]=999;

THRUST[0]=0;
THRUST[1]=100;
THRUST[2]=100;
THRUST[3]=0;
THRUST[4]=0;

double y=200;
double ymax=y;
double vy=0;
double mass=2;
double CAD=.01;
double dfy;
double fm;
double dt=.01;
double isp=200;
double imp=0;
double g=9.8;
double ay;
double fy;

do
{
if (vy>0)
{
dfy=-(.5*CAD*vy*vy);
}
else
{
dfy=(.5*CAD*vy*vy);
}
fm=interpolate(t,TIME,THRUST);
mass=mass-(fm*dt/isp/g);
imp=imp+(fm*dt);
fy=fm+dfy-(mass*g);
ay=fy/mass;
if (ymax<y)
{
ymax=y;
}
y=y+((vy+ay*dt/2)*dt);
vy=vy+(ay*dt);
t=t+dt;
} while (y>0);

cout << "time is:" << endl;
cout << t << endl;
cout << mass << endl;
cout << imp << endl;
cout << ay << endl;
cout << fm << endl;
cout << dfy << endl;
cout << vy << endl;
cout << y << endl;
cout << fy << endl;
cout << ymax << endl;

system("PAUSE");

return 0;
}
 
K

Karl Heinz Buchegger

I started learning C++ a few days ago, and I've run into a couple
questions regarding what is included in the executable when the source
is compiled... I've written a simple, 1-D rocket predicting program
that's under 2K prior to compiling, but about 540k after compiling.

The executable not only contains the translated program but lots of other
things.
Most prominent is the runtime library. If you do output to the console then
obviously there must be some code that does exactly that: handling output.
If you do math, then obviously all the math functions need to be implemented
somewhere. All of this is in the runtime library. Depending on the actual linker
it might link in all of the runtime library or just the parts that are really
needed by your program.

Another thing that might be in your final executable is the debugger information.
A debugger is a program which can control your program during execution. This way
it is possible to inspect your program while it runs. You can watch variables as
they change, set breakpoints (the debugger interrupts the program when it reaches
a specific point) and lots more. Debugger information is not cheap. The executable
needs to hold information which executable code parts correspond to which source
code part, what variable names where there in the beginning, which type did they
have, etc. Everything that is needed to bridge the gap between pure machine
code and your high level language source code.

With a size of 540K I would guess that both things happend: You have debugger
information in your executable and the runtime is linked in.
 
D

dave.harper

Karl said:
The executable not only contains the translated program but lots of other
things.
Most prominent is the runtime library. If you do output to the console then
obviously there must be some code that does exactly that: handling output.
If you do math, then obviously all the math functions need to be implemented
somewhere. All of this is in the runtime library. Depending on the actual linker
it might link in all of the runtime library or just the parts that are really
needed by your program.

Another thing that might be in your final executable is the debugger information.
A debugger is a program which can control your program during execution. This way
it is possible to inspect your program while it runs. You can watch variables as
they change, set breakpoints (the debugger interrupts the program when it reaches
a specific point) and lots more. Debugger information is not cheap. The executable
needs to hold information which executable code parts correspond to which source
code part, what variable names where there in the beginning, which type did they
have, etc. Everything that is needed to bridge the gap between pure machine
code and your high level language source code.

With a size of 540K I would guess that both things happend: You have debugger
information in your executable and the runtime is linked in.

Karl,
Thanks for the info. I turned off the debugger info, and it knocked
off 100k (down to 420k or so). I haven't been able to find out how to
unlink unused parts of the runtime library. I'm using Bloodshed
Dev-C++, and I've poked around all the options, but haven't seen it
yet. I'm not sure it's an option since it's freeware...?

Thanks!
Dave
 
P

Peter Julian

hint: iostream is a pig. use printf.

Compare oranges with oranges. printf is a method (one with deep
shortcomings), The iostream library is a complete input output stream
hierarchy used throughout the STL (not only with cin and cout). Thats with
supplied and overideable insertion and extraction operators. printf() might
as well gather cobwebs in its corner.

When compared to printf()'s parent library, that iostream pig turns the
ancestor(s) into mud. In fact, iostream makes it look like a whimp.
 
P

Peter Julian

Karl,
Thanks for the info. I turned off the debugger info, and it knocked
off 100k (down to 420k or so). I haven't been able to find out how to
unlink unused parts of the runtime library. I'm using Bloodshed
Dev-C++, and I've poked around all the options, but haven't seen it
yet. I'm not sure it's an option since it's freeware...?

Have you considered structuring the program with a class?

Bloodshed's underlying compiler is mingw / gcc.
I got that release size down to 260 KB with Dev-C++. Strip executable and
Best Optimization in Project options > Compiler tab.

You could specify additional command line options.
Example for a release compilation where Exceptions and rtti aren't needed:

-s Strip symbols
-fomit-frame-pointer Don't compile frame pointers
-Os Optimize for size
-fno-exceptions Don't support exception handling
-fno-rtti Don't generate run-time type checking

Thats but a few in a long, long list...
http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#Optimize-Options
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,997
Messages
2,570,241
Members
46,832
Latest member
UtaHetrick

Latest Threads

Top