"Eelis van der Weegen" <eelis@eelis.net> wrote in message news:cpd4kr$dr2$1@sea.gmane.org... | Two issues: | | (1.) I stumbled upon a strange inconsistency in boost::ptr_map's | iterator interface. I've attached some demonstration code that shows the | problem. As for the code, then I think you are right. Had you written const_iterator and not const iterator, I would expect differently. So this is an error in my code. | (2.) Given a (nonempty) const std::map<X, Y*> object, it is possible to | retrieve a Y& from it. Given a const boost::ptr_map<X, Y> object, it is | not possible (without casting) to retrieve a Y& from it. yes. but that cast is a bad idea; add const the right places instead. | Thus, it is not possible (in general) to refactor code which uses a | std::map<X, Y*> combined with manual ptr_map-like lifetime/ownership | management to use a boost::ptr_map<X, Y> without changing const semantics. | | Was this effect intentional? yes. All the containers propagate constness. | If so, why was this approach chosen? to make it easier to write const-correct programs. there has been discussion about this from time to time, but in general my impression has been than propagation of constness was appropriate for non-shared resources. | It seems like ptr_map attempts to "hide" the level of indirection that a | standard container of pointers has. yes, some have suggested to call them indirect containers instead. | While this may be desirable, I think | it should be mentioned in the documentation since it can come as a | surprise to people (like me) who actually try to perform the refactoring | mentioned above. yes, it will be mentioned (if it isn't all ready). Thanks Thorsten