Re: [boost] gregorian date - default constructor & more.

From: Jeff Garland (jeff_at_[hidden])
Date: 2004-01-12 07:58:01

On Mon, 12 Jan 2004 07:43:19 +0100, Pavol Droba wrote
> In my application, I need the default constructor. I'm using a 
> templated code, and I'm using default-constuctible values as 
> defaults, when no other value can be computed. Because it is a 
> generic code, I have no way to find out what a value to use to 
> initialize a particular type. (well, I can factor out the 
> initialization to some function and overload it for all the 
> different types, but it would simply do the same thing as the 
> default constuctor, so I don't consider this as a reasonable 
> solution).

Ok, that's the most persuasive argument I've heard for this...
 
> > Of course you can do it by changing one line of code:
> > 
> > Change boost/date_time/gregorian/greg_date.hpp::68
> >    explicit date(special_values sv):
> > to
> >    explicit date(special_values sv = not_a_date_time):
> 
> This is exactly what I did, to solve my problem. I'm just wondering 
> why it is not official. 

Well, to get into the details, when this class was originally written it
didn't support 'special values' like not_a_date_time.  So at that stage there
was, in my view, no reasonable default.  Overall, I see the support of special
values as a policy decision you might want to turn off (for performance
reasons) and as such it isn't wise to presume the existance of this feature. 
Also, once upon a project I ran into a major performance issue with certain
commercial library that decided the default constructor should be to set the
date to the current date (making several system calls).  We happened to be
writing a scheduler and created a very large number of objects and that simple
little call into the OS wound up being a huge performance hit -- lazy
programmers would default construct then assign wasting lots of time. 
Needless to say the changes required to fix this problem were all over the
place.  So it's possible I'm over-sensitive to the other side of this issue.

> > > The other issue is, if there is a plan to add unicode support to the 
> > > library.
> > 
> > Can you be a bit more specific about what you want?  The streaming code should
> > already support unicode if the underlying stream supports it.  
> 
> I had to_xxx_string and from_xxx_string functions in mind. I would 
> like to have wstring variants, so I don't have to convert the string 
> from unicode and back each time I'm using them.

Well I wasn't planning on doing using the to_string, from_string methods to
support this since these are largely there to support VC6 and other compilers
that have std::locale issues.  So I imagine using operator<< and operator>>. 
At the moment, however, you are missing the operator>> side.  It's pretty high
on the priority list at this point.

Jeff