Open SGTech87 opened 8 months ago
Thanks for bringing this up and sharing the related issue.
In our internal version of EASTL I recently added tests for allocator propagation because we don't have documentation on the allocator propagation behaviour (see propagate_on_X types from AllocatorAwareContainer). EASTL doesn't have the allocator traits class and instead has the same propagation behaviour for all allocators. The results of my testing were:
EASTL_ALLOCATOR_COPY_ENABLED
macro (defaults to false).Of note, and directly related to your issue is that both list and slist (forward_list) have inconsistent propagation behaviour to the rest of EASTL. Additionally, basic_string also has inconsistent behaviour. Before I can submit a fix I need to do some testing to make sure that EA code is not relying on the current incorrect behaviour for those types. It may be some time before I get to that work.
For reference / visibility the reproducible example, causing compilation error, is:
eastl::list<eastl::unique_ptr<int>> l1;
eastl::list<eastl::unique_ptr<int>> l2;
l1 = eastl::move(l2);
Same for slist.
There is a move semantic problem at the> #56
eastl::list
, which is the as issue as it was with theeastl::vector
: Cannot move assign a eastl::vector<unique_ptrThe solution works, but in case of different allocators an error message would be preferable.