Re: [boost] Heads up - string_ref landing

Subject: Re: [boost] Heads up - string_ref landing
From: Rob Stewart (robertstewart_at_[hidden])
Date: 2012-11-26 05:23:22

On Nov 25, 2012, at 7:30 AM, Andrey Semashev <andrey.semashev_at_[hidden]> wrote:

> 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.
> 
> I must say I'm a little concerned by the fact that the number of
> string types increases.

That's a valid concern, but note that we already have a great many types in this realm: char *, std::string, plus third party types.

> If I design my library interface (let's assume it doesn't use legacy APIs internally for now), what string type should I use?

std::string is appropriate, unless you care about copies and free store allocations, in which case, we're suggesting string_ref.

> I want my library to be used with any string type and I don't want to provide overloads for all possible string types.

That's an impossible order, unless you add compile-time dispatching to your code, and then "all possible string types" means as many as you care to support. boost::string_ref can be extended similarly, but that would never work for std::string_ref.

> 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);

It can also support iterator pairs and even std::vector<char>.

> But that is still not supported:
> 
> QString qstr;
> foo(qstr);

As above.

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

Why this type?

> 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.

That forces every call to extract or compute an iterator range, which is less convenient and more error prone.

> The member algorithms can easily be replaced with the general ones, so they don't really add any value to string_ref.

I agree that member versus free is a matter of syntax except for subscripting. (There may be more exceptions, but that one occurred to me.) Subscripting isn't critical, but certainly is convenient and string-like.

> And if you add yet another zstring_ref to that zoo, you're only making things worse.

It's only for the times when null termination is required. The two types could even be the same class template with different termination policies.

> 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.

How'd I do?

___
Rob