| Commit message (Collapse) | Author | Age |
|
|
|
| |
PiperOrigin-RevId: 196156010
|
|
|
|
|
|
| |
They don't make sense in the open source repository.
PiperOrigin-RevId: 183140889
|
|
|
|
|
|
|
| |
This may be misaligned for types requiring >=8-byte alignment (like pointer
types).
PiperOrigin-RevId: 169747894
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
Change: 147441750
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
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
|