This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

set and map iterators.


I have just discovered that libstdc++-v3 defines iterator for maps 
and sets as const_iterator, which till yesterday I believed was the 
right thing to do.

However the standard as far as I can tell leaves this open...
I do not quite remember (it seems to trigger some recollection, but 
I'm not sure) whether there is a DR for this that specifies such a 
behaviour.

Why I do believe that this is "not correct" ? Well, I have a set of 
points (which I want to be stored in a std::set) that are indeed 
constants, but the points also contain some properties which might 
change (ie the properties are not accounted for in the key comparison
function). With the current iterator which returns only a const 
object, it is impossible to change the property (well a const_cast 
does work and that's what I'm doing, but well this is ugly).

Same story, in pseudo code....

struct Property {
    void set_property(xxx);
};

struct MyPoint: public Point, public Property {	
    
};

template <>
struct less<MyPoint> {
    bool operator()(const MyPoint& P1,const MyPoint& P2) const { 
         return less<Point>(P1,P2);
};

int
main()
{
      std:set<MyPoint> sp;
      MyPoint mp(1,2,3);
      
      // I must add a const_cast on one or the other of the two following lines.

      MyPoint& point = sp.insert(mp).first; // Arghhh can't do that must get a const reference.
      point.set_property(something);        // If I had took a const reference, cannot do this.
}

In brief, I do believe now that the use of an iterator that is a 
const_iterator is overly restrictive. The standard should just say 
that dereferencing the iterator should not be used in any way that 
might change the ordering of the "key". Maybe not the safest choice 
and this might surprise beginners, but certainly the most general 
choice.

I asking this here because with respect to the standard, libstdc++ 
seems to have made a choice. If the choice is driven by a DR, then 
maybe Matt, Gaby or Nathan (among others) might provide a useful 
comment.

	Thank's a lot...

	Theo.


 --------------------------------------------------------------------
 Theodore Papadopoulo
 Email: Theodore.Papadopoulo@sophia.inria.fr Tel: (33) 04 92 38 76 01
 --------------------------------------------------------------------




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]