[TR1][Hash] New failures?

Anyone any idea what's causing the TR1:Hash tests to fail on the release branch? The TR1 code hasn't changed so I assume that a change in Boost::hash has broken these? Cheers, John.

2009/7/23 John Maddock <john@johnmaddock.co.uk>:
Anyone any idea what's causing the TR1:Hash tests to fail on the release branch? The TR1 code hasn't changed so I assume that a change in Boost::hash has broken these?
Do you mean unordered? The hash tests seem to be passing. I'll have a look into the unordered container failures soon. Daniel

Anyone any idea what's causing the TR1:Hash tests to fail on the release branch? The TR1 code hasn't changed so I assume that a change in Boost::hash has broken these?
Do you mean unordered? The hash tests seem to be passing. I'll have a look into the unordered container failures soon.
Sorry, yes I meant the unordered (hash) containers. Thanks, John.

2009/7/23 John Maddock <john@johnmaddock.co.uk>:
Anyone any idea what's causing the TR1:Hash tests to fail on the release branch? The TR1 code hasn't changed so I assume that a change in Boost::hash has broken these?
I think these are fixed on trunk now, I'll give it another day for more tests to run and then merge if it looks okay. For the record, there were a couple of problems. One was an odd bug in Visual C++ 7.1/8 which I think I've worked around. Although I'm not sure exactly what triggered it. The other problem was that the containers emulate C++0x std::pair constructors, which includes: template<class U, class... Args> pair(U&& x, Args&&... args); This is the best match for input_iterator_archetype's reference type. It converts the argument to key_type instead of value_type which caused the error. I've just removed support for the single argument version and I'll wait to see what the draft without concepts says (concepts would have fixed this). Gcc's version is defined to have at least two arguments so I guess this issue is well known. The constructor should probably also be 'explicit', so that's another thing I'll look out for. Daniel

I think these are fixed on trunk now, I'll give it another day for more tests to run and then merge if it looks okay.
For the record, there were a couple of problems. One was an odd bug in Visual C++ 7.1/8 which I think I've worked around. Although I'm not sure exactly what triggered it.
The other problem was that the containers emulate C++0x std::pair constructors, which includes:
template<class U, class... Args> pair(U&& x, Args&&... args);
This is the best match for input_iterator_archetype's reference type. It converts the argument to key_type instead of value_type which caused the error. I've just removed support for the single argument version and I'll wait to see what the draft without concepts says (concepts would have fixed this). Gcc's version is defined to have at least two arguments so I guess this issue is well known.
The constructor should probably also be 'explicit', so that's another thing I'll look out for.
Thanks Daniel! I appreciate your help in sorting those out, Cheers, John.
participants (2)
-
Daniel James
-
John Maddock