Why do so many new style ansi streams and files etc, still use old style strings?

Discussion in 'C++' started by Kza, Mar 3, 2006.

  1. Kza

    Kza Guest

    Hi, just in the process of maintaining some software that used some
    funy old string library and char*s , and we are updating everything to
    use std::strings. (or should I say std::basic_string<>s)

    I find it wierd that that all the new c++ ansi style librarys like the
    streams and file handling classes still expect us to use old style
    char* type strings. For example, ofstreams open function expects the
    filename as a char* parameter rather than a std::string, and the
    streams redirection operator << doesnt even work with std::strings but
    does with char*s.

    I would have expected the opposite, (or perhaps both types of strings
    are supported), in that std::strings are the native type of string for
    these new c++ style libs.

    Seems a bit like a case of not practicing what they are preaching "you
    should all use these new style strings, er unless of course you also
    need to use our other classes which still only support old style char*
    strings"
    I know its easy to solve with .c_str() but is there a reason for this?
    Kza, Mar 3, 2006
    #1
    1. Advertising

  2. Kza

    Pete Becker Guest

    Re: Why do so many new style ansi streams and files etc, still useold style strings?

    Kza wrote:
    > Hi, just in the process of maintaining some software that used some
    > funy old string library and char*s , and we are updating everything to
    > use std::strings. (or should I say std::basic_string<>s)
    >
    > I find it wierd that that all the new c++ ansi style librarys like the
    > streams and file handling classes still expect us to use old style
    > char* type strings. For example, ofstreams open function expects the
    > filename as a char* parameter rather than a std::string, and the
    > streams redirection operator << doesnt even work with std::strings but
    > does with char*s.


    Don't know which library you're using, but the standard requires a
    stream inserter for basic_string. If it's really not there, then the
    library doesn't conform.

    >
    > I would have expected the opposite, (or perhaps both types of strings
    > are supported), in that std::strings are the native type of string for
    > these new c++ style libs.


    const char *str = "abcd";
    const string str1("abcd");

    The first generates less code and uses less memory. Some people still
    care about those things.

    There is, though, a proposal to add functions taking string arguments in
    the 17 (if I remember correctly) places where there is just a char* version.

    --

    Pete Becker
    Roundhouse Consulting, Ltd.
    Pete Becker, Mar 3, 2006
    #2
    1. Advertising

  3. Kza wrote:
    > I find it wierd that that all the new c++ ansi style librarys like the
    > streams and file handling classes still expect us to use old style
    > char* type strings. For example, ofstreams open function expects the
    > filename as a char* parameter rather than a std::string,


    Yes, this is annoyance which came from two distinct sources, neither
    of which gives a satisfying reason:
    - There was original a certain desire not to couple the IOStreams
    library with the string library and possibly there could even have
    been a conversion operator from the string class to 'char const*'.
    - The IOStreams specification is older than the string specification
    and thus could not reasonably use any particular string class. It
    was apparently not properly updated.

    I think there is a "clean-up" proposal for various places like this
    at the committee which would be expected to make it into TR2 and
    into C++0x.

    > and the
    > streams redirection operator << doesnt even work with std::strings but
    > does with char*s.


    I'm not sure what you mean: there are both input and output operators
    taking 'std::string's as well as a special 'std::getline()' function
    also taking strings. These functions are just not members of the
    IOStream classes, nor should they: they are namespace level functions
    like the counterparts for the respective character type of the
    stream.

    > Seems a bit like a case of not practicing what they are preaching "you
    > should all use these new style strings, er unless of course you also
    > need to use our other classes which still only support old style char*
    > strings"


    This is true to some degree for the 'open()' methods in the various
    file stream classes. However, I would consider this to be a historical
    accident which happened while the people in the committee were busy
    getting other stuff right.
    --
    <mailto:> <http://www.dietmar-kuehl.de/>
    <http://www.eai-systems.com> - Efficient Artificial Intelligence
    Dietmar Kuehl, Mar 3, 2006
    #3
  4. Kza

    Rolf Magnus Guest

    Pete Becker wrote:

    > const char *str = "abcd";
    > const string str1("abcd");
    >
    > The first generates less code and uses less memory. Some people still
    > care about those things.


    The first probably generates no code at all. The second needs to construct a
    string object, which usually includes allocating dynamic memory (and on
    destruction giving it back) and copying the string data. On small embedded
    systems, this can make a significant difference, and C++ is supposed to be
    useful on such systems, too.
    Rolf Magnus, Mar 3, 2006
    #4
  5. "Kza" <> wrote in message
    news:...

    > I find it wierd that that all the new c++ ansi style librarys like the
    > streams and file handling classes still expect us to use old style
    > char* type strings.


    It is weird, but there is a reason for it: When the committee talked about
    the possibility of using std::string values to represent file names, the
    delegation from Japan requested that the committee consider only proposals
    that addressed both narrow and wide strings. In effect, they were asking
    "If you expand the standard to allow file names to be strings of European
    characters, we want it to allow strings of Japanese characters at the same
    time." This was an entirely reasonable request under the circumstances, and
    in response, the committee agreed not to define a mapping between strings
    and file names in the current standard.
    Andrew Koenig, Mar 3, 2006
    #5
    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. Pawel Banys
    Replies:
    1
    Views:
    485
    Joe Smith
    Jul 8, 2004
  2. Replies:
    0
    Views:
    366
  3. Mr. SweatyFinger
    Replies:
    2
    Views:
    1,766
    Smokey Grindel
    Dec 2, 2006
  4. Replies:
    1
    Views:
    476
  5. Replies:
    11
    Views:
    1,056
    Keith Thompson
    Apr 28, 2008
Loading...

Share This Page