incubator-stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Sebor <se...@roguewave.com>
Subject Re: test for lib.string.io
Date Tue, 20 Jun 2006 18:44:39 GMT
Anton Pevtsov wrote:
> Martin, I am working on the test for lib.string.io and there are several
> questions:

I'm not surprised ;-) The area of iostreams and locales are in
general less cleanly specified than the rest of the library.

> 
> 1. Shall we implement an our own locale class to exercise the >> and <<
> operators using it?

There is only one locale class and it cannot be replaced by
a user-defined one. You can customize the behavior of the class
by installing your own facets as replacements for the standard
ones in it. The only facet that affects the behavior of the string
I/O functions is ctype. It's fairly easy to replace the standard
ctype facet with your own:

     struct MyCtype: std::ctype<char> { /* ... */ };
     const std::locale myloc =
         std::locale (std::locale (), new MyCtype);
     std::istream strm;
     strm.imbue (myloc);

In the user-defined ctype facet it's important to override all
the virtual member functions that share the same behavior (in
our case both overloads of do_is(), do_scan_is(), as well as
do_scan_not()).

There are a number of iostream and locale tests with examples
of to do this.

> 
> 2. Small question about 21.3.7.9, paragraph 4:
> 
> "
> Effects: Begins by constructing a sentry object k as if k were
> constructed by typename basic_ostream<chart, thraits>::sentry k(os). If 
> bool(k) is true, inserts characters as if by calling
> os.rdbuf()->sputn(str.data(), n), padding as described in stage 3 of
> 22.2.2.2.2, where n is the larger of os.width() and str.size(); then
> calls os.width(0). If the call to sputn fails, calls
> os.setstate(iosbase::failbit).
> "
> 
> As I understand os.width(0) should be called if bool(k) is true only. I
> not sure, but Dinkumware STL from MSVC and STLPort does that while
> stdcxx calls os.with(0) in any case:
[...]
> Is this correct?

I believe your reading is correct: our behavior is wrong. Could you
open an issue please? (In your test case, please use the assert macro
to verify the postconditions.)

> The attached small test (iocheck.cpp) to illustrate this situation.
> 3. Another small question about 21.3.7.9 paragraph 4:
> 
> The stdcxx calls os.setstate(ios_base::badbit).

Hmmm, that would also be wrong. Badbit is typically set in response
to "bad" (i.e., unrecoverable) streambuf errors such as exceptions,
and failbit in response to the recoverable ones. Although I note
that the majority of implementations (including g++, IBM XLC++,
and MSVC) do set badbit as well.

OTOH, it's not clear that the behavior of your test case is wrong,
either. The string overload of operator<<) is required to set failbit
when the call to xsputn() fails but there doesn't seem to be any way
for the function to indicate failure (except by throwing an exception).
So strictly speaking the standard allows implementations to choose
whether to set failbit or leave it clear (depending on how they
interpret the value returned from xsputn).

That said, I think it makes sense to consider xsputn(s, n) as having
failed when it returns any value other than n (I sent an email to the
committee's reflector proposing this change -- see the attachment),
and for the inserter to set failbit in response to it.

Thanks
Martin

Mime
View raw message