string class problem

Discussion in 'C++' started by mann_mathann@yahoo.co.in, Jun 25, 2007.

  1. Guest

    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.
    , Jun 25, 2007
    #1
    1. Advertising

  2. red floyd Guest

    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.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.
    red floyd, Jun 25, 2007
    #2
    1. Advertising

  3. Lionel B Guest

    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.

    --
    Lionel B
    Lionel B, Jun 25, 2007
    #3
  4. 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 <string> not <string.h>

    john
    John Harrison, Jun 25, 2007
    #4
  5. 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.

    --
    Erik Wikström
    =?UTF-8?B?RXJpayBXaWtzdHLDtm0=?=, Jun 25, 2007
    #5
  6. Jerry Coffin Guest

    In article <ehSfi.2912$>,
    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.
    Jerry Coffin, Jun 25, 2007
    #6
  7. Default User Guest

    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, Jun 25, 2007
    #7
  8. Default User Guest

    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
    Default User, Jun 25, 2007
    #8
  9. James Kanze Guest

    On Jun 25, 6:36 pm, Lionel B <> wrote:

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

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
    James Kanze, Jun 26, 2007
    #9
  10. Ron Natalie Guest

    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, Jun 27, 2007
    #10
  11. Ron Natalie Guest

    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, Jun 27, 2007
    #11
  12. Default User Guest

    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
    Default User, Jun 27, 2007
    #12
  13. ll Guest

    On 6 26 , 12 15 , 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
    ll, Jun 27, 2007
    #13
  14. James Kanze Guest

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

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
    James Kanze, Jun 28, 2007
    #14
  15. James Kanze Guest

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

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
    James Kanze, Jun 28, 2007
    #15
  16. BobR Guest

    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.
    --
    Bob R
    POVrookie
    BobR, Jun 28, 2007
    #16
  17. Gavin Deane Guest

    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.

    Gavin Deane
    Gavin Deane, Jun 28, 2007
    #17
  18. P.J. Plauger Guest

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

    P.J. Plauger
    Dinkumware, Ltd.
    http://www.dinkumware.com
    P.J. Plauger, Jun 28, 2007
    #18
  19. James Kanze Guest

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

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
    James Kanze, Jun 29, 2007
    #19
  20. James Kanze Guest

    On Jun 28, 7:44 pm, "BobR" <> wrote:
    > 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.)

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
    James Kanze, Jun 29, 2007
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Mladen Adamovic
    Replies:
    0
    Views:
    723
    Mladen Adamovic
    Dec 4, 2003
  2. Purush
    Replies:
    4
    Views:
    1,606
    Purush Rudrakshala
    Apr 13, 2005
  3. E11
    Replies:
    1
    Views:
    4,710
    Thomas Weidenfeller
    Oct 12, 2005
  4. christopher diggins
    Replies:
    16
    Views:
    731
    Pete Becker
    May 4, 2005
  5. Joseph Turian
    Replies:
    5
    Views:
    576
Loading...

Share This Page