On Fri, Mar 31, 2000 at 03:20:45PM +0200, Lars Gullik Bj&resh;nnes wrote: > Dekel Tsur <[EMAIL PROTECTED]> writes: > | > And this seems very dangerous: > | > size_type & pos = (*it).first; > | > --pos; // we use preinc/predec instead of postinc/postdec > | > > | > And what is the difference from (*it).first--; ? > | > | This doesn't work because (*it).first is const. > > So you do this to trick the compiler? Yes. > | > And is it valid to just change the key like this? > | > Won't this create havoc for the internal sorting of the map? > | > (This is why I didn't use a map from the beginning.) > | > | Since I change the keys in a way that preserve the ordering, I see no > | reason why it shouldn't work (and it does work in practice). > > It is still dangerous. As I said, it does work with my compiler (egcs-1.0.3). I also checked the STL include files, and saw no reason why it shouldn't work. The only question is whether there are different STL implementations in which the above trick doesn't work ? [Is the map container is alway implemented using a red-black tree?] I've attached a small testing program. Try to find a compiler on which the program fails. > | > A safe solution to this would of course be to remove the item from the > | > map and reinsert it with the updated positions. > | > | But this is much slower. > > In the general case yes. In this specific case no, since the container > will most likely be rather small. > First, it is not so small (you can have 20-40 insets in a paragraph). Second, the whole point of using the map container (instead of list) was to improve performance. If we delete/reinsert every element in the map, it will be slower than using a list container. I can put into the source code both the "slow" and "fast" ways of updating the map keys (with an #ifdef FAST_MAP_UPDATE). We can also use the configure script to run the testing program to check if the "fast" way works.
