Abseil Blog

The Abseil str_format Library

22 Jun 2018

By Juemin Yang, Abseil Engineer

Abseil now includes a type-safe string formatting library: str_format. The str_format library is a typesafe replacement for the family of printf() string formatting routines within the <cstdio> standard library header. The str_format library provides most of the functionality of printf() type string formatting and a number of additional benefits:

• Type safety, including native support for std::string and absl::string_view
• Reliable behavior independent of standard libraries
• Support for the POSIX positional extensions
• Much faster (generally 2 to 3 times faster) than native printf functions
• Streamable to a variety of existing sinks

For more information, consult Abseil’s StrFormat Guide If you are interested in the design of this library, check out our StrFormat Design Notes.

---

Long-Term Support (LTS) Branches

18 Jun 2018

By Tom Manshreck, Abseil Tech Writer

Abseil encourages developers to “live at head” but we understand that philosophy may not work for everyone. We are therefore providing snapshots of the Abseil codebase. These snapshots are available as “Long Term Support” (LTS) branches of Abseil, and we intend to provide a new snapshot every 6 months or so.

We pledge to support these LTS snapshots for at least 2 years. If critical bug fixes, such as security issues, require us to change Abseil, we will also change them within any supported LTS snapshot.

NOTE: we don’t want you to think of these snapshots as “versions.” They are simply a snapshot of the codebase at a specific point in time. If you cannot build from source or otherwise live at head, prefer to use the latest LTS branch of Abseil instead.

For more information, consult Abseil’s Release Management guide.

---

Revisiting Regular Types

31 May 2018

Good types are all alike; every poorly designed type is poorly defined in its own way. - Adapted with apologies to Leo Tolstoy

By Titus Winters

Abstract

With 20 years of experience, we know that Regular type design is a good pattern - we should model user-defined types based on the syntax and semantics of built-in types where possible. However, common formulations of Regular type semantics only apply to values, and for performance reasons we commonly pass by reference in C++. In order to use such a reference as if it were its underlying Regular type we need some structural knowledge of the program to guarantee that the type isn’t being concurrently accessed. Using similar structural knowledge, we can treat some non-Regular types as if they were Regular, including reference types which don’t own their data. Under such an analysis, string_view indeed behaves as if it were Regular when applied to common usage (as a parameter). However, span does not, and further it is (currently) impossible to have shallow copy, deep compare, and Regular const semantics in the same type in C++.

This analysis provides us some basis to evaluate non-owning reference parameters types (like string_view and span) in a practical fashion, without discarding Regular design.

Read more

---

Abseil No Longer Depends on CCTZ

11 May 2018

An Update On Our Dependencies

By Shaindel Schwartz, Abseil Engineer

As of the April 23 update, af78826 , Abseil no longer requires an external dependency on CCTZ. If you have included the CCTZ project solely to satisfy the Abseil dependency, you can now safely remove it from your project’s setup.

Read more

---

What Should Go Into the C++ Standard Library

27 Feb 2018

By Titus Winters ([email protected]), @TitusWinters

About the Author - Titus holds a PhD in Computer Science Education from UC Riverside. He created most of Google’s internal C++ coursework, and plays an active role in the C++ mentoring program that serves several thousand Google C++ engineers. He has been deeply involved in C++ library infrastructure since 2011, through the Google C++ Library Team and now Abseil. He chairs the Library Evolution Working Group (LEWG) - the sub-committee of the C++ Standard that focuses on the design of the C++ standard library.

A few interesting pieces on the direction and design for C++ have circulated recently. First off, I strongly recommend everyone read through Direction for ISO C++ ; it provides a lot of excellent detail and suggestions, as well as some much-needed guidance on how the language should evolve. In particular, I think it’s really important to note “No language can be everything for everybody,” the technical “pillars” upon which C++ rests, and the call to remind everyone to go read “The Design and Evolution of C++”. The Direction Group is very rightly showing concern about the breadth of things being proposed for the standard, as well as how to maintain velocity and stability as we continue to move forward at an ever more rapid pace.

Read more

---