Displaying 5 results from an estimated 5 matches for "twinetmpbuff".
Did you mean:
twinetmpbuffer
2011 Jul 22
0
[LLVMdev] Correct use of StringRef and Twine
...he Twine -
> the code needing to read the individual character elements) would be
> responsible for allocating a temporary SmallVectorImpl, passing that
> in, getting a StringRef & then using that for its work.
Right. Something like this could work:
foo(const Twine &T) {
...
TwineTmpBuffer Tmp;
StringSwitch(T.toString(Tmp)).....
Which doesn't seem too horrible, just needs a typedef of smallvector to TwineTmpBuffer.
> Another example of a string sink is, say, tools/llvmc/src/Hooks.cpp. I
> found this while looking for uses of "+= '-'" to use the char...
2011 Jul 21
4
[LLVMdev] Correct use of StringRef and Twine
> And for arguments, generally always use Twine as the default, it allows construction of complex things, and is still efficient when passed the equiv of a StringRef (with the toStringRef method). The only annoying thing about it is that the API to do this requires a temporary SmallVector to scribble in, which makes it more difficult to use.
>
> It seems that there should be a good way
2011 Jul 22
0
[LLVMdev] Correct use of StringRef and Twine
> 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 Twine/StringRef/std::string than it was before. But if
the argument is that
2011 Jul 22
2
[LLVMdev] Correct use of StringRef and Twine
On Jul 21, 2011, at 12:30 AM, David Blaikie wrote:
>> [diff attached]
>
> Updated diff with test fix. (since this broke a test (printing chars
> as numerical values, rather than characters) it's possible this change
> is a bad idea & it could break the product code itself. Though
> strangely I wasn't able to do character concatenation without my
> change, so I
2011 Jul 23
2
[LLVMdev] Correct use of StringRef and Twine
...e by design but weren't clear to me)
No problem at all, happy to help answer the questions. Forcing a reexamination of past decisions is not a bad thing at all in this case :)
>> Right. Something like this could work:
>>
>> foo(const Twine &T) {
>> ...
>> TwineTmpBuffer Tmp;
>> StringSwitch(T.toString(Tmp)).....
>>
>> Which doesn't seem too horrible, just needs a typedef of smallvector to TwineTmpBuffer.
>
> In a few choice places, maybe, but as the default way to pass string
> parameters I think that'd be a hard sell as a g...