<div dir="ltr"><br><div class="gmail_quote"><div dir="ltr">On Wed, Oct 12, 2016 at 10:13 AM James Y Knight <<a href="mailto:jyknight@google.com">jyknight@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg"><div class="gmail_msg"><br></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div></div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg">I wonder what use cases you envision for this? Why does LLVM need a super extensible flexible formatting library? I mean -- if you were developing this as a standalone project, that seems like maybe a nice feature. But I see no rationale as to why LLVM should include it.</div></div></div></div></blockquote><div>We were discussing this on IRC chat the other night, but I believe many people underestimate the need for string formatting.  Here are some data points:<div><br></div><div>1. There are currently 1,637 calls to llvm::format() across the codebase, and this doesn't include calls to format_hex(), format_decimal(), and the other variants.</div><div>2. LLVM consists of a large number (20+ at a minimum) of focused tools (llc, lli, llvm-dwarfdump, llvm-objdump, etc) whose sole purpose is to output formatted text.  Consider the use case of printing a verbose disassembly listing which is fed into FileCheck.</div><div>3. Even the "flagship" tools such as clang have need for string formatting when writing diagnostic messages.</div><div>4. LLDB in particular has this kind of thing *everywhere*.  I'm talking about anywhere from 3-50+ times <b>per function</b> (and that's not an exaggeration) for logging purposes.</div><div><br></div><div>That said, LLVM already includes a formatting library.  llvm::format().  So what would be the rationale *against* a better, safer, and easier version of the same thing?</div></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">That is to say: wouldn't a much-simpler printf replacement, implemented with variadic templates instead of C varargs (and which therefore doesn't require size/signedness prefixes on %d) be sufficient for LLVM?</div></div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">You can do that as a drop-in improvement for llvm::format, replacing the call to snprintf inside the implementation with a new implementation that actually uses the type information.<br class="gmail_msg"></div></div></div></div></blockquote><div>How would you format user-defined types using this?  I gave an example earlier:  Consider you have a start time and an end time in std::chrono types, and you want to print the start, end, and duration.  The code to do this using llvm::format() or stream operators is horrible.</div></div></div>