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

[Kza]

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?

[Pete Becker]

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.

[Dietmar Kuehl]

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:di***********@yahoo.com> <http://www.dietmar-kuehl.de/>
<http://www.eai-systems.com> - Efficient Artificial Intelligence

[Rolf Magnus]

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.

[Andrew Koenig]

"Kza" <kz****@gmail.com> wrote in message
news:11*********************@u72g2000cwu.googlegro ups.com...

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.