incubator-stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anton Pevtsov <ant...@moscow.vdiweb.com>
Subject Re: Re: test for lib.string.io
Date Wed, 21 Jun 2006 15:35:43 GMT
<>Martin Sebor wrote:

 >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 jira issue opened: 
http://issues.apache.org/jira/browse/STDCXX-205

Here is another one possible issue:

As I understand 21.3.7.9, paragraph 4 the os.setstate() should be called
after os.width(0). In stdcxx width(0) is called after the setstate() and
if the exceptions mask is not ios_base::goodbit then width(0) will not
called. The Dinkumware STL and STLPort calls width (0) before
setstate().

incubator\stdcxx\trunk\include\ostream

// 21.3.7.9, p3 - defined here, declared inline in <string>
template<class _CharT, class _Traits, class _Allocator> inline
basic_ostream<_CharT, _Traits>&
operator<< (basic_ostream<_CharT, _Traits>                  & __strm,
            const basic_string<_CharT, _Traits, _Allocator> &__str) {
    _RW::__rw_insert (__strm, __str.data (), __str.length (),
                      __strm.width ()).width (0);
    return __strm;
}

See the attached test, please.

What do you think about this?


Thanks,
Anton Pevtsov


-----Original Message-----
From: Martin Sebor [mailto:sebor@roguewave.com] 
Sent: Tuesday, June 20, 2006 22:45
To: stdcxx-dev@incubator.apache.org
Subject: Re: test for lib.string.io


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