aboutsummaryrefslogtreecommitdiffhomepage
path: root/tensorflow/core/lib/gtl/flatmap.h
Commit message (Collapse)AuthorAge
* Make FlatSet and FlatMap movable.Gravatar Justin Lebar2018-05-10
| | | | PiperOrigin-RevId: 196156010
* Remove THIRD_PARTY_ from #include guardsGravatar Sanjoy Das2018-01-24
| | | | | | They don't make sense in the open source repository. PiperOrigin-RevId: 183140889
* Align the cached value in FlatMap's iterator.Gravatar A. Unique TensorFlower2017-09-22
| | | | | | | This may be misaligned for types requiring >=8-byte alignment (like pointer types). PiperOrigin-RevId: 169747894
* Switch FlatMap and FlatSet to use a non-identity hasher for pointers.Gravatar Justin Lebar2017-07-11
| | | | | | | | | | | | Previously the default hasher for FlatMap and FlatSet used std::hash by default. Most stdlibs' std::hash for pointers is the identity function. This works for std::unordered_{set,map} because those are prime-sized hashtables. But FlatSet and FlatMap are power-of-two-sized, and so the identity function is bad, bad news. This change also switches us to use Hash64 for strings, rather than std::hash. PiperOrigin-RevId: 161553663
* Workaround FlatMap windows build breakage.Gravatar A. Unique TensorFlower2017-02-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Windows builds break on the following simplified example: template <typename Key, ...> class FlatSet { public: typedef Key value_type; class const_iterator { public: typedef FlatSet::value_type value_type; // Fails on windows }; }; The build succeeds by adding 'typename': typedef typename FlatSet::value_type value_type; // OK on windows <simplified log of compiler error> flatmap.h(110): warning C4346: 'difference_type': dependent name is not a type (compiling source file ...cancellation.cc) flatmap.h(110): note: prefix with 'typename' to indicate a type (compiling source file ...cancellation.cc) flatmap.h(161): note: see reference to class template instantiation 'tensorflow::gtl::FlatMap<Key,Val,Hash,Eq>::iterator' being compiled (compiling source file ...cancellation.cc) flatmap.h(376): note: see reference to class template instantiation 'tensorflow::gtl::FlatMap<Key,Val,Hash,Eq>' being compiled (compiling source file ...cancellation.cc) flatmap.h(110): error C2061: syntax error: identifier 'difference_type' (compiling source file ...cancellation.cc) </simplified log of compiler error> This is a bug in the windows compiler. It is true that FlatSet::value_type is a dependent name, but it also refers to the "current instantiation", so 'typename' shouldn't be required. For details see: http://en.cppreference.com/w/cpp/language/dependent_name#Current_instantiation But it doesn't hurt to add typename; it is simply redundant. Change: 147776071
* Make FlatSet and FlatMap behave more like the std equivalents.Gravatar A. Unique TensorFlower2017-02-16
| | | | | | | | | | | | | | | | | | | | | | | | | | This fixes a collection of annoyances that prevented Flat{Set,Map} from being a pure drop-in replacement for std::unordered_{set,map}. I haven't exhaustively ensured compatibility; I started with stuff I've actually run into: * Construction via std::initializer_list FlatSet<int> set({1, 2, 3}); FlatMap<int, int> map({{1, 10}, {2, 20}, {3, 30}}); * Define an iterator_category for compatibility with std algorithms. E.g. the code below would yield a compile error with the useful bit truncated, and you'd need to find and set --cxxopt=-fshow-overloads=all to figure it out. FlatSet<int> set({1, 2, 3}); vector<int> vec(set.begin(), set.end()); // used to fail, now works * Defining the iterators with forward_iterator_tag requires postfix ++ Admittedly I haven't actually run into this, but it's easy to add. * Previously FlatSet::iterator allowed mutation of the set keys, which would corrupt the internal representation. I've taken the standard approach of defining iterator as an alias of const_iterator, so that we'll now get a compile error if you mistakenly do this. I haven't actually run into this either, but it seems like a worthwhile change. Change: 147731813
* Automated rollback of change 147415868Gravatar Martin Wicke2017-02-14
| | | | Change: 147441750
* Make FlatSet and FlatMap behave more like the std equivalents.Gravatar A. Unique TensorFlower2017-02-13
| | | | | | | | | | | | | | | | | | | | | | | | | | This fixes a collection of annoyances that prevented Flat{Set,Map} from being a pure drop-in replacement for std::unordered_{set,map}. I haven't exhaustively ensured compatibility; I started with stuff I've actually run into: * Construction via std::initializer_list FlatSet<int> set({1, 2, 3}); FlatMap<int, int> map({{1, 10}, {2, 20}, {3, 30}}); * Define an iterator_category for compatibility with std algorithms. E.g. the code below would yield a compile error with the useful bit truncated, and you'd need to find and set --cxxopt=-fshow-overloads=all to figure it out. FlatSet<int> set({1, 2, 3}); vector<int> vec(set.begin(), set.end()); // used to fail, now works * Defining the iterators with forward_iterator_tag requires postfix ++ Admittedly I haven't actually run into this, but it's easy to add. * Previously FlatSet::iterator allowed mutation of the set keys, which would corrupt the internal representation. I've taken the standard approach of defining iterator as an alias of const_iterator, so that we'll now get a compile error if you mistakenly do this. I haven't actually run into this either, but it seems like a worthwhile change. Change: 147415868
* Use gtl::FlatMap and gtl::FlatSet in several places instead ofGravatar A. Unique TensorFlower2016-10-31
| | | | | | | | | | std::unordered_map and std::unordered_set. Add default template argument of std::hash<Key> to gtl::FlatMap and gtl::FlatSet to better match std::unordered_{map,set} Improves performance on an RPC-intensive benchmark by ~0.4% Change: 137754417
* Added new tensorflow::gtl::FlatMap and tensorflow::gtl::FlatSet classes.Gravatar A. Unique TensorFlower2016-10-27
Mostly drop-in replacements for std::unordered_map and std::unordered_set, but much faster (does not do an allocation per entry, and represents entries in groups of 8 in a flat array, which is much more cache efficient). Benchmarks not included in this cl show about 3X to 5X performance improvements over the std::unordered_{set,map} for many kinds of common maps e.g. std::unordered_mapmap<int64, int64> or std::unordered_map<string, int64>. Change: 137401863