4 ms·
Interesting write up. There was a claim I didn't understand though > Let’s fix this. An easy way to get our std::vector implementation in-line with the rest o
by toth 9y ago
Interesting write up. There was a claim I didn't understand though
> Let’s fix this. An easy way to get our std::vector
implementation in-line with the rest of the containers is we can sort it and utilize an algorithm, std::lower_bound, in order to speed up our lookup times.
Unless I'm missing something, isn't this wrong? The point of the vector is that v[enum_value] gives you the name of enum_value as a string. Once you sort it this relationship no longer holds, unless it so happens that the vector was already sorted (which happens to be the case for "circle", "square", "triangle").
- quinnftw 9y agoI thought this aswell, but you have it backwards. The point is to convert a string to it's corresponding enum, not the other way around.
- toth 9y agoI get that part, that's why you use std::find or std::lower_bound on the vector, but my point is that std::lower_bound will not give you the right answer unless your enum is defined with the names in alphabetical order.
- SoapSeller 9y agoYou are absolutely right - and the benchmark in the repository doesn't even try to get the value - it's only check for existent of key. However, it can easily be fixed by using something like vector<tuple<string, types_t>> and supplying predicates for both std::sort and std::lower_bound to only consider the first element in the tuple. There will be some performance hit, but should be minimal.
- toth 9y agoI see, that makes sense. I guess at that point you have something very much like std::map, except it doesn't keep itself sorted, you have to do it yourself. I guess for cases like this where you initialize it once and never change it again it could even be a better choice (i.e., faster initialization).
- AstralStorm 9y agoThe main difference is that map cannot be reserved ahead of time.