Re: [boost] Heads up - string_ref landing

Subject: Re: [boost] Heads up - string_ref landing
From: Jeffrey Yasskin (jyasskin_at_[hidden])
Date: 2012-12-12 18:49:18

On Mon, Dec 10, 2012 at 3:36 PM, Vicente J. Botet Escriba
<vicente.botet_at_[hidden]> wrote:
> Le 10/12/12 22:16, Jeffrey Yasskin a écrit :
>
>> On Wed, Nov 28, 2012 at 2:48 AM, Rob Stewart <robertstewart_at_[hidden]>
>> wrote:
>>>
>>>    o char const (&)[N]
>>
>> This constructor is dangerous in cases like
>>
>>    char space[100];
>>    snprintf(space, 100, "format", args);
>>    string_ref str(space);
>>
>> so I think most of the suggestions on this list have moved toward a more
>> explicit but very verbose string_ref::from_literal("foo\0bar").
>
> I guess this is because the proposed Boost interface should work on C++98
> compilers. This doesn't mean that it could not provide something more
> adapted to C++11.

I'm thinking largely in terms of the C++14 proposal, and it sounds
like you're saying that, if we target >=C++11, then a UDL would
satisfy your want for an array-length-deducing "constructor"?

I recognize that Boost probably needs to do something to support C++98
users, although maybe that should be "pass in a length if your literal
contains a \0."

>> http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2012/n3468.pdf proposed
>> adding various user-defined literals to the standard library. What do you
>> folks think of string_ref UDLs like:
>>
>> namespace boost {
>> namespace string_literals {
>> #define BOOST_DEFINE_STRING_REF_LITERAL(CharT) \
>>    constexpr basic_string_ref<CharT> operator"" _s( \
>>        const CharT* str, size_t len) { \
>>      return basic_string_ref<CharT>(str, len); \
>>    }
>> BOOST_DEFINE_STRING_REF_LITERAL(char);
>> BOOST_DEFINE_STRING_REF_LITERAL(wchar_t);
>> BOOST_DEFINE_STRING_REF_LITERAL(char16_t);
>> BOOST_DEFINE_STRING_REF_LITERAL(char32_t);
>> #undef BOOST_DEFINE_STRING_REF_LITERAL
>> }
>> }
>>
>> using namespace boost::string_literals;
>> constexpr boost::string_ref glbl = "Constexpr"_s;
>> constexpr boost::string_ref contains_null = "Const\0expr"_s;
>> static_assert(contains_null.at(6) == 'e',
>>                "Expect string to extend past null");
>> static_assert(glbl.size() == sizeof("Constexpr") - 1,
>>                "Expect string to omit trailing null");
>>
>> (Tested with Clang r163674)
>>
>> ?
>>
> I think that the suffix _s is used also for seconds. Can both be used
> without ambiguity?
> If not, is _str too long for a suffix for strings?

_s can be used for both. See [lex.ext] for the lookup rules, but 123_s
is looked up as operator"" _s(unsigned long long) or template<char
Digit...>operator"" _s() or operator"" _s(const char*), while "123"_s
is looked up as operator"" _s(const char*, size_t). IIRC, there was
some nervousness in the committee about using that to distinguish, but
N3468 seems to say that they resolved this in Portland in favor of
using 's' for both string and seconds.

(Note that I disagree with that paper about using the 's' UDL to
return non-constexpr types, but I can hash that out with the
committee. I'm mostly asking this list about whether any UDL spelling
would remove the desire for an explicit array constructor.)

Thanks,
Jeffrey