We have got a problem... (Re: [RFC] Strive to prefer)
Matt Austern
austern@apple.com
Thu Apr 22 22:31:00 GMT 2004
On Apr 22, 2004, at 3:19 PM, Paolo Carlini wrote:
> Pétur Runólfsson wrote:
>
>> while (!_Traits::eq_int_type(__c, _Traits::eof()))
>> {
>> const size_t __n = __sbin->egptr() - __sbin->gptr();
>> if (__n > 1)
>> {
>> const char_type* p = traits_type::find(__sbin->gptr(),
>> __n, __delim);
>> if (p)
>> __n = p - __sbin->gptr();
>> __str.append(__sbin->gptr(), __n);
>> __sbin->gbump(__n);
>>
> Hi again Pétur.
>
> istream::getline(char_type*, streamsize, char_type) is almost ready and
> indeed, is very fast: in the corresponding test from 15002 we obtain
> the
> same speed of stdio! Great! Thanks again: tomorrow will post the patch.
>
> However, we have got a serious problem with getline(istream, string)
> (and
> ws, operator>>(istream, string)): gptr() and egptr() are *protected*,
> sigh!
> Can you see a way out? I can't, right now...
There is a way out: have streambuf declare those functions as friends.
Note, by the way, that there's an annoying technicality here.
basic_streambuf<> can and should declare basic_istream<> and getline<>
as friends. However, basic_istream<> and getline<> can't take
advantage of that in general. Rationale: basic_istream<> knows that
the primary template for basic_streambuf is a friend, but it has no
reason to think that a user specialization grants friendship to anyone.
The upshot of this is that whenever we're doing an optimization that
involves nonpublic members of basic_streambuf, we need two versions:
the fast version, which takes advantage of friendship and which only
works for char and wchar_t, and the slow version that goes through the
public interface. It means more code and more testing, since we have
to maintain two versions. In practice, of course, only a tiny fraction
of people will ever use the slow version.
--Matt
More information about the Libstdc++
mailing list