C++0X Its about (y)time
in [C++]
|
From: Terry G on 10 Apr 2008 10:43 This is the proposed ytime. struct ytime { time_t tv_sec; unsigned long tv_nsec; }; This time representation would be used for both absolute and relative time, i.e. all time delays and would be returned by all standard-conforming clocks. This time representation would be used as an argument for sleep() and for condition_variable::timed_wait(). Some points in favor of ytime: * simple * easy to monitor in a debugger .. * maps easily to POSIX timespec and (deprecated) time_t * same time representation for absolute and relative time Some points agains ytime * operations on ytime are difficult and error-prone because the time is broken up into two fields instead of being a continuous count * operations and storage are less efficient than just a 'long long count' of nanoseconds since midnight, Jan 1, 1970 (overflows in 2262). * has the same "Year 2038" problem that time_t has. * unclear mapping to UTC or how leap-seconds are handled * same time representation for absolute and relative time This representation is very similar to POSIX timespec, so many people already have gained experience, good or bad. More elaborate systems of clocks and time representations are possible, but please limit discussion to the ytime representation. Do you think C++ should adopt ytime? terry -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Francis Glassborow on 11 Apr 2008 02:45 Terry G wrote: > This is the proposed ytime. > > struct ytime { time_t tv_sec; unsigned long tv_nsec; }; > > This time representation would be used for both absolute and relative time, > i.e. all time delays and would be returned by all standard-conforming > clocks. > In my and my National Body's specialist task force (called a panel) for C++ opinion, this is the wrong place to start. As with any software project we should start with a set of requirements then we can measure any proposal against those. For the record we spent much of the longest BSI C++ Panel meeting on record (13 hours) thrashing out such a set of requirements. They will shortly be written up and published. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Alberto Ganesh Barbati on 12 Apr 2008 15:43 Francis Glassborow ha scritto: > Terry G wrote: >> This is the proposed ytime. >> >> struct ytime { time_t tv_sec; unsigned long tv_nsec; }; >> >> This time representation would be used for both absolute and relative >> time, >> i.e. all time delays and would be returned by all standard-conforming >> clocks. >> > In my and my National Body's specialist task force (called a panel) for > C++ opinion, this is the wrong place to start. As with any software > project we should start with a set of requirements then we can measure > any proposal against those. > > For the record we spent much of the longest BSI C++ Panel meeting on > record (13 hours) thrashing out such a set of requirements. They will > shortly be written up and published. > I have read papers N2498, N2539, N2552 and N2526 and it seems that the orientation is towards a duration-as-type approach. I was wondering: what about the possibility to define duration as a concept rather than as a type? I mean, consider this: concept TimeDuration<typename T> { typename units_type; requires ArithmeticLike<units_type>; // notice that units_type is deliberately allowed // to be a floating point type // conversion to/from units units_type to_units(const T&); T from_units(units_type); // semantic is similar to seconds_per_tick/ticks_per_seconds // of paper N2498 constexpr long long units_per_second(); constexpr long long second_per_unit(); // don't know if this is legal requires True<(units_per_second() > 0 && second_per_unit() == 0) || (units_per_second() == 0 && second_per_unit() > 0) || (units_per_second() == 1 && second_per_unit() == 1)>; }; as shown in N2498, this concept is sufficient to provide reasonable conversions between duration types, in the form of an algorithm like: template <TimeDuration T1, TimeDuration T2> T1 duration_cast(const T2& t); Helper functions for conversion to scalar forms could be provided, for example: template <IntegralLike R, TimeDuration T> R duration_in_seconds(const T& t) { // naive implementation: no type or overflow checks return static_cast<R>( TimeDuration<T>::to_units(t) * TimeDuration<T>::second_per_units()); } template <FloatingPointLike R, TimeDuration T> R duration_in_seconds(const T& t) { // naive implementation: no type or overflow checks if (second_per_units()) { return static_cast<R>( TimeDuration<T>::to_units(t) * TimeDuration<T>::second_per_units()); } else { return static_cast<R>(TimeDuration<T>::to_units(t)) / static_cast<R>(TimeDuration<T>::units_per_seconds()); } } With this machinery, a function like this_thread::sleep could be implemented like this: template <TimeDuration T> void sleep(const T& t) { sleep_impl_nanoseconds(duration_in_nanoseconds<long long>(t)); } By providing suitable concept maps, this implementation would work for system_time, ytime and even the duration<> template proposed by N2498. We don't need to commit to only one duration type! The TimeDuration concept is also sufficient to define multiplication and division of a duration by a scalar, division between durations and addition and subtraction of exactly-convertible duration types. In order to have a more general addition and subtraction, we definitely need a duration<> template like the one proposed in N2498, in order to specify the return type of operator+ and operator- in the general case, but that could be left for a subsequent TR. Does this all make sense? HTH, Ganesh -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Pedro Lamarão on 12 Apr 2008 15:43 On 10 abr, 22:43, "Terry G" <tjgol...(a)netins.net> wrote: > This is the proposed ytime. > > struct ytime { time_t tv_sec; unsigned long tv_nsec; }; > > This time representation would be used for both absolute and relative time, > i.e. all time delays and would be returned by all standard-conforming > clocks. > > This time representation would be used as an argument for sleep() and for > condition_variable::timed_wait(). nanoseconds should be a long for compatibility reasons. ]$ man time.h (...) The <time.h> header shall declare the structure timespec, which has at least the following members: time_t tv_sec Seconds. long tv_nsec Nanoseconds. (...) The following shall be declared as functions and may also be defined as macros. Function prototypes shall be provided. (...) int clock_getres(clockid_t, struct timespec *); int clock_gettime(clockid_t, struct timespec *); int clock_nanosleep(clockid_t, int, const struct timespec *, struct timespec *); -- P. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Francis Glassborow on 13 Apr 2008 03:48
Alberto Ganesh Barbati wrote: > Francis Glassborow ha scritto: >> Terry G wrote: >>> This is the proposed ytime. >>> >>> struct ytime { time_t tv_sec; unsigned long tv_nsec; }; >>> >>> This time representation would be used for both absolute and relative >>> time, >>> i.e. all time delays and would be returned by all standard-conforming >>> clocks. >>> >> In my and my National Body's specialist task force (called a panel) for >> C++ opinion, this is the wrong place to start. As with any software >> project we should start with a set of requirements then we can measure >> any proposal against those. >> >> For the record we spent much of the longest BSI C++ Panel meeting on >> record (13 hours) thrashing out such a set of requirements. They will >> shortly be written up and published. >> > > I have read papers N2498, N2539, N2552 and N2526 and it seems that the > orientation is towards a duration-as-type approach. I was wondering: > what about the possibility to define duration as a concept rather than > as a type? I mean, consider this: <snip> > could be left for a subsequent TR. > > Does this all make sense? This still does not address the issue of what we are designing for. Until we tackle that properly we will just finish up with another 'all but the kitchen sink' class like std::string etc. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |