Which is the best way to include the standard header string.h in a C++ project?
Using the [dot]h at the end, like this:
#include <string.h>
or just writing
#include <string>
Or, maybe, using another way that I don't know?
Thanks!
Those are two different headers.
<string> is for c++ std::string class
<string.h> is for c string functions (like strlen(), etc.), which should be <cstring> for c++ project (this is the third, you didn't know of).
its quite different!
<string.h> this library for C-style strings
<string> for C++ strings
by standard in C++ you should use <cstring> instead <string.h>
Wiki says:
The C++ Standard Library also incorporates 18 headers of the ISO C90 C
standard library ending with ".h", but their use is deprecated. All
other headers in the C++ Standard Library DO NOT end in ".h".
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'.
string is c++ stl headfile
provide the template class ‘string’
string.h is c standard headfile
provide many function to use. like strlen strcpy memcpy.
if you want use in namespace std,which is not use globe namespace or not want to use string.h
you can use cstring instead.
The *.h headers files are often C header files, that you can use in C++ perhaps with extern "C" { ... } wrapping
The headers without any *.h are usually genuine C++ headers.
It is a rule of thumb only.
The latest and previous C++ standards (c++11, C++03) define headers like <cstdio> to wrap properly the original C headers, using namespaces, etc.
The standard is
#include <string>
Related
How come this code
std::map <std::string , int> m;
m["a"]=1;
compiles with (I'm using MSVC 2010)
#include <string>
but not with
#include <string.h>
?
<string.h> contains old functions like strcpy, strlen for C style null-terminated strings.
<string> primarily contains the std::string, std::wstring and other classes.
string.h is a C header not a C++ header, period!
<string.h> is cstring - http://www.cplusplus.com/reference/clibrary/cstring/
<string> is the c++ string class - http://www.cplusplus.com/reference/string/
Edit per Nicol Bolas comment below and a bit of googling:
<cstring> will usually import the same things as <string.h> but into the std namespace.
<string.h> will usually import everything into the global namespace.
It appears to depend on the library implementation you're using though according to my googling.
Personally I only ever use <cstring> if I need C style string helpers.
string.h is C's header file while string is C++'s header file.
<string.h> contains C-library string functions. strlen, strcmp, etc.
<string> contains the definition for std::basic_string, which has the typedefs std::string and std::wstring. That's the difference.
They really have no relationship at all, outside of the fact that they both deal with strings.
They are entirely different headers.
<string> is C++ string class
<string.h> or <cstring> defines functions to manipulate C strings and arrays
As stated, string.h and cstring are C headers (while cstring is basically a C++ wrapper for string.h), containing functions for C strings, which are char[] terminated by '\0'. You want to use the c++ class string, which header is <string>.
I believe <string.h> is just used for C and <string> for C++. So including string.h wont work.
<string.h> is a C standard library header while <string> is a cpp in fact all the c standard header files have .h extension an non of cpp have .h.
string.h is for c compatible c++ string class
string is for pure c++ string class
I was told to not include the C headers like <stdio.h> in a c++ program, but to use <cstdio> etc. instead. How do I get struct timeval without including <sys/time.h>?
Alternative question, is there any C++11 alternative to using select/poll (on a POSIX system)?
The <cstdio> and similar are C++ variants for the C standard library. <sys/time.h> is not part of the C standard library at all (it is part of the POSIX interface for certan OS's), so there is no such thing as a C++ specific sys/ctime, so no, you just have to use the same header-file as in C.
The main reason for having a C style and C++ style header is to apply the extern "C" to the functions declared in the headerfile. In some systems, it may be required to wrap the function like this:
extern "C" {
#include <sys/time.h>
}
but in my Linux system, it does that in the standard <sys/time.h> file.
The <cstdio> is a C++ variants of the C library <stdio.h>. The difference is that the C versions are defined in the global namespace.
You can see a list of those headers here : http://www.cplusplus.com/reference/clibrary/
<sys/time.h> is not a part of the standard library so there is no equivalent in C++. You just have to use it like in C.
What should I include in C++ programs, stdio.h or cstdio? and Why?
Why two header files which provide the same functionality?
What does the standard say regarding this?
How should I go about including other such headers, Is there a base rule that I should follow?
Consider the following programs:
Sample 1:
#include<stdio.h>
int main()
{
printf("Hello World");
return 0;
}
Sample 2:
#include<cstdio>
int main()
{
printf("Hello World");
return 0;
}
Both work as expected. So which usage is more appropriate?
The answer is: Neither! Surprised? Read on.
The C++ Standard library provides all standard C headers for compatibility reason, while C++ as a language also provides all the equivalent headers. As a convention,
No C++ standard library headers(apart from ones include for C compatibility) have any file extensions, and
All C++ equivalent of C headers begin with cxxxxx.
The C++ Standard mentions this under Annex D (normative) Compatibility features:
§2 mentions the important distinguishing point. This rule applied to the examples above means:
Including cstdio imports the symbol names in the std namespace and possibly in the Global namespace.
Including stdio.h imports the symbol names in the Global namespace and possibly in the std namespace.
Let us apply this rule to our sample codes and measure the pros and cons:
Sample 1:
This brings all the symbols from stdio.h in the global namespace. Advantage is that you can use the symbols without any qualification since they are imported in the global namespace. Downside is that you end up polluting the global namespace with many symbol names that you will probably never use. This might lead to symbol name collision. In C++ always consider the global namespace as a minefield and avoid it as much as possible.
Sample 2:
This is a very bad practice because there is no guarantee that the implementation will put the symbols in global namespace, the standard simply does not demand to do so. We are simply relying on the behavior of one particular compiler implementation. We cannot and should not assume that all compilers will do so. So strictly speaking the program is not standard approved and this usage is not portable across all implementations.
So what is the correct usage?
The correct usage is to use cstdio and fully qualify the symbol names or else bring them in scope with using declarations. This guarantees all symbols we use are present in std namespace and we are not polluting the global namespace. Example of correct usage:
Sample 3:
#include<cstdio>
using std::printf;
int main()
{
printf("Hello World");
return 0;
}
Note that the directive using namespace std;, especially in a header, is not a good option and you should always use using declarations.
Note that we consider stdio.h vs. cstdio here just a sample use case, in practice it applies to all most cxxxx and xxxx.h headers, except a few like <math.h> and <cmath>.
Since this post is a bit old I wanted to share the following:
Looking at code:
Using X.h // Compatible with C language standard
---------------
#include <X.h>
int main() {
// Invoke X's corresponding function
return 0;
}
Using X // Not compatible with C language standard
--------------
#include <X>
int main() {
// Invoke X's corresponding function
return 0;
}
They both compile and execute ok!
Which one is better in C++?
Regarding C++11's and C++17's specification:
C.5.1 (section from C++17 document)
Modifications to headers [diff.mods.to.headers]
For compatibility with the C standard library, the C++ standard library provides the C headers enumerated in D.5, but their use is
deprecated in C++.
There are no C++ headers for the C headers <stdatomic.h>, <stdnoreturn.h>, and <threads.h>, nor are the C headers themselves
part of C++.
The C++ headers <ccomplex> (D.4.1) and <ctgmath> (D.4.4), as well as their corresponding C headers <complex.h> and <tgmath.h>, do not
contain any of the content from the C standard library and instead
merely include other headers from the C++ standard library.
D.5
C standard library headers [depr.c.headers]
For compatibility with the C standard library, the C++ standard library provides the C headers shown in Table 141.
Both C++11 and C++17 standard specifications documents state the use of <X.h> remains for compatibility with the C standard, although their use is regarded as deprecated.
Regarding C++ 20 standard proposal
They are reviewing "undeprecating" the use of the C library headers in C++20. <X.h> appear highlighted in green. C++11 and C++17 deprecation, as of now, is stated as a "weak recommendation" and a "tweak" for keeping the "C standard library headers (c.headers)" is displayed below:
"The basic C library headers are an essential compatibility feature, and not going anywhere anytime soon." (from C++ 20 review document)
D.5 C standard
library headers [depr.c.headers]
Weak recommendation: In addition to the above, also remove the
corresponding C headers from the C++ standard, much as we have no
corresponding <stdatomic.h>, <stdnoreturn.h>, or <threads.h>, headers.
As above, but with the following tweaks:
20.5.5.2.1 C standard library headers [c.headers]
For compatibility with the C standard library, the C++ standard
library provides the C headers shown in Table 141. Table 141 — C
headers
<assert.h> <inttypes.h> <signal.h> <stdio.h> <wchar.h>
<complex.h> <iso646.h> <stdalign.h> <stdlib.h> <wctype.h>
<ctype.h> <limits.h> <stdarg.h> <string.h>
<errno.h> <locale.h> <stdbool.h> <tgmath.h>
<fenv.h> <math.h> <stddef.h> <time.h>
<float.h> <setjmp.h> <stdint.h> <uchar.h>
The header <complex.h>
behaves as if it simply includes the header <complex>.
The header <tgmath.h> behaves as if it simply includes the headers <complex> and <cmath>.
Bjarne Stroustrup recommends maximising inter-operability between
the C and C++ languages, by reducing incompatibilities as much as
possible. Others argue otherwise, as it complicates things.
So, it seems <X.h> aren't going anywhere. Ultimately, you can use both. Personally, I would make the decision of which one I would use boil down to having your code backwards compatible with C code or not.
How come this code
std::map <std::string , int> m;
m["a"]=1;
compiles with (I'm using MSVC 2010)
#include <string>
but not with
#include <string.h>
?
<string.h> contains old functions like strcpy, strlen for C style null-terminated strings.
<string> primarily contains the std::string, std::wstring and other classes.
string.h is a C header not a C++ header, period!
<string.h> is cstring - http://www.cplusplus.com/reference/clibrary/cstring/
<string> is the c++ string class - http://www.cplusplus.com/reference/string/
Edit per Nicol Bolas comment below and a bit of googling:
<cstring> will usually import the same things as <string.h> but into the std namespace.
<string.h> will usually import everything into the global namespace.
It appears to depend on the library implementation you're using though according to my googling.
Personally I only ever use <cstring> if I need C style string helpers.
string.h is C's header file while string is C++'s header file.
<string.h> contains C-library string functions. strlen, strcmp, etc.
<string> contains the definition for std::basic_string, which has the typedefs std::string and std::wstring. That's the difference.
They really have no relationship at all, outside of the fact that they both deal with strings.
They are entirely different headers.
<string> is C++ string class
<string.h> or <cstring> defines functions to manipulate C strings and arrays
As stated, string.h and cstring are C headers (while cstring is basically a C++ wrapper for string.h), containing functions for C strings, which are char[] terminated by '\0'. You want to use the c++ class string, which header is <string>.
I believe <string.h> is just used for C and <string> for C++. So including string.h wont work.
<string.h> is a C standard library header while <string> is a cpp in fact all the c standard header files have .h extension an non of cpp have .h.
string.h is for c compatible c++ string class
string is for pure c++ string class
I know most compilers allow both:
#include <stdio.h>
and
#include <cstdio>
But someone argued that <stdio.h> is not actually C++ standard. Is that true?
stdio.h is standard, but deprecated. Always prefer cstdio in C++.
[n3290: C.3.1/1]: For compatibility with the Standard C library, the
C++ standard library provides the 18 C headers (D.5), but their use is
deprecated in C++.
[n3290: D.5/3]: [ Example: The header <cstdlib> assuredly
provides its declarations and definitions within the namespace std. It
may also provide these names within the global namespace. The header
<stdlib.h> assuredly provides the same declarations and definitions
within the global namespace, much as in the C Standard. It may also
provide these names within the namespace std. —end example ]
It's not true, because C++ main goal is backward compatibility with C. The only difference is that for
#include <cstdio>
all functions are in std namespace
The C standard headers are included in the C++ standard library for compatibility.
The difference is that identifiers in corresponding C++ headers must (also) be in std namespace, whereas identifiers in C headers must (also) be available in global namespace.
In addition, the <c...> headers add overloads for functions like abs, pow etc.
Also, C++ headers replace some C classification/comparison macros with overloaded functions.
The C++ standard library explicitly contains the C standard library, so is an entirely legitimate part of C++. And if you are talking about using #include <stdio.h> in C++ code, then you shouldn't do that, cause that's C syntax, in C++ code, you should use always cstdio