On 06/13/2016 06:31 AM, Thijs van den Berg wrote:

Hi Giuseppe,

I'm still hoping to see a strongly typed C++ heterogeneous container that doesn't enforce base classes on elements,

By "base class on elements" do you mean something like the multiple inheritance method as described in mitchnull's reply here: http://stackoverflow.com/questions/4041447/how-is-stdtuple-implemented#answe... IOW, that method muliply inherits from TupleLeaf, for I=0...sizeof...(T)-1 for: template class PseudoTuple ; If that's what you mean, then could you explain the disadvantage of this method vs some other method? TIA. -regards, Larry

Il 13/06/2016 17:25, Thijs (M.A.) van den Berg ha scritto:

No not like that. I would think something different like this would add something to the table:

http://lists.boost.org/Archives/boost/2015/05/221948.php

Which basicly splits a container into a set of single type subcontainers. The problem I see with both a tuple_vector and a vector of boost::variant's is that the types that can be added to the containers are part of the declaration of the container, so you have to know them in advance. When this is possible IMO you approach is good. Density is addressing the case in which the declaration of the container can't depend on the type of elements. Think to the dense_function_queue. An element of this container may be the result of an std::bind, or a lambda, which are unnamed types.

Il 14/06/2016 02:07, Gavin Lambert ha scritto:

On 14/06/2016 10:31, Giuseppe Campana wrote:

...

The problem I see with both a tuple_vector and a vector of boost::variant's is that the types that can be added to the containers are part of the declaration of the container, so you have to know them in advance. When this is possible IMO you approach is good. Density is addressing the case in which the declaration of the container can't depend on the type of elements. Think to the dense_function_queue. An element of this container may be the result of an std::bind, or a lambda, which are unnamed types.

Sounds like you should have a comparison between this and std::vector/queue/whateverboost::any.

Good idea. I've added two simple comparative tests with boost::any (http://peggysansonetti.it/tech/density/html/any_bench.html). In the first test, in contrast to my expectations, std::queue is performing worse than std::vector. Thank you for your suggestion, Gavin. By the way, what do you, boost people, think about the names of the containers of density? The same class template (for example dense_queue) can be used for polymorphic types (the usual Widget) and for any type (using void as base element type). There is no partial specialization, the same template works in both cases. The rationale is the same of the void pointer. Anyway C++17 already uses the name 'any' for a type-erased single value. So another option for density would be splitting the containers in two: any_list, any_queue, etc., for fully type-erased containers, and polymorphic_list, polymorphic_queue, etc. for 'partially' type-erased containers. Anyway I'm not sure about this...

Il 13/06/2016 19:56, Klaim - Joël Lamotte ha scritto:

You might want to clarify the differences with this library as colony is well advanced in it's production. The main difference is that plf::colony is an homogeneous container (elements have all the same type), while density deals with heterogeneous containers, in which elements may have a common base class (i.e. polymorphic containers like dense_list<Widget>), or may be completely type-erased (for example: dense_list<void> or dense_function_list). The core idea of colony is avoiding element reallocation and moving. The core idea of density is avoiding wastes of memory and sparse data structures.

Another difference is in the memory management: plf::colony allocates increasingly big memory blocks while the container get filled, while density paged containers allocate fixed-size pages. Fixed size allocation is extremely fast and straightforward. Furthermore, a page allocator may use a thread-local temporary depot of free pages to get a new page without having to synchronize with the other threads. This optimization is not still implemented, but I believe that it will be beneficial for all the paged containers (that is paged_queue, paged_function_queue, and all the lifo classes). Anyway density is already performing better than the alternatives, especially with queues (http://peggysansonetti.it/tech/density/html/func_queue_bench.html). density deals with lifo allocation as well. This may may at first seem unrelated to heterogeneous containers, but actually it's not. For example you may need to copy or move on the stack an element from an heterogeneous container, but you don't know how big it is, so you use a lifo_buffer, like in the producer-consumer sample (http://peggysansonetti.it/tech/density/html/producer_consumer_sample.html). As explained in the comments, the drawback of using lifo_buffer in this way is that the code is not automatically exception safe. Very soon density will provide a type-erased lifo_object that will fix this. I care a lot about exception safeness: the test of density performs an exhaustive test on the strong exception guarantee on all the testcases, trying to raise an exception in every place in which an exception may occur and checking in a catch block that the container has not changed.