親自上陣！C++大佬深度“劇透”：C++26將如何在代碼生成上對(duì)抗Rust？

點(diǎn)擊上方“C語(yǔ)言與CPP編程”，選擇“關(guān)注/置頂/星標(biāo)公眾號(hào)”
干貨福利，第一時(shí)間送達(dá)！
最近有小伙伴說(shuō)沒有收到當(dāng)天的文章推送，這是因?yàn)槲⑿鸥牧送扑蜋C(jī)制，導(dǎo)致沒有星標(biāo)公眾號(hào)的小伙伴刷不到當(dāng)天推送的文章，無(wú)法接收到一些比較實(shí)用的知識(shí)和資訊。所以建議大家加個(gè)星標(biāo)??，以后就能第一時(shí)間收到推送了。

我很喜歡做的一件事，就是比較不同編程語(yǔ)言如何解決相同的問題，尤其是當(dāng)這些語(yǔ)言采取了截然不同的方法時(shí)，我覺得這非常具有教育意義。在這篇文章中，我們將嘗試把反射（reflection）這一顛覆性的語(yǔ)言特性引入到 C++26 標(biāo)準(zhǔn)中。從根本上來(lái)講，反射可以分為兩大部分：

1、自?。↖ntrospection）：在編譯期間，能夠?qū)Τ绦蜻M(jìn)行查詢的能力。

2、代碼生成（Code Generation）：讓程序自動(dòng)生成新代碼的能力。

針對(duì) C++26 的 P2996 提案是一個(gè)處理自省問題的核心提案，它為未來(lái)擴(kuò)展反射功能奠定了基礎(chǔ)，涵蓋多個(gè)方向的延展功能（例如 P3294 的代碼生成設(shè)計(jì)）。然而，雖然自省功能本身非常有用，但它只解決了一半的問題——知名 C++ 技術(shù)專家 Andrei Alexandrescu 甚至在 CppCon 大會(huì)上宣稱，如果沒有代碼生成，自省幾乎是“無(wú)用的”。

目前，C++ 確實(shí)有一種代碼生成功能：C 宏（C Macros）。不過(guò)，這種機(jī)制非常原始，且存在許多局限。首先，C 宏缺乏嚴(yán)格的語(yǔ)法規(guī)則，甚至可能在不知情的情況下調(diào)用宏（標(biāo)準(zhǔn)庫(kù)實(shí)現(xiàn)對(duì)此有保護(hù)措施）。其次，實(shí)現(xiàn)一些簡(jiǎn)單的邏輯（如迭代或條件判斷）往往需要相當(dāng)復(fù)雜的技巧。然而，盡管存在這些問題，在某些場(chǎng)景下，C 宏仍然是最好的解決方案——這也反映了我們迫切需要更完善的代碼生成機(jī)制。

另一方面，Rust 雖然沒有任何自省功能，但它擁有成熟的代碼生成機(jī)制，特別是其聲明式和過(guò)程宏。因此本文將重點(diǎn)討論 Rust 的過(guò)程宏，尤其是派生宏（derive macro）。我們將通過(guò)兩個(gè)示例展示派生宏如何解決問題，分析其工作原理，以及我們?nèi)绾螢?C++26 提出截然不同的解決方案。

不過(guò)，我不是專業(yè) Rust 程序員，因此如果我在文中犯了錯(cuò)誤，還請(qǐng)大家指正。更新一下，在發(fā)布這篇博客后，有人指出我在一些地方犯了錯(cuò)誤，我已經(jīng)進(jìn)行了更正。這些錯(cuò)誤包括：我曾提到 Rust 屬性無(wú)法接受任意值（其實(shí)它是可以的，只是舊版本選擇不這么做），以及有比我提到的更好的方式來(lái)解析屬性（實(shí)際上大多數(shù)人都采用類似做法）。

1、結(jié)構(gòu)體的美化打印（Pretty-Printing）

當(dāng)你學(xué)會(huì)如何聲明一個(gè)帶有新成員的類型后，很可能會(huì)想讓這個(gè)類型進(jìn)行調(diào)試打印（debug-printable）。不僅是因?yàn)檎{(diào)試打印在日常開發(fā)中非常有用，還因?yàn)樵?Rust 中實(shí)現(xiàn)這一功能非常簡(jiǎn)單：

