dynamic_bitset tests and help request to Metrowerks users
Hi everybody, as promised the dynamic_bitset tests are being _slowly_ settled. My apologies for the very "calm" pace but that's all that my spare time allows me. This morning I've fixed an error caused by VC6's Dinkum Lib. Since the library in this case affects the dynamic_bitset behavior I'd like to ask for you opinion. Try the following program, which attempts to read a string from an *empty* file: #include <iostream> #include <ostream> #include <fstream> #include <string> int main() { using namespace std; ofstream of("a_temporary_file"); of.close(); ifstream f("a_temporary_file"); string s = "help"; f >> s; std::cout << "The string is now " << s << '\n'; std::cout << "(length = " << s.length() << ")\n"; } With VC6's library the string is erase()d. That's because the code in the sentry constructor fails to set an error bit in the stream state if the file is empty. With all other libraries at least eofbit is set (according to lib issue 195 failbit should be set too but many implementations deliberately avoid that; see for instance: http://gcc.gnu.org/ml/libstdc++/2000-q1/msg00086.html); thus bool(sentry_object) is false and the string remains untouched. With dynamic_bitset the situation is exactly the same, as the extractor relies on the underlying library to construct a sentry. Now, the question is: do you see any problems in this? Note that it means attempting to extract a dynamic_bitset from an empty file clears the bitset with VC6's Dinkum while leaves it unchanged on (all) other implementations; however the behavior is consistent with extractions of other types (std::strings) on each platform. Fixing the behavior at the dynamic_bitset extractor level to make it consistent across different standard libraries would be, I think, quite tricky (and ugly). Secondly, a help request. There are some MW errors which I won't be able to fix, as I don't have access to that compiler: http://boost.sourceforge.net/regression-logs/cs-win32_metacomm/output/bin-bo... If anyone wants to submit a patch I'd be more than happy to integrate it. Thanks, Genny.
Gennaro Prota <gennaro_prota@yahoo.com> writes:
Secondly, a help request. There are some MW errors which I won't be able to fix, as I don't have access to that compiler:
http://boost.sourceforge.net/regression-logs/cs-win32_metacomm/output/bin-bo...
Have you tried cwpro9? You can download an evaluation version of that compiler. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
On May 16, 2004, at 5:09 AM, Gennaro Prota wrote:
Secondly, a help request. There are some MW errors which I won't be able to fix, as I don't have access to that compiler:
http://boost.sourceforge.net/regression-logs/cs-win32_metacomm/output/ bin-boost-libs-dynamic_bitset-dyn_bitset_unit_tests1-test-cwpro8- debug.html
### mwcc Compiler: # In: ..\boost\dynamic_bitset\dynamic_bitset.hpp # From: ..\libs\dynamic_bitset\dyn_bitset_unit_tests1.cpp # ---------------------------------------------------------- # 993: return do_count(m_bits.begin(), num_blocks(), Block(0), (mode_to_type<m>*) 0 ); # Error: ^ # illegal non-type template argument # (included from: # dynamic_bitset.hpp:17 # bitset_test.hpp:27 # dyn_bitset_unit_tests1.cpp:12)
I believe this is a compiler error and the only way I'm aware of to work around it is to perform this computation: const bool no_padding = bits_per_block == CHAR_BIT * sizeof(Block); const mode m = table_width >= CHAR_BIT && no_padding ? access_by_bytes : access_by_blocks; using class static const members instead of function-locale const variables.
### mwcc Compiler: # 1419: const ctype<Ch> & fac = BOOST_USE_FACET(ctype<Ch>, os.getloc()); # Error: ^^^^^ # undefined identifier 'ctype' # (included from: # dynamic_bitset.hpp:17 # bitset_test.hpp:27 # dyn_bitset_unit_tests1.cpp:12)
Looks like <locale> is not getting included. -Howard
Thanks Howard and Dave. Reluctantly, I have to hope CW9 has these same bugs as version 8 :) Genny.
On Sun, 16 May 2004 11:04:45 -0400, Howard Hinnant <hinnant@twcny.rr.com> wrote:
I believe this is a compiler error and the only way I'm aware of to work around it is to perform this computation:
const bool no_padding = bits_per_block == CHAR_BIT * sizeof(Block); const mode m = table_width >= CHAR_BIT && no_padding ? access_by_bytes : access_by_blocks;
Sorry for asking again, but I tried CW9.2 evaluation version and it *doesn't* give errors. Since I'm worried that introducing two new class templates can trigger warnings/errors with other compilers, Would it be ok to write e.g. const bool no_padding = bits_per_block == CHAR_BIT * sizeof(Block); const bool table_is_large_enough = table_width >= CHAR_BIT; return do_count( m_bits.begin(), num_blocks(), Block(0), (mode_to_type< (no_padding && table_is_large_enough?) access_by_bytes : access_by_blocks >*) 0 ); ?
using class static const members instead of function-locale const variables.
### mwcc Compiler: # 1419: const ctype<Ch> & fac = BOOST_USE_FACET(ctype<Ch>, os.getloc()); # Error: ^^^^^ # undefined identifier 'ctype' # (included from: # dynamic_bitset.hpp:17 # bitset_test.hpp:27 # dyn_bitset_unit_tests1.cpp:12)
Looks like <locale> is not getting included.
This one is odd. I see that the command line used for regression testing includes "-runtime dmd", and our metrowerks config file has // locale support is disabled when linking with the dynamic runtime # ifdef _MSL_NO_LOCALE # define BOOST_NO_STD_LOCALE # endif Since I test for BOOST_NO_STD_LOCALE before #including it may well be that <locale> is not getting included :) But why everything works with CW 9.2 instead? Can you please confirm that _MSL_NO_LOCALE is defined for version 8.3 and not for 9.2? Thanks, Genny.
Sorry for the delay in replying. On May 23, 2004, at 5:33 AM, Gennaro Prota wrote:
On Sun, 16 May 2004 11:04:45 -0400, Howard Hinnant <hinnant@twcny.rr.com> wrote:
I believe this is a compiler error and the only way I'm aware of to work around it is to perform this computation:
const bool no_padding = bits_per_block == CHAR_BIT * sizeof(Block); const mode m = table_width >= CHAR_BIT && no_padding ? access_by_bytes : access_by_blocks;
Sorry for asking again, but I tried CW9.2 evaluation version and it *doesn't* give errors. Since I'm worried that introducing two new class templates can trigger warnings/errors with other compilers, Would it be ok to write e.g.
const bool no_padding = bits_per_block == CHAR_BIT * sizeof(Block); const bool table_is_large_enough = table_width >= CHAR_BIT;
return do_count( m_bits.begin(), num_blocks(), Block(0), (mode_to_type< (no_padding && table_is_large_enough?) access_by_bytes : access_by_blocks
*) 0 );
?
Yes, I believe this will work.
using class static const members instead of function-locale const variables.
### mwcc Compiler: # 1419: const ctype<Ch> & fac = BOOST_USE_FACET(ctype<Ch>, os.getloc()); # Error: ^^^^^ # undefined identifier 'ctype' # (included from: # dynamic_bitset.hpp:17 # bitset_test.hpp:27 # dyn_bitset_unit_tests1.cpp:12)
Looks like <locale> is not getting included.
This one is odd. I see that the command line used for regression testing includes "-runtime dmd", and our metrowerks config file has
// locale support is disabled when linking with the dynamic runtime # ifdef _MSL_NO_LOCALE # define BOOST_NO_STD_LOCALE # endif
Since I test for BOOST_NO_STD_LOCALE before #including it may well be that <locale> is not getting included :) But why everything works with CW 9.2 instead? Can you please confirm that _MSL_NO_LOCALE is defined for version 8.3 and not for 9.2?
That is correct, for building/using the std::lib in a DLL configuration. When linking statically to the std::lib, _MSL_NO_LOCALE is not defined for either release. When _MSL_NO_LOCALE is defined, that means that facets (such as ctype) don't exist as well. In a nutshell, chapter 22 disappears, along with everything that appears in the <locale> synopsis. -Howard
On Mon, 24 May 2004 10:15:43 -0400, Howard Hinnant <hinnant@twcny.rr.com> wrote:
On May 23, 2004, at 5:33 AM, Gennaro Prota wrote: [...]
Since I test for BOOST_NO_STD_LOCALE before #including it may well be that <locale> is not getting included :) But why everything works with CW 9.2 instead? Can you please confirm that _MSL_NO_LOCALE is defined for version 8.3 and not for 9.2?
That is correct, for building/using the std::lib in a DLL configuration. When linking statically to the std::lib, _MSL_NO_LOCALE is not defined for either release. When _MSL_NO_LOCALE is defined, that means that facets (such as ctype) don't exist as well. In a nutshell, chapter 22 disappears, along with everything that appears in the <locale> synopsis.
I've committed a quick fix now. I'm not proud of it, but let's see if it works first. Among other things, I've simply *disabled* the wchar_t tests when BOOST_NO_STD_LOCALE is defined. I don't like this at all: it implies we have different sets of tests for different platforms and even let libraries that do not support <locale> appear better (in the regression logs) than libraries that support it with some failures. Is there any boost policy for this? Maybe I should put the wchar_t tests in a separate file and mark that one as unusable for platforms with no <locale> support? Still, for Metrowerks that would be a problem, because the library, in general, *does* support locale; it just disables it in some configurations. Genny.
participants (2)
-
David Abrahams -
Gennaro Prota -
Howard Hinnant