Abseil Blog

    Abseil Breaking Change Policy Update

    28 Aug 2023

    Abseil Breaking Change Policy Update

    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.

    Read more


    Perf Tips

    02 Mar 2023

    Performance Tips of the Week

    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.

    Read more


    Abseil Stringify

    15 Nov 2022

    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.


    Abseil Logging

    08 Sep 2022

    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];
    }
    

    Read more


    The Danger of Atomic Operations

    18 Jan 2022

    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.



Subscribe to the Abseil Blog