similar to: How does Twine work?

Displaying 20 results from an estimated 10000 matches similar to: "How does Twine work?"

2011 Jul 24
2
[LLVMdev] Correct use of StringRef and Twine
On Jul 24, 2011, at 12:09 AM, David Blaikie wrote: >> Yes, exactly. I'm just saying that I think the additional clarity of: >> "foo" + Twine('x') >> >> is worth the inconvenience. > > Ok, attached a modified version of my patch with an Twine(char), > Twine(unsigned char), and Twine(signed char). All three are explicit & > have
2011 Jul 25
0
[LLVMdev] Correct use of StringRef and Twine
> Right, but that requires VS #ifdefs.  You can also use enum bitfields, but VS has different promotion rules from them than other compilers. Ah, I'd thought that feature (specifying the backing type with "enum name : integral_type") was standard, but I see it's a C++0x thing. My mistake. >> 1) the easy solution: create a StringRef subclass (or new type with a >>
2016 Apr 18
2
Redundant Twine->StringRef->Twine conversions in llvm::sys::fs::make_absolute?
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
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 19
0
[LLVMdev] Correct use of StringRef and Twine
On Jul 18, 2011, at 12:38 PM, David Blaikie wrote: > I'm attempting to do some amount of mass migration from const std::string& (& const char*) to StringRef. Great! > In doing so I stumbled across the fact that while StringRef has no op+ to speak of (well, it has += and I added a manual StringRef+std::string and std::string+StringRef for now - though I'm thinking perhaps
2011 Jul 18
3
[LLVMdev] Correct use of StringRef and Twine
I'm attempting to do some amount of mass migration from const std::string& (& const char*) to StringRef. In doing so I stumbled across the fact that while StringRef has no op+ to speak of (well, it has += and I added a manual StringRef+std::string and std::string+StringRef for now - though I'm thinking perhaps they can be skipped in favor of Twine operations), Twine does provide a
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
On Jul 21, 2011, at 12:00 AM, David Blaikie wrote: >> 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
2010 Apr 18
4
[LLVMdev] create two Twine object
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
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
2010 Apr 18
0
[LLVMdev] create two Twine object
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 AllocaInst(ReqTy, Twine("request") + Twine(varNum),
2010 Apr 18
1
[LLVMdev] create two Twine object
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
2011 Jul 24
0
[LLVMdev] Correct use of StringRef and Twine
> Yes, exactly.  I'm just saying that I think the additional clarity of: >  "foo" + Twine('x') > > is worth the inconvenience. Ok, attached a modified version of my patch with an Twine(char), Twine(unsigned char), and Twine(signed char). All three are explicit & have included test cases. Speaking of which - is there any LLVM dev policy or preference around
2011 Jul 19
3
[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. Yes, I noticed this - which was one of my concerns
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) >>
2012 Jul 31
0
[LLVMdev] rotate
Oh, no. I should have been more clear. The patch was not rejected, just lost in the daily shuffle. I already have my employer's approval to send this upstream, so I will prepare a patch against trunk this morning. > I proposed a similar patch to LLVM (left circular shift) around 10/2011. > > Parts of my patch did make it into trunk about a year after, but others > > did not.
2015 Dec 21
2
MSVC warning noise on "LLVM_ATTRIBUTE_ALWAYS_INLINE inline void foo()"
On Mon, Dec 21, 2015 at 12:08 AM, Aaron Ballman <aaron at aaronballman.com> wrote: > On Sun, Dec 20, 2015 at 5:57 PM, Johan Engelen <jbc.engelen at gmail.com> > wrote: > > > > Perhaps LLVM_ATTRIBUTE_ALWAYS_INLINE could be defined to "inline" if the > > compiler has no support for always_inline (currently it is set to > nothing in > > that
2012 Jul 31
4
[LLVMdev] rotate
On Monday, July 30, 2012 12:16 AM, Cameron McInally wrote: > Hey Andy, > > I proposed a similar patch to LLVM (left circular shift) around 10/2011. > Parts of my patch did make it into trunk about a year after, but others > did not. > > At that time, my solution was to add a binary operator to the IRBuilder, > since LCS fits in nicely with the other shift operators. But,
2011 Jul 19
0
[LLVMdev] Correct use of StringRef and Twine
> curiosity question: how much more efficient (vague question, I know) > is the StringRef + SmallVector than a good (eg: libc++) std::string > implementation? I know, for example, that Visual C++ 2010's > std::string does perform the small string optimization which I guess > is what SmallVector is doing. > > - David Problem is, there are REALLY bad std::string