From: Gerhard Wesp (gwesp_at_[hidden])
Date: 2006-05-15 12:02:34
On Mon, May 15, 2006 at 04:55:27PM +0200, Carlo Wood wrote:
> Now, there is a problem imho with it's type: An absolute time is
> different from a relative time. The fact that an absolute time is
Yes and no. Your "absolute time" is still relative to whatever
definition you have of January 1, 1970. Which is relative to whichever
definition you have of the birth of a well-known religious leader, which
in turn is relative to certain properties of the earth spinning around
the sun, etc.
Einstein was confused by this mess and postulated that there's no such
thing as "absolute time". A couple of years later physical experiments
showed that his theory is more than plausible.
Having implemented several major frameworks in C++ in which time played
a crucial rule, I have a pretty firm view on the subject: No time type
should include information about relative to which point it is measured.
This is the job of the spec of the function that hands out a time value,
but *not* of the type.
Physics gives quite clear directions as to which operations a time type
- Addidtion, subtraction, comparison with other time's.
- Division by other time's to give a dimensionless type.
- Conversion to/from whatever is useful, maybe stream operators.
Note that any builtin arithmetic types support those operations, but
they're not "typesafe" in the sense that you might end up e.g. adding
time and length. A user-defined type can protect you from those
accidents by only defining the above mentioned operations.
*If* we want a user-defined type to represent time, it may well be part
of a general framework for physical quantities. See e.g.
section 6 for ideas on how this can be done.
> that the two are the same thing, but I'd argue that it would be
> better to make TWO types.
I strongly disagree, for the above reasoning.
-- Gerhard Wesp ZRH office voice: +41 (0)44 668 1878 ZRH office fax: +41 (0)44 200 1818 For the rest I claim that raw pointers must be abolished.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk