From -6928689518224050552 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,31085442cf446f1e X-Google-Attributes: gidf78e5,public From: Matt Austern Subject: Re: "Modifying algorithms" aren't?? Date: 1997/05/29 Message-ID: #1/1 X-Deja-AN: 244827984 References: <5mfoo2$vj8$1@alpha.wright.edu> X-Original-Date: 29 May 1997 09:42:47 -0700 Organization: SGI X-Auth: PGPMoose V1.1 PGP comp.std.c++ iQBVAwUBM44C+0y4NqrwXLNJAQE7RwH9GoQsTtW7vndzsDnsRlpYJPjiRT/GPMVT kL9kcsZdlsmMMWBI2JaoMKHkQXGmrBkV9vLCJ0jBIU+jyrm2qLi0xQ== =OYUp Newsgroups: comp.std.c++ Originator: austern@isolde.mti.sgi.com James Kanze writes: > |> CD2 doesn't specify one way or the other that I can find, but it seems > |> that the HP-as-modified-for-DEC implementation of the algorithms in > |> 25.2, [lib.alg.modifying.operations], are behaving very non-intuitively. > |> > |> Specifically, "deleting" members of a container, by whatever method, only > |> copies the remaining elements "up" a place in the container, leaving > |> copies of the last element in the container. It seems that this would be > |> fine (lazy deallocation), BUT the extraneous copy at the end is still > |> being included in the container's membership. > > This is correct. The motivation, if I understand it correctly, is to > avoid invalidating iterators. Another motivation might be to make it > work with builtin arrays (which have a fixed size that can't be > changed). It's not just a matter of motivation: it's a matter of what is and isn't logically possible. remove()'s argument is a range of iterators, not a container. That means that remove() can't possibly erase any of the container's elements; it would need to have access to the container itself in order to do that. Note, by the way: there's nothing wrong with an algorithm that actually erases a container's elements. In fact, there probably should be such an algorithm in the STL. It's just that that algorithm couldn't possibly have the same interface that remove() does. One of its arguments would have to be a container. In general, container-based generic algorithms are a fairly big hole in the STL. There are other missing features, some of which are even more important. --- [ comp.std.c++ is moderated. To submit articles: Try just posting with your newsreader. If that fails, use mailto:std-c++@ncar.ucar.edu comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html Comments? mailto:std-c++-request@ncar.ucar.edu ]