John Maddock wrote:

Markus Schöpflin wrote:

...

I would gladly help, but I have no idea what you would exactly like to have removed. If you're referring to the multiset failure, I don't see any typecast involved in the test code. Could you please be more specific?

In:

../libs/mpl/test/multiset.cpp:61: error: '(((int)boost::mpl::count_impl<boost::mpl::aux::multiset_tag>::apply<boost::mpl::multiset0<0>, int>::value) == 0)' is not a valid template argument for type 'bool' because it is a non-constant expression

I have a suspicion that's it's complaining because of the cast to (int). But I could be completely wrong!

Hmm, I think this is completely beyond me. I can't even find where that cast to int comes from. Here is the preprocessed source code for reference: enum { mpl_assertion_in_line_61 = sizeof( boost::mpl::assertion_failed<(( count<typename T::s0,int>::value ) == 0)>( (boost::mpl::failed ************ ( boost::mpl::assert_relation\ < boost::mpl::assert_::relations( sizeof( boost::mpl::assert_::arg == boost::mpl::assert_::arg ) ) , ( count<typename T::s0,int>::value ) , 0

::************)) 0 ) ) };

Maybe this helps anyone to point me in the right direction. Markus

On 2006-10-18, John Maddock <john@johnmaddock.co.uk> wrote:

Markus Schöpflin wrote:

...

John Maddock wrote: Hmm, I think this is completely beyond me. I can't even find where that cast to int comes from. Here is the preprocessed source code for reference: Hmm, I managed to find a copy of gcc-4.1 to test with, and this completely perplexes me too. In fact I can't find *anything* in the mpl sources or tests that look like the code in the error message!

I'm pretty sure it's a compiler bug. The code in question is below (with my little bit added): template< typename T > void count_test() { #if DEFINE_THIS_TO_MAKE_THE_TEST_COMPILE enum { v1 = count<typename T::s0,int>::value }; enum { v2 = count<typename T::s1,int>::value }; enum { v3 = count<typename T::s2,int>::value }; enum { v4 = count<typename T::s2,char&>::value }; enum { v5 = count<typename T::s3,int>::value }; enum { v6 = count<typename T::s3,char&>::value }; enum { v7 = count<typename T::s4,abstract>::value }; #endif MPL_ASSERT_RELATION( ( count<BOOST_DEDUCED_TYPENAME T::s0,int>::value ), ==, 0 ); MPL_ASSERT_RELATION( ( count<BOOST_DEDUCED_TYPENAME T::s1,int>::value ), ==, 1 ); MPL_ASSERT_RELATION( ( count<BOOST_DEDUCED_TYPENAME T::s2,int>::value ), ==, 1 ); MPL_ASSERT_RELATION( ( count<BOOST_DEDUCED_TYPENAME T::s2,char&>::value ), ==, 1 ); MPL_ASSERT_RELATION( ( count<BOOST_DEDUCED_TYPENAME T::s3,int>::value ), ==, 2 ); MPL_ASSERT_RELATION( ( count<BOOST_DEDUCED_TYPENAME T::s3,char&>::value ), ==, 1 ); MPL_ASSERT_RELATION( ( count<BOOST_DEDUCED_TYPENAME T::s4,abstract>::value ), ==, 1 ); } If you enable the #if'd code, then the test compiles fine; if you don't then you get that strange error. It shouldn't, of course, make any difference... phil -- change name before "@" to "phil" for email

On 2006-10-20, Phil Richards <news@derived-software.ltd.uk> wrote:

On 2006-10-19, Phil Richards <news@derived-software.ltd.uk> wrote:

...

On 2006-10-18, John Maddock <john@johnmaddock.co.uk> wrote:

...

Hmm, I managed to find a copy of gcc-4.1 to test with, and this completely perplexes me too. In fact I can't find *anything* in the mpl sources or tests that look like the code in the error message! I'm pretty sure it's a compiler bug. The code in question is below (with my little bit added): Raised as http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29525

Turns out somebody beat me to it by a day with a subject line that I didn't quite understand :-) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29518 phil -- change name before "@" to "phil" for email

Janek Kozicki wrote:

I clicked one of the errors there and saw at the end that:

"[The content has been trimmed by the report system because it exceeds 65536 bytes]"

is it possible to see whole error output?

You might want to try and download the complete result file of the regression test runner and check if the output is truncated there as well. You can find these files at ftp://fx.meta-comm.com/boost-regression/RC_1_34_0. HTH, Markus

Robert Ramey wrote:

...

The largest block is for the serialisation lib, at least one of the errors appears to be due to http://support.microsoft.com/kb/883655 which requires splitting the .cpp file into smaller blocks as a workaround.

This is an old issue with the vc 6 compiler. In the past I made some attempts to make these tests pass by jiggering the tests but it became clear that beyond a certain point started to "teach the test".

So in this case, the test result should be interpreted as "this compiler can't support the serialization in this context" and hence the test is marked expected failure. I believe that this is the correct thing to do and requires no further action.

It's failing with VC-7 as well, so the markup needs updating? See http://cvs.sourceforge.net/viewcvs.py/*checkout*/boost/boost/libs/serializat... There are also 5 VC-6.5 failures with unresolved externals which aren't marked up, see http://cvs.sourceforge.net/viewcvs.py/*checkout*/boost/boost/libs/serializat... for a typical example.

FWIW - from time to time, these tests start passing spontaneously. Interesting - but still no call to action.

In the latest test matrix, there are couple of failures that seem related to some aspect of the boost test system. I don't believe these can be addressed from withing the serialization library test suite.

Hmm, I see this one http://tinyurl.com/ybxxnt which has an uncaught exception: "std::exception: invalid signature" Do you know what's causing the exception to be thrown?

The only real issues I see are:

a) tweak of pending markup for new borland compiler which fails a test the previous one didn't - test_variant.

Yep, the problem symbol (_Stz) appears to be in <iosfwd> so whatever the issue is, it's not down to you. Please mark them up so we don't waste time trying to track these down.

b) (Not one the matrix) An issue with the correct macro to use with STLPort to signal/detect the existence of hashed containers. The code works - but the test fails. I've never been able to figure this out.

BOOST_HAS_HASH refers to the SGI style hashed containers, is that what STLport has (I would expect so). Otherwise there's always: defined(__SGI_STL_PORT) || defined(_STLPORT_VERSION) Thanks, John.

Vladimir Prus wrote:

Speaking up: there are two failures of program_options on borland, and I have no idea what's borland that is, how to get it, and what the failure is about.

Borland's Turbo C++ is now a free download from somewhere or other. But... making the two overloads of variable_value::as class-inline fixes the problem, evidently the compiler doesn't instantiate template member functions otherwise :-( John.