4 ms·
This is taken to other extreme many times. Example: Google Chrome codebase was allocating lot of std::string and also someone used a Set to check membership of
by avasthe 6y ago
This is taken to other extreme many times.
Example: Google Chrome codebase was allocating lot of std::string and also someone used a Set to check membership of single item. [1]
I mean, if you say like this, many people don't even care about algorithm complexity.
Doesn't help that people want to write Python in the monster that is C++.
https://groups.google.com/a/chromium.org/forum/m/#!msg/chromium-dev/EUqoIz2iFU4/kPZ5ZK0K3gEJ https://groups.google.com/a/chromium.org/forum/m/#!msg/chrom...
- account42 6y agoI very much agree that many people use rules like these as excuses to write shitty code. From the post you linked though: > Not reserving space in a vector when the size is known std::vector::reserve() is actually not something you should always use when you are adding a number of elements as it will (typically) grow the vector to exactly what you ask. If your function then gets called in a loop to append to the same vector multiple times you end up with quadradtic run time that is normally avoided by the geometric growth done when you just append without reserving.
- coldtea 6y ago>and also someone used a Set to check membership of single item. [1] Depending on where it was done (fast path or not), this could be just fine.
- avasthe 6y agoYou don't know when something comes to hot path. if (std::set(itr.begin(), itr.end()).count(element)) { _____ } is it tempting for someone than something like std::find(itr.begin(), itr.end(), element) != itr.end()) ?? I don't know. That said, C++ STL quite undiscoverable.
- coldtea 6y ago>You don't know when something comes to hot path. That's the point of the first advice though...