Re: [boost] Heads up - string_ref landing

Subject: Re: [boost] Heads up - string_ref landing
From: Sergey Cheban (s.cheban_at_[hidden])
Date: 2012-12-12 15:58:40

12.12.2012 20:02, Rob Stewart пишет:

>>>>>>> - 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.
Ok. What about boost::lexical_cast? There is no 
lexical_cast<unsigned>(const string_ref &) yet but there already is 
lexical_cast<unsigned>(bool). So, lexical_cast<unsigned>( 
string_ref("5") ) will return 1.

>>>> 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?
Ok, let it be string_ref. :-)
The boost classes may extend the standard interfaces and they often do 
it. But I think that there is some reason why std::string interface does 
not include operator bool.

>>>>>> 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.
Ok, I agree that pop() without push() looks inconsistent and so I don't 
insist on it.

>>>> 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 what will use operators <, <=, == etc. to compare string_refs if 
there is no compare() method? Ok, each of them may compare the 
string_refs directly.

>>>>>> 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.
You said that the Boost library should not use the "substring" name for 
the class that represents (but does not own) a part of the existing 
string because you already use this name for the class with the same 
meaning in your private code. For me, this sounds strange. If the name 
"substring" is good for you, why boost::substring is bad for the similar 
class in the Boost library?

>>>> 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.
For me, "substring" is just an alternative name of string_ref. The 
string_ref looks worse for me because:
1. It is not a kind of C++ reference.
2. It is not related to the std::string.
So, both parts of the name "string_ref" are misleading.

-- 
Best regards,
Sergey Cheban