4 ms·
Problem with contains is we are now going to see more code like if (map.contains(foo)) { bob(map[foo]); } over the (vastly uglier) more efficie
by tubs 4y ago
Problem with contains is we are now going to see more code like
if (map.contains(foo)) {
bob(map[foo]);
}
over the (vastly uglier) more efficient:
if (auto it = map.find(foo); it != map.end()) {
bob(*it);
}
Of course languages like C# manage this in a more elegant way with out parameters declarable at the call site.
- JonChesterfield 4y agoA pity the c++ compiler has no way to recognise calls to the c++ library in order to do rewrites like that automatically. It's CSE at the stdlib level, should definitely be possible to do that.
- eklitzke 4y agoHard coding behavior like for the STL that seems pretty questionable, especially given that std::map and std::unordered_map have poor performance compared to other alternatives (e.g. absl::btree_map and absl::flat_hash_map, and likewise folly has better implementations).
- im3w1l 4y agoif let is such a nice way to express this if let Some(x) = map.get(foo) { bob(x) } One subtle but noteworthy thing is that the idiom only mentions map by name once, which is nice if you have a very long map name, and prevents copy paste bugs where you only update one of the two mentions.
- olliej 4y agoThis pattern exists in C++ as well. The specific issue here is that all these STL APIs are in terms of C++'s iterator model, and can't be replaced with a more modern "optional" style that allows this cleaner coding style :-/
- paulddraper 4y agoScala: for (x <- map.get(foo)) { bob(x) } // or map.get(foo).foreach(bob) // or map.get(foo) match { case Some(x) => bob(x) }