Date_time library question...
With the following line in my Microsoft Vc7 program: std::cout << to_simple_string(d) << std::endl; I get the following linker errors: error LNK2005: "public: __thiscall std::locale::id::id(unsigned int)" (??0id@locale@std@@QAE@I@Z) already defined in stdafx.obj error LNK2005: "private: __thiscall type_info::type_info(class type_info const &)" (??0type_info@@AAE@ABV0@@Z) already defined in LIBCD.lib(typinfo.obj) error LNK2005: "private: class type_info & __thiscall type_info::operator=(class type_info const &)" (?? 4type_info@@AAEAAV0@ABV0@@Z) already defined in LIBCD.lib(typinfo.obj) Clearly I am missing something important! I did put #define DATE_TIME_INLINE in my stdafx.h file and that allowed me to create dates (date d(...)) but clearly something else is needed (for IO related stuff?)... Do I have to for instance recreate the libboost_date_time.lib file with different settings? I just used 'bjam "-sTOOLS=vc7" "- sBUILD=debug release"'. Any help appreciated. Thanks to Jeff Garland and the rest of the Boost group for creating this library - I would really like to use it in my programs from now on but why won't the silly linker oblige!
With the following line in my Microsoft Vc7 program:
std::cout << to_simple_string(d) << std::endl;
I get the following linker errors:
error LNK2005: "public: __thiscall std::locale::id::id(unsigned int)" (??0id@locale@std@@QAE@I@Z) already defined in stdafx.obj
error LNK2005: "private: __thiscall type_info::type_info(class type_info const &)" (??0type_info@@AAE@ABV0@@Z) already defined in LIBCD.lib(typinfo.obj)
error LNK2005: "private: class type_info & __thiscall type_info::operator=(class type_info const &)" (?? 4type_info@@AAEAAV0@ABV0@@Z) already defined in LIBCD.lib(typinfo.obj)
Is this with 1.29 or with the current CVS version? Since these are multiply defined symbols you might think about taking this out of the pre-compiled headers.
Clearly I am missing something important!
I did put
#define DATE_TIME_INLINE
in my stdafx.h file and that allowed me to create dates (date d(...)) but clearly something else is needed (for IO related stuff?)...
Do I have to for instance recreate the libboost_date_time.lib file with different settings? I just used 'bjam "-sTOOLS=vc7" "- sBUILD=debug release"'.
This all looks correct to me except that I'm not sure this has been tried with pre-compiled headers... Jeff
Thanks for the prompt reply.
This was from version 1.29 that I downloaded from Boost.org.
I have been playing with the pieces of the date_time library I need
(the line below, on the other hand, was from one of the date_time
examples) and so far everything seems to be working without my doing
anything unusual or different. So this is good.
BTW are you suggesting the CVS version is more up to date?
--- In Boost-Users@y..., "Jeff Garland"
With the following line in my Microsoft Vc7 program:
std::cout << to_simple_string(d) << std::endl;
I get the following linker errors:
error LNK2005: "public: __thiscall std::locale::id::id(unsigned int)" (??0id@locale@std@@QAE@I@Z) already defined in stdafx.obj
error LNK2005: "private: __thiscall type_info::type_info(class type_info const &)" (??0type_info@@AAE@ABV0@@Z) already defined in LIBCD.lib(typinfo.obj)
error LNK2005: "private: class type_info & __thiscall type_info::operator=(class type_info const &)" (?? 4type_info@@AAEAAV0@ABV0@@Z) already defined in LIBCD.lib (typinfo.obj)
Is this with 1.29 or with the current CVS version? Since these are multiply defined symbols you might think about taking this out of the pre-compiled headers.
Clearly I am missing something important!
I did put
#define DATE_TIME_INLINE
in my stdafx.h file and that allowed me to create dates (date d (...)) but clearly something else is needed (for IO related stuff?)...
Do I have to for instance recreate the libboost_date_time.lib file with different settings? I just used 'bjam "-sTOOLS=vc7" "- sBUILD=debug release"'.
This all looks correct to me except that I'm not sure this has been tried with pre-compiled headers...
Jeff
I have been playing with the pieces of the date_time library I need (the line below, on the other hand, was from one of the date_time examples) and so far everything seems to be working without my doing anything unusual or different. So this is good.
BTW are you suggesting the CVS version is more up to date?
Yes there are some additions and fixes in the CVS version that are not in 1.29. In particular, the way the locale::id static stuff is declared is was moved from a cpp file to an hpp file, which is why I was asking. This was to fix an issue with the VisualAge compiler getting a missing symbol. Oddly in the 1.29 version you should be getting the id symbol from the library so I'm not sure how you are getting a duplicate symbol. I'm still thinking it has something to do with precompiled headers... Jeff
date bogus_date_I_hope(2002,02,29); I was hoping the above date would not be allowed (2002 is not a leap year). However I notice that the date_time library considers this to be Mar 01, 2002. This is reasonable but what if I want the stricter interpretation - i.e, "20020229 is not a valid date". After all the date_time library does not allow 20020232 and a not too unreasonable person might say "Well if 2002029 is converted to 20020301 why isn't 20020232 converted to 20020304." Short of creating my own logic is there a way for the date_time library to not accept invalid dates? I was hoping is_not_a_date() would not allow 20020229. If there isn't a simple way of coercing the right range for dates, is there some document out there that I can point to to say "Hey the decision to wrap a restricted range of invalid dates is quite ok - look at this document (from XYZ)."
date bogus_date_I_hope(2002,02,29);
I was hoping the above date would not be allowed (2002 is not a leap year).
However I notice that the date_time library considers this to be Mar 01, 2002.
Right, this isn't good.
This is reasonable but what if I want the stricter interpretation - i.e, "20020229 is not a valid date".
After all the date_time library does not allow 20020232 and a not too unreasonable person might say "Well if 2002029 is converted to 20020301 why isn't 20020232 converted to 20020304."
Short of creating my own logic is there a way for the date_time library to not accept invalid dates?
Yes. I consider allowing this invalid date a bug which will be fixed.
I was hoping is_not_a_date() would not allow 20020229.
My preference is to prevent construction of 20020229 and thus the only way to get is_not_a_date true is to construct the date explicitly not_a_date_time. Jeff
Thanks for the reply.
Yes it makes MUCH more sense not allowing invalid dates in the first
place.
BTW the same problem seems to happen with dates such as 20020431,
20040230 and so on - if day at end of month is less than 31 it looks
like it is being accepted and wrapped to the next month...
Hate to ask this but here goes! When will the fixed version be
available? I don't mean to be rude, just enquiring!
Thanks again!
--- In Boost-Users@y..., "Jeff Garland"
date bogus_date_I_hope(2002,02,29);
I was hoping the above date would not be allowed (2002 is not a
leap
year).
However I notice that the date_time library considers this to be Mar 01, 2002.
Right, this isn't good.
This is reasonable but what if I want the stricter interpretation - i.e, "20020229 is not a valid date".
After all the date_time library does not allow 20020232 and a not too unreasonable person might say "Well if 2002029 is converted to 20020301 why isn't 20020232 converted to 20020304."
Short of creating my own logic is there a way for the date_time library to not accept invalid dates?
Yes. I consider allowing this invalid date a bug which will be fixed.
I was hoping is_not_a_date() would not allow 20020229.
My preference is to prevent construction of 20020229 and thus the only way to get is_not_a_date true is to construct the date explicitly not_a_date_time.
Jeff
BTW the same problem seems to happen with dates such as 20020431, 20040230 and so on - if day at end of month is less than 31 it looks like it is being accepted and wrapped to the next month...
Yes, the current code is just checking for 'component' out of range values. That is: months < 1 months > 12 days < 1 days > 31 The date as a whole is not validated.
Hate to ask this but here goes! When will the fixed version be available? I don't mean to be rude, just enquiring!
I expect I can get this into CVS in the next week or so. It's not too big a deal. Jeff
participants (2)
-
Jeff Garland -
shaneforbes