4 ms·
> I don't understand why you are making a distinction between table-like and non-table-like containers: both can take allocators. Because for map<> in general
by 112233 9y ago
> I don't understand why you are making a distinction between table-like and non-table-like containers: both can take allocators.
Because for map<> in general I cannot know how much allocations and of what size will it need to store 1000 elements. I might glean it for particular implementation of STL, but not via any api.
Doing anything bearssl-like, "No dynamic allocation whatsoever", just does not work with STL.
> you cannot use any external library in your function, since other libraries may have other allocation requirements that your code would break.
Exactly. Most C++ libraries are not made with the idea of allowing you to police resource allocation. It's malloc all the way.
- jcelerier 9y ago> Exactly. Most C++ libraries are not made with the idea of allowing you to police resource allocation I was saying this from the point of view of the library author, not the code. e.g. for instance I spent some weeks optimizing allocations in a library that I'm working on, and am then making assumptions in the rest of the code according to the optimizations I made. If I did let users of the library change the allocation policy, I would have to introduce costly runtime checks everywhere to ensure that the invariants I set do still hold, that I really have enough memory to do what I must, and abort / throw in case such an invariant is broken. All of these situations are less desirable than enforcing my allocation policy in my code.
- pjmlp 9y agoYou can have an idea for sure, that is what profilers are for. Have datasets of typical execution runs, profile test executions and gather statistics for ideal average sizes. Gut feeling for sizes never ends well.