On Sun, 8 Oct 2017 16:59:39 +0200 François Dumont <frs.dum...@gmail.com> wrote:
> ... > >>> We have three issues with istreambuf_iterator: > >>> - debug-dependent behaviour > >> Fixed. > > + __glibcxx_requires_cond(_M_sbuf, > > _M_message(__gnu_debug::__msg_inc_istreambuf) > > ._M_iterator(*this)); > > vs > > > > + __glibcxx_requires_cond(_M_sbuf && !_S_is_eof(_M_sbuf->sgetc()), > > _M_message(__gnu_debug::__msg_inc_istreambuf) > > ._M_iterator(*this)); > > > > and > > > > + __glibcxx_requires_cond(_M_sbuf > > + && > > !traits_type::eq_int_type(_M_c,traits_type::eof()), > > _M_message(__gnu_debug::__msg_inc_istreambuf) > > ._M_iterator(*this)); > > vs > > > > + __glibcxx_requires_cond(_M_sbuf && !_S_is_eof(_M_sbuf->sgetc()), > > _M_message(__gnu_debug::__msg_inc_istreambuf) > > ._M_iterator(*this)); > > > > I'm insist on the first variant. It free from code that may lead to > > different > > behaviour between debug/non-debug (like _M_sbuf->sgetc()). > > The first patch fixed the impact of the Debug mode on the > istreambuf_iterator state. This kind of difference is classical with > Debug mode, this mode usually introduces additional calls to some > operators or in this case to sgetc. > The key is "_M_sbuf->sgetc()" and "_S_is_eof" that may call ->sgetc() too. This may lead to difference in debug/non-debug behaviour. Solution without such difference exist and was presented here.
