On 16/11/17 11:39 +0000, Jonathan Wakely 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?
In other words, the ABI is not just the "frozen sizeof".
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
