Bruno Martínez wrote:
On Wed, 13 Sep 2006 04:12:03 -0300, Ion Gaztañaga <igaztanaga@gmail.com> wrote:
If someone needs/wants more features, now's the time to request them!
I think intrusive containers would be useful. There was a separate initiative that added intrusiveness to the multi index library. I think it would be better to fold the many STL remakes that are popping up (pointer containers, intrusive containers/shared mem containers) into multi index than repeat the effort everywhere. Case in point: what do I do if I need a pointer-sharedmem-bimap?
Good point. But the problem is that users also want simple STL-like classes and they don't want to start using a class that offers a lot of additional features. That multi_index class might be also more expensive so using a multi_index as a simple single-index class can be a bad idea. If a user just wants an intrusive linked list class, I suppose that he/she expects sizeof(ilist) == 2*sizeof(void *) (plus an optional size member if he/she wants constant-time size() member). A list user might also want a non-constant size() member but a constant time splice(), etc... Another problem is the coordination between libraries and authors. Having a single library with a lot functionalities can be very difficult to maintain and it would require coordination between several authors. If you want to have shared memory multi_index you need to change multi_index implementation to accept a templatized pointer type. That can be really a big task. It's not something a wrapper can solve. Maybe ptr container can also offer wrapper over user-provided classes apart from using STL containers, so that we can have a ptr_vector based on a shared memory vector. Again, it would require support for non-raw pointers. But it would be nice to have some *core* algorithms somewhere (surely intrusive, multi_index, and intrusive_multi_index have their own version). Other Boost have also those algorithms as internal files. For example, boost/detail has rb tree algorithm implementation. Regards, Ion