absl::Hash
By Derek Mauro
Today we are announcing that Abseil is adopting the Google OSS Library Breaking Change Policy. What does this mean for Abseil users? Let’s take a look.
Abseil’s original compatibility policy made this statement:
We will always strive to not break API compatibility. If we feel that we must, we will provide a compiler-based refactoring tool to assist in the upgrade … any time we are making a change publicly we’re also doing the work to update the 250MLoC+ internal Google codebase — we very rarely do such refactoring that cannot be automated.
By Alexey Alexandrov, Google Engineer
We are pleased to announce that we’ve started publishing some of Google’s internal “Performance Tips of the Week” externally on abseil.io!
These tips form a sort of “Effective analysis and optimization of production performance and resource usage”: a gallery of “do”s and “don’t”s gathered from the hard-learned lessons of optimizing performance of production systems running on machines in Google data centers.
By Phoebe Liang, Abseil Engineer
We are pleased to introduce an easier way to format user-defined types as strings in
Abseil: AbslStringify()
. This API allows user-defined types to be printed more
easily using absl::StrFormat()
and absl::StrCat()
.
To “stringify” a custom type, define a friend function template named
AbslStringify(
):
struct Point
template <typename Sink>
friend void AbslStringify(Sink& sink, const Point& p) {
absl::Format(&sink, "(%d, %d)", p.x, p.y);
}
int x;
int y;
}
absl::StrCat()
will work right out of the box like so:
absl::StrCat("The point is ", p);
To print custom types with absl::StrFormat()
, use the new type specifier %v
:
absl::StrFormat("The point is %v", p);
%v
uses type deduction to print an argument and supports any user-defined type
that provides an AbslStringify()
definition. Most types that are supported
natively by absl::StrFormat()
are also supported by %v
. For a full list of
supported types, see the StrFormat Guide.
By Andy Getzendanner, Abseil Engineer
We are pleased to announce, at long last, the initial availability of the Abseil Logging library. This library provides facilities for writing short text messages about the status of a program to stderr, disk files, or other sinks (via an extension API).
The core interface is the LOG
macro, which has a streaming interface like
std::ostream
’s:
absl::StatusOr<absl::Duration> GetUserAge(absl::string_view user_name) {
int user_id = GetUserId(user_name);
if (user_id == -1) {
LOG(ERROR) << "No user found named " << user_name;
return absl::NotFoundError(absl::StrCat("No user found named ", user_name));
}
return age_map[user_id];
}
The library also supports terminating the process via a severity level named
FATAL
:
absl::Duration GetUserAge(absl::string_view user_name) {
int user_id = GetUser(user_name);
if (user_id == -1) {
LOG(FATAL) << "No user named " << user_name << " found";
// No need for a return statement; this line is unreachable.
}
return age_map[user_id];
}
The CHECK
macro family provides assert()
-like precondition checking and
process termination in all compilation modes with better error messages:
absl::Duration GetUserAge(absl::string_view user_name) {
int user_id = GetUser(user_name);
CHECK(user_id != -1) << "No user named " << user_name << " found";
return age_map[user_id];
}
By Ashley Hedberg, Software Engineer
The C++ Standard provides a library for performing fine-grained atomic
operations (e.g. std::atomic
). Engineers sometimes reach for these
atomic operations in the hope to introduce some lock-free mechanism,
or to introduce clever tricks to improve performance. At Google, we’ve
found – more often than not – that such attempts lead to code that
is difficult to get right, hard to understand, and can often introduce
subtle and sometimes dangerous bugs.
We’ve now published a guide on the danger of these atomic operations, and are publishing it to Abseil as a general programming guide. Atomic operations should be used only in a handful of low-level data structures which are written by a few experts and then reviewed and tested thoroughly. Most programmers make mistakes when they attempt direct use of atomic operations. Even when they don’t, the resulting code is hard for others to maintain.
For more information, check out The Danger of Atomic Operations.