Boost logo

Boost :

Subject: Re: [boost] [poly_collection] Memory allocation and allocator propagation
From: Joaquin M López Muñoz (joaquinlopezmunoz_at_[hidden])
Date: 2017-05-16 07:23:52

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
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
can be statically obtained from segment<Model,Allocator>. I have to
think this
carefully, but this can be huge in terms of insertion performance.
There's no need
to dispense with slicing detection.

Joaquín M López Muñoz

Boost list run by bdawes at, gregod at, cpdaniel at, john at