search for: twinetmpbuffer

Displaying 5 results from an estimated 5 matches for "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 s...
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 gen...