Re: [Patch]: Separate classes for constant iterators and miscellaneousoptimizations

[Gawain Bolton <gbolton at free dot fr>]

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