string class problem

[mann_mathann]

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.

 

[red floyd]

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.

Because <string.h> is the C90 header (C++ equivalent is <cstring>). Try
using <string> (note the lack of .h) And don't forget the std:: when
using std::string.

 

[Lionel B]

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.

 

[John Harrison]

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.

Because the file is called <string> not <string.h>

john

 

[Guest]

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.

 

[Jerry Coffin]

[ ... ]

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

Sort of true -- the C++ standard does explicitly include the headers
from the C standard that have a '.h' on them.

 

[Default User]

To use the class std::string

#include <string>

Note: string.h contains headers for the standard C (as opposed to
C++) string manipulation routines.

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>.





Brian

 

[Default User]

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.



Brian

 

[James Kanze]

[...]

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>.

 

[Ron Natalie]

Erik Wikström wrote:



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.

 

[Ron Natalie]

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.

 

[Default User]

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).

They are still C++ standard headers.




Brian

 

[ll]

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.

you can use it as follow:
#include<string>
using namespace std;

or
#include<string>
std::string str;//definition

Regards
Lung

 

[James Kanze]

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.)

 

[James Kanze]

James Kanze wrote:

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.)

 

[BobR]

James Kanze wrote in message...

/* """
(<cstdlib> is another story; none of the
compilers I have access to include the required overloads of
atexit, for example.)
""" */

I'm a little in-the-fog here [1].
// -------
In <cstdlib> (GCC(MinGW)3.3.1), after the #undefs:

namespace std {
// .....
using ::atexit;
// ..... }

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?
(short answer, if you can.<G> I'm just curious.)

[1] - ...still on first cup of coffee.

 

[Gavin Deane]

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.

Gavin Deane

 

[P.J. Plauger]

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.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com

 

[James Kanze]

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.)

 

[James Kanze]

James Kanze wrote in message...

/* """
(<cstdlib> is another story; none of the
compilers I have access to include the required overloads of
atexit, for example.)
""" */

I'm a little in-the-fog here [1].
// -------
In <cstdlib> (GCC(MinGW)3.3.1), after the #undefs:

namespace std {
// .....
using ::atexit;
// ..... }

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?

extern "C" int atexit(void (*f )(void))
extern "C++" int atexit(void (*f )(void))

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.)