-3

I have installed the mingw-w64 compiler on windows. But using #include<bits/stdc++.h> in the c++ program preprocessor directive always gives an error. How can this be fixed?

MercuryVapor
  • 19
  • 8
  • 4
    By not using that? [c++ - Why should I not #include ? - Stack Overflow](https://stackoverflow.com/questions/31816095/why-should-i-not-include-bits-stdc-h) – MikeCAT Mar 28 '21 at 05:06
  • 1
    `` is not standard C++, it doesn't have to exist. – mediocrevegetable1 Mar 28 '21 at 05:07
  • *But using #include* -- Where did you get the idea to use this header? No good C++ book has this. Or are you attempting to learn C++ from one of those "online competition coding" sites? – PaulMcKenzie Mar 28 '21 at 05:08
  • @PaulMcKenzie: It is standard practice in the competitive (speed) programming world, including books about the same. Gotta save those precious seconds of typing! – John Zwinck Mar 28 '21 at 05:13
  • I can't wait till those sites go to C++ 17. Then all of time saved typing that header will, in many cases, lead to compiler errors where the competitor is scratching their head as to the issue, thus wasting time. Especially if they have any identifiers with the name of [data](https://en.cppreference.com/w/cpp/iterator/data) – PaulMcKenzie Mar 28 '21 at 05:15
  • If you do want help with using this abomination please post a [mre] with the full error message and compiler version. You're often better off using visual studio's compiler on windows rather than mingw as it can be easier to install correctly – Alan Birtles Mar 28 '21 at 07:22
  • It doesn't **work** by default because it doesn't **exist** by default. – Pete Becker Mar 28 '21 at 13:30

1 Answers1

2

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.

HiddenWindshield
  • 194
  • 7
  • Following the steps in the last paragraph will get the code to compile, but the result is not necessarily portable. Standard library headers are allowed to define other symbols that aren't required for that header, so adding one header might fix some other missing symbols. When you move to a different compiler they'll be undefined, and you'll have to add more `#include` directives. – Pete Becker Mar 28 '21 at 13:35
  • @PeteBecker Yeah, things like that are why I called it a "cheat". But I don't think it would be too bad, since by that time the OP would know how to look up standard header files. – HiddenWindshield Mar 28 '21 at 19:11