#[derive(Debug)]struct Point {    x: i32,    y: i32,}
fn main() {    let p = Point { x: 1, y: 2 };    // prints: p=Point { x: 1, y: 2 }    println!("p={p:?}");}

代碼的第一行通過(guò) #[derive(Debug)] 讓 Point 結(jié)構(gòu)體支持調(diào)試打印。它的作用是自動(dòng)生成代碼，使得可以打印類型名稱以及所有成員的名稱和值，并按順序輸出。

在我手頭的《Rust 編程語(yǔ)言》書中，第 82 頁(yè)就展示了如何聲明一個(gè) struct，第 89 頁(yè)則展示了如何讓它支持調(diào)試打印，這幾乎是 Rust 學(xué)習(xí)過(guò)程中最早會(huì)遇到的功能之一。對(duì)于這個(gè)任務(wù)，Rust 還提供了另一個(gè)簡(jiǎn)便的方式：dbg!(p)，不過(guò)這里我使用 println! 是為了更貼近未來(lái)在 C++ 中實(shí)現(xiàn)類似功能的方式。

由于這是編譯時(shí)的注解（annotation），如果以后我為 Point 結(jié)構(gòu)體添加了一個(gè)新字段（比如我決定將其擴(kuò)展為三維結(jié)構(gòu)體，添加一個(gè) z 字段），調(diào)試打印的輸出也會(huì)自動(dòng)更新，以打印新字段的值。

總結(jié)來(lái)說(shuō)就是：非常簡(jiǎn)單！

你可能會(huì)問，這究竟是如何實(shí)現(xiàn)的？是什么使得宏和 Debug 特性（trait）能夠?qū)崿F(xiàn)這種交互？正如我之前提到的，不同于我們?yōu)?C++26 提出的方案，Rust 沒有任何形式的自?。╥ntrospection）功能，也沒有機(jī)制可以查詢結(jié)構(gòu)體的成員并對(duì)其進(jìn)行迭代。

相反，Rust 的 derive 宏采用了非常不同的方式：它是一個(gè)函數(shù)，接收被注解結(jié)構(gòu)體的 Token 流作為輸入，生成相應(yīng)的 Token 流代碼并注入到代碼中。實(shí)際上，這些注入的代碼并不一定與輸入直接相關(guān)。

在這種情況下，我們通過(guò)獲取 Point 結(jié)構(gòu)體的?Token?流輸入，解析它，并使用解析結(jié)果生成我們需要的輸出，從而繞過(guò)了缺乏自省的問題。我想這也算是一種“自省”——只不過(guò)它只能在特定情況下明確選擇使用。

在上面的例子中，derive 宏生成了如下代碼（我使用 cargo expand 得到的結(jié)果）：

#[automatically_derived]impl ::core::fmt::Debug for Point {    #[inline]    fn fmt(&self, f: &mut ::core::fmt::Formatter) -> ::core::fmt::Result {        ::core::fmt::Formatter::debug_struct_field2_finish(            f,            "Point",            "x",            &self.x,            "y",            &&self.y,        )    }}

這個(gè)代碼看起來(lái)并不復(fù)雜，但關(guān)鍵在于 Rust 程序員無(wú)需手動(dòng)編寫這些模板代碼。他們只需要學(xué)習(xí)如何寫一行代碼（實(shí)際上，連一整行都不需要）：#[derive(Debug)]。這就是代碼生成的強(qiáng)大之處。

即便如此，這個(gè)結(jié)果也很有趣。為什么對(duì) self.x 使用 &self.x，而對(duì) self.y 使用 &&self.y 呢？這與 Rust 無(wú)法進(jìn)行自省功能有關(guān)。在 Rust 中，最后一個(gè)字段可以是不定長(zhǎng)類型（unsized type）。不定長(zhǎng)類型可以被打印，但是需要一個(gè)額外的間接層。derive 宏無(wú)法知道 y 是否是定長(zhǎng)的（在這個(gè)例子中它是 i32，所以是定長(zhǎng)的），所以為了支持兩種情況，宏預(yù)先添加了這個(gè)額外的間接層。

在 C++ 中，如果想要提出的方案盡量貼近 Rust 的語(yǔ)法，可以這樣實(shí)現(xiàn)：

