C++打印類型名稱的分析與實現(xiàn)

3?Demanged Name

Returns an implementation defined null-terminated character string containing the name of the type. No guarantees are given; in particular, the returned string can be identical for several types and change between invocations of the same program.

但幸好，它們內(nèi)部提供的有Demangle API，通過相關(guān)API就可以將類型名稱轉(zhuǎn)換為可讀的名稱。這個API定義如下：

namespace?abi?{ ??extern?"C"?char*?__cxa_demangle?(const?char*?mangled_name, ???????????????????char*?buf, ???????????????????size_t*?n, ???????????????????int*?status); }

這里主要關(guān)注第一個參數(shù)就可以，其他參數(shù)都可以置空。第一個參數(shù)就是type_info::name()返回的Mangled Name，返回值為Demangled Name。

::type; ????//?1.?通過typeid獲得類型名稱 ????const?char*?name?=?typeid(type).name(); ????std::string?result; ????//?2.?通過gcc/clang擴展API獲得Demangled?Name #ifndef?_MSC_VER ????char*?demangled_name?=?abi::__cxa_demangle(name,?nullptr,?nullptr,?nullptr); ????result?+=?demangled_name; ????free(demangled_name); #else ????result?+=?name; #endif?//?_MSC_VER ????//?3.?添加丟棄的修飾 ????if?(std::is_const::value)?????????result?+=?"?const"; ????if?(std::is_volatile::value)??????result?+=?"?volatile"; ????if?(std::is_lvalue_reference::value)?result?+=?"&"; ????if?(std::is_rvalue_reference::value)?result?+=?"&&"; ????return?result; } struct?Base?{}; struct?Derived?:?Base?{}; int?main()?{ ????std::cout?<const?int&>()?<" "; ????std::cout?<()?<" "; ????std::cout?<()?<" "; }實現(xiàn)分為三個步驟，注釋已經(jīng)寫得很清晰了，這里補充幾個重點。第一，Demangled API的返回值是采用malloc()分配的內(nèi)存，需要手動進行釋放。第二，type_info::name()會丟棄cv及引用修飾符，所以還需要手動添加這些修飾。最終輸出如下圖所示。 這種實現(xiàn)方式來自https://stackoverflow.com/a/20170989。優(yōu)點在于，可以統(tǒng)一格式，輸出清晰。缺點在于，實現(xiàn)稍微麻煩，要考慮更多情況，且發(fā)生于運行期。

4?編譯器擴展特性

編譯器還存在另一種擴展，包含有類型信息。大家也許用過__func__，這是每個函數(shù)內(nèi)部都會預(yù)定義的一個標識符，表示當前函數(shù)的名稱。于C99添加到C標準，C++11添加到了C++標準，定義如下。

static?const?char?__func__[]?=?"function-name";C++引入的這個說是"implementation-defined string"，意思也是基于實現(xiàn)的，不過在三個平臺上的輸出基本是一致的。這個標識符只包含函數(shù)名稱，并不會附帶模板參數(shù)信息。但是與其相關(guān)的擴展附帶有這部分信息，gcc/clang的擴展為__PRETTY_FUNCTION__，msvc的擴展為__FUNCSIG__。 它們的內(nèi)容形式也是基于實現(xiàn)的，一個簡單的例子如下。

