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
> > 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
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
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
Starting from "std::string is broken" statement...
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk