Improving flat containers interface.

base/containers/README.md

Index: base/containers/README.md
diff --git a/base/containers/README.md b/base/containers/README.md
index e64e8f3a637162d1b43b7d4df0f90e705289ecc9..abdd491d529cfd715eec783a0e015ea4151cf534 100644
--- a/base/containers/README.md
+++ b/base/containers/README.md
@@ -46,7 +46,7 @@ Google naming. Be sure to use the base namespace.
   * **base::small\_map** has better runtime memory usage without the poor
     mutation performance of large containers that base::flat\_map has. But this
     advantage is partially offset by additional code size. Prefer in cases
-    where you make many objects so that the code/heap tradeoff is good.
+    where you make many objects so that the code/heap tradeoff is good.
 
   * Use **std::map** and **std::set** if you can't decide. Even if they're not
     great, they're unlikely to be bad or surprising.
@@ -124,6 +124,12 @@ strategy and the memory access pattern. Assuming items are being linearly added,
 one would expect it to be 3/4 full, so per-item overhead will be 0.25 *
 sizeof(T).
 
+flat\_set/flat\_map support C++14 interface and a notion of transparent

[danakj, 2017/06/26 19:33:12]

Can you add a code example here of using flat_map or flat_set with unique_ptr
and with std::string? And once this lands, also send an email to chromium-dev
including those examples in it?

[dyaroshev, 2017/06/26 22:40:42]

I did. Looks weird without actually providing a solution for ptr_set.

[dyaroshev, 2017/06/26 22:40:42]

I did. Seems weird not to actually provide a set for smart pointers.

+comparisons. Therefore you can, for example, lookup base::StringPiece in a set
+of std::strings without constructing a temporary std::string.
+You can find more information about transparent comparisons here:
+http://en.cppreference.com/w/cpp/utility/functional/less_void
+
 ### base::small\_map
 
 A small inline buffer that is brute-force searched that overflows into a full