[PATCH 1/4] Revert "2017-10-04 Petr Ovtchenkov <ptr@void-ptr.info>"

Jonathan Wakely jwakely@redhat.com
Thu Nov 16 11:39:00 GMT 2017


On 16/11/17 14:35 +0300, Petr Ovtchenkov wrote:
>On Thu, 16 Nov 2017 10:56:29 +0000
>Jonathan Wakely <jwakely@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?

>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



More information about the Libstdc++ mailing list