struct [[=derive]] Point {    int x;    int y;};
int main() {    auto p = Point{.x=1, .y=2};    // prints p=Point{.x=1, .y=2}    std::println("p={}", p);}

從本質(zhì)上講，C++ 和 Rust 的格式化機(jī)制有一些相似之處。在 Rust 中，你必須為 Debug trait 提供一個(gè) impl。而在 C++ 中，你需要特化 std::formatter（我們不區(qū)分 Debug 和 Display）。正如我之前展示的，Rust 的宏調(diào)用會(huì)為類型注入正確的 impl Debug 代碼，而在 C++ 中，我們并沒有這樣做。

我在這里使用的特性叫做“注解”（annotation），這個(gè)功能將在 P3394 提案中提出，首次由 Daveed Vandevoorde 在 CppCon 的閉幕演講中披露。這個(gè)提案的目標(biāo)是讓你能夠以一種自省可以觀察到的方式標(biāo)注聲明。值得注意的是，這里并沒有發(fā)生任何代碼注入，我們只是稍微擴(kuò)展了一下自省功能。

然而，鑒于 C++?本身具備自省功能（或者將隨著 P2996 的提出而獲得），這已經(jīng)足夠完成我們的目標(biāo)。我們可以提前提供一個(gè)特化的 std::formatter，該特化會(huì)在類型帶有 derive 注解時(shí)啟用，而這個(gè)注解本質(zhì)上只是一個(gè)空值：

template <auto V> struct Derive { };template <auto V> inline constexpr Derive derive;
inline constexpr struct{} Debug;
template <class T> requires (has_annotation(^^T, derive))struct std::formatter {    // ...};

一旦我們有了這個(gè)基礎(chǔ)，特化的實(shí)現(xiàn)就可以對(duì)類型?T?進(jìn)行自省，獲取我們需要的所有信息，以便展示：我們可以迭代所有非靜態(tài)的數(shù)據(jù)成員，格式化它們的名稱和值。一個(gè)簡(jiǎn)化的實(shí)現(xiàn)如下：

template <class T> requires (has_annotation(^^T, derive))struct std::formatter {    constexpr auto parse(auto& ctx) { return ctx.begin(); }
    auto format(T const& m, auto& ctx) const {        auto out = std::format_to(ctx.out(),                                  "{}", display_string_of(^^T));        *out++ = '{';
        bool first = true;        [:expand(nonstatic_data_members_of(^^T)):] >> [&]<auto nsdm>{            if (not first) {                *out++ = ',';                *out++ = ' ';            }            first = false;
            out = std::format_to(out,                                 ".{}={}",                                 identifier_of(nsdm), m.[:nsdm:]);        };
        *out++ = '}';        return out;    }};

某種意義上來(lái)說(shuō)，我們?nèi)匀皇窃谏纱a——模板實(shí)際上就是 C++ 中的一種代碼生成形式。但有趣的是，在這里我們通過(guò)非常不同的機(jī)制實(shí)現(xiàn)了相同的目標(biāo)。

請(qǐng)注意，這就是完整的實(shí)現(xiàn)代碼，可以看到代碼量其實(shí)并不多。

2、JSON 序列化

在之前討論的調(diào)試打印示例中，我們只是簡(jiǎn)單地按順序打印所有成員。那么如果我們想做些更復(fù)雜的操作呢？在處理序列化時(shí)，有時(shí)字段的名稱可能需要與原始的成員名不同。還有些情況，目標(biāo)格式在編程語(yǔ)言中根本無(wú)法直接表達(dá)——比如字段名可能是語(yǔ)言中的關(guān)鍵字，或者字段名包含空格等等。

因此，Rust 的 serde 庫(kù)提供了許多注解屬性，可以添加到類型和成員上，以控制序列化邏輯。下面是一個(gè)簡(jiǎn)單的例子：

use serde::Serialize;use serde_json;
#[derive(Serialize)]struct Person {    #[serde(rename = "first name")]    first: String,
    #[serde(rename = "last name")]    last: String,}
fn main() {    let person = Person {        first: "Peter".to_owned(),        last: "Dimov".to_owned(),    };    let j = serde_json::to_string(&person).unwrap();
    // prints {"first name":"Peter","last name":"Dimov"}    println!("{}", j);}

類似于?Debug?特性，Serialize?的派生宏會(huì)為我們注入一個(gè)實(shí)現(xiàn)，其生成的代碼如下：

#[doc(hidden)]#[allow(non_upper_case_globals, unused_attributes, unused_qualifications)]const _: () = {    #[allow(unused_extern_crates, clippy::useless_attribute)]    extern crate serde as _serde;    #[automatically_derived]    impl _serde::Serialize for Person {        fn serialize<__S>(            &self,            __serializer: __S,        ) -> _serde::__private::Result<__S::Ok, __S::Error>        where            __S: _serde::Serializer,        {            let mut __serde_state = _serde::Serializer::serialize_struct(                __serializer,                "Person",                false as usize + 1 + 1,            )?;            _serde::ser::SerializeStruct::serialize_field(                &mut __serde_state,                "first name",                &self.first,            )?;            _serde::ser::SerializeStruct::serialize_field(                &mut __serde_state,                "last name",                &self.last,            )?;            _serde::ser::SerializeStruct::end(__serde_state)        }    }};

在這里，你可以看到想要序列化的字段名（如?"first name"?和?"last name"）與實(shí)際的成員綁定在一起。需要注意的是，false as usize + 1 + 1?是用來(lái)表示要序列化的字段數(shù)量的構(gòu)造，這里的 2 顯然是字段的數(shù)量。

如果我們要添加一個(gè)中間名，并且只有當(dāng)它非空時(shí)才進(jìn)行序列化，可以使用 skip_serializing_if 屬性：

#[derive(Serialize)]struct Person {    #[serde(rename = "first name")]    first: String,
    #[serde(rename = "middle name", skip_serializing_if = "String::is_empty")]    middle: String,
    #[serde(rename = "last name")]    last: String,}

生成的代碼如下，具體新增部分為第 18-19 行、第 26-37 行：

#[doc(hidden)]#[allow(non_upper_case_globals, unused_attributes, unused_qualifications)]const _: () = {    #[allow(unused_extern_crates, clippy::useless_attribute)]    extern crate serde as _serde;    #[automatically_derived]    impl _serde::Serialize for Person {        fn serialize<__S>(            &self,            __serializer: __S,        ) -> _serde::__private::Result<__S::Ok, __S::Error>        where            __S: _serde::Serializer,        {            let mut __serde_state = _serde::Serializer::serialize_struct(                __serializer,                "Person",                false as usize + 1 + if String::is_empty(&self.middle) { 0 } else { 1 }                    + 1,            )?;            _serde::ser::SerializeStruct::serialize_field(                &mut __serde_state,                "first name",                &self.first,            )?;            if !String::is_empty(&self.middle) {                _serde::ser::SerializeStruct::serialize_field(                    &mut __serde_state,                    "middle name",                    &self.middle,                )?;            } else {                _serde::ser::SerializeStruct::skip_field(                    &mut __serde_state,                    "middle name",                )?;            }            _serde::ser::SerializeStruct::serialize_field(                &mut __serde_state,                "last name",                &self.last,            )?;            _serde::ser::SerializeStruct::end(__serde_state)        }    }};

但在 C++?中，我們并沒有像?serde?這樣的庫(kù)，它可以分離序列化的字段名和成員變量的名稱，至少我目前不知道有這樣的庫(kù)。C++ 中，通常是 JSON 庫(kù)處理 JSON 序列化，TOML 庫(kù)處理 TOML 序列化等。也許這是因?yàn)?C++ 缺乏像 Rust 那樣的語(yǔ)言支持，所以無(wú)法輕松實(shí)現(xiàn)這種序列化機(jī)制？

老實(shí)說(shuō)，雖然在格式化方面 Rust 和 C++?的實(shí)現(xiàn)有些相似，但在序列化的靈活性上 Rust 確實(shí)更具優(yōu)勢(shì)。盡管 C++ 中沒有完全類似 serde 的庫(kù)，但我們也可以使用類似 Boost.JSON 這樣的庫(kù)來(lái)實(shí)現(xiàn)序列化。

我們從支持 derive 和 rename 開始，這是為了讓代碼能夠正常工作的全部需求：

struct [[=derive]] Point {    int x, y;};
struct [[=derive]] Person {    [[=serde::rename("first name")]] std::string first;    [[=serde::rename("last name")]] std::string last;};
int main() {    // prints {"x":1,"y":2}    std::cout << boost::json::value_from(Point{.x=1, .y=2}) << '\n';    // prints {"first name":"Peter","last name":"Dimov"}    std::cout << boost::json::value_from(Person{.first="Peter", .last="Dimov"}) << '\n';}

整段代碼只有 21 行，如果我保持與之前相同的模板形式，那么基本通過(guò)?derive?可以實(shí)現(xiàn)：

namespace serde {    inline constexpr struct{} Serialize{};    struct rename { char const* field; };}
namespace boost::json {    template <class T>        requires (has_annotation(^^T, derive))    void tag_invoke(value_from_tag const&, value& v, T const& t) {        auto& obj = v.emplace_object();        [:expand(nonstatic_data_members_of(^^T)):] >> [&]<auto M>{            constexpr auto field = annotation_of(M)                .transform([](serde::rename r){                    return std::string_view(r.field);                })                .value_or(identifier_of(M));
            obj[field] = boost::json::value_from(t.[:M:]);        };    }}

這段代碼應(yīng)該看起來(lái)很熟悉，因?yàn)樗旧弦彩窃谧龈袷交ぷ?，只不過(guò)這里我們是將成員添加到一個(gè) JSON 對(duì)象中，而不是打印一堆鍵值對(duì)。然后，我們沒有自動(dòng)使用非靜態(tài)數(shù)據(jù)成員的標(biāo)識(shí)符，而是先嘗試檢查是否有 rename 注解。annotation_of()?為我們提供了一個(gè) optional，因此我們要么獲取 rename 注解的字段名（及其底層字符串），要么回退到 identifier_of(M)。

在這里添加 skip_serializing_if 的支持并不需要太多額外的工作，這也很好地展示了 C++ 和 Rust 處理方式之間的區(qū)別。在 Rust 中，你提供一個(gè)字符串，它會(huì)被注入并在內(nèi)部調(diào)用；而在 C++ 中，我們通常會(huì)直接提供一個(gè)可調(diào)用對(duì)象。

起初我以為這是因?yàn)?Rust 的屬性語(yǔ)法不支持在這里使用可調(diào)用對(duì)象，但實(shí)際上似乎是因?yàn)?serde 在支持這一點(diǎn)之前就已經(jīng)存在了。

