Re: [boost] [string_ref] Feature requests

Subject: Re: [boost] [string_ref] Feature requests
From: Daniel James (dnljms_at_[hidden])
Date: 2012-12-29 12:33:35

On 29 December 2012 16:56, Marshall Clow <mclow.lists_at_[hidden]> wrote:
>
> On Dec 29, 2012, at 6:33 AM, Daniel James <dnljms_at_[hidden]> wrote:
>
>> and there are a few missing features that might be useful:
>>
>> Construction from a pair of iterators, either
>> std::basic_string::const_iterator, or
>> boost::basic_string_ref::const_iterator. Which of course can be the
>> same type, which is annoying but not too hard to work around.
>
> Hrm.
> Given a pair of iterators (first, last),
>         how do you ensure that the range [first, last) is contiguous in memory?
>
> If you (the caller) know that, then you can construct thus:
>         string_ref (&*first, std::distance(first, last))

This is technically more dangerous, as it will work for
std::list<char>. There's also the risk of using different variables
for 'first' (and yes, I did exactly that).

If I wasn't clear enough, I'm not suggesting supporting arbitrary
iterators. Just std::basic_string::const_iterator and
boost::basic_string_ref::const_iterator. I suppose I should have
included raw char pointers as well.

> but how would a string_ref constructor know that?

How does your existing constructor know that the length doesn't overflow?

>> Easy conversion to std::basic_string. There's a C++11 explicit string
>> operator, but that isn't much good for portable code. Something like a
>> 'string' or 'to_string' member would do the trick.
>
> Makes all kinds of sense.
> However, this is problematic in C++03.
>
> I tried:
>         template<typename Allocator = std::allocator <charT> >
>         std::basic_string<charT, traits, Allocator> to_string () const
>                 { return std::basic_string<charT, traits, Allocator> ( ptr_, len_ ); }
>
> But that doesn't work, because you can't have default template arguments in functions.

I wouldn't expect support for arbitrary allocators. Olaf pointed out
std::to_string which doesn't seem to support such things. But if you
must have support, how about returning a type which is implicitly
convertible to std::basic_string?

>> Support for comparisons with std::basic_string. The comparison
>> operators are templates so they aren't called with an implicit
>> conversion. Could use a template parameter for the type so that it
>> picks up anything which is (implicitly?) convertible to
>> boost::basic_string_ref, maybe using SFINAE.
>
> I like this idea.  I'll have to think about the best way to do it.
>
> What happens if the basic_string has a different type_traits class than the string_ref?
> How do they compare then? [ Of course, that could happen with two different instantiations
> of std::basic_string today, so that's probably a solved problem.  ]

I wouldn't support that. You can't compare strings with different
char_traits, and such strings aren't convertible to
boost::basic_string_ref.