12 Dec
2012
12 Dec
'12
4:02 p.m.
On Dec 12, 2012, at 9:05 AM, Sergey Cheban <s.cheban@drweb.com> 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