similar to: [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

> 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

> 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

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

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

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

> 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

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

> 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

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

> [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 have a sneaking suspicion that while the test passed, it didn't actually expose

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

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

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),

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

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

> 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

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

Hi, sys::fs::create_directories() recurses infinitely for relative paths with only one directory or where the first directory in path doesn't exist. This was observed in r153176. Example: #include <llvm/Support/FileSystem.h> using namespace llvm; int main(int argc, char *argv[]) { bool existed; error_code ec = sys::fs::create_directories(Twine("log"), existed);

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. -------------- next part -------------- A non-text attachment was scrubbed... Name: FileOutputBuffer.patch Type: application/octet-stream Size: 25308 bytes Desc: not available URL: