Why You Should Avoid Using #include <bits/stdc++.h> While Writing Code

Written by embarcadero | Published 2021/02/05
Tech Story Tags: c++ | cpp | cplusplus | programming | coding | include | while-writing-code | c++-editor

TLDR Why You Should Avoid Using #include <bits/stdc++.h> While Writing Code? The aim of including header files while writing code is to allow access to predefined or user-defined functionality which will aid in building programs. The #include keyword instructs your C++ compiler to process (literally insert, and read at that point in code) the contents of the specified header file during compilation. Several competitive programmers make use of it due to the convenience of reducing time spent writing programs.via the TL;DR App

Introduction 
The aim of including header files while writing code is to allow access to predefined or user-defined functionality which will aid in building programs. The #include keyword instructs your C++ compiler to process (literally insert, and read at that point in code) the contents of the specified header file during compilation. <bits/stdc++.h> is a header file known for the convenience it provides to programmers. It includes all C++ header files. Due to time constraints, a large number of competitive programmers make use of it because it serves as a faster alternative while writing code. 
However, there are several implications of including this header file in programs. Like using namespace std, #include <bits/stdc++.h> is an easier but also terrible way of writing code. In this article, the reasons why including <bits/stdc++.h> is considered a bad coding practice will be discussed and a better alternative will be shared.        
Reasons why “#include <bits/stdc++.h>” should be avoided:   
For Efficiency and Better Performance 
Including the <bits/stdc++.h> header file will reduce the performance of a program by contributing to the program’s overhead. Here’s a short story to help you picture things better: 
Jake decides to travel to Barbados for his 3-day long vacation. He gets to the airport with his luggage, which turns out to be several trucks. He packed every single item in his home as opposed to just picking a box filled with clothes and toiletries that would last him for three days.
In a library somewhere in Eastleigh, Susan feels like reading a book authored by Dan Brown, she borrows “The Da Vinci Code” because it's her all-time favourite, and along with that she also borrows every other book in the library. Mind you, she only plans to read “The Da Vinci Code” and won’t be using the other books. 
What do you think about these two scenarios? I’m sure you will agree that their actions are quite odd. To put the whole thing into perspective, imagine that I want to write code to simply print an output statement using cout. Something like “std::cout << “A paragraph or two”;” and this is the only thing my program does. Now imagine I begin to include headers like <vector>, <string>, <shared_mutex>, <unordered_map>, <queue>, and <random>. Surely one will wonder why I have made those inclusions seeing as my main function has only one print statement. I haven’t used maps, sets, vectors, and strings. I have only written an output statement. The compiler needs to parse and store many tens of thousands of lines of headers and all the types and data in them that it will never use -- and that is exactly why you should avoid including <bits/stdc++.h> in your program. It adds every single C++ header file that you can possibly think of to a program that only requires one i.e. #include <iostream>.     
A lot of stress will be placed on both the airplane and the librarian by making them carry the luggage and books respectively. Your compiler will appreciate not having to carry all that load as well.      
To Encourage Good Coding Habits 
We have already noted that making use of <bits/stdc++.h> is bad for compiler performance, and most experienced programmers will agree that it is bad coding practice. In spite of this, several competitive programmers make use of it due to the convenience of reducing time spent while writing programs. Some of these programmers become accustomed to doing so and never really learn which header files are required for most of the functionalities they need to make use of in their programs. Engaging in this practice can be problematic when you join a company and begin writing code at your new workplace because you will need to spend time finding out which header file does what function. Making it a habit not to use <bits/stdc++.h> will familiarise you with many C++ headers and the scenarios in which they should be applied.   
To Avoid Compile Errors   
It should be noted that #include <bits/stdc++.h> is not a C++ standard header and hence, not all compilers support it. The MSVC compiler allows the use of #include <bits/stdc++.h>, but other IDEs do not support it. In some IDEs, adding this header file to your code will result in a warning like: "This is an internal header file, included by other library headers. Do not attempt to use it directly." While in other C++ Builders (like the one we offer at Embarcadero), your program will fail to compile.   
 For example, if you run this code:
You will get the following output in return:   
Conclusion
In short, “#include <bits/stdc++.h>” should be avoided as much as possible, and an effort should be made to use the intended header files to make compiling more efficient. Additionally, since “#include <bits/stdc++.h>” is not supported by some compilers, it is safer to make use of the better alternative, especially if you want to write portable C++ (and C++, as an open standard, should be portable.) Last but not least, avoiding the use of “#include <bits/stdc++.h>” will familiarise you with other headers and their functionalities, thus making you a better C++ programmer.

Written by embarcadero | Embarcadero tools are built for elite developers who build and maintain the world’s most critical applications.
Published by HackerNoon on 2021/02/05