簡介：?從C++11開始，標準引入了一個新概念“屬性(attribute)”，本文將簡單介紹一下目前在C++標準中已經添加的各個屬性以及常用屬性的具體應用。

作者 | 寒冬
來源 | 阿里技術公眾號

從C++11開始，標準引入了一個新概念“屬性(attribute)”，本文將簡單介紹一下目前在C++標準中已經添加的各個屬性以及常用屬性的具體應用。

一 屬性(Attribute)的前世今生

其實C++早在[pre03]甚至更早的時候就已經有了屬性的需求。彼時，當程序員需要和編譯器溝通，為某些實體添加一些額外的信息的時候，為了避免“發明”一個新的關鍵詞乃至于引起一些語法更改的麻煩，同時又必須讓這些擴展內容不至于“污染”標準的命名空間，所以標準保留了一個特殊的用戶命名空間——“雙下劃線關鍵詞”，以方便各大編譯器廠商能夠根據需要添加相應的語言擴展。根據這個標準，各大編譯器廠商都做出了自己的擴展實現，目前在業界廣泛使用的屬性空間有GNU和IBM的 __attribute__(())，微軟的 __declspec()，甚至C#還引入了獨特的單括號系統(single bracket system)來完成相應的工作。

隨著編譯器和語言標準的發展，尤其是C++多年來也開始逐漸借鑒其他語言中的獨特擴展，屬性相關的擴展也越來越龐大。但是Attribute的語法強烈依賴于各大編譯器的具體實現，彼此之間并不兼容，甚至部分關鍵屬性導致了語言的分裂，最終都會讓使用者的無所適從。所以在C++11標準中，特意提出了C++語言內置的屬性概念。提案大約是在2007年前后形成，2008年9月15日的提案版本n2761被正式接納為C++11標準中的Attribute擴展部分（此處歷史略悠久，很可能有不準確的部分，歡迎各位指正）。

二 屬性的語法定義

正如我們在上一節討論的，屬性的關鍵要求就是避免對標準用戶命名空間的污染，同時對于未來可能引入的更多屬性，我們需要有一個方式可以避免新加的“屬性關鍵字”破壞當前已有的C++語法。所以新標準采用了“雙方括號”的語法方式引入了屬性說明，比如[[noreturn]]就是一個標準的C++屬性定義。而未來新屬性的添加都被控制在雙方括號范圍之內，不會進入標準的命名空間。

按照C++語言標準，下列語言實體可以被屬性所定義/并從中獲益：

• 函數
• 變量
• 函數或者變量的名稱
• 類型
• 程序塊
• Translation Unit （這個不知道用中文咋說）
• 程序控制聲明

