[PATCH] More implicit typename fixes

[Nathan Myers]

On Fri, Dec 21, 2001 at 11:58:51PM +0100, Paolo Carlini wrote:
> Nathan Myers wrote:
> 
> > On Fri, Dec 21, 2001 at 10:44:29PM +0100, Paolo Carlini wrote:
> > >       typedef typename ctype::mask  mask;       <====== 169
> >
> > That doesn't look spurious to me.  I suspect (without looking)
> > that what's wanted is
> >
> >       typedef typename __ctype_abstract_base<_CharT>::mask  mask;
> 
> Thanks for your feedback. In fact, as you may have noticed from my
> previous fix for a similar problem in stl_rope.h, this is the kind of
> typedef I'm tempted to use ;-)
> 
> However, the new parser likes also typedef typename ctype::mask mask
> (checked a moment ago). Is that legal too? I'm tempted to think so.

Actually, looking deeper, it would be better just to use 

  typedef ::std::ctype_base::mask  mask;

or maybe even

  using ctype_base::mask;

if it works.

> By the way, what's your opinion on my basic_string::insert work?
> For sure, when inserting in the middle of a very long string the
> performance improvement is hardly noticeable, but on the other hand
> it seems to me difficult ;-) to do better and I would like to see a
> consistent implementation across append-assign-insert-replace...

I agree, I like your work.

It's too bad that C++ is stuck with such a primitive string design.
The Java people learned from our mistakes (this time -- in so many
other cases they made mistakes we avoided!).  It may be that for the
next C++ Standard we can come up with an improved interface.

The idea is to have two classes, one designed for substring manipulation
and another for transport.  Ability to share storage of substrings with 
one of the latter would be no bad thing, too.

Nathan Myers
ncm at cantrip dot org