gregorian: explicit date::date(date_int_type) ?
Hi, I'm preparing my company's step from C to C++, and when i use boost::date_time::*, there's a great danger to make mistakes like this with boost-1.30.2: #include <time.h> #include <iostream> #include <boost/date_time/posix_time/posix_time.hpp> using namespace boost::posix_time; using namespace boost::gregorian; int main() { time_t now = time(0); try { ptime time(now); // mistake cerr << to_simple_string(time) << endl; } catch (exception const& e) { cerr << "error: " << e.what() << endl; } } The problem is that the time_t in this case is treated as a day-count from which a gregorian::date() is implicitly constructed. When digging through the gregorian::date, i see that the constructors of date_time::date() from date_int_type and date_rep_type protected. So, wouldn't it be better to make the gregorian::date() constructors from date_int_type and date_rep_type explicit, to get a compile-time error with this sample rather than the out-of-range-exception "Year is out of valid range: 1400..10000" ? And another reason to make this constructor explicit might be that date_rep_type is the internal representation of date(), so when constructing date() with a day_count, you have to know the epoch, and then constructing date() should be done explicitly... What do you think about this ? Thanks, Michael Haubenwallner -- Michael Haubenwallner SALOMON Automation GmbH Forschung & Entwicklung A-8114 Friesach bei Graz T +43 3127 200 308 F +43 3127 200 22 mailto:michael.haubenwallner@salomon.at http://www.salomon.at
On Mon, 17 Nov 2003 16:23:14 +0100, Michael Haubenwallner wrote
Hi,
I'm preparing my company's step from C to C++, and when i use boost::date_time::*, there's a great danger to make mistakes like this with boost-1.30.2:
#include <time.h>
#include <iostream> #include <boost/date_time/posix_time/posix_time.hpp>
using namespace boost::posix_time; using namespace boost::gregorian;
int main() { time_t now = time(0);
try { ptime time(now); // mistake
cerr << to_simple_string(time) << endl; } catch (exception const& e) { cerr << "error: " << e.what() << endl; } }
The problem is that the time_t in this case is treated as a day-count from which a gregorian::date() is implicitly constructed.
It would be better to convert things like: ptime time(second_clock::universal_time()); In the next release you can convert from time_t if you insist like this: time_t now_t = time(0); ptime now = from_time_t(now_t);
When digging through the gregorian::date, i see that the constructors of date_time::date() from date_int_type and date_rep_type protected.
So, wouldn't it be better to make the gregorian::date() constructors from date_int_type and date_rep_type explicit, to get a compile-time error with this sample rather than the out-of-range-exception "Year is out of valid range: 1400..10000" ?
And another reason to make this constructor explicit might be that date_rep_type is the internal representation of date(), so when constructing date() with a day_count, you have to know the epoch, and then constructing date() should be done explicitly...
What do you think about this ?
I'll look into it. On first blush this would probably be reasonable. Jeff
On Mon, 17 Nov 2003 10:10:12 -0700, Jeff Garland wrote
On Mon, 17 Nov 2003 16:23:14 +0100, Michael Haubenwallner wrote
Hi,
I'm preparing my company's step from C to C++, and when i use boost::date_time::*, there's a great danger to make mistakes like this with boost-1.30.2: ...code snipped... What do you think about this ?
Jeff Garland replied: I'll look into it. On first blush this would probably be reasonable.
Only thing is when I compile your code (after some modifications for b/c of namespace std usage) on the current CVS I get: test2.cpp: In function `int main()': test2.cpp:14: no matching function for call to `boost::posix_time::ptime::ptime(time_t&)' /home/jeff/devTools/boost_cvs/boost/date_time/posix_time/ptime.hpp:28: candidates are: boost::posix_time::ptime::ptime(const boost::posix_time::ptime&) /home/jeff/devTools/boost_cvs/boost/date_time/posix_time/ptime.hpp:41: boost::posix_time::ptime::ptime(const boost::posix_time::int64_time_rep&) /home/jeff/devTools/boost_cvs/boost/date_time/posix_time/ptime.hpp:38: boost::posix_time::ptime::ptime(boost::gregorian::date) /home/jeff/devTools/boost_cvs/boost/date_time/posix_time/ptime.hpp:35: boost::posix_time::ptime::ptime(boost::gregorian::date, boost::posix_time::time_duration) So which compiler is doing this conversion for you? Jeff
I've "gcc version 2.95.4 20011002 (Debian prerelease)", which might be just a Debian special for 2.95.3 i think, and it does complain like this only if i make this constructor explicit: boost::gregorian::date(const date_int_type& rhs) if i do not, it compiles well. Thx, Haubi Jeff Garland wrote:
On Mon, 17 Nov 2003 10:10:12 -0700, Jeff Garland wrote
On Mon, 17 Nov 2003 16:23:14 +0100, Michael Haubenwallner wrote
Hi,
I'm preparing my company's step from C to C++, and when i use boost::date_time::*, there's a great danger to make mistakes like this with boost-1.30.2: ...code snipped... What do you think about this ?
Jeff Garland replied: I'll look into it. On first blush this would probably be reasonable.
Only thing is when I compile your code (after some modifications for b/c of namespace std usage) on the current CVS I get:
test2.cpp: In function `int main()': test2.cpp:14: no matching function for call to `boost::posix_time::ptime::ptime(time_t&)' /home/jeff/devTools/boost_cvs/boost/date_time/posix_time/ptime.hpp:28: candidates are: boost::posix_time::ptime::ptime(const boost::posix_time::ptime&) /home/jeff/devTools/boost_cvs/boost/date_time/posix_time/ptime.hpp:41: boost::posix_time::ptime::ptime(const boost::posix_time::int64_time_rep&) /home/jeff/devTools/boost_cvs/boost/date_time/posix_time/ptime.hpp:38: boost::posix_time::ptime::ptime(boost::gregorian::date) /home/jeff/devTools/boost_cvs/boost/date_time/posix_time/ptime.hpp:35: boost::posix_time::ptime::ptime(boost::gregorian::date, boost::posix_time::time_duration)
So which compiler is doing this conversion for you?
Jeff _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
-- Michael Haubenwallner SALOMON Automation GmbH Forschung & Entwicklung A-8114 Friesach bei Graz T +43 3127 200 308 F +43 3127 200 22 mailto:michael.haubenwallner@salomon.at http://www.salomon.at
participants (2)
-
Jeff Garland -
Michael Haubenwallner