(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>.
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.
I have question about the include of iostream when I use Xcode.
After the include of iostream, it seems that stdlib.h is also included automatically because when I write "merg",the Code Completion of Xcode gives me the function "mergesort" which is a function in the stdlib.h according to the documentation of Xcode. But I haven't included stdlib.h explicitely. So I guess it is the include of iostream that caused the include of stdlib.h. Any one could tell me why?
According to the C standard, stdlib.h doesn't have any function like mergesort, why in Xcode, the stdlib.h has such a function？ Does it mean that the stdlib.h in Xcode is not a standard one?
How can I get a map of the dependency of every header file, for exemple, for a header file example.h, how can I know which other .h files are included in this exemple.h, and which other .h files include in themselves the file exemple.h.
Sorry for this long question, thank you very much for your answers!
In short: it's implementation-defined.
Which means it depends on the particular standard library implementation. The standard explicitly allows standard library headers to include other standard library headers (or at least define the symbols in them); C++11 17.6.5.2/1:
A C++ header may include other C++ headers. A C++ header shall provide the declarations and definitions
that appear in its synopsis. A C++ header shown in its synopsis as including other C++ headers shall provide
the declarations and definitions that appear in the synopses of those other headers.
To keep your code portable (even if only between versions of the same compiler/standard library), you should follow these rules:
Don't rely on transitive includes. Always explicitly include all the headers you need.
Don't be surprised by transitive includes. They're legal.
Any one could tell me why?
Presumably, something in your implementation of iostream needs something from stdlib.h. Standard headers are allowed to include other standard headers if they need them; and, since many headers contain inline function definitions, they will need the headers for anything used by those functions.
why in Xcode, the stdlib.h has such a function？
It's a BSD extension to the standard library.
Does it mean that the stdlib.h in Xcode is not a standard one?
It does indeed.
How can I get a map of the dependency of every header file, for exemple, for a header file example.h, how can I know which other .h files are included in this exemple.h, and which other .h files include in themselves the file exemple.h.
Most compilers can output the dependencies of a translation unit. For example, GCC has a -M option to do that.
As in C++ header files are used without .h extension like <iostream> instead of <iostream.h> but its not same in case of <conio.h>. Why we can't use <conio>
The C++ standard specifies which headers are part of the C++ standard library. In addition to C++-specific headers, it includes the headers specified by the C standard. You can use them with their C names (e.g., #include <stdio.h>), and they put their symbols into the global namespace. You can use them without the .h extension and a c on the front (e.g., #include <cstdio>), and they put their symbols into the namespace std.
But that's only for the headers from the C standard. conio.h is not part of the C standard, so the C++ standard doesn't say anything about it.
conio.h is a C header, thus (traditionally) C headers had the .h extension for the system headers. C++ standard headers are mainly without this .h extension. As you may know, many C headers (those from the standard library) have C++ counterparts (like in C++ is )
Because conio.h is a C header, not C++ specific.
conio isn't part of the c++ standard, so you can't count on the compiler to know what it is. :(
In fact, i think it's usually only supported under windows.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Difference between <string> and <string.h>?
My specific example uses following clause:
#include <string>
If I use following clause instead
#include <string.h>
compiler ends with error
[BCC32 Error] utils.cpp(173): E2316 'getline' is not a member of 'std'
Line 173 in utils.cpp file is as follows:
while(std::getline(in, line, '\n'))
I thought that there is no difference between these two clauses. Now I am confused. What files are in fact included by these two clauses? Lets say, my C++ Builder installation has program directory C:\Program Files\RAD Studio\9.0 and include files are located in subdirectory C:\Program Files\RAD Studio\9.0\include.
#include <string>
This includes the C++ string header.
#include <string.h>
This includes the C string header, with all identifiers in the global namespace. (Deprecated.)
#include <cstring>
This includes the C string header, with all identifiers placed in the std:: namespace.
Edit: Rule of thumb - C++ headers never end on ".h". Prefix the traditional C header name with "c" and drop the ".h" to keep the global namespace clean. Use ".h" for your project's C headers only. Use ".hpp" for C++-only headers.
They are two different headers. The convention in the C standard library is to have the headers ending with .h, whereas in the C++ standard library the convention is to miss out the file extension altogether. Some more detail from wikipedia:
Each header from the C Standard Library is included in the C++
Standard Library under a different name, generated by removing the .h,
and adding a 'c' at the start; for example, 'time.h' becomes 'ctime'.
The only difference between these headers and the traditional C
Standard Library headers is that where possible the functions should
be placed into the std:: namespace (although few compilers actually do
this). In ISO C, functions in the standard library are allowed to be
implemented by macros, which is not allowed by ISO C++.
Other libraries follow different conventions. Boost, for instance, chooses .hpp as their C++ header extension of choice.
By convention, C (Procedural) headers ends by '.h' "string.h", "stdio.h"... and C++ (Object oriented mostly) don't include any extension: "iostream", "string" ...
Not sure if all headers follow this convention, but I think that the standards ones all do.
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.