search for: file_time_type

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 would be acceptable if this was absolutely necessary to get the job done, but it isn’t. The 16 byte integer is unnecessarily exp...

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...

...the symbols in a separate static library. > > /Eric > > On Tue, Aug 7, 2018 at 2:15 PM Louis 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 &g...

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

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