Hi, I have working in the implementation of the cpo library, so I keep working and I expect to make a formal proposal within 2 or 3 months, and meanwhile I will try my best to answer mails.

Date: Wed, 28 Aug 2013 11:18:03 +0400 From: Andrey Semashev <andrey.semashev@gmail.com> The storage strategy does not mandate the interface of the container. unordered_set/map are implemented as a number of buckets (i.e. single-linked lists), yet they provide sequence interface with an additional ability to iterate within a single bucket. I don't see why a similar approach couldn't be taken in your container.

I will not provide the classifier container with a push_back or push_front method, instead I will use insert, I suppose it is just about the meaning of sequence, I expect a sequence to keep an order on items while container means just a collection of items in not a particular order. On the other hand I will provide a way to iterate over a "single bucket". Actually, I have been working on benchmarking and that seems to be the better option to iterate over the classifier because it reduces the number of virtual method calls in the iteration. I also will provide a const random access iterator and some other utilities to access a particular item in the container.

You can't create std::multiset<shape> but you can create boost::intrusive::multiset<shape>. The reason for that is that std::multiset attempts to allocate storage for shape, while boost::intrusive::multiset doesn't, leaving this to the user. This allows you to insert any objects derived from shape to the single boost::intrusive::multiset and work with this container pretty much the same way you would with std::multiset. You can even insert the very same object in multiple containers if you need to. I recommend you to have a look at Boost.Intrusive, it is a truly amazing library.

The interface for my library needs to be far more simple than the interface in Boost.Intrusive, but I will consider that option to implement the details. Up to now, I am only using std containers to avoid dependencies, but I will consider other options to optimize speed and size performance. [snip] About "polymorphic vector", that is, a container that stores different types contigously, I should say that the interface needs to be as easy as in the classifier, so I will discard solutions that needs any requirement to objects apart from being copyable, default constructive or the like. I will try to develop a prototype from Larry Evans' example (with his permission). But because I am not an expert on alignment and memory optimization, I will try to use something "more standard", actually I am going trying to use the allocator to compute the "right" address to place an object of a given type that is greater that a "free" memory pointer. In that way, I also expect to take advantages of allocator such as tbb cache aligned allocator. Again, thank you all for your comments. Regards, Santiago -- ESCUELA TÉCNICA SUPERIOR DE INGENIEROS INDUSTRIALES UNIVERSIDAD POLITÉCNICA DE MADRID Santiago Tapia Fernández | DEPARTAMENTO DE AUTOMÁTICA, INGENIERÍA ELECTRÓNICA E INFORMÁTICA INDUSTRIAL José Gutiérrez Abascal, 2 | 28006 Madrid TEL +34 91 336 4266 E-MAIL stapia@industriales.upm.es www.industriales.upm.es