- Boost - lists.boost.org

Re: [boost] date_time: second_clock and microsec_clock errors
by Roman Yakovenko 28 Nov '05

28 Nov '05

> I'll turn it around the other way. Most instances of > microsecond_clock never > care about the a time_zone to adjust the time. So there is > no reason to drag > in that dependency. But, in fact, the overloading I pointed > out above: > > template<class time_type> > class microsecond_clock { > ... > template<class time_zone_type> > static time_type local_time(shared_ptr<time_zone_type> tz_ptr); > > enables the microsecond clock to use a time zone. When using a > local_date_time type the timezone is required. So it's true, > you'll get a > compile error if you try to call the other overloadings with a > local_date_time, but that's the intent. "... practicality beats purity" It would be nice to have small comment within source code or reference to documentation that explains why this is intent and\or work around to the problem. > Jeff Thanks for help Roman Yakovenko

3 3

Re: [boost] date_time: local_date_time small fix
by Roman Yakovenko 28 Nov '05

28 Nov '05

> > 2. Base class already has those operators, so why do you hide them? > > Unless I'm missing something the base class provides for > comparison to other > local times not ptimes: > > local_date_time l_time1(...), l_time2(...); > if (ltime_1 == ltime_2) {... 1. template<class utc_time_=posix_time::ptime, class tz_type=date_time::time_zone_base<utc_time_> > class local_date_time_base : public date_time::base_time<utc_time_, boost::posix_time::posix_time_system> { 2. template <class T, class time_system> class base_time : private boost::less_than_comparable<T , boost::equality_comparable<T > > { public: typedef T time_type; //!Equality operator -- others generated by boost::equality_comparable bool operator==(const time_type& rhs) const { return time_system::is_equal(time_,rhs.time_); } As you can see date_time::base_time<utc_time_, boost::posix_time::posix_time_system> do provides comparison operator for ptime. > Jeff Roman Yakovenko

1 0

Re: [boost] date_time: local_date_time small fix
by Roman Yakovenko 28 Nov '05

28 Nov '05

> [mailto:boost-bounces@lists.boost.org]On Behalf Of Jeff Garland > > Actually it's intentional to not do an automatic conversion > there. Call > utc_time() to get the ptime. Could you explains the reasons? I see 2 problems with this approach: 1. creation of ptime object on stack, why? 2. Base class already has those operators, so why do you hide them? > Jeff > _______________________________________________ Thanks Roman Yakovenko

2 1

Re: [boost] date_time: second_clock and microsec_clock errors
by Roman Yakovenko 28 Nov '05

28 Nov '05

> [mailto:boost-bounces@lists.boost.org]On Behalf Of Jeff Garland > > [micro]second_clock< boost::local_time::local_date_time_base<> > > > could not be compiled. The problematic function is: private: static > > time_type create_time(::std::tm* current); > > > > The error is that local_date_time_base<> does not have constructors > > that takes date and time duration. > > It's not really a problem. With local_time you need to > provide a timezone > pointer to get a time value. So you call it like this: > //get time in new york time zone: > boost::shared_ptr<time_zone> ny_tz(new > posix_time_zone("EST-05EDT,M4.1.0,M10.5.0")); > > local_date_time ldt3 = local_microsec_clock::local_time(ny_tz); > > > You'll note that there is another overloading in clock > classes for this case: > > template<class time_zone_type> > static time_type local_time(shared_ptr<time_zone_type> tz_ptr); Yes, I discovered work around few days ago. I posted the error here, because I think that this error indicates, that something wrong with design. I think that date_time library should define local_microsec_clock, not in terms of microsec_clock, but using an other class that is aware of time zone. Why is microsec_clock class not aware of time zones? > Jeff Thanks Roman Yakovenko

2 1

date_time: special_value_from_string link error
by Roman Yakovenko 28 Nov '05

28 Nov '05

Hi. Free function special_value_from_string is missing BOOST_DATE_TIME_DECL. This cause link error on windows, vc 7.1, while working with date time library as dll. ( boost version is 1.33.1 beta ) Thanks Roman Yakovenko

2 1

date_time: second_clock and microsec_clock errors
by Roman Yakovenko 28 Nov '05

28 Nov '05

Good morning. I think I found small bug, but I am not sure. ( boost version is 1.33.1 beta ) Description: [micro]second_clock< boost::local_time::local_date_time_base<> > could not be compiled. The problematic function is: private: static time_type create_time(::std::tm* current); The error is that local_date_time_base<> does not have constructors that takes date and time duration. Thanks Roman Yakovenko

2 1

date_time: local_date_time small fix
by Roman Yakovenko 28 Nov '05

28 Nov '05

Good morning. Consider next use case: struct my_ldt : public boost::local_time::local_date_time_base<>{ my_ldt() : boost::local_time::local_date_time_base<>( boost::posix_time::ptime() , boost::shared_ptr< boost::date_time::time_zone_base<boost::posix_time::ptime> >() ) {} }; int _tmain(int argc, _TCHAR* argv[]) { boost::posix_time::ptime t; my_ldt m; m == t; //^^^^^^^^ //this will not compile ( at least on VC 7.1 ) //the error is error C2678: binary '==' : no operator found which takes a left-hand operand of type 'my_ldt' (or there is no acceptable conversion) } fix: Add next code to the local_date_time_base class typedef date_time::base_time<utc_time_, boost::posix_time::posix_time_system> base_type; using base_type::operator==; using base_type::operator<; using base_type::operator-; Thanks Roman Yakovenko

2 1

Boost::factory in new vault?
by Dave Moore 28 Nov '05

28 Nov '05

Is the boost::factory mentioned in this thread available in the new vault anywhere? Is it possible for anyone to upload it? *http://lists.boost.org/boost-users/2005/05/11828.php*<http://lists.boost.org/boost-users/2005/05/11828.php> Thanks, Dave

1 0

Boost.Iostreams - memory leak in zlib filter
by Martin Slater 28 Nov '05

28 Nov '05

Hi there, Just been tracking a memory leak that ended up coming out of the zlib filter. We're using the boost 1.32.0 with the last non integrated verison of iostreams from Jonathans website, I've integrated what appear to be fixes for this leak in the current cvs head but the leak was still there. It seems that line 383 in boost\iostreams\filter\zlib.hpp (cvs head version) should be void zlib_decompressor_impl<Alloc>::close() { reset(false, false); } instead of void zlib_decompressor_impl<Alloc>::close() { reset(false, true); } This makes the leak go away for me, does this seem right? cheers Martin

2 2

[1.33.1][test] missing include problem
by Graham Bennett 28 Nov '05

28 Nov '05

Hi all, When compiling the 1.33.1 beta I noticed that a missing #include is causing a compilation problem: boost/test/impl/plain_report_formatter.ipp is missing a #include <ostream>. I'm using the Roguewave standard library, which often turns this kind of error up as its standard headers don't include quite the same set of files as gcc. It would be great if this could be fixed for the final release of 1.33.1. cheers, Graham -- Graham Bennett

3 2