Re: [boost] Heads up - string_ref landing

Subject: Re: [boost] Heads up - string_ref landing
From: Antony Polukhin (antoshkka_at_[hidden])
Date: 2012-11-16 03:52:37

2012/11/16 Andrey Semashev <andrey.semashev_at_[hidden]>:
> On November 16, 2012 10:27:33 AM Antony Polukhin <antoshkka_at_[hidden]>
> wrote:
>>
>> 2012/11/16 Yanchenko Maxim <maximyanchenko_at_[hidden]>:
>> > Marshall. low <mclow.lists. at> gmail.com> writes:
>> >
>> >> Please let me know what you think!
>> >
>> > As probably everyone, we have our own device for this.
>> > Here are some points and experience we gathered.
>> >
>> > 1. This class is essentially just an iterator_ range<char*> (modulo
>> > template for
>> > const/wchar_t), so it should either inherit from it or have
>> > corresponding converting
>> > ctors/operators. In this sense Olaf/Gennadiy's remarks are pretty valid.
>> > OTOH size
>> > is needed very frequently and having it precomputed is a good thing, so
>> > conversion
>> > approach seems to be better (but then we lose passing by reference as
>> > iterator_range, type_traits etc).
>> > I'm not sure what's more important.
>>
>> +1 for having corresponding explicit converting ctors/operators. (explicit or not?)
>
>
> As long as iterator_range uses the begin()/end() protocol and string_ref has
> the corresponding member functions it should work without any special
> constructors/operators, shouldn't it?

Yes, but constructing string_ref from iterator_range requires
additional constructor.

2012/11/16 Yanchenko Maxim <maximyanchenko_at_[hidden]>:
>
> See the difference:
>
> char s[20]="ab\0c";
> char_range(s);  // size 2 because of strlen inside, runtime
> char_range::literal( "ab\0c" ); // size 4, compile time
> char_range::from_array(s); // size 20, compile time
> char_range::from_array( "ab\0c" ); // size 5, compile time

Missed that difference at first time.

>>> approach seems to be better (but then we lose passing by reference as
>>> iterator_range, type_traits etc).
>>> I'm not sure what's more important.
>>
>> +1 for having corresponding explicit converting ctors/operators.
>
> Shouldn't they be implicit?
>
> void f(str_ref);
>
> string s = "Olaf";
> f(s);

Looks nice. And what about constructors from std::array?

BTW, I'd like to see a std::basic_string to_string()/str() and
std::array to_array()/array() member functions.

--
Best regards,
Antony Polukhin