Advertisements

On Mon, 25 Jun 2007 09:15:45 -0700, mann_mathann wrote:
> can anyone tell me a solution:
> i cannot use the features in standard c++ string classgh i included the
> string.h file but still its not working.

To use the class std::string

#include <string>

Note: string.h contains headers for the standard C (as opposed to C++)
string manipulation routines. If you need these in C++ (and chances are
you don't if you're using std::string) then you should include them via
the header <cstring> rather than string.h.

On 2007-06-25 18:36, Lionel B wrote:
> On Mon, 25 Jun 2007 09:15:45 -0700, mann_mathann wrote:
>
>> can anyone tell me a solution:
>> i cannot use the features in standard c++ string classgh i included the
>> string.h file but still its not working.
>
> To use the class std::string
>
> #include <string>
>
> Note: string.h contains headers for the standard C (as opposed to C++)
> string manipulation routines. If you need these in C++ (and chances are
> you don't if you're using std::string) then you should include them via
> the header <cstring> rather than string.h.

I'd like to add that none of the C++ standard headers have a .h in them.

No, it contains headers for the char-array-based string manipulation
functions inherited from C. They are still C++, although that
particular header is deprecated and should be replaced with the newer
one, <cstring>.

[...]
> Note: string.h contains headers for the standard C (as opposed to C++)
> string manipulation routines. If you need these in C++ (and chances are
> you don't if you're using std::string) then you should include them via
> the header <cstring> rather than string.h.

This would be good advice IF you could realiably count on a
conformant <cstring>. In practice, you can't, and you're
probably better off for the time being still using <string.h>.

Default User wrote:
> Erik WikstrÃ¶m wrote:
>
>
>> I'd like to add that none of the C++ standard headers have a .h in
>> them.
>
> Not true. While deprecated, several .h headers are standard.
>
>
Nope, there are no C++ headers that have .h, deprecated or otherwise.

What there exists are the C headers that the C++ standard includes
by reference. These can be done either by their C names (such
as stdio.h) or by a not-deprecated C++ interface (cstdio).

Any headers like iostream.h are not part of C++ (deprecated
or otherwise). Their vestiges of early non-standard implementations.

James Kanze wrote:
>
> This would be good advice IF you could realiably count on a
> conformant <cstring>. In practice, you can't, and you're
> probably better off for the time being still using <string.h>.
>
>
If you can't count on <cstring> being conformant, you can't
count on much and you might as well trash the compiler.

While there are a few things (like template exporting) that
are not well implemented across the board, I fail to see
why people should live in the past in the off chance
that some oddball compiler might be so far deviant from
the standard that things like this are a concern.

Even Microsoft (not the most responsive to the standards)
has been fairly compliant for many years.

Ron Natalie wrote:
> Default User wrote:
> > Erik WikstrÃ¶m wrote:
> >
> >
> > > I'd like to add that none of the C++ standard headers have a .h in
> > > them.
> >
> > Not true. While deprecated, several .h headers are standard.
> >
> >
> Nope, there are no C++ headers that have .h, deprecated or otherwise.
>
> What there exists are the C headers that the C++ standard includes
> by reference. These can be done either by their C names (such
> as stdio.h) or by a not-deprecated C++ interface (cstdio).

On Jun 27, 1:34 pm, Ron Natalie <> wrote:
> Default User wrote:
> > Erik Wikström wrote:
> >> I'd like to add that none of the C++ standard headers have a .h in
> >> them.
> > Not true. While deprecated, several .h headers are standard.
> Nope, there are no C++ headers that have .h, deprecated or otherwise.