我們需要為此添加一個(gè)新的注解類型：

namespace serde {      inline constexpr struct{} Serialize{};      struct rename { char const* field; };      template <class F> struct skip_serializing_if { F pred; };  }

然后稍微麻煩一點(diǎn)的部分是對(duì)它的解析，我們需要提取出某個(gè)?serde::skip_serializing_if?的特化類型注解。如果找到了，就嘗試調(diào)用其 pred 成員函數(shù)，若該函數(shù)返回 true，就跳過(guò)該字段的序列化。

搜索過(guò)程如下所示（注意，我們需要使用 constexpr，因?yàn)樾枰唇铀赃M(jìn)行調(diào)用）。我確信這個(gè)部分可以通過(guò)更好的庫(kù) API 稍作清理（至少可以用一個(gè) std::optional 來(lái)改進(jìn)）：

constexpr auto skip_if = []() -> std::meta::info {    auto res = std::meta::info();    for (auto A : annotations_of(M)) {        auto type = type_of(A);        if (has_template_arguments(type)            and template_of(type) == ^^serde::skip_serializing_if) {            // found a specialization            // but check to make sure we haven't found two            // different ones.            if (res != std::meta::info() and res != value_of(A)) {                throw "unexpected duplicate";            }
            res = value_of(A);        }    }
    return res;}();

