Re: [boost] Heads up - string_ref landing

Subject: Re: [boost] Heads up - string_ref landing
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2012-11-25 07:30:09

On Sun, Nov 25, 2012 at 3:25 PM, Rob Stewart <robertstewart_at_[hidden]> wrote:
>
> There are times when a null terminated string is required. Legacy APIs are usually the problem. Thus, it is necessary to convert. A separate type for that is appropriate. If constructed from a null terminated string_ref, it can simply reference the string_ref's data. Otherwise, it can copy the data to the free store or use the SBO to avoid the allocation. There's no extra overhead with that approach (unless program logic allows you to omit the length and termination checks, but then you could just use a char const * directly). Whether you choose to make that conversion via a string_ref member function or a converting constructor of the other class is open for debate.

I must say I'm a little concerned by the fact that the number of
string types increases. If I design my library interface (let's assume
it doesn't use legacy APIs internally for now), what string type
should I use? I want my library to be used with any string type and I
don't want to provide overloads for all possible string types. It
would seem that string_ref is the answer, but I don't see any support
for third-party string types in it. I will be able to do this:

void foo(string_ref const&);

foo("hello");

string str;
foo(str);

But that is still not supported:

QString qstr;
foo(qstr);

string_literal lit = "Hello";
foo(lit);

If string_ref is nothing more than a pair of iterators with a few
additional member functions, I find iterator_range< const char* > much
more superior because it has the begin()/end() extension mechanism.
The member algorithms can easily be replaced with the general ones, so
they don't really add any value to string_ref. And if you add yet
another zstring_ref to that zoo, you're only making things worse.

If string_ref is to be proposed for inclusion (and yes, I would like
it to follow the common protocol for the new libraries and not
silently committed) the first thing I would like to know is how it is
better than iterator_range< const char* > and what problems it solves
that can't be solved with iterator_range. If there aren't any
significant advantages I'd prefer not to introduce yet another string
type.