Re: [boost] Heads up - string_ref landing

Subject: Re: [boost] Heads up - string_ref landing
From: Rob Stewart (robertstewart_at_[hidden])
Date: 2012-11-25 06:25:41

On Nov 23, 2012, at 7:17 AM, Olaf van der Spek <ml_at_[hidden]> wrote:

> On Fri, Nov 23, 2012 at 1:07 PM, Yakov Galka <ybungalobill_at_[hidden]> wrote:
>> Important point! Current wording does not require the string_ref to point
>> to a null terminated string. This (a) enables working with substrings, (b)
>> makes it unclear how it is better than iterator_range, and (c) does not
>> solve the problem for the fstream::fopen(const char*/std::string&) case.
>> 
>> Do you really think that trading (c) for (a) is a good idea?
> 
> Yes, I do. If you'd like to have a zstring_ref, you should write one. ;)
> 
> A string_ref that's not required to be null-terminated is far more useful.

+1

There are many use cases in which start + length/end, without expecting null termination is useful. In that design, substring is like an iterator pair with convenient string syntax.

That permits extracting an iterator pair, the length, a substring, etc. while offering concatenation and other common string operations, none of which require a null terminator. IOW, you get a useful and convenient subset of std::string's interface, plus substring support.

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.

___
Rob