Include eight headers, get a 1500kb program. Is this normal?

[salem c]

C:/raylib/w64devkit/bin/g++.exe -O2 -I .. -I ../.. -c prototype.cpp
This will produce prototype.o

Then do size on the object and post your result.

$ size prototype.o
   text	   data	    bss	    dec	    hex	filename
   3512	    200	      1	   3713	    e81	prototype.o

You can also do size on your final executable.

The difference between the two is all the stuff dragged in from your libraries.

[AidanofVT]

@jonnin
"Os" and "O3" have no significant effect.

@mbozzi
Here's the source code: https://puu.sh/ISsnQ/00da245db5.cpp
Expect cringeworthy flaws. This is my first C++ project.

@salem c
Result:
text data bss dec hex filename
15192 172 672 16036 3ea4 accountant.o

I don't know how to interpret those metrics. The .o file is 31kb, more in line with what would normally be expected of a project on this scale. Previous respondents to this thread ssaid that the compiler is normally pretty good at trimming unnecessary stuff from libraries. Isn't 600kb of library imports concerningly large? You can look at my source code linked above to see what I'm importing.

[jonnin]

600kb isnt really very much anymore. No, its not concerning at all... I have many programs on my computer that are over 10MB in size and they have dynamic libraries with them as big or bigger than that. Why are you concerned? All I can think of is you are targeting a small embedded device, in which case, worrying about it is ok. Modern computers have gigs of ram, tb of disk space, ... what is the worry? Most of my 1/2 page utility programs generate 150+ kb executables with g++. I could maybe shrink them, but why?

Its not going to suffer exponential growth, either. You add a few common things up front, and you stop until you start to make a larger program that needs even more stuff, so it does make sense that even a small program will get a big bump up front that won't grow for a while until you start doing more things... you can do 10 times as much stuff with the same libraries and then would the program size seem too big? It likely would only be a small % larger though.

[salem c]

text data bss dec hex filename
15192 172 672 16036 3ea4 accountant.o

text = the executable code and read-only data (such as string constants)
data = initialised data such as char fileName [21] {"acCOUNTant_state.txt"};
bss = uninitialised and zero-initialised data such as bool running {false};
dec = the sum of the previous 3 values
hex = the same thing, but in hex.

So after commenting out a couple of Windows specifics like Sleep and MessageBox, I could compile it on Linux.

First comparing local optimisations.

$ g++ -c accountant.cpp 
$ size accountant.o
   text	   data	    bss	    dec	    hex	filename
  16268	     61	   1089	  17418	   440a	accountant.o

$ g++ -c -O2 accountant.cpp 
$ size accountant.o
   text	   data	    bss	    dec	    hex	filename
  13417	     52	   1062	  14531	   38c3	accountant.o

These are in line with your observations for the .o file itself.

Now for the whole program:

$ g++  accountant.cpp -lncurses
$ size a.out 
   text	   data	    bss	    dec	    hex	filename
  28713	   1440	   1448	  31601	   7b71	a.out

Linux images are dynamic linked by default, so all that as been added are the stubs to do the load time linking with the curses and standard libraries.

Using the ldd tool to find out what they are:

$ ldd a.out 
	linux-vdso.so.1 (0x00007ffd1428f000)
	libncurses.so.6 => /lib/x86_64-linux-gnu/libncurses.so.6 (0x00007f2d5d660000)
	libtinfo.so.6 => /lib/x86_64-linux-gnu/libtinfo.so.6 (0x00007f2d5d630000)
	libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f2d5d44e000)
	libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f2d5d433000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f2d5d241000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f2d5d23b000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f2d5d0ea000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f2d5d6b3000)
$ size $(ldd a.out | awk '/=>/ { print $3 }')
   text	   data	    bss	    dec	    hex	filename
 149855	   1700	    360	 151915	  2516b	/lib/x86_64-linux-gnu/libncurses.so.6
 166341	  14652	   1152	 182145	  2c781	/lib/x86_64-linux-gnu/libtinfo.so.6
1895210	  51208	  13920	1960338	 1de992	/lib/x86_64-linux-gnu/libstdc++.so.6
  92721	    968	    680	  94369	  170a1	/lib/x86_64-linux-gnu/libgcc_s.so.1
1988984	  20456	  16192	2025632	 1ee8a0	/lib/x86_64-linux-gnu/libc.so.6
   9175	    792	    112	  10079	   275f	/lib/x86_64-linux-gnu/libdl.so.2
1358459	    900	     12	1359371	 14be0b	/lib/x86_64-linux-gnu/libm.so.6

Note that each shared library is only loaded once for all extant processes on a system. So large libraries like libstdc++ that are used widely would not count for much just by running yet another program also using libstdc++. Depending on what you're doing of course, but this program might be the only one using libncurses at any given moment.

> Isn't 600kb of library imports concerningly large?
What is now clear from the above is that you're paying a price for both the C and C++ standard library components.

It's important to note that your program will not continue to grow at this rate.
If you added more of the same code, it would barely budge from this plateau, showing slow steady increases.
If you started using say std::vector, you might see a smaller step change, and then it would level off again.

FWIW, There isn't anything in your C++ code that couldn't be done in C with some simple modifications.

[AidanofVT]

Yeah, I'm not concerned about a 600KB program as a practical matter, it's just that some earlier comments on this thread led me to believe that 600KB is outsized for a program like this. But you guys have now looked at what libraries I'm importing, and you seem to know what you're talking about, and I guess nobody ever balked at 600KB for a program that's statically linked and compiled for Windows and is 64-bit, so I suppose I'll just let it be.

salem c, I'm not really interested in turning this into a C program, since C++ is what I'm trying to learn, but I am interested in adapting my source code to compile for Linux, so thanks for the comments about that.