<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Tue, Nov 29, 2016 at 8:32 AM Malcolm Parsons <<a href="mailto:malcolm.parsons@gmail.com">malcolm.parsons@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 29 November 2016 at 16:18, Zachary Turner <<a href="mailto:zturner@google.com" class="gmail_msg" target="_blank">zturner@google.com</a>> wrote:<br class="gmail_msg">
> I don't like the llvm_strlen approach as it is incompatible with<br class="gmail_msg">
> std::string_view which we may eventually move to.<br class="gmail_msg">
<br class="gmail_msg">
In what way is it incompatible?<br class="gmail_msg">
<br class="gmail_msg">
constexpr StringRef(const char* s) : Data(s), Length(llvm_strlen(s)) {}<br class="gmail_msg">
is equivalent to<br class="gmail_msg">
constexpr string_view(const char* s) : Data(s),<br class="gmail_msg">
Length(std::char_traits<char>::length(s)) {}<br class="gmail_msg"></blockquote><div><br></div><div>I see, but I looked over your proposed implementation from earlier in the thread, and if I'm not mistaken I see this:</div><div><br></div><div><span style="color:rgb(33,33,33);font-size:13px">     /// Construct a string ref from a cstring.</span><br class="gmail_msg" style="color:rgb(33,33,33);font-size:13px"><span style="color:rgb(33,33,33);font-size:13px">     LLVM_ATTRIBUTE_ALWAYS_INLINE</span><br class="gmail_msg" style="color:rgb(33,33,33);font-size:13px"><span style="color:rgb(33,33,33);font-size:13px">+#if __has_builtin(__builtin_strlen</span><span style="color:rgb(33,33,33);font-size:13px">)</span><br class="gmail_msg" style="color:rgb(33,33,33);font-size:13px"><span style="color:rgb(33,33,33);font-size:13px">+    /*implicit*/ constexpr StringRef(const char *Str)</span><br class="gmail_msg" style="color:rgb(33,33,33);font-size:13px"><span style="color:rgb(33,33,33);font-size:13px">+        : Data(Str), Length(Str ? __builtin_strlen(Str) : 0) {}</span><br class="gmail_msg" style="color:rgb(33,33,33);font-size:13px"><span style="color:rgb(33,33,33);font-size:13px">+#else</span><br class="gmail_msg" style="color:rgb(33,33,33);font-size:13px"><span style="color:rgb(33,33,33);font-size:13px">     /*implicit*/ StringRef(const char *Str)</span><br class="gmail_msg" style="color:rgb(33,33,33);font-size:13px"><span style="color:rgb(33,33,33);font-size:13px">         : Data(Str), Length(Str ? ::strlen(Str) : 0) {}</span><br class="gmail_msg" style="color:rgb(33,33,33);font-size:13px"><span style="color:rgb(33,33,33);font-size:13px">+#endif</span> </div><div><br></div><div>So we've got a constexpr constructor if __builtin_strlen exists, and a non-constexpr constructor if it doesn't exist.  This seems like a recipe for disaster for me.  You can't ever construct one in a constexpr context, because not all compilers will have a constexpr constructor, and if you can't construct one in a constexpr context, then the __builtin_strlen() wouldn't work as expected either, right?</div><div><br></div><div>I like making it explicit via a StringLiteral class because then everyone's code looks the same:</div><div><br></div><div>constexpr StringLiteral Strings[] = {"a", "b", "c"};<br></div><div><br></div><div>That said, what did you think about my other proposal of the complicated UDL with macro?</div><div><br></div><div>#define LIT(x) x_string_ref_literal</div><div>constexpr StringRef Strings[] = {LIT("a"), LIT("b"), LIT("c")};</div></div></div>