然后，如果我們有這樣的注解，就調(diào)用它來(lái)確定是否需要跳過(guò)這個(gè)成員。這里需要用?if constexpr?語(yǔ)句，因?yàn)槿绻?skip_if?是空反射，我們無(wú)法對(duì)其進(jìn)行拼接。除此之外，整體邏輯非常簡(jiǎn)單：如果有這樣的注解，就調(diào)用它，如果返回?false，則跳過(guò)這個(gè)成員：

if constexpr (skip_if != std::meta::info()) {    if (std::invoke([:skip_if:].pred, t.[:M:])) {        return;    }}

現(xiàn)在這段代碼已經(jīng)膨脹到了 51 行（新增部分為第 7 行、第 22-46 行）：

template <auto V> struct Derive { };template <auto V> inline constexpr Derive derive;
namespace serde {    inline constexpr struct{} Serialize{};    struct rename { char const* field; };    template <class F> struct skip_serializing_if { F pred; };}
namespace boost::json {    template <class T>        requires (has_annotation(^^T, derive))    void tag_invoke(value_from_tag const&, value& v, T const& t) {        auto& obj = v.emplace_object();        [:expand(nonstatic_data_members_of(^^T)):] >> [&]<auto M>{            constexpr auto field = annotation_of(M)                .transform([](serde::rename r){                    return std::string_view(r.field);                })                .value_or(identifier_of(M));
            constexpr auto skip_if = []() -> std::meta::info {                auto res = std::meta::info();                for (auto A : annotations_of(M)) {                    auto type = type_of(A);                    if (has_template_arguments(type)                        and template_of(type) == ^^serde::skip_serializing_if) {                        // found a specialization                        // but check to make sure we haven't found                        // two different ones.                        if (res != std::meta::info() and res != value_of(A)) {                            throw "unexpected duplicate";                        }
                        res = value_of(A);                    }                }
                return res;            }();
            if constexpr (skip_if != std::meta::info()) {                if (std::invoke([:skip_if:].pred, t.[:M:])) {                    return;                }            }
            obj[field] = boost::json::value_from(t.[:M:]);        };    }}

此時(shí)，我想到了解決此問題的另一種有趣方法。只有兩個(gè)屬性的時(shí)候這樣做可能沒有必要，但如果我打算實(shí)現(xiàn) serde 的全部功能，有一個(gè)不單獨(dú)處理每個(gè)屬性解析的策略可能會(huì)更加合理。那么，如果我們將所有屬性收集到一個(gè)類類型中，再使用這個(gè)類類型會(huì)怎樣呢？

讓我們看看這會(huì)是什么樣子。

首先，我們創(chuàng)建一個(gè)新的類類型——attributes。我們將編程定義它，給它一個(gè)每個(gè)屬性都對(duì)應(yīng)的成員，此時(shí)難點(diǎn)在于成員的類型。對(duì)于像 serde::rename 這樣的屬性，我們應(yīng)該使用 optional。但對(duì)于 skip_serializing_if 呢？我們還不知道該使用什么類型，所以這里先用?optional 來(lái)進(jìn)行類型擦除。也就是說(shuō)，我們希望生成這樣的類型：

struct attributes {    optional rename;    optional skip_serializing_if;};

這段代碼使用了?std::meta::define_class()，這是 P2996 中唯一一個(gè)用于代碼生成的 API。它功能不多，但對(duì)當(dāng)前需求來(lái)說(shuō)足夠用了。注意，由于我們遍歷了命名空間?serde?中的所有成員，需要確保排除?attributes——它當(dāng)然也在這個(gè)命名空間中：

