Nothing seems to effect the outcome. Not changing the optimization level, not whether or not I have the debug flag set, not #DEFINE WINDOWS_LEAN_AND_MEAN, as one internet denizen suggested. Of course, a 1.5MB .exe isn't exactly a big inconvenience on contemporary machines, but it strikes me as a little outsized for a 200-line console application.
As an aside, the internet seems to think that what headers I include, and what libraries I link, effect the size of the result, but I don't understand why this would be. Sure, I can see why it would bloat the job of the linker/compiler, but aren't they smart enough to discard a bunch of unused declarations and definitions for the final result?
Something is up ... debug vs not and optimized or not should change the size a little at least.
but think of it like this... if its a tiny program, then the size is indeed governed by the libraries you put in.
aren't they smart enough to discard a bunch of unused declarations and definitions for the final result?
not as much as you might think. It does what it can, but this is a sore spot and most compilers struggle to get rid of stuff not needed. I do not fully understand why. I mean, give it a try yourself, add in about 10 more common headers like math and vector and algorithm etc. See if it gets bigger.
you can also make a do-nothing empty main program with the same headers and compile it, then take away headers one by one, see if a single one is pulling in a lot of crap and if you can avoid that one
> g++.exe -I .. -I ../.. -L .. prototype.cpp -o outcome.exe -l:pdcurses.a
At the moment, you're statically linking with the library.
If you were to dynamically link with the library, your executable would get smaller, but you'd be dependent on a dynamic library being loaded at run-time.
Whether you count this as making your program 'smaller' is debatable.
> As an aside, the internet seems to think that what headers I include, and what libraries I link, effect the size of the result,
Unnecessary headers mostly just waste compilation time. It's not so much of a problem in a single source file, but if you have 100's of .cpp files all with #include everything, then build times are going to suffer.
Later, they waste the time of future porters and maintainers of the code.
Linkers usually are smart enough to discard unused stuff.
non-windows (no windows.h) g++ on my machine make about 20k .exe files. Without that .s, its ~10x larger(!). I don't think I have ever generated > mb for a small console program... will be interesting to hear back where its coming from ... all static linkage or something with a compiler flag or that specific compiler... etc?
// the two string literals and the computation can be optimised away
"ABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFGHIJKLMNOPQRSTUVWXYZ""ABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFGHIJKLMNOPQRSTUVWXYZ" ; // return 'a' - 'A'
// the two string literals and inline construction/destruction of the std::string
// objects are typically part of the generated code
const std::string str1 = "abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyz""abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyz" ;
const std::string str2 = "ABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFGHIJKLMNOPQRSTUVWXYZ""ABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFGHIJKLMNOPQRSTUVWXYZ" ;
return str1 - str2 ; // return 'a' - 'A'
The app needs code to hook into the OS that runs the app. With Windows that is code that links into at least kernel32.dll for a static linked app. For a dynamic linked app that would include the Windows C runtime DLL(s).
Thanks, George. I think I'm going to stick with static linking, not only because it is easier, but because I do need this to be multi-platform.
I found that adding those same 700 characters in std::strings increased the size of the executable by only 2kb. Exactly the size of those characters stored in a simple text file.
Adding just a single empty STD::string to an otherwise empty program yielded 331KB. So maybe my compiler is somehow incorporating every part of every library I reference?
I tried filling that otherwise-empty program with calls to the functions and classes that I used in my original program. So, basically, a main method with just fifteen useless method calls, mostly to the pdcurses library. And guess what? I came to about the same size as my original program (1470KB).
I think I'm going to stick with static linking, not only because it is easier, but because I
do need this to be multi-platform.
Whether you use static or dynamic linking for cross platform uses is really irrelevant. A Windows compiled app will not run natively on a Mac or *nix platform, the source needs to be compiled for the specific platform you want to target.
Well written code that uses only the C++ libraries, no OS hacks, will compile for any platform that has a compiler.
You are seeing a freshly mowed grass lawn and calling it a forest.
Whether I routinely use static or dynamic linking I leave to the tools I use, their default. Visual Studio does dynamic linking.
The number of for sale software packages, games and productivity office apps, that use custom libraries are numerous.