I understand why this works now, but stuff like this is why people avoid STL like the plague. Non-C++ languages would have just added a version of try_emplace which accepts a lambda (or a function pointers plus a void pointer context).
Personally, I'd much rather see the try/catch version in my code base than the clever deferred evaluation version.
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:
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.
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.
That's quite correct. All of the functions in the standard library that have "emplace" in the name would be better off by accepting a lambda. Now they are stuck in having a "perfect forwarding" interface that is not perfect at all.
I understand why this works now, but stuff like this is why people avoid STL like the plague. Non-C++ languages would have just added a version of try_emplace which accepts a lambda (or a function pointers plus a void pointer context).
Personally, I'd much rather see the try/catch version in my code base than the clever deferred evaluation version.
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:
It should be: 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
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.That's quite correct. All of the functions in the standard library that have "emplace" in the name would be better off by accepting a lambda. Now they are stuck in having a "perfect forwarding" interface that is not perfect at all.
Swift has @autoclosure for this: https://docs.swift.org/swift-book/LanguageGuide/Closures.htm...