From 868936866350459085 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,66d20309909372f6 X-Google-Attributes: gidf78e5,public From: "Theodore.Papadopoulo" Subject: Re: STL and set_union algorithm question? (newbie to STL!) Date: 1998/04/12 Message-ID: <352DEFB4.DD34E8A9@sophia.inria.fr>#1/1 X-Deja-AN: 343281376 Approved: Fergus Henderson Content-Transfer-Encoding: 7bit References: <6g2te9$a7n$1@ukwsv3.ggr.co.uk> <35290568.2781@wizard.net> <352A9B77.2781E494@pratique.fr> <6gelt5$mpp@marianna.psu.edu> X-Original-Date: Fri, 10 Apr 1998 12:08:53 +0200 Content-Type: text/plain; charset=us-ascii Organization: INRIA X-Auth: PGPMoose V1.1 PGP comp.std.c++ iQBFAgUANTCOkeEDnX0m9pzZAQH3agGAhlFDDQMBXWytJsCd7YEZqmb5vhZTMkEg G4F+PW39gPWwoZofe6GDO21fKcjyEdn5 =1poL Mime-Version: 1.0 Newsgroups: comp.std.c++ Matt Austern wrote: > I can't, though, understand wanting set<>::iterator to be a modifiable > iterator. The whole point of set<> (and all of the other associative > containers) is that the position of an element depends on the > element's key. In the case of set<>, for example, the two crucial > class invariants are > -- No element appears more than once; > -- The elements are sorted in strictly ascending order. > > If you could modify the elements once they had been inserted, then > there would be no way for set<> to maintain those two invariants. > Part of the design of set<> is that elements may be inserted and > erased, but, once inserted, they may not be changed. There are still some rare cases where one wants to operate a transformation on all the elements of the set knowing that the ordering will not be changed by the operation.... This might be not so uncommnon with complex data structures and partial ordering on those. We actually run on this problem very recently (for representing big sparse polynomials and multiplying them by a constant scale factor) and it was quite annoying because a work-around involves a lot of penalty, implies playing with const_cast a lot or requires a modified set class (which is the ugly solution we have chosen for now). Now, I understand that the provided behavior is safer but: - Is the stl is required to be totally foolproof or is it meant to be flexible ? - With the standard not specifying the proper choice, what is the risk of ending up with uncompatible set designs with this respect. I (maybe) wrongly interpret the lack of constraint on set<>::iterator in the standard as to have it behave like other container::iterator i.e. to allow modification. This will be error prone for sure but more orthogonal and it can be useful. - My prefered choice would be to add another iterator to each of the container which will always allow modifications (let's call it container<>::mutable_iterator) and define iterator as either const_iterator or mutable_iterator depending on the safety of the class. Can this scheme be in compliance with the standard ? Theo. -- -------------------------------------------------------------------------------- Theodore Papadopoulo (papadop@sophia.inria.fr) Projet Robotvis, INRIA - Sophia Antipolis, 2004, route des Lucioles, BP 93, 06902 Sophia Antipolis Cedex -- FRANCE Phone: (33) 04 92 38 76 01, Fax: (33) 04 92 38 78 45 -------------------------------------------------------------------------------- --- [ 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://reality.sgi.com/austern_mti/std-c++/faq.html ]