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.

[Lionel B]

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 <cstringrather than string.h.

--
Lionel B

[red floyd]

ma**********@yahoo.co.in 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.

Because <string.his 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.

[John Harrison]

ma**********@yahoo.co.in 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.

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

john

[=?UTF-8?B?RXJpayBXaWtzdHLDtm0=?=]

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 <cstringrather than string.h.

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

--
Erik Wikström

[Jerry Coffin]

In article <eh****************@newsb.telia.net>, Er***********@telia.com
says...

[ ... ]

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.

--
Later,
Jerry.

The universe is a figment of its own imagination.

[Default User]

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.

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]

On Jun 25, 6:36 pm, Lionel B <[e-mail]:

[...]

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

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Ron Natalie]

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.

[Ron Natalie]

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 <cstringbeing 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]

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

They are still C++ standard headers.


Brian

[ll]

On 6 26 , 12 15 , [e-mail] 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.

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

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

Regards
Lung

[James Kanze]

On Jun 27, 1:34 pm, Ron Natalie <[e-mail]:

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

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[James Kanze]

On Jun 27, 1:37 pm, Ron Natalie <[e-mail]:

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 <cstringbeing 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
<stringwhich is more or less conformant. In practice, I've
yet to see an implementation in which e.g. <cstdlibis
conformant.

The current draft has loosened the requirements considerably in
this respect; if it is accepted in the current state, most
implementations of <cstringwill become conformant, where they
aren't today. (<cstdlibis 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, <cstdlibinjects 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.)

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[BobR]

James Kanze wrote in message...

/* """
(<cstdlibis 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.<GI'm just curious.)

[1] - ...still on first cup of coffee.
--
Bob R
POVrookie

[Gavin Deane]

On 27 Jun, 12:37, Ron Natalie <[e-mail]:

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 <cstringbeing 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 <cstdiorather 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 <cxxxheaders. YMMV.

Gavin Deane

[P.J. Plauger]

"Gavin Deane" <de*********@hotmail.comwrote in message
news:11**********************@q75g2000hsh.googlegr oups.com...

On 27 Jun, 12:37, Ron Natalie <[e-mail]:

>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 <cstringbeing 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 <cstdiorather 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 <cxxxheaders. 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 <*.hvs <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]

On Jun 29, 12:40 am, "P.J. Plauger" <[e-mail]:

"Gavin Deane" <[e-mail] in message
news:11**********************@q75g2000hsh.googlegr oups.com...

On 27 Jun, 12:37, Ron Natalie <[e-mail]:

James Kanze wrote:

[...]

It's an example using <cstdiorather 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 <cxxxheaders. 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 <*.hvs <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 <cxxxheaders. 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 <cxxxheaders---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 (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[James Kanze]

On Jun 28, 7:44 pm, "BobR" <[e-mail]:

James Kanze wrote in message...

/* """
(<cstdlibis 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.)

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[P.J. Plauger]

"James Kanze" <ja*********@gmail.comwrote in message
news:11**********************@o61g2000hsh.googlegr oups.com...

On Jun 28, 7:44 pm, "BobR" <[e-mail]:

James Kanze wrote in message...

/* """
(<cstdlibis 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.)

[pjp] There you go again. Most of us implementors try to implement
what we think our customers want/need, as best we understand it.
Those of us who have merely implemented whatever we feel like have
fallen by the wayside.

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

[James Kanze]

On Jun 29, 3:47 pm, "P.J. Plauger" <[e-mail]:

"James Kanze" <[e-mail] in message

[pjp] There you go again. Most of us implementors try to implement
what we think our customers want/need, as best we understand it.
Those of us who have merely implemented whatever we feel like have
fallen by the wayside.

I think that's true for some of the smaller implementors, like
you or EDG. It's definitly not true of Microsoft or of G++;
both have their own programs, and expect (or force) the users to
go along. Most of the times, their programs aren't that bad,
because they do take into account the users' needs. But both
Microsoft and g++ seem to make a major point of ignoring export,
which I (and I suppose most other people working on large
projects) desparately need.

--
James Kanze (Gabi Software) email: ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[BobR]

James Kanze <ja*********@gmail.comwrote in message...
On Jun 28, 7:44 pm, "BobR" <[e-mail]:
/* """

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.
""" */

Thanks, James.

--
Bob R
POVrookie