Rough description of the API:

Firstly, an excuse: it's not really that object-orientated, I'm just using
some handy features of C++ to get what otherwise is messy and verbose in C.
Unfortunately, that sacrifices the relative clarity of C headers with
tricky-looking C++ headers.

What I chiefly needed was a hassle-free correlation option, a revamped parser,
and a structure that can bear further development without turning into the
mess that C mdate became, not to mention overloading.

Overview of the overview:

Most code involves converting to/from a Julian Day Number (NOT fractional),
then converting the result into a string buffer, often preformatted. Use of
the JDN in converting between calendars is time-honoured; using string buffers
is great for GUI interfaces.

mdate.hh outline:

The global variables:
- Why a typedef Bool? It's safer.
- julian_date is used by everything to convert to/from dates. also used by
  the driver, so it's not static.
- corr is heavily used also by most functions and the driver.

There are a few public data members, intended mostly for possible future use:

julian::corr_set - used in julian::set_correlation(corr c). 
- since the parser can already check for this, it may go soon.

mdate::pflag 
- this is also pretty much obsolete, and will definitely go unless someone can
  justify it to me.

There are a few friends about, sorry about that. It was either make all data
members public (ugh) or force interface functions on other classes, which is
also wrong IMHO.

class mdate inherits from everywhere else, but also hosts some core methods as
they depend on accessing the parent classes. mdate also initialises all the
parent constructors.

The various *date classes are self-explainatory, class julian is interesting
because it deals with the correlations. Our standard (584285) is the
Loundsbury Correlation (after Floyd Loundsbury, with whom most Mayan scholars
violently disagree, probably because he was right), and I give a nod to the
GoodMan-Martinez-Thompson standard (GMT), which isn't as rock-solid as many
would have you believe. There's also a roll-your-own option for those who
disagree with everyone (anyone worked out what the hell the dreamspell people
think it is?!) :)

The various string output functions are overloaded to make choosing output
formats more easily. This will become more important in the near future.

mdate.cc outline:

The AMOD(x,y) macro ensures positive moduli in certain situations. It's only
used in one place, don't panic.

David Starner kindly wrote a C version of BSD drem(). I should explain why
it's used at all: fmod() discriminates between +ve and -ve numbers, drem()
doesnt, which is important when you're taking a modulus from floating-point
numbers. It surprises me that it's seen so rarely, it's so useful. Of course,
some *nix'es decided to call it remainder() to avoid that BSDish taint from
their otherwise pristine SYSV flavour. And some have never heard of it. So
my_mod() tries to cope with it all in one go.

The two most important functions convert JDN's to Gregorian dates and vice
versa. Many, many people have tried this and everyone disagrees with everyone
else's code. For much of mdate's life I used Ivan Van Langingham's python
functions translated to C. Since then, I've been reacquainted with the public
domain Fliegel/Van Flandern algorithms which are fine as I don't use
fractional JDN's which are more in line with the more academic uses of Mayan
calendars. Since such dates are of the most obscure academic use, academics
probably have far superior programs for that.

gregdate_tostr() has a GNU-specific quirk; either strftime() is different, or
the non-constant gtm structure is allowable. This certainly didn't work the
last time I tried compiling this function with Borland C/C++, it may not work
with other compilers/systems.

the tzolkinmonth_* and haabmonth_* functions have hardcoded strings in them;
the "old" Romanisation of Mayan names. It might be nice to allow the other
variant spellings of these, but that will have to wait for other
functionality.
