File Sizes
I know that when you compile the libraries you use are compiled into your code making the file a lot bigger. Having said that can anyone tell me why a file that is 290 bytes with 1 library has a larger compiled file than a file with 782 bytes and 2 libraries? The only reason I can think of is that optimization kicked in and reduced the file size.
Last edited on
| I know that when you compile the libraries you use are compiled into your code making the file a lot bigger. |
This is incorrect.
| Having said that can anyone tell me why a file that is 290 bytes with 1 library has a larger compiled file than a file with 782 bytes and 2 libraries? |
The size of the cpp files means nothing.
The number of the libraries also means nothing.
All that matters is the size of the compiled code. When you statically link to libraries, [often] only the code you use in that library is included in your executable. So you can link to a massive library, but if you don't use any code from it, it [often] won't increase your binary's file size.
I used the iostream in both and in the larger one i also had the math.h so should it at least be the same size?
It doesn't matter what you #include, it only matters what your code is.
You can include every header there is... it won't make any difference in the file size. The only thing that increases the file size is writing/using more code.
Calling functions in libraries is what can make the binary larger. #including something does nothing.
The larger program probably has more code, despite using fewer libs.
EDIT:
Also, standard libs might not even be statically linked... so using them might not make the binary bigger even if you use them to their fullest.
You can include every header there is... it won't make any difference in the file size. The only thing that increases the file size is writing/using more code.
Calling functions in libraries is what can make the binary larger. #including something does nothing.
The larger program probably has more code, despite using fewer libs.
EDIT:
Also, standard libs might not even be statically linked... so using them might not make the binary bigger even if you use them to their fullest.
Last edited on
I don't know if your familiar with Java but Why is the compiled file size so much smaller?
If I have 2 programs that do the exact same thing in Java and C++ why is the class file so much smaller if the library is only sometimes put into the .exe? The C++ program only uses cout once and its huge in comparison to a .class file and Java that uses System.out.prinln() once. I don't get why there is such a big difference.
I've never coded in Java, and I know very little about it. I seem to recall there was some kind of additional runtime involved, though? That when you code in Java, you ended up with some kind of compiled code that doesn't actually run, but gets interpreted by a runtime. Presumably that would lead to a significant difference.
As I said, I'm way out of touch with Java and stand by to be corrected.
As I said, I'm way out of touch with Java and stand by to be corrected.
Java programs are compiled to Java byte code usually, which requires a separate interpreter (Java Virtual Machine, or JVM) to be executed. There is at least one compiler that allows you to compile Java source code to an executable binary, the Java frontend of GCC (gcj), and it also allows you to only compile to byte code to be run by the interpreter (gij). I don't know how interoperable the byte codes are between the Sun/Oracle Java compiler and gcj, though.
In any case, a class file is Java byte code if I recall correctly. It is most likely smaller since C/C++ libraries and operating system libraries are linked to the object code the C++ compiler produces to finally make an executable binary. Simply put, it is like comparing Java byte code to object code produced by a C++ compiler before it is linked to create a binary. The difference is the fact that a JVM interprets the Java byte code to properly do what the program is meant to do whereas C++ requires information from the operating system since the operating system functions as the interpreter.
In any case, a class file is Java byte code if I recall correctly. It is most likely smaller since C/C++ libraries and operating system libraries are linked to the object code the C++ compiler produces to finally make an executable binary. Simply put, it is like comparing Java byte code to object code produced by a C++ compiler before it is linked to create a binary. The difference is the fact that a JVM interprets the Java byte code to properly do what the program is meant to do whereas C++ requires information from the operating system since the operating system functions as the interpreter.
So just to make sure I have this straight. C++ code is compiled into an object file and then it gets linked to the necessary libraries in the .exe thats created? So does that mean however many times you access a part of a library the part will be linked to the .exe? Thats what makes it so big? Where as in Java the machine interpreted the language with the JVM? So instead of linking the files in just calls them reducing file size?
"So just to make sure I have this straight. C++ code is compiled into an object file and then it gets linked to the necessary libraries in the .exe thats created?"
Depends how you link it. If you go for static linking, the libraries get wrapped into the final executable. If you go for dynamic linking, they are not, but the system you run the executable on will need to provide them. In Win32, for example, these are dll files. This will lead to a smaller executable file size, but carries with it other potential disadvantages; there's a trade-off to be made.
Depends how you link it. If you go for static linking, the libraries get wrapped into the final executable. If you go for dynamic linking, they are not, but the system you run the executable on will need to provide them. In Win32, for example, these are dll files. This will lead to a smaller executable file size, but carries with it other potential disadvantages; there's a trade-off to be made.
Last edited on
| So just to make sure I have this straight. C++ code is compiled into an object file and then it gets linked to the necessary libraries in the .exe thats created? So does that mean however many times you access a part of a library the part will be linked to the .exe? Thats what makes it so big? |
Not quite... the object files and all libraries are linked together to form one executable.
Every symbol (functions etc.) you reference from an external library at least once in one of the object files is imported. If you're using it in multiple object files, it's still imported just once. There are two ways this "importing" can happen. With static linking, the actual code for a function is copied into the executable. This increases file size but has the advantage that no external libraries (.dll/.so files) are needed. With dynamic linking this doesn't happen, but as a result your program requires additional libraries to run. You should google for "dynamic vs static linking" if you want to know more.
In Java, everything is "linked" dynamically, so to speak.
MinGW tends to link the C++ runtime statically and if you use any of the C++ stream headers, this will cost you up to a few hundred kilobytes in executable size. If it's any consolation: as a result, no one will ever encounter any problems with missing msvc*.dll files when running your program.
Last edited on
Well I don't need to much detail, because I have to explain this to my class and I don't want anyones head to explode. So if its statically linked it gets but into the executable? Thats all I needed to know because I don't have and .dll files so I know I'm not Dynamically linking. Just one more question though. If I use cout multiple times in the same file does it get linked multiple times are am I just being stupid?
| If I use cout multiple times in the same file does it get linked multiple times are am I just being stupid? |
No, it gets linked once... even if you use it in a hundred different files.
Last edited on
Topic archived. No new replies allowed.