根據C++的標準提案，屬性可以出現在程序中的幾乎所有的位置。當然屬性出現的位置和其修飾的對象是有一定關聯的，屬性僅在合適的位置才能產生效果。比如[[noreturn]必須出現在函數定義的位置才會產生效果，如果出現在某個變量的聲明處則無效。根據C++17的標準，未實現的或者無效的屬性均應該被編譯器忽略且不產生任何錯誤報告（在C++17標準之前的編譯器則參考編譯器的具體實現會有不同的行為）。

由于屬性可以出現在幾乎所有的位置，那么它是如何關聯到具體的作用對象呢？下面我引用了語言標準提案中的一個例子幫助大家理解屬性是如何作用于語言的各個部分。

[[attr1]] class C [[ attr2 ]] { } [[ attr3 ]] c [[ attr4 ]], d [[ attr5 ]];

• attr1 作用于class C的實體定義c和d
• attr2 作用于class C的定義
• attr3 作用于類型C
• attr4 作用于實體c
• attr5 作用于實體d

以上只是一個基本的例子，具體到實際的編程中，還有有太多的可能，如有具體情況可以參考C++語言標準或者編譯器的相關文檔。

三 主流C++編譯器對于屬性的支持情況

目前的主流編譯器對于C++11的支持已經相對很完善了，所以對于屬性的基本語法，大部分的編譯器都已經能夠接納。不過對于在不同標準中引入的各個具體屬性支持則參差不齊，對于相關屬性能否發揮應有的作用更需要具體問題具體分析。當然，在標準中（C++17）也明確了，對于不支持或者錯誤設定的屬性，編譯器也能夠忽略不會報錯。

下圖是目前主流編譯器對于n2761屬性提案的支持情況：

對于未知或不支持的屬性忽略報錯的主流編譯器支持情況：

四 目前C++標準中引入的標準屬性

C++11引入標準：

• [[noreturn]]
• [[carries_dependency]]

C++14引入標準：

• [[deprecated]] 和 [[deprecated("reason")]]

C++17引入標準：

• [[fallthrough]]
• [[nodiscard]] 和 [[nodiscard("reason")]] (C++20)
• [[maybe_unused]]

C++20引入標準：

• [[likely]] 和 [[unlikely]]
• [[no_unique_address]]

接下來我將嘗試對已經引入標準的屬性進行進一步的說明，同時對于已經明確得到編譯器支持的屬性，我也會嘗試用例子進行進一步的探索，希望拋磚引玉能夠幫大家更好的使用C++屬性這個“新的老朋友”。

1 [[noreturn]]

從字面意義上來看，noreturn是非常容易理解的，這個屬性的含義就是標明某個函數一定不會返回。

請看下面的例子程序：

// 正確，函數將永遠不會返回。 [[noreturn]] void func1() { throw "error"; }// 錯誤，如果用false進行調用，函數是會返回的，這時候會導致未定義行為。 [[noreturn]] void func2(bool b) { if (b) throw "error"; }int main() {try{ func1() ; }catch(char const *e){ std::cout << "Got something: " << e << " \n"; }// 此處編譯會有警告信息。func2(false); }

這個屬性最容易被誤解的地方是返回值為void的函數不代表著不會返回，它只是沒有返回值而已。所以在例子中的第一個函數func1才是正確的無返回函數的一個例子；而func2在參數值為false的情況下，它還是一個會返回的函數。所以，在編譯的時候，編譯器會針對func2報告如下錯誤：

noreturn.cpp: In function 'void func2(bool)': noreturn.cpp:11:1: warning: 'noreturn' function does return11 | }| ^

而實際運行的時候，func2到底會有什么樣的表現屬于典型的“未定義行為”，程序可能崩潰也可能什么都不發生，所以一定要避免這種情況在我們的代碼中出現。（我在gcc11編譯器環境下嘗試過幾次，情況是什么都不發生，但是無法保證這是確定的行為。）

另外，[[noreturn]]只要函數最終沒有返回都是可以的，比如用exit()調用直接將程序干掉的程序也是可以被編譯器接受的行為（只是暫時沒想到為啥要這么干）。

2 [[carries_dependency]]

這個屬性的作用是允許我們將dependency跨越函數進行傳遞，用于避免在弱一致性模型平臺上產生不必要的內存柵欄導致代碼效率降低。

一般來說，這個屬性是搭配 std::memory_order_consume 來使用的，支持這個屬性的編譯器可以根據屬性的指示生成更合適的代碼幫助程序在線程之間傳遞數據。在典型的情況下，如果在 memory_order_consume 的情況下讀取一個值，編譯器為了保證合適的內存讀取順序，可能需要額外的內存柵欄協調程序行為順序，但是如果加上了[[carries_dependency]]的屬性，則編譯器可以保證函數體也被擴展包含了同樣的dependency，從而不再需要這個額外的內存柵欄。同樣的事情對于函數的返回值也是一致的。

參考如下例子代碼：

