Thread View: comp.std.c++
3 messages
3 total messages
Started by Kresimir Fresl
Thu, 28 Mar 1996 13:22
fstream constructors and strings
Author: Kresimir Fresl
Date: Thu, 28 Mar 1996 13:22
Date: Thu, 28 Mar 1996 13:22
44 lines
2638 bytes
2638 bytes
Why are there no ifstream and ofstream constructors that take a
std::string rather than plain char* for the ``file name''?
The following `idiom' was, I think, often used (I use `S', and not `s',
because this is not a proposed standard string class):
cout >> "Enter file name -> ";
String file_name;
ifstream (file_name); // or: ofstream (file_name);
Declaring file_name as String, instead of char[file_name_length],
one does not have to worry about reserving space for file name
(file_name_lengths are very different on different operating systems).
The call to istream/ostream constructor is possible because String
classes use to have:
String::operator const char*() const
According to proposed standard one should write:
ifstream (file_name.c_str());
because implicit conversion of string to const char* is not defined.
I agree that implicit conversion is (almost always) dangerous, and I
_do not_ propose to add conversion operator to string class. Instead, I
think that fstream classes, beside (or even instead of) constructors that
take const char*s, should have constructors that take strings.
In many C++ books we can read that plain C arrays (including char[]s
and char*s) are to low level, and that we should use vector and string
classes. Also, it is supposed that iostream classes and operators are
`on the higher level of abstraction' than cstdio types and functions.
So, why do we have to manualy convert `high level constructs' to `low
level constructs'?
Kresimir Fresl
Faculty of Civil Engineering, Zagreb, Croatia
fresl@master.grad.hr
---
[ comp.std.c++ is moderated. To submit articles: try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ FAQ: http://reality.sgi.com/employees/austern_mti/std-c++/faq.html ]
[ Policy: http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu ]
Re: fstream constructors and strings
Author: Andrew Bell
Date: Mon, 01 Apr 1996 18:39
Date: Mon, 01 Apr 1996 18:39
26 lines
1893 bytes
1893 bytes
Kresimir Fresl <fresl@master.grad.hr> wrote:
>According to proposed standard one should write:
> ifstream (file_name.c_str());
>because implicit conversion of string to const char* is not defined.
>I agree that implicit conversion is (almost always) dangerous, and I
>_do not_ propose to add conversion operator to string class.
Is there an explanation for why implicit conversion (at least to char
*) is dangerous? It doesn't seem to me that requiring the member
function call is that much safer, although admittedly it is easier to
grep for. However, the added complexity of code w/o a conversion
operator seems like it would add almost as many problems.
I checked out the std.c++ faq, and I've read the lang.c++ faq not too
long ago, and I didn't see a reference to this in either.
Andrew Bell
abell@mindspring.com
---
[ comp.std.c++ is moderated. To submit articles: Try just posting with your
newsreader. If that fails, use mailto:std-c++@ncar.ucar.edu
comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
Comments? mailto:std-c++-request@ncar.ucar.edu
]
Re: string conversion to char*
Author: Nathan Myers, http://www.cantrip...
Date: Tue, 02 Apr 1996 19:11
Date: Tue, 02 Apr 1996 19:11
39 lines
2577 bytes
2577 bytes
Andrew Bell wrote:
>
> Kresimir Fresl <fresl@master.grad.hr> wrote:
> >According to proposed standard one should write:
> > ifstream (file_name.c_str());
> >because implicit conversion of string to const char* is not defined.
> >
> >I agree that implicit conversion is (almost always) dangerous, and I
> >_do not_ propose to add conversion operator to string class.
> Is there an explanation for why implicit conversion (at least to char
> *) is dangerous? It doesn't seem to me that requiring the member
> function call is that much safer, although admittedly it is easier to
> grep for. However, the added complexity of code w/o a conversion
> operator seems like it would add almost as many problems.
Member c_str() is safer because the person who calls it knows it
is being called. The problem with implicit conversions is less that
they are hard to grep for, but rather that they are often invoked
accidentally and invisibly.
If an implicit conversion were provided, the pointer would inevitably
be passed to contexts in which its limited lifetime would not be kept
track of, resulting in unreliable programs. It would be nearly impossible
to find these bugs, because the cause of the bug literally does not appear
in the code.
The extra text ".cstr()" does not add to complexity; the complexity is
present regardless. It only makes the complexity visible.
Nathan Myers
ncm@cantrip.org http://www.cantrip.org/
---
[ comp.std.c++ is moderated. To submit articles: Try just posting with your
newsreader. If that fails, use mailto:std-c++@ncar.ucar.edu
comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
Comments? mailto:std-c++-request@ncar.ucar.edu
]
Thread Navigation
This is a paginated view of messages in the thread with full content displayed inline.
Messages are displayed in chronological order, with the original post highlighted in green.
Use pagination controls to navigate through all messages in large threads.
Back to All Threads