This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] basic_filebuf: 45628 + non-modal I/O


Hi,

> Which case? Throwing from imbue?

What we just committed, 45628 + seeks.

> Fair nuff. The elimination of _M_reading/writing was something I anticipated to have a high
> risk/reward ratio in the first placeâ maybe that affected my approach to it.

Sure, but note that the idea itself of reusing two data members with a different semantics isn't straightforward at all, would be probably the first time *ever* we do something similar. Even if we believe it should be fine for the instantiations for char / wchar_t, which are exported extern template.

> Although the basic
> change is mostly accomplished with a search+replace to substitute the function calls for data
> members, the secondary changes had a surprising cascade effect. Caching always_noconv
> alters the invariants of _M_codecvt. The semantics of _M_post_overflow are unsatisfactory
> considering exceptions, so right now I'm working on changing it to _M_need_unshift. That is
> also potentially cleaner, but upon trying to debug it, I got hit with a testcase failures, including
> an imbue testcase! (Diagnosing that right now.)

In general a clean-up reusing the new _M_get_ext seems a sensible and moderately safe idea at this stage.

> As I said before embarking on this round, and again in the last message, there are other
> things to do. There are a number of tangible benefits to having overflow preserve any
> unwritten part of the put area, including the standard specifically requiring it. So I'll try to wrap
> this up, post it to the list for posterity, and we can revisit this cluster later.

I'm all eyes ;)

Paolo


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]