From -8568977736562422107 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,66d20309909372f6 X-Google-Attributes: gidf78e5,public From: Oleg Zabluda Subject: Re: STL and set_union algorithm question? (newbie to STL!) Date: 1998/04/09 Message-ID: <6gh6t6$ptn@marianna.psu.edu>#1/1 X-Deja-AN: 342291626 Approved: Fergus Henderson References: <6g2te9$a7n$1@ukwsv3.ggr.co.uk> <35290568.2781@wizard.net> <352A9B77.2781E494@pratique.fr> <6gelt5$mpp@marianna.psu.edu> X-Original-Date: 8 Apr 1998 21:05:42 -0400 X-Server-Date: 9 Apr 1998 02:11:05 GMT Reply-To: zabluda@math.psu.edu (Oleg Zabluda) Organization: Penn State University, Center for Academic Computing X-Auth: PGPMoose V1.1 PGP comp.std.c++ iQBFAgUANSw+KOEDnX0m9pzZAQHQsgF/Qzg0csvt11I/lYo2n8J6j22/PaNE1Iaw 9P5p38h3I3s6J8kgE0xo3Az7daQTfX1g =jKvs Newsgroups: comp.std.c++ Matt Austern wrote: : Oleg Zabluda writes: : > Valentin Bonnard wrote: : > : James Kuyper wrote: : > : > : > set::end() on a non-const set object is supposed to return : > : > set::iterator, not set::const_iterator. You have a defective : > : > implementation of STL. : > : > : set::iterator IS set::const_iterator. You have a defective : > : knowledge of the STL. ;-) : > : > No such requirement exist in CD2. I don't think it was introduced : > in FDIS. It would be pure madness. I'd like to see a requirement : > that not only set::iterator IS NOT set::const_iterator, : > but that set::const_iterator is not even convertible to : > set::iterator. Just like I'd like to see this requirement for : > all other containers. I consider any implementation, which does not : > adhere to these requirements to be defective in this respect. : I can understand wanting set<>::iterator and set<>::const_iterator to : be distinct types, just for the sake of stricter type-checking. (The : standard neither requires nor forbids them to be distinct types.) : I can't, though, understand wanting set<>::iterator to be a modifiable : iterator. I don't want it to be modifiable. I just want it to be non-convertible to set<>::const_iterator. You still should not be able to modify a set<> through set<>::iterator, and the diagnostic must be compile-time. If set<> was the only container, I wouldn't worry about it. In fact, if set<> was the only container, there would be no reason whatsover to introduce set<>::iterator. It was introduced for interface compatibility with other containers. Therefore it must be indeed compatible. If the ``non-convertibility'' property holds for all containers, either because the Standard will mandate it, or because an implementation did it this way, I'd like the same to hold for set<>. For the same reason set<>::iterator was introduced in the first place -- interface compatibility. I would also understand the decision to remove set<>::iterator, but wouldn't support it. : 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. Right. I can imagine a modifiable set<>::iterator. An assignement would reoder elements of set appropriately. For this, set<>::iterator should carry enough information to find the corresponding set. That's against the spirit of STL, and would introduce unnesessary performance penalty. Although such info can be successfully used for debugging purposes, for example, like detecting dereferencing dangling iterators, or invalid iterator ranges. Oleg. -- Life is a sexually transmitted, 100% lethal disease. --- [ 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 ]