J
jimreesma
To the appropriate committee folks,
The current proposed resolution of issue #309
(http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#309) is
unacceptable. I write commerical software and coding around this
makes my code ugly, non-intuitive, and requires comments referring
people to this very issue. Following is the full explanation of my
experience.
In the course of writing software for commercial use, I constructed
std::ifstream's based on user-supplied pathnames on typical POSIX
systems.
It was expected that some files that opened successfully might not read
successfully -- such as a pathname which actually refered to a
directory. Intuitively, I expected the streambuffer underflow() code
to throw an exception in this situation, and recent implementations of
libstdc++'s basic_filebuf do just that (as well as many of my own
custom streambufs).
I also intuitively expected that the istream code would convert these
exceptions to the "badbit' set on the stream object, because I had not
requested exceptions. I refer to 27.6.1.1. P4.
However, this was not the case on at least two implementations -- if
the first thing I did with an istream was call operator>>( T& ) for T
among the basic arithmetic types and std::string. Looking further I
found that the sentry's constructor was invoking the exception when it
pre-scanned for whitespace, and the extractor function (operator>>())
was not catching exceptions in this situation.
So, I was in a situation where setting 'noskipws' would change the
istream's behavior even though no characters (whitespace or not) could
ever be successfully read.
Also, calling .peek() on the istream before calling the extractor()
changed the behavior (.peek() had the effect of setting the badbit
ahead of time).
I found this all to be so inconsistent and inconvenient for me and my
code design, that I filed a bugzilla entry for libstdc++. I was then
told that the bug cannot be fixed until issue #309 is resolved by the
committee.
Jim Rees
ITA Software, Inc.
The current proposed resolution of issue #309
(http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#309) is
unacceptable. I write commerical software and coding around this
makes my code ugly, non-intuitive, and requires comments referring
people to this very issue. Following is the full explanation of my
experience.
In the course of writing software for commercial use, I constructed
std::ifstream's based on user-supplied pathnames on typical POSIX
systems.
It was expected that some files that opened successfully might not read
successfully -- such as a pathname which actually refered to a
directory. Intuitively, I expected the streambuffer underflow() code
to throw an exception in this situation, and recent implementations of
libstdc++'s basic_filebuf do just that (as well as many of my own
custom streambufs).
I also intuitively expected that the istream code would convert these
exceptions to the "badbit' set on the stream object, because I had not
requested exceptions. I refer to 27.6.1.1. P4.
However, this was not the case on at least two implementations -- if
the first thing I did with an istream was call operator>>( T& ) for T
among the basic arithmetic types and std::string. Looking further I
found that the sentry's constructor was invoking the exception when it
pre-scanned for whitespace, and the extractor function (operator>>())
was not catching exceptions in this situation.
So, I was in a situation where setting 'noskipws' would change the
istream's behavior even though no characters (whitespace or not) could
ever be successfully read.
Also, calling .peek() on the istream before calling the extractor()
changed the behavior (.peek() had the effect of setting the badbit
ahead of time).
I found this all to be so inconsistent and inconvenient for me and my
code design, that I filed a bugzilla entry for libstdc++. I was then
told that the bug cannot be fixed until issue #309 is resolved by the
committee.
Jim Rees
ITA Software, Inc.