From: Jeff Garland (jeff_at_[hidden])
Date: 2002-04-22 14:59:48
> - it was not easy to find out how some classes or many member functions
> behave because the documentation says nothing about it.
> e.g. it says for a whole class like day_functor only one short
> sentence, which is imho too few.
Agreed that should be improved. Any other specific cases?
> - then i wanted to test the generic part and tried to write my own
> date-class which has only a resolution of one year. but i found no point
> in the documention describing how to start. what i would like to see is
> a description how the generic components of gdtl should and can be used.
This is a criticism that has been raised by another reviewer offline and I
agree should be addressed. However, I have been somewhat reluctant to write
spend time writing this documentation until there was some further review
of the library. There is no point spending my time on this if the library
However, in general, the goal with GDTL has been to keep individual components
of the date-time library as separate as possible. For example, the parts that
retrieve from a clock are separate from the parts that represent a date/time.
In this way, we can add a new clock source(say a network clock) that provides
a date/time component without disturbing the basic temporal types (as long as
a reasonable mapping can be made, of course). It also means that the date or
time system can be used to represent historical times even if the clock cannot
(of course it doesn't make sense for a clock to do this).
So for example the dimensions of extension include:
* Add clocks to existing date-time systems
* Add new parsers/formatters to a date or time system
* Add new date/time systems
> - i wanted to output the names of the months in my native languages, but
> it seems to be impossible. is there any support for
Support for C++ locales and facets needs to be added.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk