Displaying 5 results from an estimated 5 matches for "twinestr".
Did you mean:
twines
2011 Jul 24
2
[LLVMdev] Correct use of StringRef and Twine
...ew type with a
> similarly expressive API) that wraps a buffer that it may or may not
> use. Give it a ctor that takes a Twine. The use case then goes from
> this:
>
> SmallVectorImpl<char> v;
> StringRef s = theTwine.GetStringRef(v);
>
> to this:
>
> TwineString s(theTwine);
>
> (& the ctor looks like: TwineString(const Twine& t) { *this =
> t.GetStringRef(this->buffer); })
> So any Twine sink now has to pay one line of code to get a usable
> string out of a Twine. Cheap to implement, easy to fix existing use
> cases (priva...
2011 Jul 25
0
[LLVMdev] Correct use of StringRef and Twine
...ressive API) that wraps a buffer that it may or may not
>> use. Give it a ctor that takes a Twine. The use case then goes from
>> this:
>>
>> SmallVectorImpl<char> v;
>> StringRef s = theTwine.GetStringRef(v);
>>
>> to this:
>>
>> TwineString s(theTwine);
>>
>> (& the ctor looks like: TwineString(const Twine& t) { *this =
>> t.GetStringRef(this->buffer); })
>> So any Twine sink now has to pay one line of code to get a usable
>> string out of a Twine. Cheap to implement, easy to fix existing us...
2011 Jul 24
0
[LLVMdev] Correct use of StringRef and Twine
...asy solution: create a StringRef subclass (or new type with a
similarly expressive API) that wraps a buffer that it may or may not
use. Give it a ctor that takes a Twine. The use case then goes from
this:
SmallVectorImpl<char> v;
StringRef s = theTwine.GetStringRef(v);
to this:
TwineString s(theTwine);
(& the ctor looks like: TwineString(const Twine& t) { *this =
t.GetStringRef(this->buffer); })
So any Twine sink now has to pay one line of code to get a usable
string out of a Twine. Cheap to implement, easy to fix existing use
cases (privatize GetStringRef(SmallVectorI...
2011 Jul 23
2
[LLVMdev] Correct use of StringRef and Twine
On Jul 22, 2011, at 2:59 PM, David Blaikie wrote:
>> The dangerous part of this is that characters are integers, so "foo" + 'x' is very likely to cause serious problems.
>
> std::string already provides such overloads though, doesn't it? So the
> code isn't any safer from accidental "foo" + 'x' expressions that
> don't include
2011 Jul 26
1
[LLVMdev] Correct use of StringRef and Twine
On Jul 24, 2011, at 6:31 PM, David Blaikie wrote:
>>> This keeps things simple & seems to be "good enough" to me, but we
>>> could perhaps do better (at the very least, again, if we did do
>>> better, we could go back & remove TwineString & again fix all the
>>> places that fail to compile with whatever new hotness we invent)
>>
>> This definitely seems like a step forward. While it is kinda gross, a subclass of StringRef is probably the lowest friction path to do this.
>
> Come to think of it -...