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: test for lib.string.io
Date Mon, 26 Jun 2006 15:50:49 GMT
Martin Sebor wrote:
> But before committing the rest we need to first settle the issue of
rw_expand().

Martin, in my previous mail I didn't mention that the problem occur when
rw_expand is called from the rw_match function.
Sorry about that. The test which illustrates the problem is here:
http://people.apache.org/~antonp/stdcxx06262006/rwmatch_rwexpand_test.cp
p


Martin Sebor wrote:
[...]
> I plan to write up an issue against the standard and propose the
consistent behavior that makes sense to me but in the meantime we need
to decide whether to pedantically follow the current   > requirements
(and make changes where we don't), whether to implement the proposed
behavior, or whether to leave things alone. Any suggestions?

The possible fix of the STDCXX-206 and STDCXX-205 is here
http://people.apache.org/~antonp/stdcxx06262006/lib/
It required changes in several places:

For fix issue 205 call strm.width(0) should be called after check

if (bool(sentry))
{
    ...
    strm.width(0);
}


For fix issue 206 call strm.width(0) should be called before call 

strm.setstate(newstate);

The function 

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)

all work performs using another function

_EXPORT
template<class _CharT, class _Traits, class _StringT>
_STD::basic_ostream<_CharT, _Traits>& __rw_insert
(_STD::basic_ostream<_CharT, _Traits> &__strm,
             const _StringT                       *__s,
             _RWSTD_STREAMSIZE                     __len,
             _RWSTD_STREAMSIZE                     __width)

And after a call __rw_insert it's call strm.width(0);

So for fix the issues need:
1. copy code from __rw_insert to operator<< and then modify according to
issue requirements

Or

2. move call strm.width(0) to inside __rw_insert and add additional
information on necessity of a call of strm.width(0) (because __rw_insert
used in many other places like operater<<(istream&, char), ...)

I implemented variant 2:

__rw_insert now have additional argument bool __zerowidth, by default is
false and doesn't change behaviour of function in those places where it
is called without explicit definition of the value __zerowidth.

_EXPORT
template<class _CharT, class _Traits, class _StringT>
_STD::basic_ostream<_CharT, _Traits>& __rw_insert
(_STD::basic_ostream<_CharT, _Traits> &__strm,
             const _StringT                       *__s,
             _RWSTD_STREAMSIZE                     __len,
             _RWSTD_STREAMSIZE                     __width,
             bool                                  __zerowidth/* =
false*/)

then I put next lines right after of characters insertion code

            if (__zerowidth)
                __strm.width (0);

then I put next lines right after of characters insertion code and added
check that the I/O operation was successful.

            if (__zerowidth && __err == _STD::ios_base::goodbit)
                __strm.width (0);

And at last I changed 

// 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;
}

To the

// 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) {
    return _RW::__rw_insert (__strm, __str.data (), __str.length (),
                             __strm.width (), true);
}

The same changes may be needed in other overloads of the operator<< for
streams.

What do you think about this?

New test version updated according the fix above is here:
http://people.apache.org/~antonp/stdcxx06262006/


Thanks,
Anton Pevtsov


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


Anton Pevtsov wrote:
> The first version of the test with the required changes to 21.string.*

> and rw_streambuf.h is here: 
> http://people.apache.org/~antonp/stdcxx06232006/

Wow, this looks very good! It will need more comments but we can add
those later. I suspect I might be in a good position to suggest some
since I'm not familiar with the code and I'm trying to understand how it
works :)

> Also there is a small change to char.cpp to allowing the strings 
> ending with '\0' expanding.

I see it but as I mentioned in my previous replies I don't think the len
argument is correct there. I'll need to better understand where the
problem is (as I said, a test case would help).

> 
> The test generates asserts due to STDCXX-206 and problem with 
> ios_base::badbit / failbit.

I have been thinking about STDCXX-206 and the general issue of when
width(0) should be called. My feeling is that width should only be reset
if the I/O operation completes successfully. I.e., when there is no
indication of an error and when no exception is thrown. This is slightly
different from what the standard requires but I think it makes more
sense than the current (inconsistent) requirements where width(0) is
supposed to be unconditionally called in some cases (before any I/O) and
in others only when there hasn't been an exception (but regardless of
whether the I/O operation was successful or not).

I plan to write up an issue against the standard and propose the
consistent behavior that makes sense to me but in the meantime we need
to decide whether to pedantically follow the current requirements (and
make changes where we don't), whether to implement the proposed
behavior, or whether to leave things alone. Any suggestions?


> Also there is a question about exception safety:
> 
> If exceptions mask == ios_base::goodbit then operator>>, operator << 
> and getline hides all exceptions thrown inside function. The 
> Dinkumware does the same, but STLPort doesn't. Is this correct?

The general policy for how to deal with exceptions in iostreams
(outlined briefly in 27.6.1.1, p4) is that all exceptions should be
caught and swallowed unless badbit is set in exceptions(). This policy
is reinforced in the common requirements on formatted and unformatted
I/O functions (27.6.1.2.1, 27.6.1.2.3, 27.6.2.5.1, and 27.6.2.6).

Since both operator>> and getline() are explicitly required to behave as
formatted and unformatted input functions, respectively, they must
follow the policy (i.e., STLport fails to conform). The case of
operator<< for string is less clear since it doesn't contain the same
requirement, but it seems pretty clear to me that it should (I can't
think of any reason why not and so far no one on the committee has come
up with one either).

> 
> 
> During the test implementation I found that there is a problem with 
> test linking on Windows, 11d and 15d configurations: "unresolved 
> external symbol "public: static struct __rw::__rw_mutex 
> __rw::__rw_synchronized::_C_mutex"
> I investigate the problem and found that this member of 
> __rw_synchronized structure is not marked as _RWSTD_EXPORT. The 
> possible fix to this issue is here (differeces to files 
> include/rw/_mutex.h and src/exception.cpp): 
> http://people.apache.org/~antonp/stdcxx06232006/lib/
> What do you think about this?

The fix looks good, please go ahead and commit it.

But before committing the rest we need to first settle the issue of
rw_expand().

Martin

Mime
View raw message