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

[Devang Patel]

OK. I'll update how DebugInfo uses StringRef.
-
Devang
On Oct 12, 2009, at 7:02 AM, Daniel Dunbar wrote:

> 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/22234047/attachment.html>