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.

[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 , mann_math...@ya hoo.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.

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 <r...@spamcop.n etwrote:

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 objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[James Kanze]

On Jun 27, 1:37 pm, Ron Natalie <r...@spamcop.n etwrote:

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, <cstdlibinjec ts 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 objektorientier ter Datenverarbeitu ng
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(Mi nGW)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 <r...@spamcop.n etwrote:

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*********@ho tmail.comwrote in message
news:11******** **************@ q75g2000hsh.goo glegroups.com.. .

On 27 Jun, 12:37, Ron Natalie <r...@spamcop.n etwrote:

>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" <p...@dinkumwar e.comwrote:

"Gavin Deane" <deane_ga...@ho tmail.comwrote in message
news:11******** **************@ q75g2000hsh.goo glegroups.com.. .

On 27 Jun, 12:37, Ron Natalie <r...@spamcop.n etwrote:

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 objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[James Kanze]

On Jun 28, 7:44 pm, "BobR" <removeBadB...@ worldnet.att.ne twrote:

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(Mi nGW)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 objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]