template?<typename?T> consteval?auto?type_name()?{ #ifdef?_MSC_VER ????return?__FUNCSIG__; #elif?defined(__GNUC__) ????return?__PRETTY_FUNCTION__; #elif?defined(__clang__) ????return?__PRETTY_FUNCTION__; #endif } int?main()?{ ????std::cout?<int>(); }輸出分別為：

//?gcc consteval?auto?type_name()?[with?T?=?int] //?clang auto?type_name()?[T?=?int] //?msvc auto?__cdecl?type_name<int>(void)gcc的這種格式不錯，clang丟棄了consteval，msvc同樣如此，但它加上了函數(shù)調(diào)用約定。 現(xiàn)在需要做的，就是根據(jù)這些信息，解析出想要的信息?？梢越柚鶦++17 std::string_view在編譯期完成這個工作。具體實現(xiàn)如下。

template?<typename?T> consteval?auto?type_name()?{ ????std::string_view?name,?prefix,?suffix; #ifdef?__clang__ ????name?=?__PRETTY_FUNCTION__; ????prefix?=?"auto?type_name()?[T?=?"; ????suffix?=?"]"; #elif?defined(__GNUC__) ????name?=?__PRETTY_FUNCTION__; ????prefix?=?"consteval?auto?type_name()?[with?T?=?"; ????suffix?=?"]"; #elif?defined(_MSC_VER) ????name?=?__FUNCSIG__; ????prefix?=?"auto?__cdecl?type_name<"; ????suffix?=?">(void)"; #endif ????name.remove_prefix(prefix.size()); ????name.remove_suffix(suffix.size()); ????return?name; }通過使用std::string_view，以上代碼全都發(fā)生于編譯期。該代碼來自https://stackoverflow.com/a/56766138。這個實現(xiàn)方式要比Demanged Name好，不會丟失修飾，類型信息完善，且發(fā)生于編譯期。缺點也有，編譯器擴展一般都是基于實現(xiàn)的，沒有標準保證，內(nèi)容形式可能會改變，依賴于此的實現(xiàn)并不具備較強的穩(wěn)定性。

5?Circle

對比以上實現(xiàn)，可以發(fā)現(xiàn)，反而是第一種辦法，即主動觸發(fā)Name Lookup報錯這種方式最簡單，且最穩(wěn)定、最通用。其他方法都依賴了編譯器擴展特性，雖然可以達到目的，但技巧偏多，沒有保證。大家要是讀過之前更新的四章「C++反射」文章，就知道類型名稱其實是一個最基本的類型元信息，只要編譯器支持反射，那么實現(xiàn)這個需求是再簡單不過了。在此，我們就來看看Circle提供的強大元編程能力，是如何優(yōu)雅地實現(xiàn)這個功能的。注：Circle基本內(nèi)容，請看C++反射第三章。Circle對于該需求的實現(xiàn)如下：

template?<typename...?Ts> void?print_types()?{ ????printf("%d?-?%s ",?int...,?Ts.string)...; } print_types<int,?double,?const?char*,?int&&>(); //?output: //?0?-?int //?1?-?double //?2?-?const?char* //?3?-?int&&是不是太簡單了！而且還要強大許多，比如還可以去重、排序：

template?<typename...?Ts> void?f()?{ ????printf("unique: "); ????print_types(); ????printf("sort?by?type?name:? "); ????print_typesstring?string)...>(); } f<int,?double,?const?char*,?double,??int&&>(); //?output: //?unique: //?0?-?int //?1?-?double //?2?-?const?char* //?3?-?int&& //?sort?by?type?name:? //?0?-?const?char* //?1?-?double //?2?-?double //?3?-?int //?4?-?int&&這些操作只要加上@meta就全部可以發(fā)生于編譯期。 所以說，自己的實現(xiàn)是完全比不上這種編譯器自帶的類型元信息機制的，因為解決問題時不在一個層次。用戶自己實現(xiàn)的永遠處在應(yīng)用層，而編譯器則直接在原理層建設(shè)。

6?Static Reflection

本節(jié)再說說如何使用C++標準反射來實現(xiàn)該需求，就它目前的發(fā)展，還沒有Circle的反射強，不過標準反射的「源碼注入」能力很強。詳情請看C++反射第四章。通過標準元函數(shù)name_of()就可以獲取類型名稱，因此實現(xiàn)其實很簡單，代碼如下。

template?<typename?T> consteval?auto?type_name()?{ ????return?meta::name_of(reflexpr(T)); } int?main()?{ ????const?int?i?=?1; ????constexpr?auto?__dummy?=?__reflect_print(type_name<decltype(i)>()); }這里，將在編譯期輸出const int。雖然標準反射目前來說還是一個殘缺品，但實現(xiàn)這種需求也比自己實現(xiàn)起來要簡單太多了。

7?總結(jié)

本文不算太難，串著講了一些東西，主要是當時研究TAD時寫過相關(guān)工具，索性寫一篇完整的文章。很多時候，編譯器推導(dǎo)的類型并不和預(yù)期一致，使用本文介紹的工具可以很方便地研究編譯器的這些行為。這里還串起了重載決議和反射的相關(guān)內(nèi)容，也算是幫大家回顧一下。

?

　　審核編輯：湯梓紅