On Thu, 16 Nov 2017 18:40:08 +0100 François Dumont <frs.dum...@gmail.com> wrote:
> On 16/11/2017 12:46, Jonathan Wakely wrote: > > On 16/11/17 10:57 +0000, Jonathan Wakely wrote: > >> On 16/11/17 08:51 +0300, Petr Ovtchenkov wrote: > >>> On Mon, 6 Nov 2017 22:19:22 +0100 > >>> François Dumont <frs.dum...@gmail.com> wrote: > >>> > >>>> Hi > >>>> > >>>> Any final decision regarding this patch ? > >>>> > >>>> François > >>> > >>> https://gcc.gnu.org/ml/libstdc++/2017-11/msg00036.html > >>> https://gcc.gnu.org/ml/libstdc++/2017-11/msg00035.html > >>> https://gcc.gnu.org/ml/libstdc++/2017-11/msg00037.html > >>> https://gcc.gnu.org/ml/libstdc++/2017-11/msg00034.html > >> > >> It would be helpful if you two could collaborate and come up with a > >> good solution, or at least discuss the pros and cons, instead of just > >> sending competing patches. > > > > > > Let me be more clear: I'm not going to review further patches in this > > area while you two are proposing different alternatives, without > > commenting on each other's approach. > > > > If you think your solution is better than François's solution, you > > should explain why, not just send a different patch. If François > > thinks his solution is better than yours, he should state why, not > > just send a different patch. > > > > I don't have time to infer all that from just your patches, so I'm not > > going to bother. > > > > > Proposing to revert my patch doesn't sound to me like a friendly action > to start a collaboration. I'm already say that this is technical issue: this patch present only in trunk yet. Series is more useful for applying in different branches. BTW, https://gcc.gnu.org/ml/libstdc++/2017-11/msg00037.html was inspired by you https://gcc.gnu.org/ml/libstdc++/2017-10/msg00029.html > > My only concern has always been the Debug mode impact which is now fixed. I hope I'm suggest identical behaviour for Debug and non-Debug mode (no difference in interaction with associated streambuf). > > I already said that I disagree with Petr's main goal to keep eof > iterator linked to the underlying stream. Ok. > So current implementation is > just fine to me and I'll let Petr argument for any change. Please, clear for me: what is the "current implementation"? Is it what we see now in trunk? > @Jonathan, > You can ignore my last request to remove mutable keywork on _M_sbuf. > > François > > -- - ptr