It depends on what you consider "C++ headers". They are defined
as being part of C++ by the C++ standard, and the contents of
the C++ versions aren't 100% identical to the C versions. On
the other hand, the C++ standard does make the distinction
between "C++ headers" and "C headers". So there are standard
headers in C++ (or "C++ standard headers") with a .h, but they
aren't "C++ headers" in the sense of the standard. (Except that
it doesn't make sense---if they are part of standard C++, and
the contents are not even identical to the headers in C, how can
one say that they aren't "C++ headers".)
> What there exists are the C headers that the C++ standard includes
> by reference. These can be done either by their C names (such
> as stdio.h) or by a not-deprecated C++ interface (cstdio).
> Any headers like iostream.h are not part of C++ (deprecated
> or otherwise). Their vestiges of early non-standard implementations.

So which is it? The are not part of *standard* C++, but C++
existed long before it was standardized, and they are definitly
a part of traditional C++. Standard C++ is not all of C++. (To
begin with, only a lucky few have the privilege of being able to
use a standard conformant compiler in their daily work.)

On Jun 27, 1:37 pm, Ron Natalie <> wrote:
> James Kanze wrote:
> > This would be good advice IF you could realiably count on a
> > conformant <cstring>. In practice, you can't, and you're
> > probably better off for the time being still using <string.h>.
> If you can't count on <cstring> being conformant, you can't
> count on much and you might as well trash the compiler.

In a certain sense, you can't. At least, not unless it is. In
practice, most implementations today do provide a version of
<string> which is more or less conformant. In practice, I've
yet to see an implementation in which e.g. <cstdlib> is
conformant.

The current draft has loosened the requirements considerably in
this respect; if it is accepted in the current state, most
implementations of <cstring> will become conformant, where they
aren't today. (<cstdlib> is another story; none of the
compilers I have access to include the required overloads of
atexit, for example.)
> While there are a few things (like template exporting) that
> are not well implemented across the board, I fail to see
> why people should live in the past in the off chance
> that some oddball compiler might be so far deviant from
> the standard that things like this are a concern.

Perhaps because of the simple fact that very few compilers are
conformant in this respect.
> Even Microsoft (not the most responsive to the standards)
> has been fairly compliant for many years.

Not in VC 2005. A quick check shows that VC++ and g++ are not
conform; in both cases, <cstdlib> injects names which it
shouldn't into the global namespace.

Personally: these headers define a C API, much like the Posix
standard headers do. So it seems more natural and more correct
to use the C standard forms. And not even count on the few
changes C++ introduced being present. (The one that would be
most important to me, the overload of atexit, isn't present in
any of the implementations I have access to.)

On 27 Jun, 12:37, Ron Natalie <> wrote:
> James Kanze wrote:
>
> > This would be good advice IF you could realiably count on a
> > conformant <cstring>. In practice, you can't, and you're
> > probably better off for the time being still using <string.h>.
>
> If you can't count on <cstring> being conformant, you can't
> count on much and you might as well trash the compiler.
>
> While there are a few things (like template exporting) that
> are not well implemented across the board, I fail to see
> why people should live in the past in the off chance
> that some oddball compiler might be so far deviant from
> the standard that things like this are a concern.
>
> Even Microsoft (not the most responsive to the standards)
> has been fairly compliant for many years.

It's an example using <cstdio> rather than <cstring>, but MSVS2005
(language extensions disabled) and Comeau online both compile this:

"Gavin Deane" <> wrote in message
news:...
> On 27 Jun, 12:37, Ron Natalie <> wrote:
>> James Kanze wrote:
>>
>> > This would be good advice IF you could realiably count on a
>> > conformant <cstring>. In practice, you can't, and you're
>> > probably better off for the time being still using <string.h>.
>>
>> If you can't count on <cstring> being conformant, you can't
>> count on much and you might as well trash the compiler.
>>
>> While there are a few things (like template exporting) that
>> are not well implemented across the board, I fail to see
>> why people should live in the past in the off chance
>> that some oddball compiler might be so far deviant from
>> the standard that things like this are a concern.
>>
>> Even Microsoft (not the most responsive to the standards)
>> has been fairly compliant for many years.
>
> It's an example using <cstdio> rather than <cstring>, but MSVS2005
> (language extensions disabled) and Comeau online both compile this:
>
> #include <cstdio>
> int main()
> {
> printf("This should not compile.\n");
> }
>
> That's enough for me to not bother with <cxxx> headers. YMMV.

