search for: file_clock

...nanosecond resolution. However its timestamp is only 64 bits. It has a range of approximately [1901-12-14, 2446-05-10]. Modeling ext4 would be a good design decision for libc++. libc++ could also model other file systems (Windows, macOS). All of these are based on 64 bit timestamps. Here is a file_clock, quickly thrown together, lightly tested, that models ext4: #include "date/tz.h" #include <ostream> #include <istream> namespace filesystem { struct file_clock { using duration = std::chrono::nanoseconds; using re...

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

...m (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 the only concern we have with respect to the ABI stability of Filesystem as currently included in the release branch for LLVM 7? If that is correct...

.../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 the only concern we have with respect to the >> ABI stability of Filesystem as currently included in the re...

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