search for: twine

...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 variety of handy op+ implementations that get picked up mostly for free. A few questions from this: * When should a StringRef parameter type be preferred over a const Twine& parameter type? * Would it be OK to implement an implicit conversion from Twine to st...

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

...ing& (& 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 they can be skipped in favor of Twine operations), Twine does provide a variety of handy op+ implementations that get picked up mostly for free. Yeah, I don't think we want to support + on StringRef without going through Twine. > A few questions from this: > > * When should a StringRef parameter type be preferred over a...

...est2, 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 Twine(StringRef("status"), VarNum); // 1 Twine *x2 = new Twine(StringRef("request"), VarNum); // 2 Instruction *sstatusInst = new AllocaInst(StatusTy, *x1, entry_inst); // 3 Instruction *sreqInst = new AllocaInst(ReqTy, *x2, entry_inst); //...

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

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

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

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

> 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 C-style ca...

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

...aracters 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 std::string's interface was poorly > designed/unsafe & we can do better/safer, I'm OK with making the ctor > explicit as you've suggested. Yes, exactly. I'm just saying that I think the additional...

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 use. &g...

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 included test cases. Ok, great. > Speaking of which - is there any L...

...d be simple to do so if you know, you can save me some time because this is another maze of llvm data abstraction. Tia. Reed void MipsAsmPrinter::EmitFPCallStub( const char* Symbol, const Mips16HardFloatInfo::FuncSignature* Signature) { OutStreamer.EmitRawText("\t.globl "+ Twine(Symbol)); ......... OutStreamer.EmitRawText("\t# Stub function to call " + Twine(RetType) + " " + Twine(Symbol) + " (" + Twine(Parms) + ")"); OutStreamer.EmitRawText("\t.section\t.mips16.call.fp"+Twine(Symbol)+",\&...

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

...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 this case to the common Twine use cases. > Perhaps only explicitly invoking the Twine ctor would've got the > char-as-number behavior previously) > <twine_triple.diff> The dangerous part of this is that characters are integers, so "foo" + 'x' is very likely to cause serious problems. This...

...Constant*, llvm::ArrayRef<llvm::Value*>)in ccFB7xjg.o "llvm::GetElementPtrInst::getIndexedType(llvm::Type*, llvm::ArrayRef<llvm::Value*>)", referenced from: llvm::GetElementPtrInst::GetElementPtrInst(llvm::Value*, llvm::ArrayRef<llvm::Value*>, unsigned int, llvm::Twine const&, llvm::Instruction*)in ccFB7xjg.o "llvm::PointerType::get(llvm::Type*, unsigned int)", referenced from: llvm::GetElementPtrInst::GetElementPtrInst(llvm::Value*, llvm::ArrayRef<llvm::Value*>, unsigned int, llvm::Twine const&, llvm::Instruction*)in ccFB7xjg.o...

...>   is_writable_file() >   is_executable_file() >   set_file_executable() For these parts I would like to follow http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3365.html#TOC which is what the rest of the fs library is modeled after. So we would use: error_code permissions(const Twine &path, perms p); If the name is confusing (it says nothing about modification) I'm fine with modify_permissions or something similar. >   unique_file_sized() Instead of adding this I would much rather add resize_file and call it after unique_file. >   map_file_pages() >   unmap...

...ENT > > > > 2. Add an llvm::Triple::ObjectFormatType enum with all llvm-supported object formats. > > 3. Remove “MachO” from the llvm::Triple::EnvironmentType enum. > > 4. Add the following methods to llvm::Triple: > > > > Triple(const Twine &ArchStr, const Twine &VendorStr, const Twine &OSStr, const Twine &ObjFmtStr) > > Triple(const Twine &ArchStr, const Twine &VendorStr, const Twine &OSStr, const Twine &ObjFmtStr, const Twine &EnvStr) > > bool hasExplicitObjectFormat() const > &g...

...t 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 std::string's interface was poorly designed/unsafe & we can do better/safer, I'm OK with making the ctor explicit as you've suggested. > You should also probably add a ctor for signed/unsigned char as well (wh...