search for: system_clock

...= 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 std::chrono::time_point<file_clock, Duration>& t) noexcept; template<typename Duration> static std::chrono::time_point<file_clock, Duration> from_sys(const std::chrono::time_point<std::chrono::system_clock,...

...000000> >') : __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;...

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

...; : __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; >...

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

...at_string("{0,8:P}", 0.76); // Writes " 76.00%" 10. os << format_string("{0,-8,P}", 0.76); // Writes "76.00% " And you can also format complicated types. For example: 11. os << format_string("{0:DD/MM/YYYY hh:mm:ss}", std::chrono::system_clock::now()); // writes "10/11/2016 18:19:11" I already have a working proof of concept that supports most of the fundamental data types and formatting options such as percents, exponents, comma grouping, fixed point, hex, etc. To summarize, the advantages of this approach are: 1) *Safe.*...

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

...an not compile such code void setupNewBuffer(int (*wall_clock_reader)(clockid_t, struct timespec *)); must use typedef first . xray use clock_gettime as default implementation , which is not friendly for windows .create a fake one based on chrono system_clock(ignore clockid_t) for tls destructor part, I've just commented them out.(but https://www.codeproject.com/Articles/8113/Thread-Local-Storage-The-C-Way gives a thread exit callback way for coff) and last thing , which I don't understand is the weak symbol for __start_xray_instr_map[] __sto...

I'm learning the xray library and try if it can be built on windows, in xray_fdr_logging_impl.h line 152 , comment written as // Using pthread_once(...) to initialize the thread-local data structures but at line 175, 183, code written as thread_local pthread_key_t key; // Ensure that we only actually ever do the pthread initialization once. thread_local bool UNUSED Unused = [] {

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