There were several people in the answers to your previous post, including me, who recommended using constant constants instead of reasons not related to performance. Readability, traceability from the design board to the code ... Using const_iterators to provide mutating access to a non-constant element is much worse than never using const_iterators. You turn your code into something that only you will understand, with worse design and real maintainability. Using const just to remove it is much worse than not using const at all.
If you are sure you want this, the good / bad part of C ++ is that you can always get enough rope to hang yourself. If your intention is using const_iterator for performance issues, you should really rethink it, but if you still want to take your foot off ... well, C ++ can provide you with your weapon.
First, the simplest: if your operations accept arguments as const (even if they are used inside const_cast), I believe that it should work directly in most implementations (even if this is probably undefined behavior).
If you cannot change functors, you can solve the problem on either side: provide a non-const-iterator wrapper around constant iterators or provide a wrapper of a const functor around non-const functors.
Iterator facade, a long way:
template <typename T> struct remove_const { typedef T type; }; template <typename T> struct remove_const<const T> { typedef T type; }; template <typename T> class unconst_iterator_type { public: typedef std::forward_iterator_tag iterator_category; typedef typename remove_const< typename std::iterator_traits<T>::value_type >::type value_type; typedef value_type* pointer; typedef value_type& reference; unconst_iterator_type( T it ) : it_( it ) {}
David Rodrรญguez - dribeas Apr 19 '09 at 12:49 2009-04-19 12:49
source share