[llvm-commits] [llvm] r83082 - /llvm/trunk/include/llvm/ADT/StringRef.h

[Daniel Dunbar]

Yes, this isn't something that should be in StringRef, I would go so  
far to say this is an invariant clients can rely on:
--
StringRef(a).data() == a
--

As Chris mentions we want the StringRef constructors to be simple, we  
use them a lot and rely on the optimizer to clean them up, for example  
in default arguments. It's good to avoid any unnecessary complexity.

  - Daniel

On Sep 29, 2009, at 9:59 PM, Chris Lattner wrote:

> On Sep 29, 2009, at 11:57 AM, Devang Patel wrote:
>> On Sep 29, 2009, at 11:53 AM, Chris Lattner wrote:
>>> On Sep 29, 2009, at 11:39 AM, Devang Patel wrote:
>>> Author: dpatel
>>>> Date: Tue Sep 29 13:39:56 2009
>>>> New Revision: 83082
>>>>
>>>> URL: http://llvm.org/viewvc/llvm-project?rev=83082&view=rev
>>>> Log:
>>>> Create empty StringRef is incoming cstring is NULL.
>>>
>>> I don't think this is correct, StringRef shouldn't allow null  
>>> cstrings to be passed in.
>>
>> I'm using it to pass optional strings. For example, linkage name in  
>> debug info.
>> Note, one can create empty StringRef by say
>> 	SringRef foo;
>> If this is not desirable then I'll update DebugInfo interface.
>
> The reason I mention that is that stringref is frequently used for  
> const char*'s, and this adds an extra branch to the common case.   
> Doing something like:
>
>   return ptr != 0 : StringRef(ptr) : StringRef();
>
> in the debug info stuff would make it pay the cost locally instead  
> of making all clients of stringref pay it.
>
> What do you think Daniel?
>
> BTW, getting rid of std::string from debug info is really really  
> awesome!
>
> -Chris
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20091012/40c3e90d/attachment.html>