[TR1] Test failures with VC9 + MS TR1
I've run a set of regression tests against Trunk with VC9 and the release MS TR1. Results are @ http://beta.boost.org/development/tests/trunk/developer/tr1.html, under the RW_WinXP_VC runner. A couple of observations: 1) The test_regex\std_test_regex tests are failing because basic_regex doesnt have an 'empty' member. However, the TR1 spec doesnt seem to say that it should? 2) The test file @ "libs/config/test/has_tr1_regex_fail.cpp" says: #ifndef BOOST_HAS_TR1_ARRAY #include "boost_has_tr1_regex.ipp" Shouldnt that be #ifndef BOOST_HAS_TR1_REGEX ? As far as the other failures go: some of them are 'by design' (e.g. is_base_of) due to MS following the current proposed spec rather than sticking to the TR1 draft, but others i'm not sure about (e.g. result_of). Anyone got any thoughts? Thanks, Richard Webb
Richard Webb wrote:
I've run a set of regression tests against Trunk with VC9 and the release MS TR1. Results are @ http://beta.boost.org/development/tests/trunk/developer/tr1.html, under the RW_WinXP_VC runner.
A couple of observations:
Thanks for running these - I'm going to be tied up for a while - can you file any issues on the Trac so they don't get lost? Thanks, John.
John Maddock <john <at> johnmaddock.co.uk> writes:
Thanks for running these - I'm going to be tied up for a while - can you file any issues on the Trac so they don't get lost?
Raised @ http://svn.boost.org/trac/boost/ticket/1790 .
The std_test_regex test is now failing with a different error :( C:\Program Files\Microsoft Visual Studio 9.0\VC\INCLUDE\../include/regex(3543) : error C2676: binary '&&' : 'boost::regex_traits_architype<charT>::char_class_type' does not define this operator or a conversion to a type acceptable to the predefined operator Full error @ http://tinyurl.com/6ktl8c. Any thoughts? Thanks, Richard Webb
Richard Webb wrote:
The std_test_regex test is now failing with a different error :(
:-( Indeed.
C:\Program Files\Microsoft Visual Studio 9.0\VC\INCLUDE\../include/regex(3543) : error C2676: binary '&&' : 'boost::regex_traits_architype<charT>::char_class_type' does not define this operator or a conversion to a type acceptable to the predefined operator
Full error @ http://tinyurl.com/6ktl8c. Any thoughts?
This looks like a bug in the MS/Dinkumware implementation: the typedef char_class_type is required to be a bitmask type, and bitmask types aren't required to support operator&&. The only thing I haven't checked is the latest draft std: the website isn't responding at present :-( Regards, John.
John Maddock <john <at> johnmaddock.co.uk> writes:
This looks like a bug in the MS/Dinkumware implementation: the typedef char_class_type is required to be a bitmask type, and bitmask types aren't required to support operator&&. The only thing I haven't checked is the latest draft std: the website isn't responding at present
I've asked about this (and a couple of other failures on the Visual C++ blog. The MS response is @ http://blogs.msdn.com/vcblog/archive/2008/04/07/visual-c-2008-feature-pack-r... To confirm i've got the right idea about the failure: The test that's failing is using the tr1 basic_regex along with a boost traits class. The boost traits class uses a bitset for the char_class_type, whereas the MS version uses an int. The failure is then because the MS regex can't handle a bitset as the char_class_type, due to the lack of an operator&& ? The only other failure outside type_traits that i haven't raised yet is in result_of (http://tinyurl.com/5gg58e). I haven't used result_of and i'm not sure what problem the failure indicates. Does anyone have any other thoughts about it? Thanks, Richard Webb
Richard Webb wrote:
To confirm i've got the right idea about the failure: The test that's failing is using the tr1 basic_regex along with a boost traits class. The boost traits class uses a bitset for the char_class_type, whereas the MS version uses an int. The failure is then because the MS regex can't handle a bitset as the char_class_type, due to the lack of an operator&& ?
Correct, bitsets (and bitmask types in general) aren't required to support operator&&.
The only other failure outside type_traits that i haven't raised yet is in result_of (http://tinyurl.com/5gg58e). I haven't used result_of and i'm not sure what problem the failure indicates. Does anyone have any other thoughts about it?
Looks like a bug in the MS implementation to me, the test case appears to be something like: typedef int (&func_ref)(float, double); typedef result_of<function_ref(float,double)>::type result_type; // error here. HTH, John.
John Maddock <john <at> johnmaddock.co.uk> writes:
Looks like a bug in the MS implementation to me, the test case appears to be something like:
typedef int (&func_ref)(float, double); typedef result_of<function_ref(float,double)>::type result_type; // error here.
Thanks. Following on with the type_traits failures with is_polymorphic (http://tinyurl.com/6jq57y): If you have: class foo { public: virtual ~foo() { } }; class bar : virtual public foo { public: virtual ~bar() { } }; Then boost::is_polymorphic<bar> is true, but mstr1::is_polymorphic<bar> is false. If i either: -make foos destructor non-virtual -add an additional virtual method to bar -change the defintion of bar to 'class bar : public foo' then mstr1::is_polymorphic<bar> becomes true. MS Bug? Thanks, Richard Webb
Richard Webb wrote:
Following on with the type_traits failures with is_polymorphic (http://tinyurl.com/6jq57y):
If you have:
class foo { public: virtual ~foo() {
} };
class bar : virtual public foo { public: virtual ~bar() {
} };
Then boost::is_polymorphic<bar> is true, but mstr1::is_polymorphic<bar> is false.
If i either: -make foos destructor non-virtual -add an additional virtual method to bar -change the defintion of bar to 'class bar : public foo'
then mstr1::is_polymorphic<bar> becomes true. MS Bug?
Most strange, yes it looks like a bug to me, I mean the class is defininely polymorphic right? In any case *removing* a virtual destructor surely can't move a class from non-polymorphic to polymorphic ! :-) John.
participants (2)
-
John Maddock -
Richard Webb