i'm sam

[180] Google's Abseil Project, Part 1

Sam Tsai -

Google 在今年的 CppCon 推出重量級的 C++ Library — Abseil。官網上的自我介紹：

Abseil is an open-source collection of C++ library code designed to augment the C++ standard library. The Abseil library code is collected from Google’s own C++ code base, has been extensively tested and used in production, and is the same code we depend on in our daily coding lives.

我在上述自介看到兩點：

  1. Abseil 預期跟 C++ Standard Library 合作愉快，其設計目標是補標準之不足，而非取代
  2. Abseil 是一個高品質的 C++ 程式碼集合，而這又帶出兩點：
    • 可以安心在自己的專案服用
    • 應該花時間學習閱讀其架構與程式碼

來真的嗎？

在 Abseil 官方網站中，Google 解釋為什麼你應該慎重考慮把 Abseil 納入專案裡：

  1. 保證相容於現在以及未來的 C++ 標準規格
  2. 諸多 Google 開源專案皆使用 Abseil 作為基礎構件，如 Protocol Buffers、gRPC 以及TesorFlow。（實際走訪該些專案，發現 gRPC 有用到 Abseil）
  3. 升級容易，時時享用最新版。（因為 Abseil 高度 API 相容，所以不用擔心 pull master 會爆掉）
  4. 實戰經驗豐富，在 Google 等級的產品中身經百戰
  5. 與 C++ 標準規格的設計考量不盡相同，在與標準相容的前提下，採用不同的設計考量

Abseil 可以說是 Google 多年來的心血結晶，撞了不少牆，從錯誤中學到的經驗後的修正皆在 Abseil 專案體現。但 Abseil 非銀彈，這點 Google 說得很清楚。有了正確的期待才能有效利用 Abseil，最大化其效益。

有鑑於先前使用 Chromium C++ Code 的痛苦經驗，看到 Google 修正了 Chromium 無法做為通用型工具專案的缺點，我等不及在下一個專案中導入 Abseil。不過，衝動歸衝動，還是要先做一些評估。這時候 Side Project 最好用。

要我說，Google 來真的嗎？我說是。接著來看看「使用說明」，並把注意事項列出來。

注意事項

採用 Apache 授權，商用軟體可以安心使用。

使用 Abseil 有一些地方要注意，官方明白指出：

  1. Abseil 不保證 ABI 相容，服用時，一律由原始碼編譯。也就是說，不要將 Abseil 編譯成 DLL 然後不重編譯導至新舊版本混用。這麼做肯定會死，只是時間早晚與何處發生的問題
  2. Abseil 會努力維護 API 相容，若真發生 API 不相容的改動，Abseil 團隊會講清楚，說明白，而且還會提供升級機制，讓 Abseil 用戶依照步驟即可輕易轉換至新的版本。所以，需要工具的場合不要遲疑
  3. 不要使用動態缷載（Dynamic Unloading）
  4. 不要使用動態載入（Dynamic Loading）
  5. 不要對 absl namespace 及裡頭的程式碼有非分之想
  6. 不要在 Abseil 使用前置宣告（Forward Declararion）招術
  7. 使用Abseil 時，儘量不要依賴 Argument-Dependent Lookup (ADL)。什麼是 ADL，請見此說明
  8. 避免相依於 Abseil 內部實作
  9. 用到 Abseil 的地方，儘量使用 full qualified name，也就是包含 namespace

Abseil 的承諾

開源專案的敵人之一是：服用免費，後果自負。通常專案的主要維護者不會提供任何的保證，如維持介面不改，保證往前相容等。使用開源專案時，必須要有自覺，一旦出問題，能靠得是自己，靠別人得看運氣或人品。

以前使用 Chromium 專案的程式碼面臨同樣的問題，裡頭有許多優質的程式碼，但 Chromium Team 明白表示，雖它們看起來維護良好，但該些程式碼持續在變，其他專案不應該依賴該些不打算給外界使用的程式碼。要用可以，介面改了造成編譯不過，請自行處置，此類問題反應一概不理。

Abseil 把自己推出去的企圖心之強，官方提供以下承諾：

  1. 提供五年保固
  2. 保持 API 相容
  3. 往後相容 C++ 標準
  4. 提供 exception-safe 基本款

幾乎所有軟體專案都內含 Workaround，這種變通方法有時叫「暫時解」或「沒臉見人解」。Abseil 也不例外。有些「暫時解」歸功於外在因素，例如 Xcode 7 以前不支援 Thread-Local Storage，那麼 Xcode 8 推出之後的五年，便不支援 Xcode 7，會拿掉為了她而設計的「暫時解」。

保證 API 層的相容性。絕不會發生一夜醒來，原本好端端的專案一編譯出現鬼見愁的錯誤訊息。一旦遇到非要破壞相容性才能解決的問題，也會一併提供轉換工具，而且等一段時間後才會拿掉舊的介面。

Abseil 未來的版本一定相容於現在以及未來的 C++ 標準規格。大頭都照著規格走，對 C++ 長遠的發展助益甚大。

Google 不愛 C++ Exception 舉世皆之，Google C++ Style Guide Exception 章節開頭即說＂We do not use C++ exceptions.＂。＂not use＂ 跟 ＂not support＂ 還是有些差別，有機會再談。Google 知道他們是少數不使用 Exception 的族群，因此，Abseil 會盡力做到 exception-safe，但可以預期例外有時候還是會例外。

其他

Abseil 的專案負責人 Titus Winters 日前上 CppCast 閒聊。這傢伙也負責維護 Google C++ Style Guide。

Google 在此次 CppCon 提供若干演講，值得看看：

🔚