...probably just an omission. TimeValue and Time are
also default constructible, and this makes sense, semantically.
Please note that Time values are *immutable* though.
Only TimeVar can be reassigned. This is so by design
Initially I've deliberately omitted those, to nudge towards
using time quantisation and TCode formatting for any external
representation of time values.
While this recommendation is still valid, the overloaded
string conversion turns out to be helpful for unit testing
and diagnostics in compound data structures.
See Record<GenNode>
using our util::_Fmt front-end helps to reduce the code size,
since all usages rely on a single inclusion of boost::format
including boost::format via header can cause quite some code bloat
NOTE: partial solution, still some further includes to reorganise
implemented as extension to the linear combinations.
I decided to use the same "always floor" rule
as employed for time quantisation. Moreover,
we don't support floating point, only rationals
removed that inheritance relation; it was a typical
example of abusing inheritance and violated the
Liscov substitution principle. It is sufficient
to allow promotion of an offset into a Duration.
Note: Duration is the time metric
Note: it's rather arbitrary choosen,
because any time grid can define its own origin.
You must not assume that the origin of any time axis
is located at Time::ZERO !!
this is the first building block in an attempt to
protrect against time wraparound. The intention is
not to be airtight, but practically effective.
A really airtight solution would require writing
our own SafeInt class
questions: what is mutable / immutable?
what is the distinction between TimeValue and Time ?
what conversions make sense?
what mutations / operators to support?
namespace lib::time
lumitime.cpp will define the basic time wrapper
quantiser.cpp the grid alitnment and formatting wrapper
header for
- timevalues / ranges
- quantised time valuse
- timecode valuse
"lumitime.hpp" will contain the interface facilities
