From: Powell, Gary (powellg_at_[hidden])
Date: 2004-03-25 18:04:03
I have been reading the code, and am working through the docs. I compiled and ran the examples with gcc 3.2. All compiled and ran as advertised. I did try with gcc 2.95.3 but it fails :<
I have occasionally needed a container just like this one. So I am glad to see such a nice one being offered to boost.
I made an earlier comment about operator== et.al. I don't think its worth holding up this change in attempt to get all the std::containers and boost containers to conform. I did complain about this with circular buffer but I've deleted the response. If no one else complains about this, I'll write a paper for the std committee for presentation in Redmond in Oct 2004. I don't see the harm in fixing containers as they are proposed to boost though. When we first wrote the VTL library we did this with no ill effects.
I have not run any timing tests, of using this container vs using two (N) maps with links or whatever with pointers to the same data.
A small nit, sequenced_index::remove and sequenced_index_remove should be called "erase". Its a small nit because they live in "details". But really they do erase.
I like having index_fwd.hpp I wish all the std::containers had such a file.
Also you should look at Dave Abraham's and my paper on Move semantics/copy construction vs Andrei's MOJO. IMO Its worth implementing. :>
BTW, I also really like the example that uses boost::lambda to help set up the conditionals! And a plug for my library in no way influences my vote.. no sir yee, I'm totally impartial here...
I vote to accept unconditionally.
Sorry to hear about your cat. I had one that only made it to 3 yrs, and that was hard to take. But cats gotta be cats.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk