7

I read that #include <file> will copy paste “file” into our source file by C++ preprocessor before being compiled.

Does this mean that the “file” (iostream) will also be compiled again and again as long as we compile source file?

Also after C++ does its job, will the size of intermediate file also have bytes of “file” + "size of source file"?

Martin Bonner supports Monica
  • 28,528
  • 3
  • 51
  • 88
Harsh Pathak
  • 85
  • 1
  • 8
  • A previous question on the same topic can help you a lot http://stackoverflow.com/questions/22645097/what-does-include-iostream-do – AurA Dec 13 '16 at 08:10
  • Read documentation of the [preprocessor](https://gcc.gnu.org/onlinedocs/cpp/) (it is nearly the same for C and for C++, but configured differently). If using [GCC](http://gcc.gnu.org/) (e.g. `g++`) compiler, you could pass it [preprocessor options](https://gcc.gnu.org/onlinedocs/gcc/Preprocessor-Options.html) like `-H` (to understand which headers are really included), or get the preprocessed form using `-C -E` – Basile Starynkevitch Dec 13 '16 at 08:40
  • It's probably worth mentioning "[forward declaration](http://stackoverflow.com/questions/553682/when-can-i-use-a-forward-declaration)" headers, particularly [`iosfwd`](http://stackoverflow.com/questions/4300696/what-is-the-iosfwd-header), which is something like a reduced-size `iostream`, useful when you don't need all the details of the full iostream file. – R.M. Dec 13 '16 at 17:09

5 Answers5

12

I read that #include <file> will copy paste “file” into our source file by C++ preprocessor before being compiled.

Yes. The data that the compiler proper sees will consist of the data in file and the data in your source file. (Actually, real compilers these days tend to merge the C preprocessor and the compiler front end and the compiler back end into a single program - but that is pretty much a detail.)

Does this mean that the “file” (iostream) will also be compiled again and again as long as we compile source file?

Yes. Some compilers have a feature called "pre-compiled headers" which allow you to compile a bunch of headers once, and then use the output of that multiple times. How you do this varies from compiler to compiler; if you need portability, don't worry about it (it doesn't make that big a difference to compile times).

Also after C++ does its job, will the size of intermediate file also have bytes of “file” + "size of source file"?

No. The size of the output file is only very weakly related to the size of the source file. For example #include <iostream> defines many, many inline functions. Any particular program will only use a very few of those - so they will be omitted from the compiler output.

Comments (which use space in the source file) don't appear in the output.

On the other hand, if you write a complex template, and then instantiate it for several different types, then the output will contain a different copy of the template for each type, and may be quite a bit larger than the input.

Martin Bonner supports Monica
  • 28,528
  • 3
  • 51
  • 88
  • I did what Shubham told here...wrote a hello world code with size 77 bytes...preprocessed code had size 428282 bytes...assembly version had size 1745 bytes and object code had size 2480 bytes.Wonder what is the size of iostream header file. – Harsh Pathak Dec 13 '16 at 08:38
  • Note that iostream itself is quite likely to be quite small - but it will include lots of other files. – Martin Bonner supports Monica Dec 13 '16 at 14:59
3

Regarding the size of intermediate file size, yes it will increase. You can check this by writing a simple hello world program and then compile it as follows (in Linux)

g++ name.cpp -o name --save-temps

This will store intermediate files, specifically:

"name.ii" (Preprocessed code after including <iostream>
"name.s"  (Assembly version of the code)
"name.o"  (Object code)

Check the difference in this size of file using:

ls -l name.cpp name.ii
Shubham
  • 2,847
  • 4
  • 24
  • 37
  • Um. Either the #include file is required to compile (in which case there won't *be* an output file if it isn't included), or it isn't required (in which case I would be surprised by a #include which managed to increase the size of the .o file - yes, I can construct counter examples, but they are pretty artificial). – Martin Bonner supports Monica Dec 13 '16 at 08:28
  • @MartinBonner Sorry I didn't understand. Can you explain a bit more? What I knew was that before compiling, the preprocessor will copy all the included headers in the source file and then compile this file. This is why I said the size will increase because the intermediate source file is being compiled. But I am not sure whether all the unused features of this intermediate source file are included in Assembly and subsequently Object code or not. – Shubham Dec 13 '16 at 08:49
  • "file size will increase" - I took this to mean "the size of the output file will be larger if you include the header file than if you don't". I don't think this is true. If you meant "the size of the output file will be larger than the size of the input file because of the included files" I don't think that is true either. The size of the input and output files is only very weakly correlated. – Martin Bonner supports Monica Dec 13 '16 at 08:54
  • Well, the preprocessed source will be at least size-of-iostream bigger, but the object file probably won’t be bigger (but maybe if you use LTO). Both can be considered ›intermediate files‹. – Darklighter Dec 13 '16 at 11:17
  • @MartinBonner `` likely does increase the object file size though - it is required to behave as if it defines a static storage duration object of type `ios_base::Init`, and the easiest way to implement it is...to define such an object. – T.C. Dec 13 '16 at 22:39
  • @T.C.: That was the "artificial" case I was thinking of - I had forgotten IOStream actually used it! (And of course, I don't think there's any need for `ios_base::Init` to be > 1 byte). – Martin Bonner supports Monica Dec 14 '16 at 06:39
  • 1
    @MartinBonner Probably not, but the associated initialization and destruction code is probably > 1 byte :) – T.C. Dec 14 '16 at 08:34
0

No.libraries(headers) don't increase the size of file because compiler don't add all of the header into your code.It just add things you use in your code to your code,

Leo
  • 867
  • 1
  • 15
  • 41
0

No, it doesn't increase program size. The file iostream and many other header files don't have compilable statements. They contain some definitions required for you program. If you look at a preprocessed C/C++ file, you will see thousands of definitions are added at the beginning of the file.

You can try it with cpp tool, run it with commands just like normal g++/gcc and see the outputs.

cpp -I /usr/include/ -I. file.cpp -o file.preprocessed

It contains just the headers and definitions, they don't increase you final program size.

Edit: As martin said, they have compilable inline functions which will compile each time, but they doesn't increase your program size unless you use them.

Lefty G Balogh
  • 1,771
  • 3
  • 26
  • 40
e.jahandar
  • 1,715
  • 12
  • 30
  • 1
    `iostream` most assuredly *does* have compilable statements! Definitions (particularly of inline functions and templates) *are* compilable - and will increase the size of your program if you use them. – Martin Bonner supports Monica Dec 13 '16 at 08:30
0

I read that #include <file> will copy paste “file” into our source file by C++ preprocessor before being compiled.

It's a little more subtle than that. #include "file" does what you describe. #include <file> pulls in a header which is not required to be a file. The idea is that the compiler can have its own internal version of that header, already in binary form, so it doesn't have to read and parse a file. If there is no header with that name, then it treats the include directive as if it had been #include "file" and looks for a file to read.

In practice, I don't know of a compiler that takes advantage of this leeway; all headers are, in fact, files that get compiled over and over again. But, as others have said, that in itself does not mean that the executable file becomes larger. Ideally, if you don't use it, it doesn't get into the executable, although some systems are better about this than others.

Pete Becker
  • 74,985
  • 8
  • 76
  • 165