diff options
author | Abseil Team <absl-team@google.com> | 2020-09-18 15:55:15 -0700 |
---|---|---|
committer | Derek Mauro <dmauro@google.com> | 2020-09-24 13:47:15 -0400 |
commit | b56cbdd23834a65682c0b46f367f8679e83bc894 (patch) | |
tree | dacab9a64dd1a9e9668737e511d1a5420ff96001 /absl/hash/hash.h | |
parent | b832dce8489ef7b6231384909fd9b68d5a5ff2b7 (diff) |
Abseil LTS 2020092320200923
What's New:
* `absl::StatusOr<T>` has been released. See our [blog
post](https://abseil.io/blog/2020-091021-status) for more
information.
* Abseil Flags reflection interfaces have been released.
* Abseil Flags memory usage has been significantly optimized.
* Abseil now supports a "hardened" build mode. This build mode enables
runtime checks that guard against programming errors that may lead
to security vulnerabilities.
Notable Fixes:
* Sanitizer dynamic annotations like `AnnotateRWLockCreate` that are
also defined by the compiler sanitizer implementation are no longer
also defined by Abseil.
* Sanitizer macros are now prefixed with `ABSL_` to avoid naming collisions.
* Sanitizer usage is now automatically detected and no longer requires
macros like `ADDRESS_SANITIZER` to be defined on the command line.
Breaking Changes:
* Abseil no longer contains a `dynamic_annotations` library. Users
using a supported build system (Bazel or CMake) are unaffected by
this, but users manually specifying link libraries may get an error
about a missing linker input.
Baseline: 7680a5f8efe32de4753baadbd63e74e59d95bac1
Cherry picks: None
Diffstat (limited to 'absl/hash/hash.h')
-rw-r--r-- | absl/hash/hash.h | 11 |
1 files changed, 6 insertions, 5 deletions
diff --git a/absl/hash/hash.h b/absl/hash/hash.h index 23a65ea8..5de132ca 100644 --- a/absl/hash/hash.h +++ b/absl/hash/hash.h @@ -37,8 +37,11 @@ // types. Hashing of that combined state is separately done by `absl::Hash`. // // One should assume that a hash algorithm is chosen randomly at the start of -// each process. E.g., absl::Hash<int>()(9) in one process and -// absl::Hash<int>()(9) in another process are likely to differ. +// each process. E.g., `absl::Hash<int>{}(9)` in one process and +// `absl::Hash<int>{}(9)` in another process are likely to differ. +// +// `absl::Hash` is intended to strongly mix input bits with a target of passing +// an [Avalanche Test](https://en.wikipedia.org/wiki/Avalanche_effect). // // Example: // @@ -85,7 +88,6 @@ ABSL_NAMESPACE_BEGIN // * T is an arithmetic or pointer type // * T defines an overload for `AbslHashValue(H, const T&)` for an arbitrary // hash state `H`. -// - T defines a specialization of `HASH_NAMESPACE::hash<T>` // - T defines a specialization of `std::hash<T>` // // `absl::Hash` intrinsically supports the following types: @@ -98,6 +100,7 @@ ABSL_NAMESPACE_BEGIN // * std::tuple<Ts...>, if all the Ts... are hashable // * std::unique_ptr and std::shared_ptr // * All string-like types including: +// * absl::Cord // * std::string // * std::string_view (as well as any instance of std::basic_string that // uses char and std::char_traits) @@ -124,8 +127,6 @@ ABSL_NAMESPACE_BEGIN // * Natively supported types out of the box (see above) // * Types for which an `AbslHashValue()` overload is provided (such as // user-defined types). See "Adding Type Support to `absl::Hash`" below. -// * Types which define a `HASH_NAMESPACE::hash<T>` specialization (aka -// `__gnu_cxx::hash<T>` for gcc/Clang or `stdext::hash<T>` for MSVC) // * Types which define a `std::hash<T>` specialization // // The fallback to legacy hash functions exists mainly for backwards |