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 Fri, 23 Jun 2006 20:08:35 GMT
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