I'm taking my first c++ class (and I'm in week 6.)
I used getchar(), which according to every reference I can find, is located in cstdio (or stdio or stdio.h.) Just to see what would happen I commented out
#include <cstdio>
Much to my surprise, my program still ran without errors. Other libraries I included are: algorithm, cstdlib, iostream, and string. I take it that getchar() is a part of one of these other libraries, but searching the internet, I don't see any reference that mentions any non-cstdio-like library.
Is cstdio and cstdlib the same thing?
Is there a definitive reference for what libraries hold each method/command?
Thank you for tolerating my noob questions. ~d
The answer is that one of your other header files is also including <cstdio> or it's equivalent (I would guess <iostream>).
Including <cstdio> is the right thing to do. If you don't then you might find that your code stops compiling when it's used with a different compiler.
BTW header files are not libraries, and the definitive references for what is found in which header file are the C++ and C standards documents.
Also BTW this kind of experimentation is exactly the sort of thing you should be doing as a new C++ programmer.
Related
This question already has answers here:
Why isn't the C++ standard library already pre-included in any C++ source?
(7 answers)
Closed 1 year ago.
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?
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.
This question already has answers here:
Why should I not #include <bits/stdc++.h>?
(9 answers)
Closed 4 years ago.
I have read from a codeforces blog that if we add #include <bits/stdc++.h> in a C++ program then there is no need to include any other header files. How does #include <bits/stdc++.h> work and is it ok to use it instead of including individual header files?
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.
#include <bits/stdc++.h> is an implementation file for a precompiled header.
From a software engineering perspective, it is a good idea to minimize the include. If you use <bits/stdc++.h> it actually includes a lot of files, which your program may not need, thus increase both compile-time and program size unnecessarily. [edit: as pointed out by #Swordfish in the comments that the output program size remains unaffected. But still, it's good practice to include only the libraries you actually need, unless it's some competitive competition ]
But in contests, using this file is a good idea, when you want to reduce the time wasted in doing chores; especially when your rank is time-sensitive.
It works in most online judges, programming contest environments, including ACM-ICPC (Sub-Regionals, Regionals, and World Finals) and many online judges.
The disadvantages of it are that it:
increases the compilation time.
uses an internal non-standard header file of the GNU C++ library, and so will not compile in MSVC, XCode, and many other compilers
That header file is not part of the C++ standard, is therefore non-portable, and should be avoided.
Moreover, even if there were some catch-all header in the standard, you would want to avoid it in lieu of specific headers, since the compiler has to actually read in and parse every included header (including recursively included headers) every single time that translation unit is compiled.
Unfortunately that approach is not portable C++ (so far).
All standard names are in namespace std and moreover you cannot know which names are NOT defined by including and header (in other words it's perfectly legal for an implementation to declare the name std::string directly or indirectly when using #include <vector>).
Despite this however you are required by the language to know and tell the compiler which standard header includes which part of the standard library. This is a source of portability bugs because if you forget for example #include <map> but use std::map it's possible that the program compiles anyway silently and without warnings on a specific version of a specific compiler, and you may get errors only later when porting to another compiler or version.
In my opinion there are no valid technical excuses that explain why this is necessary for the general user: the compiler binary could have all standard namespace built in and this could actually increase the performance even more than precompiled headers (e.g. using perfect hashing for lookups, removing standard headers parsing or loading/demarshalling and so on).
The use of standard headers simplifies the life of who builds compilers or standard libraries and that's all. It's not something to help users.
However this is the way the language is defined and you need to know which header defines which names so plan for some extra neurons to be burnt in pointless configurations to remember that (or try to find and IDE that automatically adds the standard headers you use and removes the ones you don't... a reasonable alternative).
this is probably a dumb question, but I couldnt find the answer I was looking for. Also, I was unsure if this was a C++ question or a VS2010 question, but the answer I'm looking for is that of a technical POV, so I ended up here.
When you start a new Console Application project in VS2010, it automatically includes stdafx.h, which in turn includes stdio.h.
The answers I found regarding stdio.h vs. iostream was more or less:
stdio.h was used in C and iostream is
used in C++
I dont know if this is right or wrong, but...
My question is: Why is stdio.h still automatically included in C++ projects? Wouldnt iostream be sufficient?
IO streams in older C++ implementations were pretty slow, leading programmers to keep using stdio.h. Apparently, that got included in stdafx.h in the past and cannot be removed from that header anymore as removing it would break existing code.
Usually projects are created using Create Empty Project, so that you can customize your includes and precompiled headers yourself.
I have no idea why does this "default" include happens, but it's a good thing to setup your project from scratch as I've described before.
Even if you're using stream output, being able to do some formatting is nice. So, if nothing else, sprintf will sometimes be used. sprintf lives in stdio.h
Possibly because visual studio targets Mort programmers, who wouldn't be able to get 'my first c++' program done without printf, and they would decide that the product didn't work right.
Before down voting plea google visual studio mort persona.
Suppose i have the following code (literally) in a C++ source file:
// #include <iostream> // superfluous, commented-out
using std::cout;
using std::endl;
int main()
{
cout << "Hello World" << endl;
return 0;
}
I can compile this code even though #include <iostream> is commented-out:
g++ -include my_cpp_std_lib_hack source.cpp
Where my_cpp_std_lib_hack is a file in some central location that includes all the files of the C++ Standard Library:
#include <ciso646>
#include <climits>
#include <clocale>
...
#include <valarray>
#include <vector>
Of course, i can use proper compilation options for all compilers i care about (that being MS Visual Studio and maybe a few others), and i also use precompiled headers.
Using such a hack gives me the following advantages:
Fast compilation (because all of the Standard Library is precompiled)
No need to add #includes when all i want is adding some debugging output
No need to remember or look up all the time where the heck std::max is declared
A feeling that the STL is magically built-in to the language
So i wonder: am i doing something very wrong here?
Will this hack break down when writing large projects?
Maybe everyone else already uses this, and no one told me?
So i wonder: am i doing something very wrong here?
Yes. Sure, your headers are precompiled, but the compiler still has to do things like name lookups on the entire included mass of stuff which slows down compilation.
Will this hack break down when writing large projects?
Yes, that's pretty much the problem. Plus, if anyone else looks at that code, they're going to be wondering where std::cout (well, assume that's a user defined type) came from. Without the #includes they're going to have no idea whatsoever.
Not to mention, now you have to link against a ton of standard library features that you may have (probably could have) avoided linking against in the first place.
If you want to use precompilation that's fine, but someone should be able to build each and every implementation file even when precompilation is disabled.
The only thing "wrong" is that you are relying upon a compiler-specific command-line flag to make the files compilable. You'd need to do something different if not using GCC. Most compilers probably do provide an equivalent feature, but it is best to write portable source code rather than to unnecessarily rely on features of your specific build environment.
Other programmers shouldn't have to puzzle over your Makefiles (or Ant files, or Eclipse workspaces, or whatever) to figure out how things are working.
This may also cause problems for users of IDE's. If the IDE doesn't know what files are being included, it may not be able to provide automatic completion, source browsing, refactoring, and other such features.
(FWIW, I do think it is a good idea to have one header file that includes all of the Standard Library headers that you are using in your project. It makes precompilation easier, makes it easier to port to a non-standard environment, and also helps deal with those issues that sometimes arise when headers are included in different orders in different source files. But that header file should be explicitly included by each source file; there should be no magic.)
Forget the compilation speed-up - a precompiled header with templates isn't really "precompiled" except for the name and the parse, as far as I've heard. I won't believe in the compilation speed up until I see it in the benchmarks. :)
As for the usefulness:
I prefer to have an IDE which handles my includes for me (this is still bad for C++, but Eclipse already adds known includes with ctrl+shift+n with... well, acceptable reliability :)).
Doing 'clandestine' includes like this would also make testing more difficult. You want to compile a smallest-possible subset of code when testing a particular component. Figuring out what that subset is would be difficult if the headers/sources aren't being honest about their dependencies, so you'd probably just drag your my_cpp_std_lib_hack into every unit test. This would increase compilation time for your test suites a lot. Established code bases often have more than three times as much test code as regular code, so this is likely to become an issue as your code base grows.
From the GCC manual:
-include file
Process file as if #include "file" appeared as the first line of the
primary source file. However, the
first directory searched for file is
the preprocessor's working directory
instead of the directory containing
the main source file. If not found
there, it is searched for in the
remainder of the #include "..." search
chain as normal.
So what you're doing is essentially equivalent to starting each file with the line
#include "my_cpp_std_lib_hack"
which is what Visual Studio does when it gathers up commonly-included files in stdafx.h. There are some benefits to that, as outlined by others, but your approach hides this include in the build process, so that nobody who looked directly at one of your source files would know of this hidden magic. Making your code opaque in this way does not seem like a good style to me, so if you're keen on all the precompiled header benefits I suggest you explicitly include your hack file.
You are doing something very wrong. You are effectively including lots of headers that may not be needed. In general, this is a very bad idea, because you are creating unnecessary dependencies, and a change in any header would require recompilation of everything. Even if you are avoiding this by using precompiled headers, you are still linking to lots of object that you may not need, making your executable much larger than it needs to be.
There is really nothing wrong with the standard way of using headers. You should include everything you are using, and no more (forward declarations are your friends). This makes code easier to follow, and helps you keep dependencies under control.
We try not to include the unused or even the rarely used stuff for example in VC++ there is
#define WIN32_LEAN_AND_MEAN //exclude rarely used stuff
and what we hate in MFC is that if u want to make a simple application u will produce large executable file with the whole library (if statically linked), so it's not a good idea what if u only want to use the cout while the other no??
another thing i don't like to pass arguments via command line coz i may leave the project for a while, and forget what are the arguments... e.g. i prefer using
#pragma (comment, "xxx.lib")
than using it in command line, it reminds me at least with what file i want
That's is my own opinion make your code stable and easy to compile in order to to rot as code rotting is a very nasty thing !!!!!
In my project I use two libraries, v8 and boost. Boost uses the .hpp extension for its headers, while v8 uses the .h extension for its headers.
In the end of day, my source code starts like that:
#include "v8.h"
#include "boost/filesystem.hpp"
...
In other question I asked about this subject, the general answer was that it is okay, but I just should be consistent between names.
This code compiles well, but, coding styles/standards - is it okay? Is there any solution for this problem (like changing all .hpp to .h automatically somehow?)
Thanks. And sorry for those stupid questions.
Don't worry about the inconsistency, it doesn't matter. Too much time is often spent obsessing about such details, and everyone is guilty of it.
Just be consistent with your own coding standards.
You'll eventually use some 3rd party library or several that use different conventions than you. There's nothing you can do about it, and often 2 of those libraries you use will be conflicting with your standards and with each other. That's not only for include extensions, but also for naming convetions like function_that_does_something vs FunctionThatDoesSomthing .It's fine.
I would definitely strongly advice against trying to change someone else's library to fit into your coding standard. I.e. for example renaming boost .hpp to .h. This is a bad idea and when you want to upgrade to newer versions of the library it will be a nightmare.
Spend your time solving the problem you're solving in a more elegant way rather than worrying about details like this.
It's fine. Coding standards don't really come into it since you have to go with what you're given. If the v8 people only provide .h and the boost people only provide .hpp then, short of copying one set of files to the other choice or providing your own wrapper header files, you have few options.
Both of those option have their downsides for what is really dubious benefits, so I wouldn't concern yourself with the fact that you have to include two different file extensions.