detail/iterator.hpp: workaround_test fails with two-phase lookup (+ patch)
On compilers with two-phase lookup (CW*) the workaround_test (range lib) fails because of incorrect typedefs in iterator.hpp. (Yes, I know it's very strange to disable partial specialization on a compiler with two-phase lookup.) OK to commit this patch for detail/iterator.hpp? Stefan Index: iterator.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/detail/iterator.hpp,v retrieving revision 1.30 diff -u -r1.30 iterator.hpp --- iterator.hpp 26 Jul 2004 00:31:59 -0000 1.30 +++ iterator.hpp 5 Aug 2004 09:35:08 -0000 @@ -334,8 +334,8 @@ : std::iterator_traits<Iterator> { typedef typename std::iterator_traits<Iterator>::distance_type difference_type; - typedef value_type* pointer; - typedef value_type& reference; + typedef typename std::iterator_traits<Iterator>::value_type* pointer; + typedef typename std::iterator_traits<Iterator>::value_type& reference; }; template <class Iterator> @@ -343,8 +343,8 @@ : std::iterator_traits<Iterator> { typedef typename std::iterator_traits<Iterator>::distance_type difference_type; - typedef const value_type* pointer; - typedef const value_type& reference; + typedef const typename std::iterator_traits<Iterator>::value_type* pointer; + typedef const typename std::iterator_traits<Iterator>::value_type& reference; }; # ifdef BOOST_BAD_OUTPUT_ITERATOR_SPECIALIZATION
Stefan Slapeta <stefan@slapeta.com> writes:
On compilers with two-phase lookup (CW*) the workaround_test (range lib) fails because of incorrect typedefs in iterator.hpp. (Yes, I know it's very strange to disable partial specialization on a compiler with two-phase lookup.)
OK to commit this patch for detail/iterator.hpp?
Well, in principle the patch is OK, but whatever you're doing that's causing that code to be compiled with CW8 is emphatically *NOT* OK. At best it represents a deadly ODR trap. So I'd rather not see you make any changes to detail/iterator.hpp -- that part of the code is not meant for conforming compilers. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
David Abrahams wrote:
Well, in principle the patch is OK, but whatever you're doing that's causing that code to be compiled with CW8 is emphatically *NOT* OK. At best it represents a deadly ODR trap.
So I'd rather not see you make any changes to detail/iterator.hpp -- that part of the code is not meant for conforming compilers.
Sorry, as I thought it was harmless I as I wanted to see the results for it in the next run, I commited it before I read your mail. Shall I remove it again? What I'll do anyway is to disable this workaround test for all compilers that support partial specialization. Stefan
Stefan Slapeta <stefan@slapeta.com> writes:
David Abrahams wrote:
Well, in principle the patch is OK, but whatever you're doing that's causing that code to be compiled with CW8 is emphatically *NOT* OK. At best it represents a deadly ODR trap. So I'd rather not see you make any changes to detail/iterator.hpp -- that part of the code is not meant for conforming compilers.
Sorry, as I thought it was harmless I as I wanted to see the results for it in the next run, I commited it before I read your mail. Shall I remove it again?
It is basically harmless, so you can leave it there unless it causes problems.
What I'll do anyway is to disable this workaround test for all compilers that support partial specialization.
I'm still highly suspicious that something is wrong whether or not the test is enabled. What could cause that code to be compiled by CW? -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
On Thu, Aug 05, 2004 at 09:48:32AM -0600, David Abrahams wrote:
What I'll do anyway is to disable this workaround test for all compilers that support partial specialization.
I'm still highly suspicious that something is wrong whether or not the test is enabled. What could cause that code to be compiled by CW?
I think it's line 19 in libs/range/test/partial_workaround.cpp, which says: #define BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION 1 for all compilers, unconditionally. This causes a few failures for GCC 3.4, because it takes code paths that aren't meant for it. jon -- "Those who don't understand UNIX are doomed to reinvent it, poorly." - Henry Spencer
Jonathan Wakely <cow@compsoc.man.ac.uk> writes:
On Thu, Aug 05, 2004 at 09:48:32AM -0600, David Abrahams wrote:
What I'll do anyway is to disable this workaround test for all compilers that support partial specialization.
I'm still highly suspicious that something is wrong whether or not the test is enabled. What could cause that code to be compiled by CW?
I think it's line 19 in libs/range/test/partial_workaround.cpp, which says:
#define BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION 1
for all compilers, unconditionally.
This causes a few failures for GCC 3.4, because it takes code paths that aren't meant for it.
Well, that's just wrong. The right way to handle this is to write: #if BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION // the test code you have now #else // something simple that always passes. #endif As an optimization you can mark the test not to be run on most compilers. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
David Abrahams wrote:
The right way to handle this is to write:
#if BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION
// the test code you have now
#else
// something simple that always passes.
#endif
Done.
As an optimization you can mark the test not to be run on most compilers.
IIRC that's only possible in the jamfiles, isn't it? Stefan
Stefan Slapeta <stefan@slapeta.com> writes:
As an optimization you can mark the test not to be run on most compilers.
IIRC that's only possible in the jamfiles, isn't it?
Right. Is that a problem? -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
David Abrahams <dave@boost-consulting.com> wrote:
Stefan Slapeta <stefan@slapeta.com> writes:
As an optimization you can mark the test not to be run on most compilers.
IIRC that's only possible in the jamfiles, isn't it?
Right. Is that a problem?
Maybe - as an optimization - this can be better configured in an XML file like, too. It's easier to look up this kind of things at a central place, and it's much easier to administrate. OTOH, I don't know if it's worth the trouble. Stefan
participants (1)
-
David Abrahams -
Jonathan Wakely -
Stefan Slapeta