Re: [Patch] Fix libstdc++/11722

[Paolo Carlini <pcarlini at suse dot de>]

Hi Nathan,

and, first, sorry for not having explained in detail these details of my 
code,
thus wasting at least part of your time.

> Sorry for being late with this, but isn't
>
> +	   if (__avail == 1)
> +	     *__s = *this->gptr();
> +	   else if (__avail > 1)
> +	     traits_type::move(__s, this->gptr(), __avail);
> +	   __s += __avail;
> +	   this->gbump(__avail);
> +	   __ret += __avail;
> +	   __n -= __avail;
>
> a bit too precious?
Definitely! But...

>  Maybe 
>
>  if (__avail != 0)
>    {
>      traits_type::copy(__s, this->gptr(), __avail);
>      __s += __avail;
>      this->gbump(__avail);
>      __ret += __avail;
>      __n -= __avail;
>    }
>
> This way it doesn't waste time checking __gptr < __egptr again
> when __avail == 1, and doesn't waste time adding zeroes to __s,
> __ret, and __n when __avail == 0.  A really smart optimizer 
> might do part of that transformation, but it seems clearer not 
> to depend on it.
>  
We have *very* consistent evidence that special casing the single char case
leads to much better performance (at least with the current optimizers):
remember the *impressive* improvement we got in basic_string

   http://gcc.gnu.org/ml/libstdc++/2004-04/msg00096.html

?
This leads to the most important source of "uglyness" in the code...

> We are at least certain that the target __s doesn't overlap the 
> buffer, so traits_type::copy suffices, and ought to be faster.
This is (even) more subtle: indeed, I wanted to use copy. Then, i considered
the possibility of a user provided buffer (via setbuf), which he can 
control and
access directly. In that case, as a matter of QoI, I think we should 
allow the user
to carry out some strange tricks, i.e., calling sgetn with a pointer inside
his setbuf-ed get area. That crazy user expects, I think, the semantics 
of move.
What do you think? Shall we allow that kind of weird code?

Thanks again for your feedback,
Paolo.