std::atomic<int *> p; std::atomic<int *> q;void func1(int *val) { std::cout << *val << std::endl; }void func2(int * [[carries_dependency]] val) { q.store(val, std::memory_order_release); std::cout << *q << std::endl; }void thread_job() {int *ptr1 = (int *)p.load(std::memory_order_consume); // 1std::cout << *ptr1 << std::endl; // 2func1(ptr1); // 3func2(ptr1); // 4 }

• 程序在1的位置因為ptr1明確的使用了memory_order_consume的內存策略，所以對于ptr1的訪問一定會被編譯器排到這一行之后。
• 因為1的原因，所以這一行在編譯的時候勢必會排列在1后面。
• func1并沒有帶任何屬性，而他訪問了ptr1，那么編譯器為了保證內存訪問策略被尊重所以必須在func1調用之間構建一個內存柵欄。如果這個線程被大量的調用，這個額外的內存柵欄將導致性能損失。
• 在func2中，我們使用了[[carries_dependency]]屬性，那么同樣的訪問ptr1，編譯器就知道程序已經處理好了相關的內存訪問限制。這個也正如我們再func2中對val訪問所做的限制是一樣的。那么在func2之前，編譯器就無需再插入額外的內存柵欄，提高了效率。

3 [[deprecated]] 和 [[deprecated("reason")]]

這個屬性是在C++14的標準中被引入的。被這個屬性加持的名稱或者實體在編譯期間會輸出對應的警告，告訴使用者該名稱或者實體將在未來被拋棄。如果指定了具體的"reason"，則這個具體的原因也會被包含在警告信息中。

參考如下例子程序：

[[deprecated]] void old_hello() {}[[deprecated("Use new_greeting() instead. ")]] void old_greeting() {}int main() {old_hello();old_greeting();return 0; }

在支持對應屬性的編譯器上，這個例子程序是可以通過編譯并正確運行的，但是編譯的過程中，編譯器會對屬性標志的函數進行追蹤，并且打印出相應的信息（如果定義了的話）。在我的環境中，編譯程序給出了我如下的提示信息：

deprecated.cpp: In function 'int main()': deprecated.cpp:9:14: warning: 'void old_hello()' is deprecated [-Wdeprecated-declarations]9 | old_hello();| ~~~~~~~~~^~ deprecated.cpp:2:6: note: declared here2 | void old_hello() {}| ^~~~~~~~~ deprecated.cpp:10:17: warning: 'void old_greeting()' is deprecated: Use new_greeting() instead. [-Wdeprecated-declarations]10 | old_greeting();| ~~~~~~~~~~~~^~ deprecated.cpp:5:6: note: declared here5 | void old_greeting() {}| ^~~~~~~~~~~~

[[deprecated]]屬性支持廣泛的名字和實體，除了函數，它還可以修飾：

• 類，結構體
• 靜態數據成員，非靜態數據成員
• 聯合體，枚舉，枚舉項
• 變量，別名，命名空間
• 模板特化

4 [[fallthrough]]

這個屬性只可以用于switch語句中，通常在case處理完畢之后需要按照程序設定的邏輯退出switch塊，通常是添加break語句；或者在某些時候，程序又需要直接進入下一個case的判斷中。而現代編譯器通常會檢測程序邏輯，在前一個case處理完畢不添加break的情況下發出一個警告信息，讓作者確定是否是他的真實意圖。但是，在case處理部分添加了[[fallthrough]]屬性之后，編譯器就知道這是程序邏輯有意為之，而不再給出提示信息。

5 [[nodiscard]] 和 [[nodiscard("reason")]]

這兩個屬性和前面的[[deprecated]]類似，但是他們是在不同的C++標準中被引入的，[[nodiscard]]是在C++17標準中引入，而[[nodiscard("reason")]]是在C++20標準中引入。

這個屬性的含義是明確的告訴編譯器，用此屬性修飾的函數，其返回值（必須是按值返回）不應該被丟棄，如果在實際調用中舍棄了返回變量，則編譯器會發出警示信息。如果此屬性修飾的是枚舉或者類，則在對應函數返回該類型的時候也不應該丟棄結果。

參考下面的例子程序：

struct [[nodiscard("IMPORTANT THING")]] important {}; important i = important(); important get_important() { return i; } important& get_important_ref() { return i; } important* get_important_ptr() { return &i; }int a = 42; int* [[nodiscard]] func() { return &a; }int main() {get_important(); // 此處編譯器會給出警告。get_important_ref(); // 此處因為不是按值返回nodiscard類型，不會有警告。get_important_ptr(); // 同上原因，不會有警告。func(); // 此處會有警告，雖然func不按值返回，但是屬性修飾的是函數。return 0; }

在對上述例子進行編譯的時候，我們可以看到如下的警告信息：

nodiscard.cpp:8:25: warning: 'nodiscard' attribute can only be applied to functions or to class or enumeration types [-Wattributes]8 | int* [[nodiscard]] func() { return &a; }| ^ nodiscard.cpp: In function 'int main()': nodiscard.cpp:12:18: warning: ignoring returned value of type 'important', declared with attribute 'nodiscard': 'IMPORTANT THING' [-Wunused-result]12 | get_important();| ~~~~~~~~~~~~~^~ nodiscard.cpp:3:11: note: in call to 'important get_important()', declared here3 | important get_important() { return i; }| ^~~~~~~~~~~~~ nodiscard.cpp:1:41: note: 'important' declared here1 | struct [[nodiscard("IMPORTANT THING")]] important {};| ^~~~~~~~~

可以看到，編譯器對于按值返回帶屬性的類型被丟棄發出了警告，但是對于非按值返回的調用沒有警告。不過如果屬性直接修飾的是函數體，那么則不受此限制。

在新的C++標準中，除了添加了[[nodiscard]]屬性對應的處理邏輯，同時對于標準庫中的不應該丟棄返回值的操作也添加相應的屬性修飾，包含內存分配函數，容器空判斷函數，異步運行函數等。請參考下面的例子：

#include <vector> std::vector<int> vect;int main() { vect.empty(); }

在編譯這個例子的時候，我們收到了編譯器的如下警告，可見，新版本的標準庫也已經對[[nodiscard]]屬性提供了支持（不過這個具體要看編譯器和對應庫版本，需要參考編譯器和標準的提供方）。

nodiscard2.cpp: In function 'int main()': attibute/nodiscard2.cpp:5:13: warning: ignoring return value of 'bool std::vector<_Tp, _Alloc>::empty() const [with _Tp = int; _Alloc = std::allocator<int>]', declared with attribute 'nodiscard' [-Wunused-result]5 | { vect.empty(); }| ~~~~~~~~~~^~ In file included from /usr/local/include/c++/11.1.0/vector:67,from attibute/nodiscard2.cpp:1: /usr/local/include/c++/11.1.0/bits/stl_vector.h:1007:7: note: declared here1007 | empty() const _GLIBCXX_NOEXCEPT| ^~~~~

6 [[maybe_unused]]

通常情況下，對于聲明了但是從未使用過的變量會給出警告信息。但是在聲明的時候添加了這個屬性，則編譯器確認是程序故意為之的邏輯，則不再發出警告。需要注意的是，這個聲明不會影響編譯器的優化邏輯，在編譯優化階段，無用的變量該干掉還是會被干掉的。

7 [[likely]] 和 [[unlikely]]

這一對屬性是在C++20的時候引入標準的，這兩個語句只允許用來修飾標號或者語句（非聲明語句），目的是告訴編譯器，在通常情況下，哪一個分支的執行路徑可能性最大，顯然，他倆也是不能同時修飾同一條語句。

截止我撰寫本文的今天，已經有不少編譯器對于這個屬性提供了支持，包括GCC9，Clang12，MSVC19.26等等。但是結合現代編譯器各種登峰造極的優化行為，我們在使用這個屬性的時候也需要有一個合理的期望，不能指望他發揮點石成金的效果。當然，這并不代表我不鼓勵你使用它們，明確的讓編譯器知道你的意圖總歸是一件好事情。

同樣的，我們先來看第一個例子：

我們看到case 1是我們明確用屬性標明的運行時更有可能走到的分支，那么我們可以看到對應生成的匯編代碼中，case 1的流程是：首先給eax寄存器賦值5，然后比對輸入值1，如果輸入值為1，則直接返回，eax寄存器包含返回值。但如果這時候輸入值不為1，則需要一次跳轉到.L7去進行下面的邏輯。顯然，在case1的情況下，代碼是不需要任何跳轉，直接運行的。

我們再看第二個例子：

這次我們將優先級順序調轉，用屬性標明case 2的是運行時更有可能走到的分支，那么對應的匯編代碼中，我們看看case 1的邏輯：首先進來就和1比對，如果相等，跳轉到.L3執行返回5的操作；如果不相等，那么直接和2比對，同時edx和eax寄存器分別賦值7和1，根據比對的結果確定是否將edx的值賦值到eax（cmove語句），然后返回。似乎上來還是優先比對了1的情況，但是仔細研究我們就會發現，在case 2的邏輯通路上是不存在跳轉指令的，意味著case 2的流程也是需要跳轉可以直接運行下去的，沒有跳轉處理器也就不需要清空流水線（此處簡化理論，不涉及到處理器內部分支預測邏輯），case 2相對于case 1還是更加快速的流程，[[likely]]屬性發揮了它應有的作用。

當然，程序的優化涉及到的領域實在太多了，在真實的場景中，[[likely]]和[[unlikely]]屬性能否如我們所愿發揮作用是需要具體問題具體分析的。不過正確的使用屬性即便沒有正向收益，也不會有負收益，并且我相信在大部分的場景下這是有好處的，并且在未來編譯器更加優化之后，明確意圖的代碼總是能得到更多優化。

8 [[no_unique_address]]

這個屬性也是在C++20中引入的，旨在和編譯器溝通非位域非靜態數據成員不需要具有不同于其相同類型其他非靜態成員不同的地址。帶來的效果就是，如果該成員擁有空類型，則編譯器可以將它優化為不占用空間的部分。

下面也還是用一個例子來演示一下這個屬性吧：

#include <iostream> struct Empty {}; // 空類型 struct X { int i; }; struct Y1 { int i; Empty e; }; struct Y2 { int i; [[no_unique_address]] Empty e; }; struct Z1 { char c; Empty e1, e2; }; struct Z2 { char c; [[no_unique_address]] Empty e1, e2; };int main() {std::cout << "空類大小：" << sizeof(Empty) << std::endl;std::cout << "只有一個int類大小：" << sizeof(X1) << std::endl;std::cout << "一個int和一個空類大小：" << sizeof(Y1) << std::endl;std::cout << "一個int和一個[[no_unique_address]]空類大小：" << sizeof(Y2) << std::endl;std::cout << "一個char和兩個空類大小：" << sizeof(Z1) << std::endl;std::cout << "一個char和兩個[[no_unique_address]]空類大小：" << sizeof(Z2) << std::endl; }

編譯之后，我們運行程序可以得到如下結果（這個例子是在Linux x64 gcc11.1下的結果，不同的操作系統和編譯器可能結果不同）：

空類大小：1

只有一個int類大小：4

一個int和一個空類大小：8

一個int和一個[[no_unique_address]]空類大小：4

一個char和兩個空類大小：3

一個char和兩個[[no_unique_address]]空類大小：2

說明：

• 對于空類型，在C++中也會至少分配一個地址，所以空類型的尺寸大于等于1。
• 如果類型中有一個非空類型，那么這個類的尺寸等于這個非空類型的大小。
• 如果類型中有一個非空類型和一個空類型，那么尺寸一定大于非空類型尺寸，編譯器還需要分配額外的地址給非空類型。具體會需要分配多少大小取決于編譯器的具體實現。本例子中用的是gcc11，我們看到為了對齊，這個類型的尺寸為8，也就是說，空類型分配了一個和int對齊的4的尺寸。
• 如果空類型用[[no_unique_address]]屬性修飾，那么這個空類型就可以和其他非同類型的非空類型共享空間，可以看到，這里編譯器優化之后，空類型和int共享了同一塊內存空間，整個類型的尺寸就是4。
• 如果類型中有一個char類型和兩個空類型，那么編譯器對于兩個空類型都分配了和非空類型char同樣大小的尺寸，整個類型占用內存為3。
• 同樣的，如果兩個空類型都用[[no_unique_address]]進行修飾的話，我們發現，其中一個空類型可以和char共享空間，但是另外一個空類型無法再次共享同一個地址，又不能和同樣類型的空類型共享，所以整個結構的尺寸為2。

五 總結

以上本文介紹了屬性作為一個新的“舊概念”是如何引入到C++標準的和屬性的基本概念，同時還介紹了已經作為標準引入C++語言特性的部分屬性，包含C++11，14，17和20的部分內容。希望能夠拋磚引玉，和大家更好地理解C++的新功能并讓它落地并服務于我們的產品和項目，初次撰文，如果有錯漏缺失，還請各位讀者斧正。

原文鏈接

本文為阿里云原創內容，未經允許不得轉載。

總結

以上是生活随笔為你收集整理的谈谈C++新标准带来的属性（Attribute）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。