Re: [boost] [string] proposal

Subject: Re: [boost] [string] proposal
From: Artyom (artyomtnk_at_[hidden])
Date: 2011-01-29 02:02:38

> 
> > 1. "Contiguity" 
> > 
> >     Continuity and c_str() is one of the most important
> >     properties of C++ string (that is BTW required by C++0x)
> 
> Eliminating c_str() doesn't mean  there's no easy way to produce a
> contiguous NTBS.
> 

Yes, just it can't be really "char const *c_str() CONST" or would require
extra stuff like linearization.

It would turn away 90% of users.

> > 3.  non-uniform-memory-architecture 
> >    
> >    Give  me a break... Who uses NUMA for string processing?!
> 
> Anyone running on a  multiprocessor system with AMD Opterons or Intel
> Nehalem or Tukwila  processors.  You don't always get to choose the
> kind of architecture  your code will run on, and those systems are all
> NUMA.  But even when  you do get to choose, some very large problems
> that would be appropriate to  NUMA involve lots of strings.
> 

1. The locality of cache or private processor cache
   does not makes them "NUMA"
2. In such case it would be even better to have non-shared
   strings

> > 4. About string builder. Most  languages require is as they
> >    don't have "reserve" also if  you want efficient
> >    string builder use std::ostream with  nice stream buffer.
> 
> There's nothing efficient about std::ostream, no  matter what buffer
> you put on it.
> 

I beg your pardon? It is efficient as all functions
are as efficient as memcpy with exceptions of overflow/underflow
happens which require some virtual functions calls
which are pretty fast as well...

Also 99% of issues are just solved with reserve.
(and I work with text parsing, combining and processing a lot)

> 
> > 6. Encoding is extrinsic to strings
> >     
> >    ?!?!?!
> > 
> >    All the  discussion in started because we need UTF-8
> >    in strings now  we are back to the beginning?
> 
> This, I believe, is a persistent  misunderstanding.  IIUC, Dean is only
> suggesting to avoid giving UTF-8  any special status in the string's
> interface.  He's not arguing against  using UTF-8 storage in the
> implementation.
> 

The entire "buzz" started with the fact that under windows
we have problems with string encoding not being UTF-8

> > This is classic  example of how trying to do something
> > "cool" gives us theoretically  interesting and cool things
> > that are useless in real world where simple  and straight
> > forward things actually work a way better.
> 
> That may  ultimately turn out to be true, but your reaction here seems
> so over-the-top  and premature as to make that conclusion very
> unconvincing.
> 

This article written from wrong understanding of real
problems - instead of solving a problem it suggests
some idea for some cases not looking to the problem
in hole.

Starting from "std::string is broken" statement...

Artyom