Yuval Ronen wrote:
Hi, After reading most of N2320, I have a few comments:
...snip several thoughts...
* Time issues. To my eyes, it looks not pretty trying to get threading with time issues standardized before we have std::date_time. Making it a templated type not because we want genericity, but because we don't have the type we want yet, makes it look coerced. I think it's best to drop the time-related stuff, and add it properly together with date_time. Using the timed version of thread::join(), mutex::lock() and condition::wait() are very rare, and I think (hope) they can be implemented externally using native_handle().
A minimal subset of date-time *is* being added. During the Kona meeting we worked on unifying N2411 with N2320 to go into the working paper. You can read more about it at: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2411.html Basically allowing you to write code like: std::this_thread::sleep(std::seconds(1)); Lock l; std::condition::timed_wait(l, std::microseconds(100)); std::condition::timed_wait(l, std::milliseconds(100)); std::condition::timed_wait(l, std::nanoseconds(100)); std::condition::timed_wait(l, std::seconds(1)); etc. The templatization of the time interfaces is at my request. The primary motivation is that 1) users/platform developers need the ability to create and use their own time types (eg: picoseconds), and 2) unlike boost::date_time, there is no "universal time_duration type" in the new proposals. The history on this is that I've been uncomfortable with the 'universal time_duration type' for some time, but going without makes the date-time implementation harder (more template magic) so it makes it less portable to older compilers. And with the backward compatibility issues, I haven't removed time_duration from date-time yet. Anyway, I'm uncomfortable with the time_duration type because it locks you into an underlying representation with a particular size. While a 64 bit integers for these types work 95% of the time, there are date-time users that compile the library using 96 bit internals b/c 64 isn't enough for them. However, the 'recompile the library' solution doesn't really work for the standard. So, a better option is to allow user extensibility and eliminate the universal time duration. That way if they want a 96 bit picosecond type it's easy to create and use. Jeff