RE: [boost] Re: counting_iterator_test.hpp fails on aC++

Dave, The only workaround I have is to surround the static assertion with guards: #if !defined (__HP_aCC) BOOST_ITERATOR_ADAPTOR_ASSERT_TRAVERSAL(random_access_traversal_tag) #endif The assumption is that if "advance" is called, the compiler errors eventually anyway so this change should be harmless (and lets aC++ compile the code). I had to do the same for "decrement" and "distance_to" member functions. Is this workaround okay? I probably should check this in only after 1.32 release in any case. -Jerry -----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of David Abrahams Sent: Thursday, July 22, 2004 10:36 AM To: boost@lists.boost.org Subject: [boost] Re: counting_iterator_test.hpp fails on aC++ "DY, JERRY U \(SBCSI\)" <jd2419@sbc.com> writes:
The problem is that since my_int2 is not a random access iterator, class iterator_adaptor's member function "advance" would not compile because of the static assertion below trying to convert random_access_traversal_tag to bidirectional_traversal_tag (my_traversal).
It should never be instantiated, because it should never be called. This is a compiler bug. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

"DY, JERRY U \(SBCSI\)" <jd2419@sbc.com> writes:
Dave, The only workaround I have is to surround the static assertion with guards:
#if !defined (__HP_aCC)
BOOST_ITERATOR_ADAPTOR_ASSERT_TRAVERSAL(random_access_traversal_tag) #endif
The assumption is that if "advance" is called, the compiler errors eventually anyway
Not quite. The rest of the code doesn't care what the traversal category is actually set to for the iterator.
so this change should be harmless (and lets aC++ compile the code). I had to do the same for "decrement" and "distance_to" member functions.
Is this workaround okay? I probably should check this in only after 1.32 release in any case.
Probably the right way to fix this is to indirect through an auxilliary function template that does the assertion. I presume _that_ wouldn't be instantiated unless it was actually called. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
participants (2)
-
David Abrahams
-
DY, JERRY U (SBCSI)