This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [v3] more istream::ignore cleanups


>Sorry about that Benjamin, but I have been refininf and tweaking those 
>function
>both from the conformance and the performance point of views for months, you
>know! I'm going in vacations for just a few days and was *really* afraid of
>possible regressions.

yep, i understand now. have fun on your vacation!

>>It looks like, in these situations, _M_gcount should be set to
>>numeric_limits::max() here. Ie, in the LFS case, say delim is at max +
>>5, _M_gcount will not be set correctly (ie, not max().)
>>  
>>
>Indeed, we can have that, if we want: whatever we do is not strictly 
>speaking
>conforming since the number of extracted chars in principle should always
>match gcount and with LFS can be much bigger. The current (and recent)
>situation) gives the user more information (i.e. at least the "modulo" 
>of the
>total number of extracted chars) whereas returning max() is more clean. Let
>me think a little more about it: we can always set _M_gcount = max at the
>end if we eventually decide to do that, without changing the main loop.

feel free to pick this up after you get back. it makes sense to  not
rush something in before you go away!

it is my understanding that max(), not some modulo,  was the imperfect
solution that multiple people thought made the most sense in the
(admittedly) corner case. it's not great, but i think it at least
signals what is going on for people who care to look.

best,
benjamin


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]