<string.h> vs <string>

[Carmen Sei]

it seem to me that when doing include -

#include <string.h> - is CRT
#inlcude <string> - is C++ standard library

Is that true those header with .h extension is CRT and those without
extension <string> is C++ standard library headers?

[Ian Collins]

Post by Carmen Sei
it seem to me that when doing include -
#include <string.h> - is CRT

No, it's an obsolete C++ header.

There isn't a "CRT", there's the C and C++ standard libraries. The
latter includes the former.

[Sharad]

Post by Ian Collins

Post by Carmen Sei
it seem to me that when doing include -
#include <string.h> - is CRT

No, it's an obsolete C++ header.

Are you sure? Have you looked at <cstring>?

Sharad

[Ian Collins]

Post by Sharad

Post by Ian Collins

Post by Carmen Sei
it seem to me that when doing include -
#include <string.h> - is CRT

No, it's an obsolete C++ header.

Are you sure? Have you looked at <cstring>?

Oops, I misread the OP.

[Ron Natalie]

Post by Ian Collins

Post by Carmen Sei
it seem to me that when doing include -
#include <string.h> - is CRT

No, it's an obsolete C++ header.
There isn't a "CRT", there's the C and C++ standard libraries. The
latter includes the former.

The latter includes an obsolete version of the former.

[Sharad]

Post by Carmen Sei
it seem to me that when doing include -
#include <string.h> - is CRT
#inlcude <string> - is C++ standard library

The intention of <string.h> is for the C style string category of functions
like strcpy, strlen etc. <string> is meant for the std::string class in the
C++ Standard library. At least with Comeau just including <string> takes
care of <string.h> also, but I am not sure if it's yet a standard behavior.

Sharad

[Ron Natalie]

Post by Sharad

Post by Carmen Sei
it seem to me that when doing include -
#include <string.h> - is CRT
#inlcude <string> - is C++ standard library

The intention of <string.h> is for the C style string category of functions
like strcpy, strlen etc. <string> is meant for the std::string class in the
C++ Standard library. At least with Comeau just including <string> takes
care of <string.h> also, but I am not sure if it's yet a standard behavior.
Sharad

It is allowed for it to do this.
It is not REQUIRED for it to do so.

If you're going to need the C string functions, you need to include
string.h or cstring.

[Jim Langston]

Post by Carmen Sei
it seem to me that when doing include -
#include <string.h> - is CRT
#inlcude <string> - is C++ standard library
Is that true those header with .h extension is CRT and those without
extension <string> is C++ standard library headers?

Not always. An OS/Compiler specific header may have a .h or not, usually
they do though.

Most headers without an extention are part of the STL.

Some headers with an .h extention are from the C routines.

However, the standard C headers can be included by adding a 'c' to the front
and removing the exteion. I.E.
#include <string.h>
becomes
#include <cstring>

So how would you catagorize cstring?

[Pete Becker]

Post by Jim Langston

Post by Carmen Sei
it seem to me that when doing include -
#include <string.h> - is CRT
#inlcude <string> - is C++ standard library
Is that true those header with .h extension is CRT and those without
extension <string> is C++ standard library headers?

Not always. An OS/Compiler specific header may have a .h or not, usually
they do though.
Most headers without an extention are part of the STL.
Some headers with an .h extention are from the C routines.
However, the standard C headers can be included by adding a 'c' to the front
and removing the exteion. I.E.
#include <string.h>
becomes
#include <cstring>
So how would you catagorize cstring?

Let me restate that. Among the headers defined in the C++ standard:

Headers without an extension describe names in the C++ standard library.
Headers with a .h extension describe names in the C standard library,
and put those names in the global namespace.
Headers with names that are the same as the C headers but with a 'c' in
front and no extension put names from the C standard library into
namespace std.

[Martin York]

Post by Jim Langston

Post by Carmen Sei
Is that true those header with .h extension is CRT and those without
extension <string> is C++ standard library headers?

Not always. An OS/Compiler specific header may have a .h or not, usually
they do though.

But also note (and just to clarify the above correct statement) that
<string.h> (as with several other header files) is an unsupported (or
non standard) header and should NOT be used in modern code. It is
usually put there so that old legacy code (and examples in old books)
will not break, but it is not an official part of the C or C++
libraries (It is there for historical compatibility ONLY).

All C++ header files do NOT have a .h
i.e. <strings>

All (I think) C header files have a C++ version that puts the
declarations in the std namespace. The C++ version has the same base
name as the C version but drops the '.h' and prefix a 'c.
i.e. <ctype.h> is <cctype>
etc.

[Pete Becker]

Post by Martin York

Post by Jim Langston

Post by Carmen Sei
Is that true those header with .h extension is CRT and those without
extension <string> is C++ standard library headers?

Not always. An OS/Compiler specific header may have a .h or not, usually
they do though.

But also note (and just to clarify the above correct statement) that
<string.h> (as with several other header files) is an unsupported (or
non standard) header and should NOT be used in modern code.

It is both standard C and standard C++. It is deprecated in the C++
standard, which means that in some future standard it might not be
supported. But that's wishful thinking. In any event, it is part of
the current standard and part of C++0x, and its meaning is well defined.

Post by Martin York
It is
usually put there so that old legacy code (and examples in old books)
will not break, but it is not an official part of the C or C++
libraries (It is there for historical compatibility ONLY).
All C++ header files do NOT have a .h
i.e. <strings>

There is no standard header with that name.