struct attributes;consteval {    std::vector<std::meta::info> specs;    for (auto m : members_of(^^serde)) {        if (m == ^^attributes or not has_identifier(m)) {            continue;        }
        auto underlying = is_type(m) ? m : ^^std::meta::info;        specs.push_back(data_member_spec(            substitute(^^std::optional, {underlying}),            {.name=identifier_of(m)}));    }
    define_class(^^attributes, specs);};

然后我們可以編寫一個(gè)解析函數(shù)，將非靜態(tài)數(shù)據(jù)成員的屬性寫入 attributes 實(shí)例中。這里最麻煩的部分就是找到寫入 attributes 哪個(gè)非靜態(tài)數(shù)據(jù)成員。我們暫時(shí)跳過(guò)這部分邏輯，直接進(jìn)入如何利用這些工作成果：

namespace boost::json {    template <class T>        requires (has_annotation(^^T, derive))    void tag_invoke(value_from_tag const&, value& v, T const& t) {        auto& obj = v.emplace_object();        [:expand(nonstatic_data_members_of(^^T)):] >> [&]{            constexpr auto attrs = serde::parse_attrs_from();
            constexpr auto field = attrs.rename                .transform([](serde::rename r){                    return std::string_view(r.field);                })                .value_or(identifier_of(M));
            if constexpr (attrs.skip_serializing_if) {                if (std::invoke(                    [:*attrs.skip_serializing_if:].pred,                    t.[:M:]))                {                    return;                }            }
            obj[field] = boost::json::value_from(t.[:M:]);        };    }}

當(dāng)然，我們將最復(fù)雜的邏輯（解析注解）移到了一個(gè)函數(shù)中，而這個(gè)函數(shù)我沒有包含在上面的代碼塊中。如我所說(shuō)，對(duì)于只有兩個(gè)屬性的情況，這樣做可能有點(diǎn)大材小用。不過(guò)，這種方法意味著添加一個(gè)新屬性只需在命名空間 serde 中聲明一個(gè)新類或類模板，然后在實(shí)現(xiàn)中使用它即可。

3、Rust 屬性 vs. C++ 注解

在對(duì)比 C++ 和 Rust 中的 serde 解決方案時(shí)，有兩個(gè)方面引起了我的注意：語(yǔ)法和庫(kù)的設(shè)計(jì)。

語(yǔ)法

首先從語(yǔ)法差異來(lái)看，使用時(shí)的體驗(yàn)是我最先關(guān)注的點(diǎn)。以下是我在 Rust 中的聲明：

#[derive(Serialize)]struct Person {    #[serde(rename = "first name")]    first: String,
    #[serde(rename = "middle name", skip_serializing_if = "String::is_empty")]    middle: String,
    #[serde(rename = "last name")]    last: String,}

而這是我在 C++ 中的聲明：

struct [[=derive]] Person {    [[=serde::rename("first name")]]    std::string first;
    [[=serde::rename("middle name")]]    [[=serde::skip_serializing_if(&std::string::empty)]]    std::string middle = "";
    [[=serde::rename("last name")]]    std::string last;};

可以看到，C++ 的注解語(yǔ)法顯得更為復(fù)雜和冗長(zhǎng)，而這大多是由于語(yǔ)法本身的問題。相較之下 Rust 的注解較為簡(jiǎn)潔，因?yàn)樗鼈冏裱煌谡Z(yǔ)言其余部分的語(yǔ)法規(guī)則?—— 比如 serde(rename = "first name")?在 Rust 中是無(wú)效的，這里也沒有調(diào)用名為 serde 的函數(shù)。

這種差異帶來(lái)的好處是，Rust 中的注解使用起來(lái)更加清晰自然，因?yàn)樗娴木拖袷墙o選項(xiàng)賦值一樣。例如，類似于 serde(rename = "first name") 這樣的用法更像是傳遞配置參數(shù)，而不是在調(diào)用函數(shù)。這為使用者提供了靈活性，比如可以像這樣使用屬性：#[arg(short)]?或 #[arg(short = 'k')]，前者使用了默認(rèn)值，而后者顯式指定了 'k'。

看到這里，你可能會(huì)有一種沖動(dòng)，想要重用（非常特殊且具體的）屬性語(yǔ)法，并允許在 C++ 中使用 using 關(guān)鍵字。但實(shí)際上，這樣做并不會(huì)節(jié)省太多的輸入：

