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.
Related
(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>.
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.
It's said that when including C header files in C++, the ".h" suffix should be removed and then add "c" at the beginning. For example, #include <cstdio> instead of #include <stdio.h>. But when I use sleep() in my code, #include <cunistd> does not work, but #include <unistd.h> works. Why not <cunistd>?
Your algorithm is correct for most (all?) standard C headers, but unistd.h is not part of standard C so standard C++ in turn doesn't include it with the other c... headers.
Because unistd.h never was part of the C language. It is part of the Operating System.
<unistd.h> , stands for unix standard header ,the name says it all.
unistd.h is not part of standard C.
Standard C++ lib doesn't include it with the other c headers.
I have some header file that was written for use in a C99 program. This header includes all the function definitions, and is not paired with a source file. I am including it in a C++ file.
My C++ compiler flags include -pedantic -std=c++11, which gives me various warnings in the header file such as "ISO C++ forbids compound literals", and "ISO C++ forbids variable length arrays". Obviously the C++ compiler is treating the C99 code as C++. Two questions:
Is this a potential problem when trying to write code that will run correctly on various platforms using different compilers?
What is a good way to resolve the warnings, and produce standard conforming code? I was thinking of making a precompiled header file using gcc, but don't know enough about the process to be assured that I am not going to have unintended consequences from included a C precompiled header in a C++ source.
Thanks
Is this a potential problem when trying to write code that will run correctly on various platforms using different compilers?
Yes. GCC may just give a warning, other compilers (e.g. Visual Studio, or GCC with other options) could very well give an error.
What is a good way to resolve the warnings, and produce standard conforming code?
The correct way to resolve the problems is to write the header in the common subset of C and C++. Functions and object-definitions that use C99 features (such as variable-length arrays and compound literals) should be moved to a separate C source file (that gets compiled with a C compiler!).
To include a pure C header file(*) in a C++ project, you should wrap the include statement in an extern "C" block:
// C++
extern "C" {
// C-code goes here
#include "foo.h"
}
This is because C++ performs name mangling on all function names to make overloading work. C doesn't use name mangling, so C++ parses C function signatures with name mangling.
Please note that extern "C" doesn't put the compiler into "C-mode" (there is no such mode but you might falsely think of this instruction as such), it doesn't mangle the function names (+ changes the calling convention and forbids overloading; thanks for doomster for pointing these things out).
However, it shouldn't be a problem if you are including a header only (with inline implementations), since this name mangling will only be a problem when you link the C source file or library against your C++ project, since the function names are different in this case.
This being said, you should use the common subset of C and C++ for the header file, extract and compile the implementations of these functions separately with a C compiler, not C++. Then, you (hopefully) can link both parts together. A lot of C libraries already have headers which are compatible with C++, so this is a common procedure.
(*): Some header files are already made to be compatible with both languages C and C++ by using the common subset of language features plus wrapping everything in a conditional extern "C" block. For such headers, you should not use this method, but only for the ones which don't have such a block in it.
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.