Why Should I Not #Include ≪Bits/Stdc++.H≫

Why should I not #include bits/stdc++.h?

Including <bits/stdc++.h> appears to be an increasingly common thing to see on Stack Overflow, perhaps something newly added to a national curriculum in the current academic year.

I imagine the advantages are vaguely given thus:

  • You only need write one #include line.
  • You do not need to look up which standard header everything is in.

Unfortunately, this is a lazy hack, naming a GCC internal header directly instead of individual standard headers like <string>, <iostream> and <vector>. It ruins portability and fosters terrible habits.

The disadvantages include:

  • It will probably only work on that compiler.
  • You have no idea what it'll do when you use it, because its contents are not set by a standard.
  • Even just upgrading your compiler to its own next version may break your program.
  • Every single standard header must be parsed and compiled along with your source code, which is slow and results in a bulky executable under certain compilation settings.

Don't do it!

More information:

  • #include <bits/stdc++.h> with visual studio does not compile
  • How does #include <bits/stdc++.h> work in C++?

Example of why Quora is bad:

  • Is it good practice to use #include <bits/stdc++.h> in programming contests instead of listing a lot of includes?

#include bits/stdc++.h with visual studio does not compile [duplicate]

Is there any way to avoid this error?

Yes: don't use non-standard header files that are only provided by GCC and not Microsoft's compiler.

There are a number of headers that the C++ standard requires every compiler to provide, such as <iostream> and <string>. But a particular compiler's implementation of those headers may rely on other non-standard headers that are also shipped with that compiler, and <bits/stdc++.h> is one of those.

Think of the standard headers (e.g. <iostream>) as a "public" interface, and compiler-specific stuff (like everything in bits/) as the "private" implementation. You shouldn't rely on compiler-specific implementation details if you want your program to be portable to other compilers — or even future versions of the same compiler.

If you want a header that includes all the standard headers, it's easy enough to write your own.

Why #includebits/stdc++.h does not work by default on windows?

bits/stdc++.h is not a standard header file. Thus, it is not guaranteed to work except with certain specific compilers. Even different versions of the same compiler might or might not provide it.

When it is available, bits/stdc++.h just #includes every standard C++ header file. This might make sense for someone just starting out in the language, so they don't have to worry about figuring out which includes they need and which they don't. But using it slows down compile time, might in certain cases make the executable bigger than it needs to be, and (as you discovered) makes the code non-portable.

The only solution to this is to not use it, and instead, #include just the specific headers you need. You're really "supposed" to do it as you program; when you need a certain function declared in a header, you include that header, then write the function call. Some IDEs will tell you which includes you need for each function.

But if you've already gotten the code all written, you can cheat. Just delete the #include <bits/stdc++.h> line and try to compile. If the compiler complains about missing or undefined symbols, google the symbol to figure out which header it comes from, and #include it. Rinse and repeat until you get a clean compile.

How does #include bits/stdc++.h work in C++? [duplicate]

It is basically a header file that also includes every standard library and STL include file. The only purpose I can see for it would be for testing and education.

Se e.g. GCC 4.8.0 /bits/stdc++.h source.

Using it would include a lot of unnecessary stuff and increases compilation time.

Edit: As Neil says, it's an implementation for precompiled headers. If you set it up for precompilation correctly it could, in fact, speed up compilation time depending on your project. (https://gcc.gnu.org/onlinedocs/gcc/Precompiled-Headers.html)

I would, however, suggest that you take time to learn about each of the sl/stl headers and include them separately instead, and not use "super headers" except for precompilation purposes.

Which header file should I use instead of #include bits/stdc++.h [duplicate]

The solution for problems like this is to consult a suitable reference for the function in question. One well-regarded C++ reference site is cppreference.com. In this case, its reference for modf starts with:

Defined in header <cmath>

There's your answer.

Compare the above reference for the C++ version (a family of overloaded functions) defined in the C++ header <cmath> with reference for the C version defined in the C header <math.h>:

float modff( float arg, float* iptr );
double modf( double arg, double* iptr );
long double modfl( long double arg, long double* iptr );

C doesn't have function overloading, so modf in <math.h> is only the double version. <cmath>, being C++, declares all the 3 C++ overloads (float, double, long double), of which you're using the last one.

This is actually one of the reasons to stay clear of C standard library headers (<*.h>) and use C++ standard library ones (<c*>).

How can I include bits/stdc++ in Xcode

You can do it by copying stdc++.h file from here:

Then you can include the file in your c++ file like this:

 //suppose the file is in your home folder, here my username is reza
#include "/Users/reza/stdc++.h"

Related Topics

Leave a reply