Felipe Magno de Almeida <felipe.m.almeida <at> gmail.com> writes:
On 2/20/06, Bill Buklis <boostuser <at> pbjzone.com> wrote:
[snip]
The only point of #1 is so that the iterators behave exactly like std::map iterators, right? One the one hand, that would be nice for consistency with std::map, but then this is a different class with slightly different uses, so I personally don't mind if it has slightly different characteristics. And the usefulness of operator-> as T* outweighs the need for identical behavior, IMO.
I had some issues with using std::ptr_map in generic algorithms because of
this.
I think that the inner typedef's of std::ptr_map, wrt iterator concept modelling, must be carefully choosed too. That can break a lot of generic code to not work on ptr_map or other ptr_containers.
What specific problems did you have? Let's assume I simply base the implementation on std::ptr<key,T*> so that I can just reuse the existing iterators. It worries me that the pointer now becomes exposed. One might write a copy-algorithm for std::map<key,T*>, std::map<key,shared_ptr<T>> and ptr_map<key,T>. Trying to do that leads major problems. Of course, what if the algorithm only searches and call members, but does copy anything it works ok. -Thorsten