When including a header file in C++, what's the difference between...
including the .h part versus not including .h part when wrapping it in <> signs?
#include <iostream> vs. #include <iostream.h>
wrapping the header name in double quotes versus wrapping it in < > signs?
#include <iostream.h> vs. #include "iostream.h"
In short:
iostream.h is deprecated—it is the original Stroustrup version. iostream is the version from the standards committee. Generally, compilers point them both to the same thing, but some older compilers won't have the older one. In some odd cases, they will both exist and be different (to support legacy code) and you then must be specific.
"" versus <> simply means check the local directories for the header before going to the library (in most compilers).
Here is a decent link article.
To summarize, the reason given:
The version of the iostream library that the Standards Committee
produced was quite a bit different from the CFront implementation.
{snip}
To ease transition, the C++ Standards Committee declared that code
including the standard C++ headers would use include directives that
lack an extension. This allowed compiler vendors to ship the old style
C++ library headers with the .h extension and the new style headers
without.
An advantage of not using the .h version:
There are several reasons why new code should be written using the
extensionless version of the header files instead of the .h forms. The
first is the unpredictability of such code when compiled on modern
compilers. As previously mentioned, the result of using the .h headers
is implementation specific. And as time goes by, the chance that a
given compiler will have the old style library available decreases.
As the person on the standards committee (X3J16) who proposed leaving off the .h, my original intent was to settle the debate over .h, .H, .hpp, .hxx, or .h++ file extensions; or a desire by some that there be no implication in the standard that this was the name of a file on disk in order to allow an IDE to pull pre-compiled header information out of somewhere internal, like a resource file or even the guts of the compiler.
While Unix considered the filename to be a single string and did not actually recognize the concept of an extension, DEC operating systems had a tradition of separating the name from the extension, and supplying the "default extension" if it was omitted in particular contexts. That's where I got the idea from of leaving it up to the implementation to use whatever extension the implementation wanted to use, and it allowed the implementation to not even have this a file on disk. (I was DEC's representative on the committee at the time.)
Differentiating between the standard and the pre-standard headers was an added benefit.
The standard way (and the only one guaranteed to work) is <iostream>. On gcc, <iostream.h> (which might need to be included as <backward/iostream.h>) pulls the relevant declarations to the global namespace (so you do not need the std:: namespace prefix).
"iostream.h" would try first from the directory with your source code, since "" is meant for headers from your project. <> should always be used for system headers, and "" for your own headers.
Typically <> is used for system or standard library files whereas "" is used for project files. I would not be surprised if your compiler searches locally and when it cannot find it it defaults to the standard library version.
As for the .h, I don't think that it actually matters if you use C.
In C++, I remember vaguely that there was a newer version and an older version and that without the h it was supposed to be the new version, but I'm not even sure the old version still exists.
These are really two different questions.
The difference between the .h and
extensionless headers with the same
name is historical. The ones with
the .h extension are from the
original C++ standard which did not
have some modern features such as
namespaces and templates. It was
simpler for the new standard to put
that same functionality in new
header files to be able to use these
new features and keep the old (.h)
files for backward compatibility of
legacy code.
The difference between the #include
<...> and #include "..." format is
the order in which the compiler
looks for files. This is generally
implementation dependent, but the
idea is that the <> format looks in
system include directories first,
while "" looks in the same directory
as the source file that #included it
first.
The simple answer to the first answer is that iostream.h doesn't exist, at least in the GCC implementation. If you're on a Unix-like system, type
% locate iostream.h
/usr/include/c++/3.4.3/backward/iostream.h
and
% locate iostream
/usr/include/c++/3.4.3/iostream
/usr/include/c++/3.4.3/backward/iostream.h
As Zee's article says, iostream.h is for backward compatibility.
Regarding the names of the standard C++ header files, in the early days (the first two years) of X3J16, we faced an argument over what the extension should be on the standard C++ header files.
In use at the time by various vendors (and influenced by constraints that some operating systems placed on file names) I believe there were .h, .H, .h++, .hpp, .HXX, and possibly others. In a library group meeting I suggested that we leave the extension off, and leave it up to the implementation to supply a default file extension of its choosing if there was none in the include line, or use the name as a key in a database of pre-compiled header files if desired.
(While Unix-like systems treat the filename and 'extension' as a single string, I was representing DEC on the committee, and many DEC operating systems stored the extension in the directory as a separate field from the name. So DEC operating systems had a strong tradition of applying a default extension based on what program was accessing the file for what purpose. Telling an assembler 'X,Y=Z' might result in reading input file Z.MAC (macro) and writing output files X.OBJ and Y.LST.)
Anyway, it avoided a long, no-win debate, so the group went along with it, and Andy Koenig presented the group's conclusions on this (among others) to the entire committee which accepted it. I find it somewhat amusing that implementations missed the whole point that they could apply a default extension of their choice (which I would think would be useful to editors and other tools) and just left the extension off of the file name.
The compiler is free to add a missing ".h" (or whatever it wants) to a standard header name in order to determine the name of the actual disk file to read, if the compiler indeed gets standard headers from actual disk files. So the user program can say "#include <iostream>" and the compiler could be smart enough to open up a file named "iostream.h" (or whatever it wants) in some directory it knows about (or is told about via command line switches). The standard does not require the standard header to be in an actual disk file of text with any particular name.
Related
I have just started learning cpp and one thing that is really confusing me is #include <iostream> or #include<vector>. Some people say that we are including iostream library and some say that #include is used for including header files. But iostream and vector don't have .h extension so how can they be header files? Also, can we include a library by using #include ? This also makes me think about difference between iostream.h and iostream . Which one is header file? Which one is library? If we are only including header files then why don't we write #include<vector.h>?
What does the standard cpp library contain? Smaller libraries like containers library , utilities library?
I tried looking on cppreference but couldn't understand
iostream and others are header files.
Usually headers have .h or .hpp extension, but it's merely a convention. The C++ standard library uses a different convention, which is to have no extension.
What counts as a library is moot. A "library" can mean either:
A single .a, .so, .lib, or .dll file (or something else, depending on your platform).
A collection of predefined entities for a programmer to use.
The individual standard headers are definitely not (1). The whole standard library is (2), and is usually split into several (1)s.
Whether each individual standard header counts as (2) is moot, I wouldn't call them that.
The C++ standard splits the standard library into several header groups, and calls each a "library" (2). Cppreference does the same.
Put it this way: iostream and other #include items are really header files containing libraries of built-in functions and other things in the C++ language. specifically helps you with input and output through the terminal using cin, cout, and more. Also, here is a tip: if you want to avoid the tedious need to add each header file so you can use a variety of functions and other items, just #include <bits/stdc++.h>, which is really just a header that includes every other header and their libraries; It should make your life easier.
(As far as I know) C++ doesn't accept the ".h" extension on header files (as it's usually not present in other include statements) so how does the include <bits/stdc++.h> work in C++ and why does this have the ".h" extension?
why there is “.h” extension in <bits/stdc++.h>
Because the developer - who created the file - chose that name.
It is conventional to name headers with the suffix .h and the developer presumably followed such convention.
(As far as I know)c++ doesn't accept the ".h" extension header files
Your knowledge is wrong. Any "extension", including no extension are accepted. There is no limitation to how a header file can be named.
You've tagged [c++-standard-library], so I'll add that C++ standard headers are all named without a suffix, except for those inherited from the C standard library which use the conventional .h suffix (and which do have non-suffixed aliases). bits/stdc++.h is not a standard header even though it may be part of a standard library implementation.
C++ does not use the .h extension for standard library headers named in #include statements.
But bits/stdc++.h is not a standard header, so the standard library naming conventions wouldn't apply to it. It should never be used anyway.
There is no mandatory mapping, IIRC, from the name used in the include statement, to the filename. You can certainly use .h extensions on your own headers if you want, although it may get confusing if you mix C and C++ in a project.
(As far as I know)c++ doesn't accept the ".h" extension header files
That is an incorrect statement.
You can use any filename in that statement.
After the preprocessor has inserted all the files and the result is valid C++ code, then there will not be any errors during compilation.
The case with standard headers is that the C++ standard library developers have created the standard functionality in files without an extension. So the filename is "vector", so #include <vector> is used.
If the developers add a file "vector.hpp", (which has a statement #include <vector> inside the body of the file) then it has to be used as #include <vector.hpp>.
In my code base, I 'hide' implementation details of heavily templated code in .tcc files inside a bits sub-directory, i.e.
// file inc/foo.h:
#ifndef my_foo_h // include guard
#define my_foo_h
namespace my {
/* ... */ // templated code available for user
}
#include "bits/foo.tcc" // includes implementation details
namespace my {
/* ... */ // more templated code using details from foo.tcc
}
#endif
// file inc/bits/foo.tcc:
#ifndef my_foo_tcc // include guard
#define my_foo_tcc
#ifndef my_foo_h
# error foo.tcc must be #included from foo.h
#endif
namespace my { namespace details {
/* ... */ // defails needed in foo.h
} }
#endif
Of course, there must only be one file bits/foo.tcc in the include path. Otherwise, there will be a clash and (hopefully) a compilation error. This just happened to me with bits/vector.tcc, which is included from gcc's (4.8) vector but also my own header (using #include "bits/vector.tcc" and not #include <bits/vector.h>).
My question: is this formally a bug of gcc (since it uses a name bits/vector.tcc which is not protected by the standard) or correct, i.e. even formally my fault? If the latter, what names for header files are guaranteed to be okay to use?
(note I don't want to hear obvious advices of how to avoid this).
Edit The problem is that the header file vector provided by the standard library (shipped by the compiler) has a preprocessor directive #include <bits/vector.tcc> which causes the preprocessor to load my file rather than that provided with the standard library.
Here's what the C++11 standard [cpp.include] has to say about this:
1 A #include directive shall identify a header or source file that can be processed by the implementation.
2 A preprocessing directive of the form
# include < h-char-sequence> new-line
searches a sequence of implementation-defined places for a header identified uniquely by the specified sequence
between the < and > delimiters, and causes the replacement of that directive by the entire contents
of the header. How the places are specified or the header identified is implementation-defined.
3 A preprocessing directive of the form
# include " q-char-sequence" new-line
causes the replacement of that directive by the entire contents of the source file identified by the specified
sequence between the " delimiters. The named source file is searched for in an implementation-defined
manner. If this search is not supported, or if the search fails, the directive is reprocessed as if it read
# include < h-char-sequence> new-line
with the identical contained sequence (including > characters, if any) from the original directive.
In other words, #include < > is intended for searching for headers only. A header is one of the things provided by the standard library. I say "things" because the standard doesn't specify what it is - it doesn't have to a file at all (although all compilers I know implement headers as files).
#include " " is intended for "everything else" - in terms of the standard, they're all "source files," although in general speech we usually refer to files intended for being #included as "header files." Also note that if no such source file is found, a (standard library) header will be searched for instead.
So, in your case:
The standard doesn't say anything about files like bits/vector.tcc; in fact, it doesn't say anything about any files. All of this falls under the "implementation-defined" heading as is thus up to your compiler and its documentation.
At the same time (thanks to #JamesKanze for pointing this out in the comments), the standard clearly specifies what #include <vector> should do, and never mentions that it could depend on a file's presence or absence. So in this regard, gcc loading your bits/vector.tcc instead of its own is a gcc bug. If gcc loaded its own bits/vector.tcc instead of yours, it would be within its "implementation-defined" scope.
#include "vector" is primarily intended to include a source file named vector. However, if no such file is found, the effect is the same as including the standard header <vector> (which causes class template std::vector to be considered defined).
The standard is pretty open, but... including <vector> should
work; I don't see anything that authorizes it not to (provided
you've done #include <vector>, and not #include "vector"),
regardless of the names your personal includes.
More generally, the more or less universal algorithm for
searching for a header is to first search in the directory which
contains the file which does the include. This is done
precisely to avoid the type of problems you have encountered.
Not doing this (or not using some other mechanism to ensure that
includes from standard headers find the file they're supposed
to) is an error in the compiler. A serious one, IMHO. (Of
course, the compiler may document that certain options introduce
certain restrictions, or that you need to use certain options
for it to behave in a standard manner. I don't think that g++
documents -I as being incompatible with the standard headers,
but it does say that if you use -iquote, it shouldn't
influence anything included using <...>.)
EDIT:
The second paragraph above really only applies to the "..."
form of the include. #include <vector> should find the
standard header, even if you have a file vector in the same
directory as the file you are compiling.
In the absense of -I options, this works. Universally,
however, the -I option adds the directory in the search lists
for both types of include. The reason for this is that you,
as a developer, will probably want to treat various third party
libraries (e.g. X-Windows) as if they were part of the system as
well. (I think Linux does put X-Windows as part of the system,
putting its headers in /usr/include, but this wasn't the usual
case in other Unices in the past.) So you use -I to specify
them, as well as you're other include directories. And if you
have a file vector in one of your other directories, it will
"override" the system one.
This is clearly a flaw: if I recall correctly (but it's been
some time), g++ at one time did have additional options to put
a directory in the list for only one type of include. And in
modern gcc/g++, there's -iquote (and -I-, which specifies
that all of the earlier -I options are for the "..."
includes only). These features are little used, however,
because gcc/g++ is the only compiler which supported them.
Given all this, the gcc/g++ handling is probably the best you
can hope for. And the error isn't in the compiler itself, but
the library headers, which use <bits/vector.tcc> when it
absolutely wants the include file from the same directory as the
file doing the including. (Another way of saying this is that
bits/vector.tcc isn't a system header, in any sense of the
word, but an implementation header of system library.)
None of which helps the original poster much, unless he feels
like modifying the library headers for g++. (If portability
isn't any issue, and he's not considering his headers as part of
the system, he could change the -I to -iquote.)
I want to take a peek inside of namespace std but, i'm not able to actually find the file on my computer where it is defined. I tried googling this but, i haven't had much luck.
On most Unix systems, the C++ headers are usually stored in /usr/include/c++/<version>/, where <version> is the GCC/libstdc++ version (i.e. 4.9 or 4.9.2), or else the libc++ version i.e. v1.
Within that directory are all (or just most?) of the standard-mandated headers, which are mostly just ordinary C++ code. For libstdc++, note in particular that most of the older headers just include something in bits/; few of the C++11-specific headers do this.
A list of every thing included in namespace std can be found here.
If you are using Visual Studio you can find it locally here :
~\Microsoft Visual Studio\VC\crt\src
There is also an online representation here.
NOTE : Edit the src files at your own risk, I'd recommend not editing them at all.
Many of the things implemented in the std namespace are templated, which means their entire implementation will be in the header files. For example, std::vector should be in the vector header file. Simply look at the options for your compiler to find out where those header files are located.
There may be some non-templated parent classes and free standing functions, which will not be in the headers. Again, look at the compiler documentation to see if the source files are included somewhere and where they would be.
for gcc they should be the same, right? which one of them is more popular , i am now preparing a project from scratch and i would like to pick one among these 2.
thanks
In C++, the file extension doesn't actually matter. The use of .h, .hpp, .hxx, or no file extension are all by convention.
The standard library uses no file extension for its header files. Many projects, including Boost, use .hpp. Many projects use .h. Just pick one and be consistent in your project.
The compiler doesn't distinguish between the two extensions, so technically it doesn't matter which one you use. Personally I use the .hxx extension for header files that are only used internally in the project, and .hpp for those that should be release with the library/software.
I propose that we re-open this discussion, in view of a recent discovery that I made. For the last 9 years, I have used the following naming convention for the source files in my C and C++ projects.
C = Straight C source code, containing one or more related entry points
CPP = C++ source code, containing one or more related entry points
H = Declaration of functions, macros, structures, typedefs, etc.
INL = Inline (function bodies) that are the bodies of two or more functions whose main definition file is a C or CPP file, into which they are incorporated by #include
An example of these common function bodies, MyStringFunctionA, the ANSI implementation, is defined in MyStringFunctionA.cpp, while MyStringFunctionW, the Unicode (wide character) implementation, is defined in MyStringFunctionW.cpp. MyStringFunctionA.cpp and MyStringFunctionW.cpp contain the prototype, opening and closing brackets, and headers, subject to UNICODE for the wide character version. The function body is defined in the INI file, which is #included inline, within the function definition block.
Combined with generic TCHAR mappings, this approach greatly simplifies maintaining Unicode and ANSI versions, both of which remain in active use.
This naming convention worked great with Visual Studio 6. However, when I began migrating my code base to Visual Studio 2013, I discovered an annoying change that was initially confusing. Although everything compiled cleanly, when one of my INL files was open in the code editor, I would see dozens of Intellisense "errors" listed in the Errors window. I quoted the term "errors" because they are not true errors; they vanish when the INL file is closed, and the C and CPP files into which the iNL is pulled compile without errors, link, and run correctly.
Header file extensions don't usually make a difference, but I know that in some cases the extension of the .cpp file can make a difference. Depending on your compiler the front-end may choose to compile the source file as either C or C++.
This can make a difference, especially if you are combining compilation with the link phase, as it can lead to different libraries being linked (e.g. g++ vs gcc) and so you can control the outcome in your makefile.
Source code header file written in the C++ programming language; may include data types, constants, variables, and other definitions; used for declaring and storing reusable components of code.
HXX files can be inserted into a C++ program using the #include directive. For example, #include myHeader.hxx instructs the C++ compiler to include "myHeader.hxx" into the current program file.