Calm down. There's a difference between a compiler accepting
a program that *should* compile and one failing to compile a
program that *shouldn't* compile. And in this particular case,
the issues run even deeper. Several compiler vendors warned the
C++ committee that their rules for namespaces in <*.h> vs <c*>
headers were unrealistic, but their warnings were ignored. As a
consequence, the rules of C++98 have been largely ignored, to
repay the compliment, by *most* compiler vendors, not just
Microsoft. Now guess what -- the next C++ Standard (informally
known for now as C++0X) has finally accepted the obvious and
blessed the behavior you're seeing. So this is just a transient
hiccup, not a major sin.

On Jun 29, 12:40 am, "P.J. Plauger" <> wrote:
> "Gavin Deane" <> wrote in message
> news:...
> > On 27 Jun, 12:37, Ron Natalie <> wrote:
> >> James Kanze wrote:
[...]
> > It's an example using <cstdio> rather than <cstring>, but MSVS2005
> > (language extensions disabled) and Comeau online both compile this:
> > #include <cstdio>
> > int main()
> > {
> > printf("This should not compile.\n");
> > }
> > That's enough for me to not bother with <cxxx> headers. YMMV.
> Calm down. There's a difference between a compiler accepting
> a program that *should* compile and one failing to compile a
> program that *shouldn't* compile. And in this particular case,
> the issues run even deeper. Several compiler vendors warned the
> C++ committee that their rules for namespaces in <*.h> vs <c*>
> headers were unrealistic, but their warnings were ignored. As a
> consequence, the rules of C++98 have been largely ignored, to
> repay the compliment, by *most* compiler vendors, not just
> Microsoft. Now guess what -- the next C++ Standard (informally
> known for now as C++0X) has finally accepted the obvious and
> blessed the behavior you're seeing. So this is just a transient
> hiccup, not a major sin.

Just to make my point of view clearer: I didn't mean to (overly)
criticize the implementors with my comments. My opinion was
very much that none of the implementations were conform,
*because* the requirements of the standard weren't really
reasonable (which I really should have said explicitly). Which
means, in a very real sense, that I don't know what I can count
on in the <cxxx> headers. I knew what most implementors did,
and I rather thought that it was a reasonable compromize, but
why count on it? What if the standard adopted a different
position in the future, in its attempts to become reasonable?

As for Gavin's comment: I agree. Why bother with the new
headers if they don't provide what the standard claims to
require? There's certainly no rush; the old ones aren't going
to disappear, and my code will work just as well with them.

Now that the standard has been clarified, I'll probably
reevaluate my position. Although somewhere deep inside me, I
still don't see any real reason for the <cxxx> headers---I'm
using a legacy, C API, so why hide the fact?

(This is, of course, independant of the atexit problem. Where
the library implementor is rather at the mercy of the compiler,
and whether it implements `extern "C"' correctly.)

Which, of course, isn't a legal implementation according to the
current standard (although the next release will make it one).
> In <stdlib.h>:
> /* Note: This is in startup code, not imported directly from dll */
> int __cdecl atexit (void (*)(void));
> // -------
> What 'required overloads' are you refering to?

Note that the standard requires this for every function in the C
library which takes a callback.

And of course, the real problem here is that the compiler isn't
conform; a header which did the above with g++ probably wouldn't
compile. (But then, g++ is just behaving like most other
implementors in this respect: implement whatever you feel like,
rather than what the standard requires.)

Share This Page

Welcome to The Coding Forums!

Welcome to the Coding Forums, the place to chat about anything related to programming and coding languages.

Please join our friendly community by clicking the button below - it only takes a few seconds and is totally free. You'll be able to ask questions about coding or chat with the community and help others.
Sign up now!