struct [[=derive]] Person {    // old version: 83 chars    [[=serde::rename("middle name"), =serde::skip_serializing_if(&std::string::empty)]]    std::string middle = "";
    // new version: 82 chars    [[using serde: =rename("middle name"), =skip_serializing_if(&std::string::empty)]]    std::string middle = "";};

相比之下，Rust 版本只有 74 個(gè)字符。雖然長(zhǎng)度上的差異并不大，但至少它少于 80 個(gè)。

另一方面，要關(guān)注 Rust 為實(shí)現(xiàn)這一點(diǎn)付出了什么代價(jià)。在 C++ 注解設(shè)計(jì)中，注解本質(zhì)上就是值。你需要學(xué)習(xí)的新語(yǔ)法很少，還可以很清楚地看到這里發(fā)生了什么。注解的內(nèi)容并不是由庫(kù)定義含義的咒語(yǔ)，而是實(shí)際的 C++ 值。如果你不知道 serde::skip_serializing_if 是什么意思，可以直接查看它的定義。

你可能會(huì)注意到，在討論這些示例實(shí)現(xiàn)時(shí)，我沒有提到如何從注解中解析出值——這是因?yàn)閷?shí)際上我不需要做任何解析，編譯器為我完成了這項(xiàng)工作！我唯一需要做的，就是從注解列表中提取我關(guān)心的注解，這并不涉及實(shí)際的解析過(guò)程。而 Rust 庫(kù)則必須真正解析這些 Token 流，對(duì)于 serde 來(lái)說(shuō)，這意味著接近 2000 行代碼。

另一個(gè)有趣的事情是，盡管?Rust 和 C++?最終以不同的方式實(shí)現(xiàn)了相似的功能，但它們并不完全相同。在 Rust 中，#[derive(Debug)] 會(huì)為類型注入適當(dāng)?shù)?impl Debug。而在 C++ 的注解方法中，我們并沒有注入適當(dāng)?shù)?formatter 特化，只是添加了一個(gè)全局約束的版本。

這意味著，如果不做進(jìn)一步處理，僅僅做一個(gè)小小的改動(dòng)就可能導(dǎo)致歧義：

struct [[=derive]] Point {    int x;    int y;
    // let's just make this a range for seemingly no reason    auto begin() -> int*;    auto end() -> int*;};
int main() {    auto p = Point{.x=1, .y=2};    std::println("p={}", p); // error: ambiguous}

嗯，我需要做兩個(gè)小小的改動(dòng)。我原本的特化定義如下：

template <class T> requires (has_annotation(^^T, derive))struct std::formatter { /* ... */ };

但如果我將其改為：

template <class T, class Char> requires (has_annotation(^^T, derive))struct std::formatter { /* ... */ };

那么它就可能與 C++23 新增的用于范圍的 std::formatter 特化產(chǎn)生歧義。為了解決這個(gè)問題，可以禁用一個(gè)額外的變量模板（在鏈接中會(huì)被預(yù)處理掉）：

template <class T> requires (has_annotation(^^T, derive))inline constexpr auto std::format_kind = std::range_format::disabled;

這似乎有點(diǎn)令人意外——因?yàn)閺母拍钌现v，C++ 的方法與 Rust 的方法是相同的，添加注解會(huì)注入一個(gè)非常特定且明確的特化，這不可能與其他內(nèi)容產(chǎn)生歧義——但事實(shí)并非如此。因此，這種部分特化的歧義肯定會(huì)成為一個(gè)問題。或許在未來(lái)，我們可以想出一種方法，使諸如 [[=derive]] 這樣的注解能夠真正注入一個(gè)特化來(lái)避免這個(gè)問題。

庫(kù)設(shè)計(jì)

在 Rust 的 serde 庫(kù)中，序列化是一個(gè)兩階段的過(guò)程。首先，類型作者選擇參與序列化，這會(huì)生成一個(gè)類似于該類型即時(shí)表示的實(shí)現(xiàn)。然后，不同協(xié)議的作者可以有效地實(shí)現(xiàn)不同的后端。

例如在 Person 類型的 serde 實(shí)現(xiàn)中，Rust 會(huì)生成一個(gè) Serialize 實(shí)現(xiàn)，該實(shí)現(xiàn)接受滿足 serde::Serializer 的任意類型。然后我們對(duì)這個(gè) serializer 進(jìn)行一系列的序列化調(diào)用，這些調(diào)用會(huì)根據(jù)協(xié)議需求（比如 JSON、CBOR、YAML、TOML 等）執(zhí)行相應(yīng)的操作。

如果我們將這種實(shí)現(xiàn)方式轉(zhuǎn)換為 C++，看起來(lái)可能會(huì)像這樣（為避免陷入不相關(guān)的錯(cuò)誤處理細(xì)節(jié)，這里假設(shè)這些函數(shù)在出現(xiàn)錯(cuò)誤時(shí)拋出異常，而不是像 Rust 中那樣返回 Result）：

template auto serialize(Person const& p, S& serializer) -> void {    auto state = serializer.serialize_struct(        "Person",        2 + (p.middle.empty() ? 0 : 1));    state.serialize_field("first name", p.first);    if (not p.middle.empty()) {        state.serialize_field("middle name", p.middle);    } else {        state.skip_field("middle name", p.middle);    }    state.serialize_field("last name", p.last);    state.end();}

這種設(shè)計(jì)允許解耦，非常不錯(cuò)。然而你可能注意到了，我之前展示的 C++ 實(shí)現(xiàn)根本沒有這樣做。并不是因?yàn)槲覒?，而是因?yàn)樵谟凶允。╥ntrospection）的情況下，這樣的操作完全沒有必要。在 C++ 中，我們不需要生成這種中間表示，Boost.JSON 實(shí)現(xiàn)可直接從數(shù)據(jù)成員完成所有的序列化工作。

