El 16/05/2017 a las 1:00, Ion Gaztañaga escribió:
[discussion about avoiding unique_ptr in segment_backend and scoped allocators]
I'll definitely try to implement this along your suggestions --might need your offlist help, though :-)
- The "emplace" operation uses a placement new to wrapped in a lambda which is type-erased with a captureless lambda. It looks to me that instead of delegating the work into the value_holder, the type erasure arguments should be treated by the segment so that internal vectors propagate the allocator when needed.
I don't see how this could be done: type erasure must happen before segment is used, and actual args types are then unknown to segment... Care to elaborate?
I haven't thought it carefully and it might not possible at all, but maybe the lambda could execute:
s.emplace_back(forward<Args>(args...));
where s is the concrete segment type that can be obtained via Model (the address of the aligned storage inside "class storage" is casted to Mode::get_segment_type<T>::type*) because the ConcreteType we are going to construct is known at compile time in emplace_back_impl.
I also wonder if insert<T> and other functions should avoid slicing detection so that they can also avoid the virtual call overhead. If T is assumed to be the same type of the final ConcreteType, you can use typeid(T) instead of typeid (x) (which can require to trip through the vptr) when searching in the unordered map and obtain a pointer to the concrete segment type just casting. Insertion times could be improved, specially range insertions could shine (as vector could be resized just once). Or am I missing something?
Ion, I think you're on to something here. As it happens, poly_collection
can
statically determine when T is acceptable and dynamically detect the cases
where x's subtype is actually T, in which case virtual calls can be omitted
altogether --A reference to the internal
packed_segment/split_segment