[date_time] default constructor for period?
I would like to use this: std::deque<boost::posix_time::time_period> But std::deque depends on (as does some of my other code) it's type having a default constructor. I'm surprised it does not already exists. An implementation that seems to work for me is trivial, although I'm not sure it will work for everyone? My changes to 'boost/date_time_time_period.hpp' follow. I have guarded them with DATE_TIME_NO_DEFAULT_CONSTRUCTOR and simply set begin to point_type() and end to begin_ -1; Is this a change worth an eventual release? Thanks, SB --- a/period.hpp 2015-04-29 15:13:28.040930833 -0700 +++ b/period.hpp 2015-04-29 15:15:01.201392793 -0700 @@ -57,6 +57,9 @@ typedef point_rep point_type; typedef duration_rep duration_type; +#if !defined(DATE_TIME_NO_DEFAULT_CONSTRUCTOR) + period(); +#endif // DATE_TIME_NO_DEFAULT_CONSTRUCTOR period(point_rep first_point, point_rep end_point); period(point_rep first_point, duration_rep len); point_rep begin() const; @@ -82,6 +85,16 @@ point_rep last_; }; +#if !defined(DATE_TIME_NO_DEFAULT_CONSTRUCTOR) + //! default constructor + template<class point_rep, class duration_rep> + inline + period<point_rep,duration_rep>::period() : + begin_(point_type()), + last_(begin_ - duration_rep::unit()) + {} +#endif // DATE_TIME_NO_DEFAULT_CONSTRUCTOR + //! create a period from begin to last eg: [begin,end) /*! If end <= begin then the period will be invalid */ -- Scott Bailey
On Thu, Apr 30, 2015 at 12:27 AM, Scott Bailey <Bailey@insanegenius.org> wrote:
My changes to 'boost/date_time_time_period.hpp' follow. I have guarded them with DATE_TIME_NO_DEFAULT_CONSTRUCTOR and simply set begin to point_type() and end to begin_ -1;
Shouldn't end_ == begin_?
Olaf, Sort of, my pseudocode is wrong, but my patch works: last_ is set to begix_ - 1. end() is a function that returns last+1. At least it works on my linux. SB On Thu, Apr 30, 2015 at 4:56 AM, Olaf van der Spek <ml@vdspek.org> wrote:
On Thu, Apr 30, 2015 at 12:27 AM, Scott Bailey <Bailey@insanegenius.org> wrote:
My changes to 'boost/date_time_time_period.hpp' follow. I have guarded them with DATE_TIME_NO_DEFAULT_CONSTRUCTOR and simply set begin to point_type() and end to begin_ -1;
Shouldn't end_ == begin_?
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- Scott Bailey
But std::deque depends on (as does some of my other code) it's type having a default constructor. I'm surprised it does not already exists.
In what situation are you finding the std::deque requires an object to be default constructible? As far as I know this is simply not true for any std containers so I'd like to know how you've happened upon this. -- chris
Chris, Yes, you are right! It wasn't std::deque I had the problem with. In fact, it was std::map; specifically operator[](). Technically, I could work around that by using insert() and testing the return value and, if necessary, calling operator[](). But that's neither very elegant nor maintainable, in my opinion. Especially when I've yet to see a downside of adding a default constructor. Furthermore, I have other other container code that depends on default constructors. Sure, I could workaround period's lack of default constructor, but wheres the advantage in that? SB On Thu, Apr 30, 2015 at 11:31 AM, Chris Glover <c.d.glover@gmail.com> wrote:
But std::deque depends on (as does some of my other code) it's type
having
a default constructor. I'm surprised it does not already exists.
In what situation are you finding the std::deque requires an object to be default constructible? As far as I know this is simply not true for any std containers so I'd like to know how you've happened upon this.
-- chris
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- Scott Bailey
Chris,
Yes, you are right! It wasn't std::deque I had the problem with. In fact, it was std::map; specifically operator[](). Technically, I could work around that by using insert() and testing the return value and, if necessary, calling operator[](). But that's neither very elegant nor maintainable, in my opinion. Especially when I've yet to see a downside of adding a default constructor.
Furthermore, I have other other container code that depends on default constructors. Sure, I could workaround period's lack of default constructor, but wheres the advantage in that?
SB
Hi Scott, Yes, using operator[] requires the object to be default constructible Working around that requires doing some sort of find first. Something like this (or possibly more efficiently with lower_bound if your items are equality comparable). auto iter = map.find(key); if(iter == map.end()) map.insert(make_pair(key, item)); else *iter = item; At any rate, I am not sure why the original authors decided that this type should not be default constructible. I think most value-like types should be, but not always, so it's not clear if this is an oversight or intentional. Someone with more knowledge of the library might know. I was more interested in that specific deque problem you were having. -- chris
participants (3)
-
Chris Glover
-
Olaf van der Spek
-
Scott Bailey