[Patch]: Separate classes for constant iterators and miscellaneous optimizations

[Gawain Bolton]

Gabriel Dos Reis wrote:

>Gawain Bolton <gbolton@free.fr> writes:
>
>| This patch introduces new classes for constant iterators for std::list
>| and the _Rb_tree class which is used to implement the
>| std::{multi}*{map|set} containers.
>| 
>| The reasons for doing this are:
>| 
>|     * code clarity/simplicity
>|     * eliminate need for const_casts
>
>I think we should aim at more code sharing than code duplication
>targetting  const_cast<> eliminating.
>
Is it worth sharing code when the implementation is a trivial inline 
function?

>  "More codes" in headers means
>potential increase in compile-time.  We also need to take that aspect
>into account when working on "perfomance" or code "header washing".
>
I agree.  But the new classes introduced replace horrible syntax like 
global template comparison operators and template class with multiple 
arguments and inheritance.  Consider the current std::list iterator 
class which is:

   template<typename _Tp, typename _Ref, typename _Ptr>
     struct _List_iterator : public _List_iterator_base

And the patch I proposed replaces this with:
   template<typename _Tp>
     struct _List_iterator

I think this simpler code can only compile faster.

>As of container member functions accepting or not-accepting
>const_iterator, there is a library DR regarding const-correctness.
>The general sentiment is that const_iterator should be accepted in
>more situations than is currently the case. 
>  
>
Ok, but I'm not sure what this has to do with the patch I suggested.  If 
anything having a real separate type allows finer and more obvious 
control via type checking concerning where const_iterators can be used.

Anyway, I found a silly bug in the patch I posted so please __do not__ 
apply it as is!

Cheers,


Gawain