這不僅僅是代碼量減少的問題，更重要的是根本不需要處理額外的抽象層。這個(gè)抽象層雖然不會(huì)消耗太多計(jì)算資源，也很容易被編譯優(yōu)化掉，但它本身就是不必要的。

接下來(lái)再考慮 skip_field 調(diào)用。對(duì)于很多序列化目標(biāo)（例如 JSON），跳過(guò)某個(gè)字段的方法就是簡(jiǎn)單地不對(duì)其進(jìn)行序列化。這也是為什么 skip_field 的默認(rèn)實(shí)現(xiàn)什么都不做，serde_json 也沒有覆蓋這個(gè)函數(shù)。同樣，考慮上面提到的字段數(shù)量計(jì)算。JSON 序列化器也不需要這樣的值，因此它會(huì)忽略這個(gè)字段類型名稱的值。

但在創(chuàng)建中間表示時(shí)，你需要?jiǎng)?chuàng)建一個(gè)足夠豐富的表示來(lái)處理所有可能的序列化/反序列化目標(biāo)。某些序列化目標(biāo)可能需要預(yù)先知道字段數(shù)量，或者需要為跳過(guò)的字段預(yù)留位置。因此，serde 必須為此提供支持。

而在 C++ 中，我們根本不需要這樣做。對(duì)于任何給定的目標(biāo)，序列化器可以直接執(zhí)行它所需的所有操作，因?yàn)樗梢灾苯釉L問所有信息，不需要額外的抽象層。因此，C++ 版本的 serde 庫(kù)可能只需要一系列可作為注解的類型、parse_attrs_from() 函數(shù)，以及幾個(gè)小的輔助函數(shù)即可。

4、這并不是終點(diǎn)

最后，我想指出幾種不同語(yǔ)言中的一些相關(guān)特性來(lái)結(jié)束這篇文章：

• Rust 的過(guò)程宏（procedural macros）

• Python 的裝飾器（decorators）

• Herb Sutter 的元類（metaclasses）提案

它們都有一個(gè)共同點(diǎn)：編寫代碼，然后將代碼傳遞給一個(gè)函數(shù)，以生成新的代碼。元類和裝飾器實(shí)際上會(huì)替換原始代碼，而 derive 宏只會(huì)注入新代碼（盡管其他過(guò)程宏也可以替換代碼）。

注解提案在大體上看起來(lái)與這些特性類似，但它是一個(gè)完全不同的機(jī)制，不應(yīng)與它們混淆：注解并不會(huì)注入代碼，它只是增強(qiáng)了類型的自省能力。但這并不是說(shuō)注解沒用！正如我所展示的那樣，注解有望成為一個(gè)非常有用的工具，可以編寫出以前在 C++ 中無(wú)法想象的用戶友好型庫(kù) API。

但這僅僅是一個(gè)開始。

本文轉(zhuǎn)自公眾號(hào)“CSDN”，ID：CSDNnews

本文經(jīng)授權(quán)轉(zhuǎn)自公眾號(hào)CSDN（ID：CSDNnews）

作者 | Barry Revzin，C++ 標(biāo)準(zhǔn)委員會(huì)成員，翻譯?| 鄭麗媛

——
EOF
——
你好，我是飛宇。日常分享C/C++、計(jì)算機(jī)學(xué)習(xí)經(jīng)驗(yàn)、工作體會(huì)，歡迎點(diǎn)擊此處查看我以前的學(xué)習(xí)筆記&經(jīng)驗(yàn)&分享的資源。
我組建了一些社群一起交流，群里有大牛也有小白，如果你有意可以一起進(jìn)群交流。
歡迎你添加我的微信，我拉你進(jìn)技術(shù)交流群。此外，我也會(huì)經(jīng)常在微信上分享一些計(jì)算機(jī)學(xué)習(xí)經(jīng)驗(yàn)以及工作體驗(yàn)，還有一些內(nèi)推機(jī)會(huì)。
加個(gè)微信，打開另一扇窗
經(jīng)常遇到有讀者后臺(tái)私信想要一些編程學(xué)習(xí)資源，這里分享 1T 的編程電子書、C/C++開發(fā)手冊(cè)、Github上182K+的架構(gòu)路線圖、LeetCode算法刷題筆記等精品學(xué)習(xí)資料，點(diǎn)擊下方公眾號(hào)會(huì)回復(fù)"編程"即可免費(fèi)領(lǐng)取~
感謝你的分享，點(diǎn)贊，在看三連??