search for: time_point

...stream> #include <istream> namespace filesystem { struct file_clock { using duration = std::chrono::nanoseconds; using rep = duration::rep; using period = duration::period; using time_point = std::chrono::time_point<file_clock>; static constexpr bool is_steady = false; static time_point now(); template<typename Duration> static std::chrono::time_point<std::chrono::system_clock, Duration> to_sys(const st...

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

...gt; #include <thread> using namespace std; using namespace std::chrono; using tick = ratio<1, 300>; using tick_duration = duration<long, tick>; class ticking_clock { public: using duration = tick_duration; using rep = duration::rep; using period = duration::period; using time_point = time_point<ticking_clock, duration>; static constexpr bool is_steady = true; static time_point now() noexcept; }; void f(long &elapsed_time) { auto start = ticking_clock::now(); this_thread::sleep_for(tick_duration(71)); auto finish = ticking_clock::now(); auto dur...

...lt;long, std::ratio<1, 1000000> >') : __d(__t.time_since_epoch()) ^ ~~~~~~~~~~~~~~~~~~~~~~ /usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../include/c++/4.6/condition_variable:106:42: note: in instantiation of function template specialization 'std::chrono::time_point<std::chrono::system_clock, std::chrono::duration<long, std::ratio<1, 1000000> > >::time_point<std::chrono::duration<long, std::ratio<1, 1000000000> > >' requested here const __clock_t::time_point __s_atime = __s_entry + __delta;...

...1000000> >') > : __d(__t.time_since_epoch()) > ^ ~~~~~~~~~~~~~~~~~~~~~~ > /usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../include/c++/4.6/condition_variable:106:42: > note: in instantiation of function template specialization > 'std::chrono::time_point<std::chrono::system_clock, > std::chrono::duration<long, std::ratio<1, 1000000> > > >::time_point<std::chrono::duration<long, > std::ratio<1, 1000000000> > >' requested here > const __clock_t::time_point __s_atime = __s_entry + __del...

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

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 std::chrono::time_point<std::chrono::file_clock> instead, which is an ABI break. Is this correct, and is this...

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 > llvm::format() or your new proposal, there is some sort of glue/hel...

...ouis Dionne <ldionne at apple.com> wrote: > >> 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 >> std::chrono::time_point<std::chrono::file_clock> instead, which is an ABI >>...

...equiring yet. So you've gotta write (uint64_t)x and then use PRIx64. Ugh. 4. *Redundant.* If you're giving it an integer, why do you need to specify %d? It's an integer! We should be able to use the type system to our advantage. 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. So I've been working on a library that will solve all of these problems and more. The high level design of my library is borrowed heavily from C#. But if y...

On Aug 10, 2018, at 9:35 PM, Eric Fiselier <eric at efcs.ca> wrote: > > Part of me is still concerned with the future, and the filesystems which are yet to exist. > Me too. But it is best to target modern systems when targeting future systems adds an unnecessary cost. When future systems come into being, it is likely because future hardware is making those future systems

...a write (uint64_t)x > and then use PRIx64. Ugh. > > 4. *Redundant.* If you're giving it an integer, why do you need to > specify %d? It's an integer! We should be able to use the type system to > our advantage. > > 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 > llvm::format() or your new proposal, there is some sort of glue/hel...

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

..._OR_OVERWRITE, 512); } Xapian::TermGenerator indexer; Xapian::Stem stemmer("english"); Xapian::Document doc; string line_string; char filename[100]; ifstream infs; char *tok, filepath[1536], content[2048], line[2048]; int i; high_resolution_clock::time_point start, end; infs.open(argv[1], ifstream::in); indexer.set_stemmer(stemmer); start = high_resolution_clock::now(); doc.set_data("content"); indexer.set_document(doc); line_string = ""; while(infs.good()) { doc_...