On Tue, 20 Jul 2004 17:20:45 -0400, David Abrahams wrote

"Jeff Garland" writes:

...

I've given in to user demand -- the default constructor to not_a_date_time will be in the 1.32 -- gregorian::date same story.

Why was that the right choice? It seems like an opportunity for bugs.

Well, you are the first to defend my original stance :-) Really though, it isn't that big a window for error. And, you can turn the default constructors off by setting a compilation flag. Jeff

On Tue, 20 Jul 2004 21:45:19 -0400, Caleb Epstein wrote

On Tue, 20 Jul 2004 17:20:45 -0400, David Abrahams wrote:

...

"Jeff Garland" writes:

...

I've given in to user demand -- the default constructor to not_a_date_time will be in the 1.32 -- gregorian::date same story.

Why was that the right choice? It seems like an opportunity for bugs.

What would you propose as an alternative? I hope not the current system time, the acquisition of which can be a relatively expensive operation.

Oh my, never, no way. A certain famous vendor of C++ libraries made this mistake. Needless to say, I was none to happy when my scheduling application had to make 100K time values and we found we were burning all our time reading the system clock to get a value that would be overwritten in a few instructions. In a future version this company created a whole new time class and deprecating the original solution.... There's probably a design principle here like: value object constructors shouldn't have expensive side effects like making system calls.

I for one prefer the not_a_date_time option.

This should be about as expensive as boost::int64_t v = 0; depending on how good your compiler is at munching template code ;-) Jeff

--- At Wed, 21 Jul 2004 07:47:51 -0400, David Abrahams wrote:

Caleb Epstein writes:

...

On Tue, 20 Jul 2004 17:20:45 -0400, David Abrahams wrote:

...

"Jeff Garland" writes:

...

I've given in to user demand -- the default constructor to not_a_date_time will be in the 1.32 -- gregorian::date same story.

Why was that the right choice? It seems like an opportunity for bugs.

What would you propose as an alternative?

Not having a default constructor for for dates at all.

I've never used dates (and I don't play one on TV) but is there a reason to put dates into a container? Doesn't this (usually) require having a default constructor? ...Duane

surely whether you wish to store a date-time in a container or use it in some other piece of generic code isn't the point. if the default constructor is in-expensive and congruent with the intentions of the library then why not provide the facility so that it can be standardized within the library? jonathan. Jeff Garland wrote:

On Wed, 21 Jul 2004 08:09:21 -0700, Duane Murphy wrote

...

I've never used dates (and I don't play one on TV) but is there a reason to put dates into a container?

Yes, many reasons.

...

Doesn't this (usually) require having a default constructor?

Nope. You can search the developer list archives for more details -- it has been discussed there.

Jeff

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

Victor A. Wagner Jr. wrote:

At Tuesday 2004-07-20 14:20, you wrote:

...

"Jeff Garland" writes:

...

I've given in to user demand -- the default constructor to not_a_date_time will be in the 1.32 -- gregorian::date same story.

Why was that the right choice? It seems like an opportunity for bugs.

seems that way to me also. that C polluted the programming world with the default uninitialized variables (they really shoulda paid more attention to BCPL, at least you had to say = ? if you meant to leave it alone), and C++ followed (so, purportedly, us 'old farts' would use the language) is NO reason to follow down a bad path.

Accessing the value of an unitialized variable is undefined behavior. Accessing the value of a default-constructed user-defined type is perfectly defined. Leaving out the default constructor offers little to no benefit to users.

Victor A. Wagner Jr. wrote:

why would you want such a thing?

Typically, in order to let generic code that needs a default constructor to work unmodified on date/time values.

David Abrahams wrote:

"Peter Dimov" writes:

...

Victor A. Wagner Jr. wrote:

...

why would you want such a thing?

Typically, in order to let generic code that needs a default constructor to work unmodified on date/time values.

Is there much generic code out there that works only on default constructible objects whose other concept requirements are satisfied by dates?

I can only give one example: serialization. The real question is: do the benefits (none from my POV) gained by _not_ supplying a default constructor outweigh the disadvantages?

How about clearer code:

//what does it do -- non-obvious date d; std::cout << d << std::endl;

//obvious... date d(not_a_date_time); std::cout << d << std::endl;

surely coding a default constructor does not prevent you from writing: date d (not_a_date_time); it just gives you the option of not doing so, eg. in generic code that requires a default constructor to be present, and anyway you can always comment those non-obvious lines of code for those who do not know how the library works. jonathan.

"Peter Dimov" writes:

David Abrahams wrote:

...

"Peter Dimov" writes:

...

Victor A. Wagner Jr. wrote:

...

why would you want such a thing?

Typically, in order to let generic code that needs a default constructor to work unmodified on date/time values.

Is there much generic code out there that works only on default constructible objects whose other concept requirements are satisfied by dates?

I can only give one example: serialization.

The real question is: do the benefits (none from my POV) gained by _not_ supplying a default constructor outweigh the disadvantages?

If not_a_date_time is a possible value regardless of whether a default ctor is provided, I guess I can't argue "simpler/stronger invariants". But otherwise, I would argue "simpler/stronger invariants" :) -- Dave Abrahams Boost Consulting http://www.boost-consulting.com