Could anyone explain to me why there is not a default constructor for boost::gregorian::date_time and boost::posix_time::ptime. I implemented a simple constructor where both classes are created as 'not_a_date_time'. The only problem I have had is compiling my code on other peoples machines that do not have my modification to the date_time library. jonathan
On Tue, 20 Jul 2004 21:30:04 +0100, Jonathan Oulds wrote
Could anyone explain to me why there is not a default constructor for boost::gregorian::date_time and boost::posix_time::ptime.
Yes, you can see this thread: http://lists.boost.org/MailArchives/boost-users/msg05864.php
I implemented a simple constructor where both classes are created as 'not_a_date_time'. The only problem I have had is compiling my code on other peoples machines that do not have my modification to the date_time library.
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. Jeff
"Jeff Garland" <jeff@crystalclearsoftware.com> writes:
On Tue, 20 Jul 2004 21:30:04 +0100, Jonathan Oulds wrote
Could anyone explain to me why there is not a default constructor for boost::gregorian::date_time and boost::posix_time::ptime.
Yes, you can see this thread:
http://lists.boost.org/MailArchives/boost-users/msg05864.php
I implemented a simple constructor where both classes are created as 'not_a_date_time'. The only problem I have had is compiling my code on other peoples machines that do not have my modification to the date_time library.
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. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
On Tue, 20 Jul 2004 17:20:45 -0400, David Abrahams wrote
"Jeff Garland" <jeff@crystalclearsoftware.com> 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 17:20:45 -0400, David Abrahams <dave@boost-consulting.com> wrote:
"Jeff Garland" <jeff@crystalclearsoftware.com> 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. I for one prefer the not_a_date_time option. -- Caleb Epstein caleb.epstein@gmail.com
On Tue, 20 Jul 2004 21:45:19 -0400, Caleb Epstein wrote
On Tue, 20 Jul 2004 17:20:45 -0400, David Abrahams <dave@boost-consulting.com> wrote:
"Jeff Garland" <jeff@crystalclearsoftware.com> 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
Caleb Epstein <caleb.epstein@gmail.com> writes:
On Tue, 20 Jul 2004 17:20:45 -0400, David Abrahams <dave@boost-consulting.com> wrote:
"Jeff Garland" <jeff@crystalclearsoftware.com> 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. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
--- At Wed, 21 Jul 2004 07:47:51 -0400, David Abrahams wrote:
Caleb Epstein <caleb.epstein@gmail.com> writes:
On Tue, 20 Jul 2004 17:20:45 -0400, David Abrahams <dave@boost-consulting.com> wrote:
"Jeff Garland" <jeff@crystalclearsoftware.com> 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
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
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
At Tuesday 2004-07-20 14:20, you wrote:
"Jeff Garland" <jeff@crystalclearsoftware.com> writes:
On Tue, 20 Jul 2004 21:30:04 +0100, Jonathan Oulds wrote
Could anyone explain to me why there is not a default constructor for boost::gregorian::date_time and boost::posix_time::ptime.
Yes, you can see this thread:
http://lists.boost.org/MailArchives/boost-users/msg05864.php
I implemented a simple constructor where both classes are created as 'not_a_date_time'. The only problem I have had is compiling my code on other peoples machines that do not have my modification to the date_time library.
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. if people want not_a_date_time as the value, let 'em use an explicit constructor to say so!
-- Dave Abrahams Boost Consulting http://www.boost-consulting.com
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"
Victor A. Wagner Jr. wrote:
At Tuesday 2004-07-20 14:20, you wrote:
"Jeff Garland" <jeff@crystalclearsoftware.com> 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.
why would you want such a thing? At Tuesday 2004-07-20 13:30, you wrote:
Could anyone explain to me why there is not a default constructor for boost::gregorian::date_time and boost::posix_time::ptime.
I implemented a simple constructor where both classes are created as 'not_a_date_time'. The only problem I have had is compiling my code on other peoples machines that do not have my modification to the date_time library.
jonathan _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"
"Peter Dimov" <pdimov@mmltd.net> 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? -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
David Abrahams wrote:
"Peter Dimov" <pdimov@mmltd.net> 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?
On Wed, 21 Jul 2004 21:00:00 +0300, Peter Dimov wrote
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.
boost::serialization doesn't require a default and we wrote date_time serialization code so that it doesn't use the default constructor. Requiring a default constructor is, however, a weakness of many serialization frameworks...
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; Personally, that's enough for me... Jeff
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.
Jeff Garland wrote:
On Wed, 21 Jul 2004 21:00:00 +0300, Peter Dimov wrote
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;
Personally, that's enough for me...
That's why I said "from my POV". Obviously you can still write the // obvious way. Having a default constructor simply does not _prevent_ the "non-obvious" code from being written. "From my POV", I see little value in these "prevention" features, because I never obfuscate code just because it's allowed. I do know that other viewpoints exist. It's a philosophical issue and the spirit of C++ is to give programmers the benefit of the doubt (i.e. not penalize the "I know what I'm doing" group).
"Peter Dimov" <pdimov@mmltd.net> writes:
David Abrahams wrote:
"Peter Dimov" <pdimov@mmltd.net> 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
participants (7)
-
Caleb Epstein -
David Abrahams -
Duane Murphy -
Jeff Garland -
Jonathan Oulds -
Peter Dimov -
Victor A. Wagner Jr.