Problems Using boost:date_time library
I recently tried some simple tests of the Boost date-time library (Boost 1.30.0 MSVC6) and ran into problems. I don't have the original code in front of me (unfortunately I left it at work), but more or less, it looked like this: #include "boost/date_time/gregorian/gregorian.hpp" #include <iostream> int main() { using namespace boost::gregorian; date today = day_clock::local_day(); month_iterator it(today); std::advance(it, 3); std::string strDate(to_simple_string(*it)); std::cout << "New date is " << strDate << std::endl; return 0; } The first problem I ran into was that I got a linker error because the class greg_month (in greg_month.hpp) did not provide definitions for the following member functions: const char* as_short_string() const; const char* as_long_string() const; I quicky wrote some inline switch statements to get past that hurdle, but then the compiler started complaining when I tried to use std::advance. It is unfortunate that I do not have the exact error in front of me right now, but I did trace the problem to the definition of month_iterator. I found that if I derived its base implementation class from the class template iterator that it would compile without problems. Is this a problem with the STL that ships with MSVC6? Anyway, I was wondering if maybe there was something I had not set up correctly with my compiler that was causing me to get these errors. Any help would be appreciated. Carl Waldbieser waldbie(at-sign-goes-here)attglobal.net
The first problem I ran into was that I got a linker error because the class greg_month (in greg_month.hpp) did not provide definitions for the following member functions:
const char* as_short_string() const; const char* as_long_string() const;
I quicky wrote some inline switch statements to get past that hurdle, but
This isn't the way to handle this. You will need to build and link the library (libboost_date_time). If you cd to libs/date_time/build and run bjam that will take care of it.
then the compiler started complaining when I tried to use std::advance. It is unfortunate that I do not have the exact error in front of me right now, but I did trace the problem to the definition of month_iterator. I found that if I derived its base implementation class from the class template iterator that it would compile without problems. Is this a problem with the STL that ships with MSVC6?
Unclear without the detail. The regression tests for MSVC6 do pass, so there is hope. Jeff
Ah! I had thought it was just a "header file only" library. Whoops. That
did fix the first problem. I tried switching to STLPort, and this time I
copied the errors from the compiler. I guess that answers my question
whether it was an STL specific problem. There is really no reason I have to
use advance(), but I believe a model of Input Iterator should work with it.
Carl Waldbieser
Error follows:
C:\Documents and Settings\waldbcar.WALDBCAR\My Documents\My
Projects\VC\stlport\STLport-4.5.3\stlport\stl/_iterator_base.h(443) :
error C2664:
'struct _STL::random_access_iterator_tag __cdecl
_STL::iterator_category(const struct _STL::_Bit_iterator_base &)' :
cannot convert parameter 1 from
'class boost::date_time::date_itr
This isn't the way to handle this. You will need to build and link the library (libboost_date_time). If you cd to libs/date_time/build and run bjam that will take care of it.
then the compiler started complaining when I tried to use std::advance.
is unfortunate that I do not have the exact error in front of me right now, but I did trace the problem to the definition of month_iterator. I found that if I derived its base implementation class from the class template iterator that it would compile without problems. Is this a problem with
STL that ships with MSVC6?
Unclear without the detail. The regression tests for MSVC6 do pass, so
It the there
is hope.
whether it was an STL specific problem. There is really no reason I have to use advance(), but I believe a model of Input Iterator should work with it.
I see what is happening, there is probably something about the iterator that is non-standard that is preventing advance from working correctly. Converting the iterator to use iterator adaptors so that conformance is better has been on my todo for about a year now, so you might have to avoid advance for awhile. Sorry about that... Jeff
participants (2)
-
Carl Waldbieser -
Jeff Garland