John -
Sorry to be slow on this reply...
John Torjo wrote:
> > > [1]
> > > unary operator-(time_iterator).
> > > Example: -hours(24) instead of hours(-24).
> > > (seems more straightforward)
> >
> > I see your point, but then don't you have to add all the other
> > operators for consistency? Not sure that makes sense to do with
> > the iterator.
> >
>
> I'm sorry I messed up. I wanted it for time_duration :)
> But anyway, unary operator- I think could make some parts of code a little
> more readable. For instance, I had some code where I would use time_iterator
> to go from, lets say, today, to 3 months before.
>
> I think unary operator- is very easy to implement for time_duration (and
> perhaps date_duration).
Ah, that makes sense -- on the todo list...
> > > [2]
> > > Does a *FOUR* functions justify having a jam file?
> > > (greg_month::as_short_string(), greg_month::as_long_string(),
> > > greg_weekday::as_short_string(), greg_weekday::as_long_string())
> > >
> ... detail omitted...
> I thought a smart compiler could definitely overcome that.
> Something like, a static inline function:
>
> // Warning: untested code
> static const char* as_short_string( int idx) {
> static const char * months[] ={ ... };
> return months[ idx];
> }
Yep, true.
> > localized strings ever gets into the library there will be many more
> > strings (take a look at libs/date_time/test/gregorian/test_facet.cpp).
> > Finally, there may be other functions that eventually will be in the
> > library and not inlined.
>
> Sure thing. But you haven't convinced me ;)
> Basically, the above could become:
>
> static const char * default_as_short_string( int idx) {
> ...
> }
>
> And as for locales, the user can choose the right locale for him, you can
> still have some static functions, like:
>
> static const char*[] de_short_month_names() {
> static const char* const
> names[]={"Jan","Feb","Mar","Apr","Mai","Jun","Jul","Aug","Sep","Okt","Nov","
> Dez", "NAM"};
> return names;
> }
>
> So, if the user wants a "de" locale, you could - behind the scenes -, select
> de_short_month_names(), de_long_month_names(), etc.
>
> - they could exist in a distinct header, and they would be #included only if
> the user needs them (wants localized information).
>
Ok, sure. I can't really see anything wrong with your argument. That said,
I still don't want to change this lightly. While this would make life
easier for users, they are already used to the library. If I get rid of it
and then want/need it back it won't be nice. So I'll put this on my
to be considered list, ok?
> > > As I understood by looking at the docs, fraction actually means
> > > nano-seconds.
> >
> > Not necessarily. It depends on the resolution the time duration template
> is
> > instantiated with. For example, there is a second option that many people
> use
>
> In that case, I'm confused ;-)
> There should be more info in the docs, I think.
Yep, that's for sure.
> > which only provides microsecond duration resolution, but only requires a
> > single 64 bit integer to represent a time value. The bottom line is that
> > fractional seconds is a count of the number of fractional seconds at the
> > given resolution.
>
> Maybe still, for simplicity you could have a time_duration::nanoseconds()
> function.
I agree this would be nice. Of course, I think this will need to fail
compilation if the resolution doesn't support nanoseconds.
> Also, now that I come to think of it :), the following functions would come
> in handy:
>
> time_duration::total_hours() - the number of hours (ignoring mins, secs,
> etc.)
Don't see how this would be different from the current method.
> time_duration::total_mins() - the total number of minutes (hours*60 +
> minutes() )
> time_duration::total_secs() - you get the idea.
>
> (of course they can be computed, but it's more error prone)
Yep, these would be handy -- on the list...
Jeff
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
