Topic: should set<T,cmp1>::iterator and set<T,cmp2>::iterator be of the


Author: dants@cs.huji.ac.il (Dan Tsafrir)
Date: Fri, 4 Nov 2005 16:00:42 GMT
Raw View
Hello,

While obviously not standard, this email suggests the answer to the question
appearing in the subject should be "yes". Indeed, the following cleanly compiles
and runs when using gcc-4.0.1:

        set<int,cmp_runtime>  s1;    // holds N jobs (int = job handle)
        set<int,cmp_arrival>  s2;    // holds the same N jobs
        ...                          // s3, s4, s5... etc.

        set<int>::iterator beg, end;

        // beg/end assignment can be O(1) using the "factory" design pattern:
        if     ( p == RUNTIME ) {  beg = s1.begin(); end = s1.end(); }
        else if( p == ARRIVAL ) {  beg = s2.begin(); end = s2.end(); }
        else if( p == ...     ) {  //...                             }

        for(set<int>::iterator i=beg; i!=end; ++i)
            // do whatever...

Unfortunately, this code is implementation-defined, e.g. because we
assign an object of the type   :  set<int,cmp_runtime>::iterator
(as returned from s1.begin())
into 'beg' which is of the type:  set<int            >::iterator.
These types are the same for the gcc distribution (and also for
STLPort), but may not be for other distributions (e.g. when 'iterator'
is a nested class of 'set').

The above piece of code can be very useful in the common scenario
where several container<T>-s order the same object collection in
various ways. To the best of my understanding, the portable
alternative of the above 'for' mandates defining a "base" iterator
class to be the type of 'i', and wrapping all the set<int,cmp*>::iterator
types using an associated sub-class. The price of this alternative
is of course that the iteration code may no longer be inlined.
Several alternatives exist but to the best of my knowledge suffer from
similar or other deficiencies.

Is there an inherent reason why the above shouldn't be made standard?
(I failed to find previous postings on the subject).
If so, I suggest considering adding to STL a requirement like:
    TYPE[ container<T,cmp*1*>::iterator ] =
    TYPE[ container<T,cmp*2*>::iterator ]
(as it seems there's nothing to loose and a lot to be gained by adding it).
I think the same argument may also be applied to other template parameters
namely allocators.

Thanks,
 --Dan

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]