Subject: Re: [boost] [string] proposal
From: Dave Abrahams (dave_at_[hidden])
Date: 2011-01-28 16:01:07
At Fri, 28 Jan 2011 12:26:59 -0800 (PST),
> I'm sorry but this "document" full of mistakes
> and misses serious points:
I don't think sarcasm is warranted here. It most certainly is a
> 1. "Contiguity"
> Continuity and c_str() is one of the most important
> properties of C++ string (that is BTW required by C++0x)
> Reason: c_str() is a boundary to almost every library
> existing in C++ and C world. So removing this "bad" feature
> makes it useless for vast majority of string users.
> Note: all strings around in all languages are continuous for
> the reasons.
Eliminating c_str() doesn't mean there's no easy way to produce a
> 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.
> 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.
> Don't copy paradigms that do not belong to C++!
So we have nothing to learn from other languages?
> 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
> 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
-- Dave Abrahams BoostPro Computing http://www.boostpro.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk