Hacker News new | past | comments | ask | show | jobs | submit login

My gut feeling is that a lot of issues in this class are because the allocator for STL containers are built into the container, rather than passed-in. So, rather than:

    vector v;
    v.push_back(Bob{ });
It should be:

    vector v;
    v.push_back(BobAlloc, Bob{ });
But the ergonomics would be severely lacking.



That's a different issue. Tangentially related that Allocator::construct has the same slightly crippled interface, so both the allocator concept and the container interfaces would needed to be fixed for accepting a lambda.

The stored allocator issue comes up when you need to store a bunch of vectors with the same stateful allocator, and you needlessly have to have a copy in each vector.


I don’t think that would work.

If every element of a vector can have its own allocator, and you later do

  v.erase(v.end() - 1);
how would the vector know it has to call BobFree? The class _could_ store that with each element, but for small element sizes, that’s quite a bit of overhead.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: