On Thu, 16 Nov 2017 11:39:30 +0000 Jonathan Wakely <jwak...@redhat.com> wrote:
> On 16/11/17 14:35 +0300, Petr Ovtchenkov wrote: > >On Thu, 16 Nov 2017 10:56:29 +0000 > >Jonathan Wakely <jwak...@redhat.com> wrote: > > > >> On 10/10/17 22:55 +0300, Petr Ovtchenkov wrote: > >> >This reverts commit 0dfbafdf338cc6899d146add5161e52efb02c067 > >> >(svn r253417). > >> > >> I'm not even going to bother to review patches sent without any > >> explanation or rationale for the change. > > > >https://gcc.gnu.org/ml/libstdc++/2017-11/msg00044.html > > > >Along with "violate principles of C++ objects life cycle", > >the side-effect is > > > > - Make istreambuf_iterator::_M_sbuf immutable > > - streambuf_iterator: avoid debug-dependent behaviour > > > >I should underline, that "_M_sbuf = 0" when istreambuf_iterator > >see eof, lead to cripple lifecycle of istreambuf_iterator > >object and [almost] block usage of istreambuf_iterator > >for entities other then immutable files. > > > >All tests from 24_iterators and 25_algorithms passed, > >so I expect it conform to Standard. > > > >This is series of patches, not single patch because > >I keep in mind technology aspect---easy transfer > >to branches other then trunk. > > > >> > >> I will repeat what Paolo said: changing the ABI is not acceptable. > > > >I will repeat special for you: > > > ><snip> > >Is we really worry about frozen sizeof of instantiated template? > >(Removed private template member). > > > >If yes, than > > > > int_type __dummy; > > > >is our all. > ></snip> > > > >I.e. problem can be easy resolved---i.e. ABI will not suffer, if we will > > What about other translation units which have inlined the old > definition of the template, and expect to find a buffered character in > that member? I can say that I can write int_type _M_c; but you see, this is a _private_ member of template, so we should (may?) worry only about size of object. Just for clarification: Do you made accent on "buffered" or on "character" ("symbol" in ELF)? > > >reach some consensus on the main issue. > > We don't have any consensus, in fact I don't see anybody agreeing with > you, and I've previously stated I don't want to support your use case: > https://gcc.gnu.org/ml/libstdc++/2017-09/msg00100.html >
