I posted a question with my code whose only #include directive was the following:
#include <bits/stdc++.h>
My teacher told me to do this, but in the comments section I was informed that I shouldn't.
Why?
Why should I not #include <bits/stdc++.h>?
How bad is including
WithOUT
WITH
Where and what is
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
#includeline. - 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:
"perhaps something newly added to a national curriculum in the current academic year" Blind leading the blind :( –
Pierian
Under certain compilation settings, however, the use of precompiled headers will reduce compilation time. Also, with standard out-of-the-box settings, I just compiled a trivial program with and without
#include <bits/stdc++.h> and the difference in the size of the EXE file was 91 KB with, 89 KB without. –
Faust Just came here through a wormhole in another question, very good. What makes this teaching habit worse is that it is usually followed by a direct
using namesapce std;. Just two lines in and virtually every nice identifier is used. Incredibly frustrating to see it being taught. –
Hiller About the quora example, it might have shifted with time. I've visited the page today and both pros and cons of <bits/stdc++.h> where listed in the specific context of online programming contests. I find their conclusion ok-ish. –
Levitical
The fourth bulletpoint is advantageous if precompiled headers are in use. See here for explanation, this code is basically the gcc version of
#include "stdafx.h" –
Fryer @M.M: Not really - just because you're precompiling headers doesn't mean you need to precompile every header –
Disarray
@EvgeniSergeev: 2KiB is a lot of code, data, symbol information, etc., when trying to determine its effect. Do you understand everything that is being added? For your compiler? The current release? All releases in between? All future releases? If you need to decide between convenience and correctness, there is only a single valid option. –
Tyika
Hopefully not a curriculum but rather just a cargo-cult spread across 'contest' websites or something... although sadly nothing would surprise me either way. –
Confinement
An heaven forbid you are using the pre-compiled headers option with it. Take a look at the size of the .pch file generated by VS under one of your repos/Debug (or Release) directories, They can be tens to hundreds of megabyes. –
Celiotomy
Devil's advocate. While all this is certainly true for professional code, you might make an argument that the include is acceptable for people using C++ to learn programming for the first time -- it lets them concentrate on their own code, and makes the teacher's grading job easier. The disadvantages (except your second bullet point to some extent) go away in a pedagogical situation. Frankly, the
using namespace std makes me cringe more than the include. –
Elmer Lets have a new take on this please. All the points mentioned above are all very valid...however, shouldn't we fix all of them so we "can" actually just have 1 include line? Shouldn't our compiler do all the work to find the right header and include it if we wish? –
Cochabamba
Updated link C++ Standard - 16.5.1.2 Headers –
Celiotomy
@SujayPhadke> yes, the compiler should guess what the developer has in mind. Because of course there is only one function in the world named
distance, the word vector certainly has no meaning outside of containers, … You're right a tool should help with this. But that's not a job for the compiler, that's the job of the IDE (and some of them indeed do it). –
Sarmiento @Sarmiento there's no need of sarcasm. There is no need to guess. By default the compiler just needs to have defaults configured. If you decide to change it for your purpose you can do it. By why should the 1000s of people have to keep writing this for their default use when 1 person changes the default behavior? –
Cochabamba
@SujayPhadke finding things is simply not the job of the compiler. If something is not defined, it's not defined. Simple, clean, consistent, reliable, reproducible. I agree, having such things automated is great, and in fact many IDEs have this feature (bonus: it works for all libraries, not just the std one). There is no reason to introduce inconsistencies in the language and break design rules in the toolchain. –
Sarmiento
Actually, GCC now produces pretty good warnings suggesting missing includes (although it does choose fairly arbitrary spots to recommend them - breaking the sorting order in my programs!) –
Semirigid
Every single standard header must be parsed and compiled along with your source code, which is slow. How slow? I did a quick "hello world" test and posted the results here. –
Sherasherar Why? Because it is used as if it were supposed to be a C++ standard header, but no standard mentions it. So your code is non-portable by construction. You won't find any documentation for it on cppreference. So it might as well not exist. It's a figment of someone's imagination :)
I have discovered - to my horror and disbelief - that there is a well-known tutorial site where every C++ example seems to include this header. The world is mad. That's the proof.
To anyone writing such "tutorials"
Please stop using this header. Forget about it. Don't propagate this insanity. If you're unwilling to understand why doing this is Wrong, take my word for it. I'm not OK being treated as a figure of authority on anything at all, and I'm probably full of it half the time, but I'll make an exception in this one case only. I claim that I know what I'm talking about here. Take me on my word. I implore you.
P.S. I can well imagine the abominable "teaching standard" where this wicked idea might have taken place, and the circumstances that led to it. Just because there seemed to be a practical need for it doesn't make it acceptable - not even in retrospect.
P.P.S. No, there was no practical need for it. There aren't that many C++ standard headers, and they are well documented. If you teach, you're doing your students a disservice by adding such "magic". Producing programmers with a magical mindset is the last thing we want. If you need to offer students a subset of C++ to make their life easier, just produce a handout with the short list of headers applicable to the course you teach, and with concise documentation for the library constructs you expect the students to use.
That well known site is that the one where every C++ example looks like a C program? –
Meras
He is talking about GeeksForGeeks –
Eudemonia
It will be fun when that header is included, along with
using namespace std;. Then simple things like a user-defined gcd, swap or variable named data will act strangely or not compile at all, leaving the coder scratching their head as to what the issue could be. –
Exocentric I'm talking about the prototypical "well known site". There are, unfortunately, very many of them. And they all invariably look like blind leading the blind :( –
Pierian
There's a Stack Exchange site called Programming Puzzles & Code Golf. The programming puzzles on that site fit this definition of puzzle:
a toy, problem, or other contrivance designed to amuse by presenting difficulties to be solved by ingenuity or patient effort.
They are designed to amuse, and not in the way that a working programmer might be amused by a real-world problem encountered in their daily work.
Code Golf is "a type of recreational computer programming competition in which participants strive to achieve the shortest possible source code that implements a certain algorithm." In the answers on the PP&CG site, you'll see people specify the number of bytes in their answers. When they find a way to shave off a few bytes, they'll strike out the original number and record the new one.
As you might expect, code golfing rewards extreme programming language abuse. One-letter variable names. No whitespace. Creative use of library functions. Undocumented features. Nonstandard programming practices. Appalling hacks.
If a programmer submitted a pull request at work containing golf-style code, it would be rejected. Their co-workers would laugh at them. Their manager would drop by their desk for a chat. Even so, programmers amuse themselves by submitting answers to PP&CG.
What does this have to do with stdc++.h? As others have pointed out, using it is lazy. It's non-portable, so you don't know if it will work on your compiler or the next version of your compiler. It fosters bad habits. It's non-standard, so your program's behavior may differ from what you expect. It may increase compile time and executable size.
These are all valid and correct objections. So why would anyone use this monstrosity?
It turns out that some people like programming puzzles without the code golf. They get together and compete at events like ACM-ICPC, Google Code Jam, and Facebook Hacker Cup, or on sites like Topcoder and Codeforces. Their rank is based on program correctness, execution speed, and how fast they submit a solution. To maximize execution speed, many participants use C++. To maximize coding speed, some of them use stdc++.h.
Is this is a good idea? Let's check the list of disadvantages. Portability? It doesn't matter since these coding events use a specific compiler version that contestants know in advance. Standards compliance? Not relevant for a block of code whose useful life is less than one hour. Compile time and executable size? These aren't part of the contest's scoring rubric.
So we're left with bad habits. This is a valid objection. By using this header file, contestants are avoiding the chance to learn which standard header file defines the functionality they're using in their program. When they're writing real-world code (and not using stdc++.h) they'll have to spend time looking up this information, which means they'll be less productive. That's the downside of practicing with stdc++.h.
This raises the question of why it's worth taking part in competitive programming at all if it encourages bad habits like using stdc++.h and violating other coding standards. One answer is that people do it for the same reason they post programs on PP&CG: some programmers find it enjoyable to use their coding skills in a game-like context.
So the question of whether to use stdc++.h comes down to whether the coding speed benefits in a programming contest outweigh the bad habits that one might develop by using it.
This question asks: "Why should I not #include <bits/stdc++.h>?" I realize that it was asked and answered to make a point, and the accepted answer is intended to be the One True Answer to this question. But the question isn't "Why should I not #include <bits/stdc++.h> in production code?" Therefore, I think it's reasonable to consider other scenarios where the answer may be different.
I've upvoted already, but it might be worth pointing out that "for fun" is a good reason to take part in competitive programming. On the other hand "to impress a potential employers" is not - it will actively harm your case with me. –
Diadiabase
@MartinBonner I know some hiring managers see competitive programming experience as a red flag. But as long as top software companies use CP-style problems in their interviews and run programming contests to find new recruits, CP will continue to be popular among aspiring developers. –
Supporter
@Supporter I am not a manager (thank $DEITY), but I sometimes have influence on hireing desitions. And I definitely see any reference to "competitive programming" as a huge red flag - not an advantage. –
Mastoiditis
@JesperJuhl If technical interviewers at your company use algorithmic puzzles in their interviews (as many do), that gives candidates with competitive programming experience an advantage. Maybe the rational choice for candidates is to participate in CP but avoid mentioning it on their resume/CV. –
Supporter
While it's true that this header can find use in some competitive programming, it's not quite where it came from. It came from a classroom. And whoever taught in that classroom had enough influence to pollute - via cascade that followed - tens if not hundreds of thousands of students (by educating the teachers and peers who then, unwittingly, had been spreading that disease). And now those students are also writing tutorials in a go-to-place for tutorials. I just want to cry in a corner. Competitive programming sites should just have a regex to reject any nonstandard header. –
Pierian
@Supporter Why is competitive programming a red flag?? It is better than someone who has no programming experience.... –
Boyfriend
@YunfeiChen Some people believe it encourages bad habits (like using
#include <bits/stdc++.h> or writing unreadable code) that the candidate would need to un-learn on the job. Having zero programming experience is also a red flag, but that's why we have interviews. –
Supporter @Supporter When I say zero coding experience I mean people who never worked in a programming job before, most university graduates have not worked in coding before. So they have nothing except for a degree certificate..... Hmm also why does coding competitions not care about effieciency I thought that was the whole point of the competition?? –
Boyfriend
@YunfeiChen Coding competition scores are based on correctness, runtime speed, and coding speed (submission time). Using
bits/stdc++.h only affects compilation speed and executable size, so it doesn't affect contest results. –
Supporter @YunfeiChen> they also do not care (or even discourage) a lot of things that are very important for professional code. Readability, reusability, testability (of pieces), the ability to build upon existing wheels rather than reinventing it, … –
Sarmiento
@Sarmiento well for reability, there's a reason why it is called coding golf, and all three of those factors are very subjective, this is no objective metric to measuring those so it should not be include as part of the criteria.... –
Boyfriend
@MartinBonnersupportsMonica The idea that a mention of CP results on a cv - demonstrating related problem solving skills and active enthusiasm - is a negative is simply madness. Coding style and good use of architecture, teamwork, etc. are all essential, but an applicant shouldn't have to tick all of those boxes at each dot point of the cv. –
Glaab
From N4606, Working Draft, Standard for Programming Language C++ :
17.6.1.2 Headers [headers]
Each element of the C++ standard library is declared or defined (as appropriate) in a header.
The C++ standard library provides 61 C++ library headers, as shown in Table 14.
Table 14 — C++ library headers
<algorithm> <future> <numeric> <strstream> <any> <initializer_list> <optional> <system_error> <array> <iomanip> <ostream> <thread> <atomic> <ios> <queue> <tuple> <bitset> <iosfwd> <random> <type_traits> <chrono> <iostream> <ratio> <typeindex> <codecvt> <istream> <regex> <typeinfo> <complex> <iterator> <scoped_allocator> <unordered_map> <condition_variable> <limits> <set> <unordered_set> <deque> <list> <shared_mutex> <utility> <exception> <locale> <sstream> <valarray> <execution> <map> <stack> <variant> <filesystem> <memory> <stdexcept> <vector> <forward_list> <memory_resorce> <streambuf> <fstream> <mutex> <string> <functional> <new> <string_view>
There's no <bits/stdc++.h> there. This is not surprising, since <bits/...> headers are implementation detail, and usually carry a warning:
- This is an internal header file, included by other library headers.
- Do not attempt to use it directly.
<bits/stdc++.h> also carries a warning:
- This is an implementation file for a precompiled header.
I at least like seeing a list of all headers one can include, and which version of C++ they pertain to, by looking at this header file. It is really useful in that regard.
How bad is including <bits/stdc++.h>, really?
I wanted to see some real data--some numbers to compare compile time and binary executable size. So, here is a quick "hello world" comparison test.
Note: to learn where is the <bits/stdc++.h> header file, and what is in it, jump straight down to the section at the bottom titled "Where and what is <bits/stdc++.h>?".
Summary:
Including the <bits/stdc++.h> "include all headers" header is easy, but comparatively slow to compile.
Including the <bits/stdc++.h> header file works fine with the GCC/g++ compiler (and presumably the LLVM Clang compiler too, since they aim to be GCC-compatible), and
- makes no difference on binary executable size, but
- it takes up to 4x longer to compile!
My testing
Here is a sample C++ program:
// We will test including this header vs NOT including this header
#include <bits/stdc++.h>
#include <iostream> // For `std::cin`, `std::cout`, `std::endl`, etc.
int main()
{
printf("Hello ");
std::cout << "world!\n\n";
return 0;
}
Here are some build and run commands:
# make a bin directory
mkdir -p bin
# compile, timing how long it takes
time g++ -Wall -Wextra -Werror -O3 -std=c++17 include_bits_stdc++.cpp -o bin/a
# check binary executable size
size bin/a
# run
bin/a
WithOUT #include <bits/stdc++.h> at the top
If I run the "compile" command above with the code as-is, here are 10 compile times I see:
real 0m0.362s
real 0m0.372s
real 0m0.502s
real 0m0.383s
real 0m0.367s
real 0m0.283s
real 0m0.294s
real 0m0.281s
real 0m0.292s
real 0m0.276s
Average compile time: (0.362 + 0.372 + 0.502 + 0.383 + 0.367 + 0.283 + 0.294 + 0.281 + 0.292 + 0.276)/10 = 0.3412 seconds.
size bin/a shows:
text data bss dec hex filename
2142 656 280 3078 c06 bin/a
WITH #include <bits/stdc++.h> at the top
10 compile times:
real 0m1.398s
real 0m1.006s
real 0m0.952s
real 0m1.331s
real 0m1.549s
real 0m1.454s
real 0m1.417s
real 0m1.541s
real 0m1.546s
real 0m1.558s
Average compile time: (1.398 + 1.006 + 0.952 + 1.331 + 1.549 + 1.454 + 1.417 + 1.541 + 1.546 + 1.558)/10 = 1.3752 seconds.
size bin/a shows:
text data bss dec hex filename
2142 656 280 3078 c06 bin/a
Conclusions
So, including the header works fine with the gcc/g++ compiler, and makes no difference on binary executable size, but it takes 1.3752 sec / 0.3412 sec = 4x longer to compile!
Where and what is <bits/stdc++.h>?
Summary
The <bits/stdc++.h> header file is included as part of the gcc/g++ compiler.
You can find it on your Linux (ex: Ubuntu) system with this command:
find /usr/include -ipath "*bits/stdc++.h*"
The above command is almost instant. But, if it doesn't find anything, you can search your entire file system like this, which will take much longer:
# Option 1: showing read permissions errors
find / -ipath "*bits/stdc++.h*"
# Option 2 (preferred): hiding read permissions (stderr, file descriptor 2)
# errors
find / -ipath "*bits/stdc++.h*" 2>/dev/null
If on Linux Ubuntu, <bits/stdc++.h> will be located on your local system at:
- On Ubuntu 18.04, with GCC 8:
/usr/include/x86_64-linux-gnu/c++/8/bits/stdc++.h - On Ubuntu 22.04, with GCC 11:
/usr/include/x86_64-linux-gnu/c++/11/bits/stdc++.h
You can view the file in the gcc source code directly online here: gcc/libstdc++-v3/include/precompiled/stdc++.h
I at least like seeing a list of all headers one can include, and which version of C++ they pertain to, by looking at that header file. It is really useful in that regard.
Details
If you open the code above in an IDE with a great indexer, such as Eclipse (which has the best indexer I've ever found; it indexes far better than MS VSCode), and Ctrl + Click on the #include <bits/stdc++.h> line, it will jump straight to that header file on your system! On Linux Ubuntu, it jumps straight to this path and opens this file: /usr/include/x86_64-linux-gnu/c++/8/bits/stdc++.h.
You can view the latest version of this file in the gcc source code directly, here: gcc/libstdc++-v3/include/precompiled/stdc++.h. It is simply a header file which includes all other header files! This is really useful and insightful to just look at all header files in one place to get a feel for what they are and what they include! And again, in Eclipse, you can easily Ctrl + Click on each included header file to jump right to its source code implementation.
Here is the full, latest <bits/stdc++.h> header file included with the gcc compiler. You can always copy and paste this content and create this file yourself if you want to include it in your own personal project or use it with another compiler.
gcc/libstdc++-v3/include/precompiled/stdc++.h:
// C++ includes used for precompiling -*- C++ -*-
// Copyright (C) 2003-2024 Free Software Foundation, Inc.
//
// This file is part of the GNU ISO C++ Library. This library is free
// software; you can redistribute it and/or modify it under the
// terms of the GNU General Public License as published by the
// Free Software Foundation; either version 3, or (at your option)
// any later version.
// This library is distributed in the hope that it will be useful,
// but WITHOUT ANY WARRANTY; without even the implied warranty of
// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
// GNU General Public License for more details.
// Under Section 7 of GPL version 3, you are granted additional
// permissions described in the GCC Runtime Library Exception, version
// 3.1, as published by the Free Software Foundation.
// You should have received a copy of the GNU General Public License and
// a copy of the GCC Runtime Library Exception along with this program;
// see the files COPYING3 and COPYING.RUNTIME respectively. If not, see
// <http://www.gnu.org/licenses/>.
/** @file stdc++.h
* This is an implementation file for a precompiled header.
*/
// 17.4.1.2 Headers
// C
#ifndef _GLIBCXX_NO_ASSERT
#include <cassert>
#endif
#include <cctype>
#include <cfloat>
#include <ciso646>
#include <climits>
#include <csetjmp>
#include <cstdarg>
#include <cstddef>
#include <cstdlib>
#if __cplusplus >= 201103L
#include <cstdint>
#endif
// C++
// #include <bitset>
// #include <complex>
#include <algorithm>
#include <bitset>
#include <functional>
#include <iterator>
#include <limits>
#include <memory>
#include <new>
#include <numeric>
#include <typeinfo>
#include <utility>
#if __cplusplus >= 201103L
#include <array>
#include <atomic>
#include <initializer_list>
#include <ratio>
#include <scoped_allocator>
#include <tuple>
#include <typeindex>
#include <type_traits>
#endif
#if __cplusplus >= 201402L
#endif
#if __cplusplus >= 201703L
#include <any>
// #include <execution>
#include <optional>
#include <variant>
#include <string_view>
#endif
#if __cplusplus >= 202002L
#include <bit>
#include <compare>
#include <concepts>
#include <numbers>
#include <ranges>
#include <span>
#include <source_location>
#include <version>
#endif
#if __cplusplus > 202002L
#include <expected>
#include <stdatomic.h>
#if __cpp_impl_coroutine
# include <coroutine>
#endif
#endif
#if _GLIBCXX_HOSTED
// C
#ifndef _GLIBCXX_NO_ASSERT
#include <cassert>
#endif
#include <cctype>
#include <cerrno>
#include <cfloat>
#include <ciso646>
#include <climits>
#include <clocale>
#include <cmath>
#include <csetjmp>
#include <csignal>
#include <cstdarg>
#include <cstddef>
#include <cstdio>
#include <cstdlib>
#include <cstring>
#include <ctime>
#include <cwchar>
#include <cwctype>
#if __cplusplus >= 201103L
#include <ccomplex>
#include <cfenv>
#include <cinttypes>
#include <cstdalign>
#include <cstdbool>
#include <cstdint>
#include <ctgmath>
#include <cuchar>
#endif
// C++
#include <complex>
#include <deque>
#include <exception>
#include <fstream>
#include <functional>
#include <iomanip>
#include <ios>
#include <iosfwd>
#include <iostream>
#include <istream>
#include <iterator>
#include <limits>
#include <list>
#include <locale>
#include <map>
#include <memory>
#include <new>
#include <numeric>
#include <ostream>
#include <queue>
#include <set>
#include <sstream>
#include <stack>
#include <stdexcept>
#include <streambuf>
#include <string>
#include <typeinfo>
#include <utility>
#include <valarray>
#include <vector>
#if __cplusplus >= 201103L
#include <array>
#include <atomic>
#include <chrono>
#include <codecvt>
#include <condition_variable>
#include <forward_list>
#include <future>
#include <initializer_list>
#include <mutex>
#include <random>
#include <ratio>
#include <regex>
#include <scoped_allocator>
#include <system_error>
#include <thread>
#include <tuple>
#include <typeindex>
#include <type_traits>
#include <unordered_map>
#include <unordered_set>
#endif
#if __cplusplus >= 201402L
#include <shared_mutex>
#endif
#if __cplusplus >= 201703L
#include <any>
#include <charconv>
// #include <execution>
#include <filesystem>
#include <optional>
#include <memory_resource>
#include <variant>
#endif
#if __cplusplus >= 202002L
#include <barrier>
#include <bit>
#include <compare>
#include <concepts>
#include <format>
#include <latch>
#include <numbers>
#include <ranges>
#include <span>
#include <stop_token>
#include <semaphore>
#include <source_location>
#include <syncstream>
#include <version>
#endif
#if __cplusplus > 202002L
#include <expected>
#include <generator>
#include <print>
#include <spanstream>
#if __has_include(<stacktrace>)
# include <stacktrace>
#endif
#include <stdatomic.h>
#include <stdfloat>
#endif
#if __cplusplus > 202302L
#include <text_encoding>
#endif
#endif // HOSTED
See also
- https://www.geeksforgeeks.org/bitsstdc-h-c/
- this article plagiarizes from Stack Overflow, though; see my comment here: How does #include <bits/stdc++.h> work in C++?
- [my Questions & Answers] learn what
text,data,bss, anddecmean in thesizeoutput:
Because the file is GPL licensed, you should be careful about copying it for your own project. It might open you to legal liabilities that could be very unfortunate for you and your employer. –
Mean
"If on Linux, it will be located on your local system at ... " - not necessarily, it depends on where you got your gcc, how it was packaged, etc. On my system it's at a completely different path from the one you show. –
Sotelo
@JonathanWakely, answer updated to specify Ubuntu. Where is it located on your system, and which version of Linux do you have? –
Sherasherar
I have 141 different copies of it. I don't think giving you the paths will be useful. I don't think stating the path in your answer is really useful either (e.g. you forgot to say Ubuntu amd64). The precise location isn't important, gcc knows where to find it. –
Sotelo
The reason we do not use:
#include <bits/stdc++.h>
is because of effiency. Let me make an analogy: For those of you who know Java: If you asked your instructor if the following was a good idea, unless they are a bad instructor they would say no:
import java.*.*
The #include... thing does the same thing basically... That's not the only reason not to use it, but it is one of the major reasons not to use it. For a real life analogy: Imagine you had a library and you wanted to borrow a couple of books from the library, would you relocate the entire library next to your house?? It would be expensive and ineffiecient. If you only need 5 books, well then only take out 5... Not the whole library.....
#include <bits/stdc++.h>
Looks convienent to the program look I only need to type one include statement and it works, same thing with moving a whole library, look I only need to move one whole library instead of 5 books, one by one. Looks convienent to you that is, for the person who actually has to do the moving?? Not so much, and guess what in C++ the person doing the moving will be your computer... The computer will not enjoy moving the entire library for every source file you write :).....
This is almost certainly the underlying reason why nobody has seriously proposed a Standard "include everything" header. So there's a plausible claim to call it "the reason" we don't use it. –
Semirigid
But computers are very fast , these things doesn't effect that much , it will done in like milliseconds, MISERY will waste human time instead. –
Microanalysis
@Microanalysis you have never worked on a large scale project have you? It adds up very quickly when you have many files. –
Boyfriend
What if I have not a large scale project, Can I use bits/stdc++.h . –
Microanalysis
@Microanalysis Thats up to you, but just note it is non standard and not portable, meaning you will run into compatiability issues later on. –
Boyfriend
@Microanalysis My experience is including bits/stdc++.h without having precompiled headers set up correctly increases the amount to time spent compiling by close to an order of magnitude (better disk IO and no antivirus will help a lot here). So if your build time for a single small file increase from half a second to five seconds, you'll probably shoot past the amount of time you saved typing in one header instead of four or five headers in about 3 compiles. In other words if your program works right the first or second time, you win. After that you start to lose. –
Pozzy
@Pozzy that is assuming the IDE you use doesnt auto import headers for you, which is very common for IDEs these days. –
Boyfriend
Yes IDE our angel , nothing to worry. –
Microanalysis
The comparison is very wrong, as is the answer: In Java
import java.*.* is valid and well-defined, in C++ #include <bits/stdc++.h> IS NOT as that is, as that header even says, and internal header and an implementation-detail of GCC. It can change at any time, it could include macros that make your code format your drives, it could just vanish with the next release. –
Kimble If your teacher is an ICPC coach then he/she is right, but if your teacher is a software engineer probably he/she is not.
There are pros and cons of both:
pros:
- Using it saves coding time
- You don't need to take the pain of remembering which header contains what
- If you have a source code limit(which ICPC style contests generally have) and you want to squeeze in as many lines as possible then it might come handy.
cons:
- But it increases compile time.
- Since it includes lots of namespaces, you may accidentally get into issues which might be hard to debug.
As explained in the top answer to the Quora question mentioned by @Lightness Races in Orbit, there's nothing wrong with including bits/stdc++.h in the context of a programming competition. The disadvantages around portability, compile time, and standardization are not relevant there. The same would be true in a college programming class if the example code uses that include.
If you're writing production code, then don't use it. It shouldn't be a big deal to switch back and forth depending on the purpose of the code you're currently writing.
Meh, if a programming competition is judging broken, non-standard code then I don't really get the purpose of it. "Who can make the most broken code the fastest" yay! Well done, I guess.... –
Disarray
A one-line convenience doesn't make the whole program broken, any more than, for example, using short variable names does. I think you may be judging all of competitive programming based on a few people who show up on SO with off-topic questions about it. –
Supporter
Using short variable names and using
#include <bits/stdc++.h> are completely different things! –
Disarray They're both examples of programming practices that make sense when submitting a contest program that has a lifetime of an hour or so, but not when writing code that needs to be maintained for years. –
Supporter
"The same would be true in a college programming class if the example code used that include." Heck no. The people you teach to don't know any better. They don't know what's appropriate and what's not: anything the professor writes is gospel taken on faith. Please, don't suggest any educators that this idiocy is warranted. –
Pierian
"Broken", "non-standard", "non-portable", "idiocy": all of these are scare words that don't belong to this discussion. Code using the include in question is no more non-portable than code that includes a third-party library. Being one of those things that can be ported trivially if and when the need arises, it is absolutely harmless and I consider it a pointlessly inflammatory gesture to be referring to hundreds of thousands of programs that use it as "broken". This discussion is a good example of what happens when standards pedantry and portability zealotry get in the way of convenience. –
Faust
@EvgeniSergeev: There is a big difference between installing a third-party library to satisfy a dependency, and having to hack the heck out of someone else's code to make it work (thus necessarily creating a fork in the process). You accuse us of doing nothing but employing "scare words", but I challenge you to explain what you're doing here saying we're "pedants" and "zealots" with no goals further to being those things. Physician.... heal thyself. –
Disarray
@EvgeniSergeev Last I checked, any given compiler's internal header files explicitly can't be ported to another compiler trivially, because they're liable to rely on compiler-specific keywords and extensions that other compilers won't necessarily support. Therefore, to port an internal header, you have to go through the entire thing, and rewrite anything that uses compiler-specific code, then rewrite all of the target compiler's files to use the new header instead of their own compiler-specific internal headers. Try porting Visual Studio's
<xlocale> to GCC, you'll see what I mean. –
Sputter <xlocale> will do nothing unless you rewrite GCC's <locale> to use it. If you do, you'll get errors about not having files like <xlocinfo> or <xdebug>, and about not having MS's 20,000 or so internal macros defined. ...Not exactly the most trivial of things. ...Meanwhile, a third-party library can just be used as-is, perhaps with minor configuration necessary by defining one or two macros. There is a large difference between the two. –
Sputter "The same would be true in a college programming class" - Certainly not. After all, it is college students that eventually write production code. What's worse, if you teach enough students the wrong thing, they will eventually wind up in teams, where no one is left that knows what's right and wrong. Convenience is nice. Convenience with as high a cost and as little a benefit is highly questionable. –
Tyika
@Tyika Production code is different from college code, example code in documentation, and competitive programming code. Coding standards should be optimized for the goals of the code, not strictly applied without regard for context. A team working on a web application that deploys every day is going to use different rules than one writing code running on a robot that gets launched into space. –
Supporter
You haven't made a convincing point, why college students shouldn't be taught the Right Way, from the beginning. Plus, portability concerns are very real, even with college programming assignments. I remember always using Visual Studio for authoring and debugging, but had to pass in code that would compile with GCC. This is all the more true today, with a plethora of compilers and IDE's readily available. –
Tyika
@Tyika College students should be taught to use the Right Way for the problem context. If they're doing competitive programming (which is the context of this question) then
#include <bits/stdc++.h> is the Right Way. That's just how it's done in that community. In other contexts, they can be taught production programming standards. –
Supporter I fail to see the context you keep repeating. Nothing in the question even remotely indicates some sort of competition. And even then, I don't see the relative merit over doing it the Right Way. –
Tyika
@Tyika
bits/stdc++.h originates in the competitive programming community. See the Quora question linked in the top answer above. Competitive programming solutions are written once, and then thrown away once the contest is over. So the disadvantages cited above (portability, slow compilation, only works on one compiler, etc.) are not relevant. –
Supporter I've upvoted this answer. I think it's a perfectly legitimate use-case to use 1 include to include them all when in a massive rush to complete a coding exercise and you don't have time to meticulously trace down the 10 specific includes you otherwise need. Production code use? No, but the answer states that too. +1. –
Sherasherar
Here is a highly-upvoted answer which supports this answer: How does #include <bits/stdc++.h> work in C++. And here is the most-upvoted answer there, which also supports this answer. –
Sherasherar
@LightnessRacesinOrbit "Meh, if a programming competition is judging broken, non-standard code then I don't really get the purpose of it.". These competitions are merely for judging designing an algorithm and implementing them as quick as possible. It would be a foolish decision to not use compiler extensions (such as variable array sizes) and other compiler-specific stuff (like this) if they are faster to code merely just because it's not the standard. Nobody ever said you should do the same thing in a non-competitive setting. –
Mantelpiece
The biggest problem for me is that including this header file won’t compile. So if it’s there, I’ll have to remove it, try to compile, and add the standard header files that are needed.
My first thought would be that bits/stdc++.h really seems to be a internal implementation detail header of GNU libstdc++. Thus, it should never be directly included from c++ program sources.
This is based on a consistent observation that on GNU/linux, subdirectories named bits most likely seem to be the conventional place where the GNU libc and GNU libstdc++ put their internal private headers. Such headers contain implementation details, and their existence are not guaranteed to be stable across patch compiler versions.
Taking a look at the glibc headers directly located under /usr/include/x86_64-linux-gnu/bits/, almost all of them prohibit direct inclusion by use of #error directives.
Similarly, for the GNU libstdc++ headers; those are located under /usr/include/c++/12/bits/ or /usr/include/x86_64-linux-gnu/c++/12/bits/ (almost) all of them have documentation comments at the beginning such as:
/** @file bits/atomic_wait.h
* This is an internal header file, included by other library headers.
* Do not attempt to use it directly. @headername{atomic}
*/
Grepping under some bits subdirectories seem to indicate this directory really is reserved for the implementation. Assuming version of gcc is 12, on a x86_64 arch, try the following commands:
$ grep "Never include" /usr/include/x86_64-linux-gnu/bits/*.h
$ grep "Do not attempt to use it directly" /usr/include/c++/12/bits/{*.h,*.tcc}
$ grep "Do not attempt to use it directly" /usr/include/x86_64-linux-gnu/c++/12/bits/*.h
Now, the header bits/stdc++.h is somewhat special, as it is used to generate a precompiled header for the hole library. As such, it is more of a .cpp implementation file rather than a proper .h header file -- .cpp source are not meant for inclusion.
Regarding the use of precompiled headers, good C++ practice is to make C++ programs/libraries that do not depend on whether a precompiled header is used to build the executable/library; simply adhere to the "Include what you use" principle. Use of a precompiled header should be specified by external means, from the build system or the command line, but not from #include directives in source files.
From the viewpoint of the GNU libstdc++'s API, the file bits/stdc++.h is not exposed as being part of it, and is only mentioned in the context of creating a binary pch, and only gives instructions on how to use this precompiled header from the command line invocation of g++, namely it does not instruct to directly include the file anywhere in source code; it is not exposed as being part of the public API of libstdc++'s header set -- in other words, it is not includeable (in essence).
© 2022 - 2024 — McMap. All rights reserved.
using namespace std;out there somewhere. – Pozzybits/stdc++.h.gchinstead, the precompiled version. It exists because it has to exist so that the precompiled version of it can be generated. – Sotelo<bits/stdc++.h>– Sverige