flat maps are not quite what many assume they are, some panacea for performance. In fact for most cases, you will still benefit from using the ordinary maps already provided in C++. In fact if you merely swap out std::map with std::flat_map, most code will start running much more slowly. They have a very specific, limited use case and for everything else, you should not make any changes.
Your comment has a gaping lack of real world profiling and "it depends", so that's likely why it's getting downvoted.
> most code will start running much more slowly
Most code, as in, most code that uses it? Are there are stats on how exactly std::map (and std::unordered_map, the more useful general purpose map) are used?
> and std::unordered_map, the more useful general purpose map
std::unordered_map is a hash table. It's not a very good hash table but that's what it is, and so whilst that is much more generally useful, it's also irrelevant to the purpose of map (and thus of flat_map).
It seems to me that if "most code" would be harmed by using flat_map instead of map that's actually good news, since map isn't going anywhere. What I anticipate is the reality is that a considerable amount of code would benefit from using flat_map instead of map, because of the improved performance from linear access.
I said for latency, not performance in general. If you're generally working with maps with only 10s to 100s of small entries, it's easily possible to see a 10x reduction in worst-cost latency by switching from std::[unordered_]map to flat_map, due to a massive reduction in latency and pointer chasing (e.g. std::unordered_map allocates for every single insertion, and std::map lookup/pointer chasing often leads to log(n) cache misses).
