The difference between "go" <string> <string.h> <cstring>

#include <string. h >

voidMain ()
{
　　 stringAAA ="ABCSD D";
printf"looking for ABC from ABCDECD%s\n",
(strcmp (AAA,"ABC")) ?"Found":"Not Found");
}
//does not execute correctly, the hint is that the string type is undefined and the following:
#include <string>
usingnamespaceStd
voidMain ()
{
　　 stringAAA ="ABCSD D";
printf"looking for ABC from ABCDECD%s\n",
(strcmp (AAA,"ABC")) ?"Found":"Not Found");
The string compiler here knows it, but strcmp doesn't know it?
Generally a C + + old standard with ". h" extension of the library file, such as Iostream.h, and the new standard after the standard library has a non-". h" extension of the corresponding,apart from the many improvements in the latter, there is a point where the latter is crammed into the "Std" namespace.
　　 but the string is special.
　　The problem is that C + + is compatible with the standard library, and C's standard library also happens to have a header file called "String.h", which contains some commonly used C string processing functions, such as the strcmp mentioned by the landlord.This header file has nothing to do with the C + + string class, so <string> is not a "upgraded version" of <string.h>, they are two header files that have no relationship.

To achieve the purpose of the landlord, such as at the same time:
#include < string. h >
#include < string >
using namespace Std;
Or
#include < CString >
#include < string >
　 where <cstring> is the <string.h> corresponding to the C standard library, but is wrapped in a version of the Std namespace.
　　
The C + + standard library is large. Very large. Incredibly big. What's a Dafa? Let's put it this way: in the C + + standard, the specification of the standard library accounts for more than 300 pages, which does not include the standard C library, which is only "as a reference" (to be honest, the original word is used) included in the C + + library. Of course, not always the bigger the better, but in the present case, the bigger the better, because the large library will contain a lot of functionality. The more features in a standard library, the more features you can use to develop your own applications. The C + + library does not provide everything (obviously, it does not provide support for concurrent and graphical user interfaces), but it does provide a lot. You can ask for it almost anything. Before you summarize something in the standard library, you need to describe how it is organized. Because there are so many things in the standard library, the class name or function name you choose (or someone like you) is likely to be the same as a name in the standard library. In order to avoid name collisions caused by this situation, everything in the standard library is actually placed in namespace STD (see clause 28). But this poses a new problem. Countless existing C + + code relies on features in pseudo-standard libraries that have been in use for years, such as those that are declared in <iostream.h>,<complex.h>,<limits.h> and other header files. Existing software is not designed to work with namespaces, and it would be shameful to use STD to wrap a standard library so that existing code could not be used. (This drastic will make the programmer of the existing code say something worse than "shameful") awed by the destructive power of the enraged programmer, the standard Committee decided to create a new header file name for the part of the standard library component that was packaged with Std. The only way to generate a new header file is to put the existing C + + header in the filename. H is removed, the method itself is unimportant, just as the result of the final inconsistency is not important. So <iostream.h> became a <iostream>,<complex.h> <complex&gt, and so on. For the C header file, the same method is used, but a C is added before each name. So C's <string.h> turns into <cstring>,<stdio.h> <cstdio&gt, and so on. The last point is that the old C + + header file is officially objected to (that is, explicitly listed no longer supported), but the old C header file is not (to maintain compatibility with C). In fact, the compiler manufacturer does not stop supporting the customer's existing software, so it can be expected that the old C + + header files will still be supported in the coming years.
So, actually, here is the status of the C + + header file:
Old C + + header filenames such as <iostream.h> will continue to be supported, although they are not in the official standard. The contents of these header files are not in the namespace Std.
The new C + + header file, such as <iostream> contains the same basic functionality as the corresponding old header file, but the contents of the header file are in the namespace Std. (in the process of normalization, the details of some parts of the library have been modified, so the old header files and the entities in the new header file do not necessarily correspond exactly.) ）

Standard C header files such as <stdio.h> continue to be supported. The contents of the header file are not in Std.
A new C + + header file with C library functionality has a name such as <cstdio>. They provide the same content as the corresponding old C header file, except that the content is in Std.

All of these look a bit strange at first, but it's not hard to get used to it. The biggest challenge is figuring out the string header file:
<string.h> is the old C header file, corresponding to the char*-based string processing function;
<cstring> is the STD version corresponding to the old C header file;
<string> is the C + + header file that wraps the STD, which corresponds to the new string class.
If you can master these (I believe you can), the rest will be easy.

The difference between "go" <string> <string.h> <cstring>