search for: twines

...le non-concatenative case (all those callers who just pass in a straight string without any concatenation - the Twine then returns that string by value when str() is called, right?)? At the moment, if the lifetime works out & Twine can return a reference to a member (this would mean unrealized Twines would have a bunch of empty/spare std::strings lying around, but I expect those could be optimized away fairly reliably), that Twine would be strictly superior to StringRef & could be preferred in all cases, potentially even replacing/simplifying StringRef substantially. Thoughts? - David ---...

I'm looking at the documentation on Twine at http://llvm.org/docs/ProgrammersManual.html#llvm-adt-twine-h and it gives example code: void foo(const Twine &T); ... StringRef X = ... unsigned i = ... foo(X + "." + Twine(i)); How exactly does that last line work? Since addition is left associative, I would expect it to be parsed as (X + ".") ... so it's trying to add

...orary concatenation expression) wouldn't the Twine's internal storage live long enough to allow the caller to use that buffer within the life of the statement (as in, say, o << (aStringRef + "foo"))? This is really dangerous. I'd much rather extend raw_ostream to take twines. > This last one is probably the bigger question & relates to the other two. It seems like Twine is nice for cases where deferred concatenation is required & might be able to be avoided altogether - if the majority case is that the concatenation ends up being thrown away, you win. But a...

I need to generate variables like status1, status2, status3, ...... request1, request2, request3, ...... this is my code, other unrelated detail are eliminated. static int varNum; static const char *getVarNum() { ++varNum; std::stringstream ss; ss << varNum; std::string *varname = new std::string(ss.str()); return varname->c_str(); } const char *VarNum = getVarNum(); Twine *x1 = new

...ass, it's not easy to use efficiently & I don't think it'd be appropriate (correct me if I'm wrong) to go adding in temporary SmallVectors all over the place to try to consume Twine parameters in any code that needs to handle string contents after migrating the argument types to Twines. One place I experimented with fixing tonight (after trying broader goals - like changing all StringRef args in clang only, say) was to add a Twine(char) ctor to enable llvm::Triple's ctor to take Twines rather than StringRefs, and then do Twine op+ to build the Data member. The problem I see...

llvm::sys::fs::make_absolute converts its first parameter (const Twine &current_directory) to StringRef p(path.data(), path.size()), and then passes that StringRef to several functions (path::has_root_directory, path::has_root_name, and path::append) that accept Twines as parameters. Since llvm::StringRef can implicitly convert to an llvm::Twine, p converts to a bunch of Twine temporaries. In a few places, namely path::has_root_directory & path::has_root_name, that temporary Twine is again converted to a StringRef: bool has_root_directory(const Twine &p...

According to documentation Twines should be used only for temporary values and not stored, so allocating the in heap sounds wrong. I think all you need here is static int varNum; ++varNum; Instruction *sstatusInst = new AllocaInst(StatusTy, Twine("status") + Twine(varNum), entry_inst); Instruction *sreqInst = new Alloca...

On Sun, Apr 18, 2010 at 4:36 AM, Eugene Toder <eltoder at gmail.com> wrote: > According to documentation Twines should be used only for temporary > values and not stored, so allocating the in heap sounds wrong. Yes, in general you should never be naming Twine directly, except in the case where you need to make a Twine for an integer. All other uses should be considered poor style, as they are dangerously...

...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(SmallVecto...

...ingRef + "foo"))? > > This is really dangerous. Is it much/any more dangerous than Twine's existing functionality, though? Twine's already referring to temporaries & will break in fun ways if used outside that cliche. > I'd much rather extend raw_ostream to take twines. Certainly that covers this case, but I'm not sure how many different sinks there are that would need the nuanced efficient Twine handling code. Perhaps it's not many - though some easy way to do "stdStr = twine" would be great since quite often we want to take a string & put...

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

...sy to use efficiently & I > don't think it'd be appropriate (correct me if I'm wrong) to go adding > in temporary SmallVectors all over the place to try to consume Twine > parameters in any code that needs to handle string contents after > migrating the argument types to Twines. Are you concerned about the stack size of the smallvector's, or the amount of code that needs to be written? > One place I experimented with fixing tonight (after trying broader > goals - like changing all StringRef args in clang only, say) was to > add a Twine(char) ctor to enable...

...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 (pri...

I'm rewriting this patch for the stubs to not use outputing of raw text. Generating the instructions is very straightforward and that part is done. I'm translating the actual function now. How do you emit an .ent or .globl from asm printer? .type ? .end ?? .section ??? I'm studying the classes now but it should be simple to do so if you know, you can save me some time because this

...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...

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

Hi, I am trying to use some LLVM API in my C++ code, and I end up getting linker errors. I am working on Apple MacOSX Lion. Using g++ for the compile. It is the CreateGlobalStringPtr which is throwing the error. This is LLVM 3.0. Here's the codeI am trying to use some LLVM API in my C++ code, and I end up getting linker errors. I am working on Apple MacOSX Lion. Using g++ for the compile. It

On Thu, May 17, 2012 at 3:25 PM, Nick Kledzik <kledzik at apple.com> wrote: > I now have an implementation of FileOutputBuffer (OutputBuffer was already taken).  The patch supports the functionality listed below and I've tested that it works for lld. > > To implement the FileOutputBuffer, I needed to add some more functions to llvm/Support/FileSystem.h, including: >  

On Aug 17, 2012, at 2:50 AM, Paweł Bylica <pawel.bylica at ibs.org.pl> wrote: > On Fri, Aug 17, 2012 at 12:16 AM, Kaylor, Andrew <andrew.kaylor at intel.com> wrote: > Hi Paweł, > > > > Thanks for continuing this discussion. > > > > I like the simplicity of your suggestion. My only concern involves the ambiguity of what is meant by “environment”.

> 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