Why would it be less? point = point2 is doing the exact same work as before (inside the operator), just with a different interface.
–
GManNickGAug 19 '10 at 23:55

1

@GMan: that's why he's asking this question...perhaps he believes that the exe's grew in size based on the lines of code.
–
Jorge Israel PeñaAug 19 '10 at 23:57

4

Im going to upvote this simply for the fact that this is a really good question that a lot of people ask when their starting programming.
–
Faisal AbidAug 20 '10 at 0:03

1

I'm slightly at a loss where the "grow in size" title is coming from. The actual question wonders why the executable stays the same size. The discrepancy seems to have caused a few unjustified downvotes.
–
MSaltersAug 20 '10 at 7:25

To reduce size of exe, you need to process exe with gnu strip 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 (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. 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). 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.

The compiler probably optimised your operator overload by inlining it. So it effectively compiles to the same code as your original example would. So you may have cut down a lot of lines of code by overloading the assignment operator, but when the compiler inlines, it takes the contents of your assignment operator and sticks it inline at the calling point.

Inlining is one of the ways an executable can grow in size. It's not the only way, as you can see in other answers.

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.

Who's voting down without a comment? What's up with that?
–
EboMikeAug 20 '10 at 1:19

+1 for the downvote without comment, not cool!
–
Sam MillerAug 20 '10 at 1:52

I downvoted because it does not answer the question.
–
user195488Aug 20 '10 at 2:09

It answered the question exactly. Maybe you didn't understand my answer? Assuming (based on the limited information in the question) that his "point" is a class that contains two floats, then using the assignment operator will do a member-by-member copy, i.e. it will copy both floats individually. Which is the exact same thing as he did before. Bottom line - different source code, identical assembly code. There, how did that not answer the question?
–
EboMikeAug 20 '10 at 2:12

@EboMike: Your edit answers the question, initial answer didn't. +1 Your initial answer was more like a comment than an answer. I only downvoted once, apparently someone else felt the same way.
–
user195488Aug 20 '10 at 13:01

I think this a good example why one shouldn't worry too much about code being too verbose if you have a good optimizing compiler. Instead always code clearly so that fellow programmers can read your code and leave the optimization to the compiler.

When you compile a c or c++ program into an executable, the compiler translates your code into machine code, and applying optimizations as it sees fit.
But simply, more code = more machine code to generate = more size to the executable.

Also, check if you have lot of static/global objects. This substantially increase your exe size if they are not zero initialized.

For example:

int temp[100] = {0};
int main()
{
}

size of the above program is 9140 bytes on my linux machine.

if I initialize temp array to 5, then the size will shoot up by around 400 bytes. The size of the below program on my linux machine is 9588.

int temp[100] = {5};
int main()
{
}

This is because, zero initialized global objects go into .bss segment, which ill be initialized at once during program startup. Where as non zero initialized objects contents will be embedded in the exe itself.