Boost logo

Boost :

From: Jeff Garland (jeff_at_[hidden])
Date: 2007-10-28 16:02:31

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:

Basically allowing you to write code like:


  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));


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.


Boost list run by bdawes at, gregod at, cpdaniel at, john at