[Lldb-commits] [PATCH] D27632: Add Formatv() versions of all our printf style formatting functions

[Zachary Turner via lldb-commits]

I would say format provider should be the default way to add formatting for
a commonly formatted type. Member function syntax is used to implement
adaptors that allow you to override formatting behavior of a type that
already has a provider.

One nice thing about F and D would be this:

formatv("Dir: {0:D}, File: {0:F}", F):

Here you only pass the argument once, but format it differently each time.
You do have a point about not getting a compiler error. In the future i had
planned to add compile time format string checking but it's a ways out. For
now we assert and then fallback to the default case of an empty style.

Also, i still haven't finished the Args stuff, so no risk of me going on a
reformatting spree :)
On Sat, Dec 10, 2016 at 1:03 AM Pavel Labath via Phabricator <
reviews at reviews.llvm.org> wrote:

> labath added a comment.
>
> This looks like a step in the right direction. I trust you won't go on a
> reformatting spree of the log messages until we settle on the syntax there.
> ;)
>
>
>
> ================
> Comment at: include/lldb/Core/ModuleSpec.h:244
> +      strm.Format("object_mod_time = {0:x+}",
>                    uint64_t(llvm::sys::toTimeT(m_object_mod_time)));
>      }
> ----------------
> you can delete the `uint64_t` cast now. It was only there to make this
> portably printable.
>
>
> ================
> Comment at: include/lldb/Host/FileSpec.h:784
> +///
> +template <> struct format_provider<lldb_private::FileSpec> {
> +  static void format(const lldb_private::FileSpec &F, llvm::raw_ostream
> &Stream,
> ----------------
> I am wondering.. what is the preferred style for adding formatting
> capability. I sort of assumed that the `format_provider` thingy was
> reserved for cases where you had no control over the object being formatted
> (e.g. because it comes from a third party library), and that for cases like
> this we would use the member format function (or, to put it differently: if
> we're going to be using the `format_provider` everywhere, what's the point
> of having the member functions in the first place?).
>
> Also, my preference would be to not have the F and D styles for FileSpec.
> I think they are redundant, as we have FileSpec::GetFilename and
> FileSpec::GetDirectory, and also they are not compiler-enforced --
> `Formatv('{0}', fs.GetFilename())` is slightly longer than
> `Formatv('{0:F}', fs)`, but if I make a typo in the former one, it will be
> a compiler error, while the other one won't. I suppose it could be useful,
> if one wants to format say an array of FileSpecs using the array format
> syntax, but I'm not sure how often will someone want to do that *and*
> display only the filenames.
>
> I don't care strongly about any of these things, but I want to know what
> to expect.
>
>
> https://reviews.llvm.org/D27632
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20161210/a560a17f/attachment.html>