similar to: RFC: General purpose type-safe formatting library

On Tue, Oct 11, 2016 at 8:59 PM Mehdi Amini <mehdi.amini at apple.com> wrote: > Hi, > > I On Oct 11, 2016, at 6:22 PM, Zachary Turner via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > A while back llvm::format() was introduced that made it possible to > combine printf-style formatting with llvm streams. However, this still > comes with all the risks

On Tue, Oct 11, 2016 at 8:59 PM Mehdi Amini <mehdi.amini at apple.com> wrote: > > 5. *Not flexible.* How do you print a std::chrono::time_point with > llvm::format()? You can't. You have to resort to providing an overloaded > streaming operator or formatting it some other way. > > > It seems to me that there is no silver bullet for that: being for >

* UDL Syntax is removed in the latest version of the patch <https://reviews.llvm.org/D25587>. * Name changed to `formatv` since `format_string` is too much to type. * Added conversion operators for `std::string` and `llvm::SmallString`. I had some feedback offline (not on this thread, unfortunately) that it might be worth using a printf style syntax instead of this Python-esque syntax.

I don't object to compile time checking *as long as it doesn't severely detract from brevity*. At the same time, I do object to *preventing* runtime format strings. When we have C++14, we can make every member of StringRef constexpr, and at that point we will get compile time checking mostly "for free" without preventing runtime format strings. For example, given a

Ahh, UDLs also wouldn't permit non literal format strings, which is a deal breaker imo On Wed, Oct 12, 2016 at 7:03 AM Zachary Turner <zturner at google.com> wrote: > I'm not sure that would work well. The implementation relies on being able > to index into the parameter pack. How would you do that if each parameter > is streamed in? > > "{0} {1}"_fs(1, 2)

On Aug 10, 2018, at 1:28 PM, Marshall Clow via cfe-dev <cfe-dev at lists.llvm.org> wrote: > > * The clock stuff being added in C++20 has already been discussed here. I’ve missed the discussions on file_time_type, however I thought I should throw in my opinion here before it is too late to do anything about it. I believe it is a mistake to model file_time_type with 128 bits. It

Hi All, I recently committed <filesystem> to trunk. I wanted to bring attention to some quirks it currently has. First, it's been put in a separate library, libc++fs, for now. Users are responsible for linking the library when they use filesystem. Second, it should still not be considered ABI stable. Vendors should be aware of this before shipping it. Hopefully all the standard and

I thought I did. :) Passing format strings between functions is very useful. For example, imagine wanting to write a function like printRange(const char *Fmt, std::vector<int> Items); This isn't possible if your format string MUST be a string literal and is very useful. Equally importantly, I don't see a good reason to disallow runtime format strings. On Wed, Oct 12, 2016 at

You get compile time checking automatically when we can use c++14 though. If you use it with a string literal, you'll get compile time checking, otherwise you won't. Here's a different example though. Suppose you're writing a tool which prints formatted output, and the field width is specified by the user. Now you NEED to build the format string at runtime, there's no other

All, I'm in the process of upgrading an LLVM client from using 3.8 to using 4.0 and am running into the following issue: // compile with: // clang++ -std=c++11 -Wno-c++14-extensions -S -emit-llvm // ~/chrono.cpp -o chrono.ll #include <chrono> #include <ratio> #include <thread> using namespace std; using namespace std::chrono; using tick = ratio<1, 300>; using

On Mon, Oct 31, 2016 at 5:21 PM, Chandler Carruth via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Mon, Oct 31, 2016 at 3:46 PM Zachary Turner via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Hi all, >> >> Tentatively final version is up here: https://reviews.llvm.org/D25587 >> >> It has a verbal LGTM, but I plan to wait a bit

Sorry ... I missed mentioning the details - this is the error I get - root at no1slu398:~/Documents/LLVM/tmp# clang++ -std=c++0x hello.cpp In file included from hello.cpp:1: In file included from /usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../include/c++/4.6/thread:38: /usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../include/c++/4.6/chrono:535:6: error: no matching constructor for initialization of

Hi, I'd really appreciate some pointers in this regard. Regards, Kashyap On Wed, Oct 16, 2013 at 5:43 PM, C K Kashyap <ckkashyap at gmail.com> wrote: > Sorry ... I missed mentioning the details - > > this is the error I get - > > root at no1slu398:~/Documents/LLVM/tmp# clang++ -std=c++0x hello.cpp > In file included from hello.cpp:1: > In file included from >

On 15/10/13 22:22, C K Kashyap wrote: > Hi, > I'd like to try out the new c++11 features using clang. However, I am > running into some issue or the other on both Windows and Linux. In both > cases, it looks like the problem is due to headers from VC/g++. > I was wondering if someone can point me to some steps on setting up a > Windows or Linux(ubuntu 12.04 LTS) box for

Hi, I'd like to try out the new c++11 features using clang. However, I am running into some issue or the other on both Windows and Linux. In both cases, it looks like the problem is due to headers from VC/g++. I was wondering if someone can point me to some steps on setting up a Windows or Linux(ubuntu 12.04 LTS) box for exploring clang. I was able to successfully build clang on my ubuntu but

>> 1. os << format_string("Test"); // writes "test" >> 2. os << format_string("{0}", 7); // writes "7" > > > The "<< format_string(..." is ... really verbose for me. It also makes me > strongly feel like this produces a string rather than a streamable entity. I wonder if we could use UDLs instead? os

Hi, My current understanding of the problem (based on https://reviews.llvm.org/D49774) is that we have a type, file_time_type, which is part of the ABI and is currently defined as std::chrono::time_point<_FileSystemClock>, where _FileSystemClock is an internal type represented using a __int128_t. However, C++20 will add a type called file_clock and redefine file_time_type to be

Why did you want the symbols moved out of libc++experimental, and for the header to be moved from <experimental/filesystem> to <filesystem>? It certainly seems like it'd be safer and clearer to move them back to the old locations, but it's not clear to me if that'd be trading off something else of value. Was there some other greater purpose served by the change in

On Wed, Oct 12, 2016 at 10:13 AM James Y Knight <jyknight at google.com> wrote: > > > 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. > We

FWIW, I’d like for us to come to an agreement before the branch for LLVM 7.0 is cut. How do others feel about this? Am I wrong when I claim that shipping an ABI-unstable feature in the std:: namespace is a deviation from normal practice? Am I overcautious when I say it’s asking for trouble? Eric, I know you’re busy and may not have time to do the work so I’m totally willing to chime in, but I’d