Re: We have got a problem... (Re: [RFC] Strive to prefer)

[Matt Austern <austern at apple dot com>]

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