Boost logo

Boost :

From: Gennadiy Rozental (rogeeff_at_[hidden])
Date: 2002-04-23 21:59:38

"Jeff Garland" <jeff_at_[hidden]> wrote in message
> > 1. Generic base
> > I did not agree with design of generic base of the library. Separation
> > date and time does not look reasonable.
> Ok, but the basic premise is that a 'date only' library shouldn't depend
> 'time specific' things. There are many programming problems that exist
> strictly at the 'date level'.

System I invision would not have this problems.

> >For one it's replication of code sometime. But mainly it's not flexible.
> >if I need 3 level date/time system that have day, hour and seconds? Or 2
> >time system that have only weeks and days. Generic solution may look
> >something like this (from top of my head, only sketch ):
> This is done by replacing the time system and supporting types.

I wonder how you would you implement week/day day system, given the fact
that you have year/month/ydm hardcoded in generic part of the library. Or
time_duration assumes that time have hours, minutes and seconds but this
would not be the case in my first example. Do not mention output formats.

> > Generic class time_system_level
> > ...snip implementation suggestion...
> I think this would be an interesting approach to explore. What you're
> suggesting (assuming I understand it and we could get it to compile)
> could unify the idea of the concept of time point.
> > is_valid() // ?? why do we need that?
> >Could not we make sure that value
> > is valid always and throw an exceptions on invalid operations?
> Because some date-time systems will allow of 'not-a-date-time'
> values. They need to be able to query for this state before
> they get the exception.
> > operator-,+ will use some other class that encapsulate duration
> > of two similar classes date_duration, time_duration
> >
> > read-only property: unit_type m_value;
> > }
> >
> > normalized_value<n,level_id> :=
> > uple( date_time_system_policies::level_unit_types::get<n>::level_type,
> >
> > date_time_system_policies::level_unit_types::get<n-1>::level_type,
> > ...
> >
> > date_time_system_policies::level_unit_types::get<level_id>::level_type )
> >
> >
> > Then we need one generic iterator through level.
> > Some generic io support.
> > There may be another level of generality that provide current

we could have
template<date_system,time_system<date_system> >

> > Also we need some generic support for conversions.

target_date_time_system::date convert( orig_date_time_system::date )

> I'm not following here....
> > 2. I/O
> > I/O functionality supplied is very inflexible. It should be completely
> > managed by some user supplied (with some defaults) format string.
> > date_time_system_policies could assign specific letter to each level and
> > that user could define arbitrary formats. Also to/from_string interface
> > not acceptable. It should be iostream based one.
> I'm sure no matter what is done someone won't be happy with the I/O. I
> didn't want to write a 'format string' capability. This is a complex job
> would consume a great deal of time. I would be happy to incorporate this
> someone else wants to take it on. As for inflexible, you are always free
> to extract the elements of a date-time and write your own formatting

I know that absence of custom format make this library unusable for me. One
of the application is a timestamp of logging entry. Output format is
specified by logging library user so I need to be able to specify it either.
And I do not want to reimplement it myself.

> > b. fix naming conventions,
> Such as?

name_ -> m_name

> > f. examples should include using <> instead of ""
> Disagree. I subscribe to the <> for std library only camp....

See other sources in boost.

> > 7. time_iterator and date_iterator
> > a. time_iterator should use iterator_adaptor
> > b. date_iterator should use iterator_adaptor and should not be using
> > functions, really should be one type
> You are correct that these should use iterator_adaptors -- I haven't had a
> chance to look at this yet. The problem is that date_iterator is really
> solving a different problem. It is allowing the user to plug-in a
> functor so that it can do things like figure adjust for the end of months
> appropriately. So maybe it needs a different name like logical_iterator.

why time_iterator does not need such functor

> > 9. Misc.
> > c_local_time_adjustor, local_time_adjustor: does not seems to belong to
> > generic framework. probably should be moved in conversions subsystem.
> > day_clock, second_clock : does not seems to belong to generic framework.
> > probably should be moved in conversions posix subsystem.
> No. These could be used for other date-time systems.

time.h. Is it part of generic framework? Probably on different level.

> > 10. Compilation on MSVC issued following warnings:
> > \gdtl_057_boost\boost\gdtl\gregorian\gregorian_calendar.ipp(27) :
> > C4244: 'return' : conversion from 'unsigned long' to 'short', possible
> > of data
> > \gdtl_057_boost\boost\gdtl\gregorian\gregorian_calendar.ipp(58) :
> > C4244: 'initializing' : conversion from 'unsigned long' to 'unsigned
> > possible loss of data
> > \gdtl_057_boost\boost\gdtl\gregorian\gregorian_calendar.ipp(59) :
> > C4244: 'initializing' : conversion from 'unsigned long' to 'unsigned
> > possible loss of data
> > \gdtl_057_boost\boost\gdtl\gregorian\gregorian_calendar.ipp(63) :
> > C4244: 'argument' : conversion from 'unsigned long' to 'unsigned short',
> > possible loss of data
> These are acceptable. I suppose we should try to suppress them.

They look strange why do you define local variable long if return type is

> Jeff


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