Re: [dynamic_bitset] Stream extraction failures on CodeWarrior 9.4
--- Doug Gregor <dgregor@cs.indiana.edu> wrote:
The stream extraction operators for dynamic_bitset are failing on CodeWarrior 9.4. See: http://tinyurl.com/addko Is anyone familiar enough with the quirks of Metrowerks' iostreams to fix this issue?
Hi Doug, Jeremy and Howard unfortunately, due to a series of vicissitudes that would be too long to tell, I have no home connection at the moment (a situation that lasts from several months) and thus I can't work on CVS. Howard Hinnant is probably the person who knows Metrowerks compiler and library best. Howard? -- Genny. Yahoo! Mail Stay connected, organized, and protected. Take the tour: http://tour.mail.yahoo.com/mailtour.html
On May 10, 2005, at 5:41 AM, Gennaro Prota wrote:
--- Doug Gregor <dgregor@cs.indiana.edu> wrote:
The stream extraction operators for dynamic_bitset are failing on CodeWarrior 9.4. See: http://tinyurl.com/addko Is anyone familiar enough with the quirks of Metrowerks' iostreams to fix this issue?
Hi Doug, Jeremy and Howard
unfortunately, due to a series of vicissitudes that would be too long to tell, I have no home connection at the moment (a situation that lasts from several months) and thus I can't work on CVS. Howard Hinnant is probably the person who knows Metrowerks compiler and library best. Howard?
I know the Metrowerks library inside/out. I started looking at this last night but I'm pretty lost in the test code. Here's what I have so far: Failure inside of: template<typename Stream, typename String> static void stream_extractor(Bitset& b, Stream& is, String& str ) at: if(stream_was_good) BOOST_CHECK(remainder == str.substr(after_digits)); At this point remainder is a zero-length string, after_digits is 0 and str is length 359. On entry to this routine b has length 1 and that element is true. I believe, but I am not positive that str is unmodified through this test, despite being passed by reference (as opposed to const ref). I've so far been unable to determine the state of the stream is on entry. But it looks completely hosed by the time the BOOST_CHECK is triggered. For example the iostate has the value 0x7E even though the highest numerical state it can possibly have is 0x07. did_throw is false. -Howard
On May 10, 2005, at 5:41 AM, Gennaro Prota wrote:
--- Doug Gregor <dgregor@cs.indiana.edu> wrote:
The stream extraction operators for dynamic_bitset are failing on CodeWarrior 9.4. See: http://tinyurl.com/addko Is anyone familiar enough with the quirks of Metrowerks' iostreams to fix this issue?
Hi Doug, Jeremy and Howard
unfortunately, due to a series of vicissitudes that would be too long to tell, I have no home connection at the moment (a situation that lasts from several months) and thus I can't work on CVS. Howard Hinnant is probably the person who knows Metrowerks compiler and library best. Howard?
This is preliminary, but I'm currently thinking this is compiler error. The following local array: std::string strings[] = { // NOTE: "const" gives the usual problems with Borland // (in Tests::stream_extractor instantiation) #if !(defined __BORLANDC__ \ && BOOST_WORKAROUND(BOOST_RWSTD_VER, BOOST_TESTED_AT(0x20101))) // Borland 5.5.1 with RW library crashes // empty string std::string(""), // no bitset spaces, #endif // no bitset std::string("x"), std::string("\t xyz"), // bitset of size 1 std::string("0"), std::string("1"), std::string(" 0 "), std::string(" 1 "), spaces + "1", "1" + spaces, spaces + "1" + spaces, std::string(" x1x "), std::string(" 1x "), // long bitset long_string, " " + long_string + " xyz", spaces + long_string, spaces + long_string + spaces }; in run_test_cases() appears to get destructed right after it is constructed. I haven't figured out what the trigger is yet. I haven't been able to reproduce the symptom in a smaller example, and it doesn't appear to happen with the other strings[] local array: std::string strings[] = { std::string(""), std::string("0"), std::string("1"), std::string("11100"), get_long_string() }; Destruction of "short" strings is harmless as we're using the short string optimization. But once you hit strings[13] (corresponding to the long_string entry) then the test starts working with a string with entries other than '0' and '1', and things pretty much fall apart. A workaround is to declare the strings[] array static. I've sent a test case to the compiler team and if they turn up any further information or workarounds I'll pass it on here. -Howard
participants (2)
-
Gennaro Prota -
Howard Hinnant