-4

Why must I #include various libraries, such as iostream? I have learned that libraries, such as iostream specifically, are part of the C++ 'Standard Library' "which are written in the core language and part of the C++ ISO Standard itself."

This is pretty neat, but, if they are so 'standard' and such a 'core part' of the language, why do I need to #include them? Why is it that I can write a script that uses +, -, *, /, or other things without #including any libraries? [As a person completely unqualified to have an opinion on this matter,] I feel like being able to add two operands together is just as essential as being able to retrieve input from an operator (std::cin).

What exactly is the issue? Is it that my specific compiler (using Visual Studio exclusively so far) doesn't have those functions built-in? But the designers chose to innately include simple arithmetic operators instead? I understand the need to do this for an obscure or lesser known library, but not so much iostream.

Secondly, how can I 'look inside' a standard header file, such as iostream? How can I inspect the source code of common header files to see how string compare or cin works? I understand the beauty of abstraction and not having to know the nitty gritty details, but I'm obsessed with knowing how everything works.

Third, are there penalties associated with #including header files? For example, if I #include iostream, but I only use a single operator, such as std::cin, is the entire header file included in the final product? Would my program/file or the machine running it be burdened with the unused portions of iostream?

Shaun Love
  • 5
  • 1
  • One question per question please. – JaMiT Oct 17 '21 at 21:52
  • 4
    Plenty of programs do no console IO at all (most services). You only need to include what you have to use and no more. No point in compiling code you never use. – Richard Critten Oct 17 '21 at 21:53
  • 1
    For the second question, what's the issue? You look inside a standard header the same way you look inside a non-standard header: by using a text editor. Perhaps you should instead ask where you can find the standard headers on your system? – JaMiT Oct 17 '21 at 21:54
  • The includes for VS's standard library are somewhere inside the install directory. Or search for libc++ or libstdc++ to find clang's and gcc's standard libraries. Warning: that stuff is absolutely horrible to read due to constraints they have to follow on identifiers. – Mat Oct 17 '21 at 21:55
  • About penalties: no, your final program won't contain anything unused, compilers are smart enough to throw unused code away. But `#include`s make the compilation process slower, because the compiler has to parse thousands and thousands of lines of code every time (on my system, preprocessing `#include ` pastes 28'624 lines into the source) – Expurple Oct 17 '21 at 22:23
  • I don’t know what “written in the core language” is intended to mean. I can’t think of a reasonable meaning for that phrase that’s correct. Don’t read anything into it. – Pete Becker Oct 17 '21 at 22:57

1 Answers1

1

When looking at a C++ "implementation", you are really looking at two separate parts: The compiler, and the library. Basics like integer arithmetics, pointers, references and the like are defined by the core language, and implemented in the compiler core.

Higher level functions are defined in libraries. Of these, the Standard Library is only one, and defined in the same standard document as the language core.

But the standard library can be, and often is, a separate project that only happens to work in tandem with the compiler. You might use the compiler with a different library implementation, or may use the library implementation with a different compiler.

That you have to #include headers before you can use the library has something to do with efficiency. Both the compiler and you (or any other developer reading your source later on) only has to "know" about those parts of any libraries that are actually #included by your source. The compiler has less looking-up to do when parsing your code, and a developer knows pretty exactly which part of the documentation to look at for further information -- especially if you resist the urge to write using namespace ... in your source. This becomes even more important later on when you will be using several different libraries with different namespaces.

You should not use the header files for information. Highly abstracted C++ source can be somewhat of a handful to understand, and the headers are usually not written for the end user anyway. You are very much better off by referring to actual documentation, like cppreference.com, instead.

As for the third part of your question, including a header will introduce all the identifiers from that header (and, with C++, likely several other headers as well) into your translation unit. (With C, the library implementation is actually forbidden to introduce any identifiers from other standard headers unless that header was explicitly included.) This should not bother you, though. Things that are not needed do not result in actual code in your resulting binary. With really small example programs and <iostream> specifically, the "burden" might seem comparatively large because something "simple" like std::cin requires significant support (files, streams, buffers and the like). But this effect rapidly diminishes as your program becomes larger, because whatever support code is added to your binary is only added once.

And finally, most of the above is the same in other languages as well, with only minor differences. Java, C# or Python might not have "headers" per se, but in the end the issues with the standard library being separate from the compiler, identifier namespacing, and (as far as compiled languages are concerned) effect on resulting binary are similar across the board.

DevSolar
  • 67,862
  • 21
  • 134
  • 209