<div><span style="font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)">> Why? [ I'm not opposed to making the change, but I don't see a difference ]</span></div><span style="font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)">I actually just did some tests and with optimization on there is no difference between the two. Actually the static one is less desirable because it emits a symbol into the object file.</span><div>
<span style="font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)">The case that I was (mistakenly) thinking of is when these declarations happen in the global scope. The [] version "bakes" the string literal into the object file, so to say. That is, the thing reference by that symbol is the array. Whereas for the pointer, the thing referenced by that symbol is actually a pointer, which in turn references the an array that is allocated separately, which costs an extra indirection when using the variable. However, as a local, it doesn't matter since there is no pointer symbol.</span></div>
<div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">Also, there's a surprisingly subtle discussion of the difference here:</font></div><div><a href="http://stackoverflow.com/questions/9460260/what-is-the-difference-between-char-a-string-and-char-p-string">http://stackoverflow.com/questions/9460260/what-is-the-difference-between-char-a-string-and-char-p-string</a><font face="arial, sans-serif"><br>
</font><div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">--Sean Silva<br></font><br><div class="gmail_quote">On Tue, Jun 12, 2012 at 9:45 PM, Marshall Clow <span dir="ltr"><<a href="mailto:mclow.lists@gmail.com" target="_blank">mclow.lists@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><div class="im"><div>On Jun 12, 2012, at 8:39 PM, Sean Silva wrote:</div><br>
<blockquote type="cite">what's the deal with this my_pair business? Either use std::pair or leave a comment explaining why you did this. I suspect it has to do with POD-ness and static initializers? if so, call it pod_pair.</blockquote>
<div><br></div></div>Yes, it has to do with POD-ness.</div><div>pod_pair is a better name.</div><div><div class="im"><br><blockquote type="cite"><div>Even better, you can probably get away with having one struct type with int or unsigned (whichever signedness enum values have by default) as their first member, and avoid having a bunch of bit-identical instantiations of std::map for all these different types.</div>

<div><br></div><div>You should see whether the maps are even needed at all. A linear search may be faster for small fixed sets of data like this.<br><div><br></div><div>
Also, in LLVM, most (all?) code uses one space to separate the initial // from the comment text itself. You are consistently using 2.</div></div></blockquote><div><br></div></div>OK.</div><div><div class="im"><br><blockquote type="cite">
<div><div><br></div><div>in writeHexStream, please make</div><div>const char *hex = "0123456789ABCDEF";</div>
<div>into</div><div>static const char hex[] = "0123456789ABCDEF";</div></div></blockquote><div><br></div></div>Why? [ I'm not opposed to making the change, but I don't see a difference ]</div><div><br></div>
<div><div class="im"><blockquote type="cite"><div><div><div>+llvm::raw_ostream &writeHexNumber(llvm::raw_ostream &Out, unsigned long long N) {</div><div>+  if ( N > 10 )</div>
<div>+    Out << "0x";</div><div>+  Out.write_hex(N);</div><div>+  return Out;</div><div>+}</div></div><div><br></div><div>I think you mean >= 10, otherwise, it'll just output an inexplicable "A" with no "0x".</div>
</div></blockquote><div><br></div></div>Oops. Thanks!</div><div><div class="h5"><div><br><blockquote type="cite"><div>
<div>+const char endl = '\n';</div><div><br></div><div>why? either just write '\n' in the code, or as in many cases it seems in the code, just include "\n" in the string literal instead of causing a pointless extra call to raw_ostream's operator<<. e.g. instead of</div>

<div>+        Out << "        Type: " << endl;</div><div>just do</div><div>+        Out << "        Type: \n"</div><div><div><br></div><div>--Sean Silva<br><br><div class="gmail_quote">

On Tue, Jun 12, 2012 at 8:35 AM, Marshall Clow <span dir="ltr"><<a href="mailto:mclow.lists@gmail.com" target="_blank">mclow.lists@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>On Jun 9, 2012, at 2:44 AM, Michael Spencer wrote:<br>
<br>
> On Fri, Jun 8, 2012 at 11:09 AM, Marshall Clow <<a href="mailto:mclow.lists@gmail.com" target="_blank">mclow.lists@gmail.com</a>> wrote:<br>
>> [ resending to llvm-commits instead of -dev ]<br>
>><br>
>> This patch adds a tool called 'obj2yaml', which takes an object file, and produces a YAML representation of the file.<br>
>> This is a companion tool to Michael Spencer's proposed "yaml2obj" tool.<br>
>><br>
>> This tool processes only COFF files; the plan is to enhance it to handle other object formats, as well as object archives.<br>
>> The primary uses for this tool is expected to be:<br>
>>        1) Debugging object files that are produced by llvm and lld.<br>
>>        2) Automated testing suites.<br>
>><br>
>> The goal is to have obj2yaml and yaml2obj be inverse operations, so that one can test either by using the other.<br>
>> So, both obj -> yaml -> obj and yaml -> obj -> yaml are expected to be idempotent.<br>
>><br>
>> -- Marshall<br>
>><br>
>> Marshall Clow     Idio Software   <mailto:<a href="mailto:mclow.lists@gmail.com" target="_blank">mclow.lists@gmail.com</a>><br>
>><br>
>> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait).<br>
>>       -- Yu Suzuki<br>
><br>
> The design looks good, however there are quite a few LLVM style issues.<br>
<br>
</div>Extensively reworked. Now uses the facilities in llvm/Object/COFF.h for byte-sex awareness.<br>
Still a few 80 column issues, and the relocation dumping is not done - but since yaml2obj doesn't build relocation entries yet, this may be moot. ;-)<br>
<div><div><br>
-- Marshall<br>
<br>
Marshall Clow     Idio Software   <mailto:<a href="mailto:mclow.lists@gmail.com" target="_blank">mclow.lists@gmail.com</a>><br>
<br>
A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait).<br>
        -- Yu Suzuki<br>
</div></div><br>_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@cs.uiuc.edu" target="_blank">llvm-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br>
<br></blockquote></div><br></div></div>
</div>
</blockquote></div><br><div>
<span style="text-indent:0px;letter-spacing:normal;font-variant:normal;text-align:auto;font-style:normal;font-weight:normal;line-height:normal;border-collapse:separate;text-transform:none;font-size:medium;white-space:normal;font-family:'Lucida Grande';word-spacing:0px">-- Marshall<br>
<br>Marshall Clow     Idio Software   <<a href="mailto:mclow.lists@gmail.com" target="_blank">mailto:mclow.lists@gmail.com</a>><br><br>A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait).<br>
        -- Yu Suzuki</span>
</div>
<br></div></div></div></blockquote></div><br></div></div>