Re: [boost] Heads up - string_ref landing

Subject: Re: [boost] Heads up - string_ref landing
From: Rob Stewart (robertstewart_at_[hidden])
Date: 2012-12-12 11:02:36

On Dec 12, 2012, at 9:05 AM, Sergey Cheban <s.cheban_at_[hidden]> wrote:

> On 12.12.2012 1:47, Rob Stewart wrote:
> 
>>>>>> - safe bool or explicit bool conversion operator
>>>>> I don't think this is a good idea.
>>>> Why not?
>>> This seems to be not intuitive and not so safe.
>> It is quite intuitive to me. true means non-null, and false means null.
> If the basic_substring<T> was convertible to bool, it would be used to compare basic_substring<char> with basic_substring<wchar_t> (with meaningless results).

It would not be meaningless. Though certainly not the likely intent. Still, all that's needed are equality operators between the types to poison the flawed comparison.

>>> The std::string has no such operator.
>> Why does that matter? It's still convenient. It would be a nice addition to std::string.
> I think that the substring class should be consistent with the existing standard string interface. If you think that the operator bool is a good addition to the [sub]string you may propose it to the standard commitee.

We're discussing string_ref, not substring. Furthermore, why can't string_ref have a feature before string gets it?

>>>>> What about pop_back(), pop_front(), swap()?
>>>> string_ref isn't a container, so pop_back() and pop_front() are inappropriate. However, back(), front(), and swap() are reasonable.
>>> It is not a container (i.e., it does not own the content) but pop_* methods still may remove the characters from it.
>> They wouldn't remove characters, they would only "forget" them. The semantic is sufficiently different that I don't think I would find them intuitive.
> What is the difference? The substring does not own the characters anyway.

As I said, without ownership, they don't seem semantically valid.

>>> Btw, there also are [r]find*(), r[c]begin()/r[c]end() and compare() groups of methods in the std::basic_string.
>> I don't think of string_ref as so complete an analogue to string. I see such things as the purview of a substring class, though that's purely subjective.
> Why not? For example, it may be used as a key in some temporary std::map.

What's your point? map uses < by default.

>>>>> And again, I propose "substring" instead of "string_ref".
>>>> I also have [const_]substring classes which have a different interface, so I disagree. (There is, of course, some overlap.)
>>> 1. Are these classes in the Boost library and/or namespace?
>> No. They are my own classes which I've not proposed to Boost.
> I respect your needs but I don't think that it is a good idea for the Boost library to avoid using convenient names just because these names are used by somebody who uses the boost namespace implicitly.

I don't understand how your comment applies.

>>> 2. Do these classes do a different job, or they just have a different interface?
>> They reference a std::string and operate on a subset of the string's characters. The have special constructors and replicate most of string's interface.
> It seems that you may just switch to the boost::substring and get rid of your substring implementation some day.

Of course, but there isn't one and this discussion is about string_ref.

___
Rob