On 29 December 2012 16:56, Marshall Clow <mclow.lists@gmail.com> wrote:
On Dec 29, 2012, at 6:33 AM, Daniel James <dnljms@gmail.com> 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.