Question: My executable was 364KB in size. It did not use a Vector2D class so I implemented one with overloaded operators.

I changed most of my code from

```
point.x = point2.x;
point.y = point2.y;

```

to 

```
point = point2;

```

This resulted in removing nearly 1/3 of my lines of code and yet my exe is still 364KB. What exactly causes it to grow in size?

Answer: 
> 
> What makes EXE’s grow in size?
> 
> 
> 

External libraries, especially static libraries and debugging information, total size of your code, runtime library. More code, more libraries == larger exe. 

To reduce size of exe, you need to process exe with [gnu strip](http://sourceware.org/binutils/docs-2.16/binutils/strip.html) utility, get rid of all static libraries, get rid of C/C++ runtime libraries, disable all runtime checks and turn on compiler size optimizations. Working without CRT is a pain, but it is possible. Also there is a [wcrt](http://wcrt.sourceforge.net/) (alternative C runtime) library created for making small applications (by the way, it hasn't been updated/maintained during last 5 years).

The smallest exe that I was able create with msvc compiler is somewhere around 16 kilobytes. This was a windows application that displayed single window and required msvcrt.dll to run. I've modified it a bit, and turned it into practical joke that wipes out picture on monitor.

For impressive exe size reduction techniques, you may want to look at [.kkrieger](http://www.theprodukkt.com/kkrieger). It is a 3D first person shooter, 96 kilobytes total. The game has a large and detailed level, supports shaders, real-time shadows, etc. I.e. comparable with Saurbraten (see [screenshots](http://www.theprodukkt.com/kkrieger#22)). The smallest working windows application (3d demo with music) I ever encountered was 4 kilobytes big, and used compression techniques and (probably) undocumented features (i.e. the fact that \*.com executbale could unpack and launch win32 exe on windows xp)..

In most cases, size of \*.exe shouldn't really bother you (I haven't seen a diskette for a few years), as long as it is reasonable (below 100 megabytes). For example of "unreasonable" file size see debug build of Qt 4 for mingw.

> 
> This resulted in removing nearly 1/3 of my lines of code and yet my exe is still 364KB. 
> 
> 
> 

Most likely it is caused by external libraries used by compiler, runtime checks, etc. 
Also, this is an assignment operation. If you aren't using custom types for x (with copy constructor), "copy" operation is very likely to result in small number of operations - i.e. removing 1/3 of lines doesn't guarantee that your code will be 1/3 shorter. 

If you want to see how much impact your modification made, you could "ask" compiler to produce asm listing for both versions of the program then compare results (manually or with diff). Or you could disasm/compare both versions of executable. BUt I'm certain that using GNU strip or removing extra libraries will have more effect than removing assignment operators.
What type is point? If it's two floats, then the compiler will implicitly do a member-by-member copy, which is the same thing you did before.

EDIT: Apparently some people in today's crowd didn't understand this answer and compensated by downvoting. So let me elaborate:

Lines of code have NO relation to the executable size. The source code tells the compiler what assembly line to create. One line of code can cause hundreds if not thousands of assembly instructions. This is particularly true in C++, where one line can cause implicit object construction, destruction, copying, etc.

In this particular case, I suppose that "point" is a class with two floats, so using the assignment operator will perform a member-by-member copy, i.e. it takes every member individually and copies it. Which is exactly the same thing he did before, except that now it's done implicitly. The resulting assembly (and thus executable size) is the same.