Gimme std::vector/map/unordered_map/list. The performance cost is pretty miniscule to not have to worry about which dependency is better. The debuggabilty of those classes is kinda nasty tho.
Gimme std::vector/map/unordered_map/list. The performance cost is pretty miniscule to not have to worry about which dependency is better. The debuggabilty of those classes is kinda nasty tho.
It’s not too bad as long as you have the gdb pretty-printers installed, and explicitly instantiate each of the member functions for each of the template specializations that you use, and link against a debug libstdc++ with bounds checking enabled, and… okay fair point.
Measured how? Being good enough or not for which of a million uses? Without that these statements may well be true for the author but meaningless for the reader & potential user.
(Avoiding allocations is frequently a reasonable idea when minimizing latency, for example - maybe not for you).
I think it's wild how people insinuate I'm a fool if I literally say it never is a problem for us. I think it creates a "boy who cried wolf" problem if you always harp on stuff that doesn't actually manifest.
In general, I'm with you on memory allocation. I recently rewrote our animation system to not allocate memory at runtime, but to say "never use std::vector because it's performance is bad" is a statement I can't get behind.