[date_time] a possible bug in date_facet.hpp
Three date_time library tests: testgreg_wstream, testparse_date and teststreams -- are marked as failures on Tru64 because of the bug in version v2.0 of the Rogue Wave library: The failure is caused by a standard library bug. The end-of-stream istream iterator can only be constructed when the istream iterator has been instantiated with char as the character type. This has been reported to the compiler vendor. I fixed this bug last fall, but the fix did not make the compiler release for Tru64 (it did make AlphaVMS release; the versions of RW library on iVMS and HP-UX do not have this bug). While investigating the failures of date_time library tests on HP-UX, I ran three tests above on Tru64 using library with the fix. Test testparse_date succeeded, teststreams failed to compile for some unrelated reasons and testgreg_wstream.cpp failed to compile as the following: cxx: Error: ../boost/date_time/date_facet.hpp, line 641: no operator "+" matches these operands operand types are: const char [35] + boost::date_time::parse_match_result<wchar_t>::string_type The offending line in date_facet.hpp is: throw std::ios_base::failure("Parse failed. No match found for '" + mr.cache + "'"); As far as I can tell, in the case of testgreg_wstream.cpp, mr.cache is std::wstring, and, of course, no "+" operator exists for a narrow string literal and std::wstring. Since std::ios_base::failure() expects "const std::string&", I think, you'd need to go through codecvt::out() or equivalent here, to convert wstring to string. Test testgreg_wstream also fails to compile, for exactly the same reason, on Linux with g++ 3.2.3 and Intel 9.0 and on HP-UX with aCC6 (with aCC6, there is additional compilation error "responsible" for failures of other date_time library tests on this platform). So, is it a bug in date_facet.hpp or I'm missing something? Or, may be, a bad test? Boris
Boris Gubenko wrote:
Three date_time library tests: testgreg_wstream, testparse_date and teststreams -- are marked as failures on Tru64 because of the bug in
...details snipped...
So, is it a bug in date_facet.hpp or I'm missing something? Or, may be, a bad test?
Hi Boris -- Good catch on this, it is indeed a bug in the new facet code. The thing is, it never shows up in the regression tests because those wide stream tests are run using the old date-time i/o code -- I think we must have forgot to include both variations. Anyway, if you look at the Jamfile you'll see it uses the following define: <define>USE_DATE_TIME_PRE_1_33_FACET_IO when compiling those tests (or alternatively from libs/date_time/test you can say bjam --verbose-test testgreg_wstream and the flags will be set for you). So actually, whatever errors that are showing up in these regression tests aren't coming out of the code that you are pointing out. There's a set of alternative i/o code that was developed is contained mostly in xyz_limited.hpp files that should be in effect for these particular tests. So, in short, there's a bug in the new code that I'm going to fix, but it isn't causing the current regression failures you're seeing. BTW, this is one of the reason I want to rid myself of maintaining these old compilers -- the i/o code is tricky enough and hard enough without having 2 versions with different levels of ability. Jeff
Jeff Garland wrote:
So, in short, there's a bug in the new code that I'm going to fix, but it isn't causing the current regression failures you're seeing.
I know. I was just trying to see what will happen with date_time library tests on the two HP platforms -- Tru64 and HP-UX -- when you get rid of the old I/O code conditionlized with USE_DATE_TIME_PRE_1_33_FACET_IO macro. I think, that after the fix in date_facet.hpp, Tru64 will be fine: the tests compile cleanly without the USE_DATE_TIME_PRE_1_33_FACET_IO macro defined except teststreams.cpp which is missing: #include "boost/date_time/gregorian/greg_facet.hpp" Currently, teststreams.cpp does not compile without the USE_DATE_TIME_PRE_1_33_FACET_IO macro defined not only on Tru64 with cxx, but, also, on Linux with either Intel compiler or g++. When I add missing '#include', it compiles cleanly on all of the above. There is a general problem with date_time library tests HP-UX: the tests fail to compile with the same compilation error. I'm looking into it. Boris Gubenko ----- Original Message ----- From: "Jeff Garland" <jeff@crystalclearsoftware.com> To: <boost@lists.boost.org> Cc: "Boris Gubenko" <Boris.Gubenko@hp.com> Sent: Thursday, June 15, 2006 11:48 AM Subject: Re: [boost] [date_time] a possible bug in date_facet.hpp
Boris Gubenko wrote:
Three date_time library tests: testgreg_wstream, testparse_date and teststreams -- are marked as failures on Tru64 because of the bug in
...details snipped...
So, is it a bug in date_facet.hpp or I'm missing something? Or, may be, a bad test?
Hi Boris --
Good catch on this, it is indeed a bug in the new facet code. The thing is, it never shows up in the regression tests because those wide stream tests are run using the old date-time i/o code -- I think we must have forgot to include both variations. Anyway, if you look at the Jamfile you'll see it uses the following define:
<define>USE_DATE_TIME_PRE_1_33_FACET_IO
when compiling those tests (or alternatively from libs/date_time/test you can say bjam --verbose-test testgreg_wstream and the flags will be set for you).
So actually, whatever errors that are showing up in these regression tests aren't coming out of the code that you are pointing out. There's a set of alternative i/o code that was developed is contained mostly in xyz_limited.hpp files that should be in effect for these particular tests.
So, in short, there's a bug in the new code that I'm going to fix, but it isn't causing the current regression failures you're seeing. BTW, this is one of the reason I want to rid myself of maintaining these old compilers -- the i/o code is tricky enough and hard enough without having 2 versions with different levels of ability.
Jeff
participants (2)
-
Boris Gubenko -
Jeff Garland