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

打印類型名稱，聽起來像是一個很簡單的需求，但在目前的C++當中，并非易事。

本文介紹了一些對此需求的分析與實現(xiàn)。

1?概述

類型屬于type，對象屬于value，前者是編譯期的東西，后者則是運行期的東西。你可以打印一個變量的值，卻無法打印一個類型的名稱。那么如何才能實現(xiàn)這個需求？通常來說，解決問題的思路是將新問題轉換為已經(jīng)存在解決方案的舊問題。其一，編譯期目前只能輸出錯誤信息，這個錯誤信息也可以是一種打印類型名稱的方法。我們需要做的，就是主動觸發(fā)報錯，可以利用重載決議的相關知識達到這個目的。其二，既然無法直接打印類型，那么就將類型轉換為value，從而在運行期進行打印。但是，通過表格暴力轉換法其實并不可行，因為類型組合起來實在太多了。此時可以借助一些語言或編譯器特性來獲取到類型信息，比如通過typid就可以根據(jù)類型得到一個簡單的名稱。思路確定了，接著就可以順著這個思路設計實現(xiàn)，以下各節(jié)展示各種實作法。

2?編譯期打印類型名稱?

這種思路是利用錯誤信息輸出類型信息，如何觸發(fā)錯誤，如果大家已經(jīng)讀過【洞悉C++函數(shù)重載決議】，相信已經(jīng)有了深刻認識。

具體實現(xiàn)如下：

template?<typename...>?struct?type_name?{}; template?<typename...?Ts>?struct?name_of?{ ????using?X?=?typename?type_name::name; }; int?main()?{ ????name_of<int,?float,?const?char*>(); }由于Name Lookup查找的名稱name_of帶有模板，因此會進入重載決議的第二階段：Template Handling。模板參數(shù)已經(jīng)顯式指出，因此其實并不會進行TAD，而是直接模板參數(shù)替換。但是編譯器發(fā)現(xiàn)type_name::name并沒有name類型，因此模板替換失敗，產(chǎn)生hard error，編譯失敗。這個hard error錯誤信息，就帶有類型名稱，輸出如下：

error:?no?type?named?'name'?in?'struct?type_name' ????7?|?????using?X?=?typename?type_name::name;現(xiàn)在，就可以使用該實現(xiàn)在編譯期查看實際類型的名稱，比如：

template?<typename?T> void?f(T?t)?{ ????name_of<decltype(t)>(); } int?main()?{ ????const?int?i?=?1; ????f(i); }輸出為：

error:?no?type?named?'name'?in?'struct?type_name'?? ????7?|?????using?X?=?typename?type_name::name;??可以看到，TAD在推導參數(shù)時丟棄了top-level const修飾，t實際類型為int。這種形式的優(yōu)點是完全發(fā)生于編譯期，實現(xiàn)簡單；缺點也很明顯，無法指定輸出形式，看起來不夠直觀。

3?Demanged Name

另一種方式是借助typeid關鍵字，通過它可以獲得一個std::type_info對象，其結構如下。

namespace?std?{ ????class?type_info?{ ????public: ????????virtual?~type_info(); ????????bool?operator==(const?type_info&?rhs)?const?noexcept; ????????bool?before(const?type_info&?rhs)?const?noexcept; ????????size_t?hash_code()?const?noexcept; ????????const?char*?name()?const?noexcept; ????????type_info(const?type_info&)?=?delete;?//?cannot?be?copied ????????type_info&?operator=(const?type_info&)?=?delete;?//?cannot?be?copied ????}; }其中的成員函數(shù)name()就可以返回類型的名稱，這樣就根據(jù)type獲取到了value。但是標準說這個名稱是基于實現(xiàn)的。

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.

事實上也的確如此，MSVC返回的是一段可讀的類型名稱，而gcc, clang返回的是Mangled Name。（Name Mangling內容可以參考【洞悉C++函數(shù)重載決議】）

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

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

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

因此，現(xiàn)在就可以分而論之，msvc直接使用type_info::name()返回的類型名稱就可以；對于gcc/clang，則先使用Demangle API進行解析，次再使用。具體實現(xiàn)如下：

#include? #include? #include? #include? #ifndef?_MSC_VER ????#include? #endif?//?_MSC_VER template?<typename?T> std::string?type_name()?{ ????using?type?=?typename?std::remove_reference::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()分配的內存，需要手動進行釋放。第二，type_info::name()會丟棄cv及引用修飾符，所以還需要手動添加這些修飾。最終輸出如下圖所示。

這種實現(xiàn)方式來自https://stackoverflow.com/a/20170989。優(yōu)點在于，可以統(tǒng)一格式，輸出清晰。缺點在于，實現(xiàn)稍微麻煩，要考慮更多情況，且發(fā)生于運行期。

4?編譯器擴展特性

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

static?const?char?__func__[]?=?"function-name";C++引入的這個說是"implementation-defined string"，意思也是基于實現(xiàn)的，不過在三個平臺上的輸出基本是一致的。這個標識符只包含函數(shù)名稱，并不會附帶模板參數(shù)信息。但是與其相關的擴展附帶有這部分信息，gcc/clang的擴展為__PRETTY_FUNCTION__，msvc的擴展為__FUNCSIG__。它們的內容形式也是基于實現(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ù)調用約定。現(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)的，沒有標準保證，內容形式可能會改變，依賴于此的實現(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基本內容，請看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)的永遠處在應用層，而編譯器則直接在原理層建設。

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)起來要簡單太多了。