Boost logo

Boost :

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

      


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk