🕖 🙆🏼 🤞🏻 C ++ 14のリフレクション 🚵🏼 ♨️ 🤾🏼

この記事は、Anton antoshkka Polukhinのレポート（「C ++ 14のちょっとした魔法」）の写しです（若干の修正を加えています）。

私は最近C ++をいじくりまわし、C ++ 14でのリフレクションを可能にするいくつかの新しいメタプログラミング手法を偶然発見しました。いくつかの動機付けの例。ここには、ある種のPOD構造とその中のいくつかのフィールドがあります。

struct complicated_struct { int i; short s; double d; unsigned u; };

フィールドの数とその名前は重要ではありません。重要なことは、この構造を使用して次のコードを記述できることです。

 #include <iostream> #include "magic_get.hpp" struct complicated_struct { /* … */ }; int main() { using namespace pod_ops; complicated_struct s {1, 2, 3.0, 4}; std::cout << "s == " << s << std::endl; // Compile time error? }

メイン関数では、構造体の変数を作成し、何らかの方法で集約の初期化を介して初期化し、この変数をstd :: coutで表示しようとします。そして現時点では、理論上、コンパイルエラーが発生するはずです。構造のストリームに出力演算子を定義しなかったため、コンパイラはこれらすべてをコンパイルして出力する方法を知りません。ただし、構造の内容をコンパイルして表示します。

 antoshkka@home:~$ ./test s == {1, 2, 3.0, 4}

コードに戻り、フィールドの名前を変更し、構造体の名前を変更し、変数の名前を変更するなど、何でもできます。コードは引き続き機能し、構造体の内容を正しく表示します。仕組みを見てみましょう。

この演算子は、ヘッダーファイルmagicget.hppで説明されており、どのデータ型でも機能します。

 template <class Char, class Traits, class T> std::basic_ostream<Char, Traits>& operator<<(std::basic_ostream<Char, Traits>& out, const T& value) { flat_write(out, value); return out; }

このステートメントは、flat_writeメソッドを呼び出します。 flat_writeメソッドは中括弧を表示し、中央にダッシュ文字列を含みます：

 template <class Char, class Traits, class T> void flat_write(std::basic_ostream<Char, Traits>& out, const T& val) { out << '{'; detail::flat_print_impl<0, flat_tuple_size<T>::value >::print(out, val); out << '}'; }

文字列行の中央には、flat_tuple_size <T> ::値があります。ここで、標準ライブラリにはstd :: tuple_size <std :: tuple>があり、タプル内の要素数が導入されることに注意する必要があります。ただし、ここでTはタプルではなく、std :: tupleではなく、ユーザータイプです。ここで、flat_tuple_sizeはユーザータイプのフィールド数を出力します。

print関数の機能をさらに見てみましょう。

 template <std::size_t FieldIndex, std::size_t FieldsCount> struct flat_print_impl { template <class Stream, class T> static void print (Stream& out, const T& value) { if (!!FieldIndex) out << ", "; out << flat_get<FieldIndex>(value); // std::get<FieldIndex>(value) flat_print_impl<FieldIndex + 1, FieldsCount>::print(out, value); } };

print関数は、作業しているフィールドのインデックスに応じてコンマを表示するか表示しません。その後、flat_get関数を呼び出して、std :: getのように機能することをコメントします。つまり、インデックスから構造体からフィールドを返します。自然な疑問が生じます：それはどのように機能しますか？

次のように機能します。ストリーム内の出力演算子は、構造内のフィールド数を決定し、インデックスを介してフィールドを反復処理し、インデックスごとに各フィールドを表示します。したがって、記事の冒頭で見たことがわかります。

カスタム構造で動作するflat_getおよびflat_tuple_sizeメソッドを作成し、構造内のフィールド数を決定し、この構造をフィールドごとに表示する方法をさらに見てみましょう。

 /// Returns const reference to a field with index `I` /// Example usage: flat_get<0>(my_structure()); template <std::size_t I, class T> decltype(auto) flat_get(const T& val) noexcept; /// `flat_tuple_size` has a member `value` that constins fields count /// Example usage: std::array<int, flat_tuple_size<my_structure>::value > a; template <class T> using flat_tuple_size;

簡単なものから始めましょう。構造内のフィールドの数をカウントします。 POD構造Tがあります。

 static_assert(std::is_pod<T>::value, "")

この構造に対して、式を書くことができます：

 T { args... }

これは集約構造の初期化です。引数の数が構造内のフィールドの数以下であり、引数の各タイプが構造内のフィールドのタイプに対応する場合、この式は正常にコンパイルされます。

このアブラカダブラから、構造T内のフィールドの数を取得しようとします。これをどのように行うのでしょうか。構造Tを取得し、膨大な数の引数で初期化しようとします。これはコンパイルされません。引数の1つを拒否して、再試行します。これもコンパイルされませんが、いつかは構造内のフィールドの数に等しい引数の数に到達し、それが組み立てられます。この時点で、引数の数を覚えておくだけで、準備は完了です。構造内にフィールドの数があります。これは基本的な考え方です。詳細に行きましょう。

T構造にcharまたはunsigned charのみ、およびその他のタイプのサイズ1バイトが含まれている場合、最初から何個の引数が必要ですか？この場合、構造T内のフィールドの数は、この構造のサイズに等しくなります。他のフィールド、たとえばintやポインターがある場合、フィールドの数は構造体のサイズよりも少なくなります。

集計の初期化を開始するフィールドの数を取得しました。つまり、sizeof（T）に等しい引数の数で構造Tを初期化します。コンパイルに失敗した場合は、引数を1つ戻してコンパイルし直し、構造内のフィールドの数を見つけました。 1つの問題が残っています。構造内の引数の数を推測しても、コードはコンパイルされません。フィールドのタイプを正確に知る必要があるからです。

回避策を実行しましょう。任意の型への暗黙的な型変換の演算子を使用して構造体を作成します。

 struct ubiq { template <class Type> constexpr operator Type&() const; }; int i = ubiq{}; double d = ubiq{}; char c = ubiq{};

つまり、この構造体の変数は、int、double、std :: string、std :: vector、任意のカスタム型など、あらゆる型にキャストされます。

全体のレシピ：T構造を取得し、sizeof（T）に等しい引数の数でこの構造の初期化を集約します。各引数は、ubiq構造のインスタンスです。集約の初期化段階で、ubiqの各インスタンスはT構造内のフィールドタイプに変わり、引数の数のみを選択できます。多くの引数がコンパイルされていない場合、1つを破棄して再試行します。コンパイルされた場合、引数の数を考慮し、結果を得ました。

今、少しコード。 ubiq構造を少し変更します。可変長テンプレートでこの構造を使用しやすくするために、テンプレートパラメータを追加します。また、std :: make_index_sequence（std :: index_sequence-数字の長いチェーン）に展開されるC ++ 14のエンティティも必要です。

怖いコードを見る準備はできましたか？行こう

次の2つの機能のみ：

 // #1 template <class T, std::size_t I0, std::size_t... I> constexpr auto detect_fields_count(std::size_t& out, std::index_sequence<I0, I...>) -> decltype( T{ ubiq_constructor<I0>{}, ubiq_constructor<I>{}... } ) { out = sizeof...(I) + 1; /*...*/ } // #2 template <class T, std::size_t... I> constexpr void detect_fields_count(std::size_t& out, std::index_sequence<I...>) { detect_fields_count<T>(out, std::make_index_sequence<sizeof...(I) - 1>{}); }

両方の関数は、detect_fields_countと呼ばれます。最初の機能はもう少し専門的です。したがって、コンパイラがdetect_fields_count <T>を検出すると、最初の関数はより特殊化されており、使用を試みる必要があると考えられます。

この関数には末尾の戻り値の型があります。つまり、この関数の型はTからのdecltypeです。

集約の初期化。引数の数で推測した場合、この式はコンパイルされ、この関数の本体に入り、出力変数に、持っている引数の数を書き込みます。うまくいかない場合（引数の数は推測しませんでした）、コンパイラーはこれがエラーではなく置換の失敗であると判断し、同じ名前で専門性の低い別の関数を見つける必要があります。彼は機能＃2を取ります。関数＃2は、インデックスの1つを破棄し（つまり、引数の数を1つ減らします）、detect_fields_countを再度呼び出します。繰り返しますが、最初の関数または2番目の関数が呼び出されます。したがって、引数を調べて、構造内のフィールドの数を見つけます。それは簡単な部分でした。

複雑な先：構造T内のフィールドの型を取得する方法？

集計の初期化を含むT式が既にあり、ubiqインスタンスを内部に渡します。各ubiqインスタンスに対して、暗黙の型変換演算子が呼び出され、この演算子内のフィールドの型がわかります。今必要なのは、何らかの方法でこの情報を取得し、外部構造に引き込み、T構造体の集約初期化を超えて作業できるようにすることです。残念ながら、C ++には、データ型を変数に書き込むメカニズムがありません。より正確には、std :: type_indexおよびstd :: type_infoがありますが、コンパイル段階では役に立ちません。後でタイプを元に戻しません。

どういうわけか、この制限を回避してみましょう。これを行うには、PODが何であるかを思い出してください（非常に大雑把に言うと、標準化委員会は3年ごとに定義を変更することを好みます）。

POD構造は、フィールドがpublic、private、またはprotectedのいずれかでマークされている構造です（パブリックフィールドにのみ関心があります）。そして、この構造内のすべてのフィールドは、他のPOD構造または基本タイプ（ポインター、int、std :: nullptr_t）のいずれかです。数分間、ポインターを忘れてしまい、32-x未満の基本型はほとんどないことがわかりました。これは、各基本型に特定の識別子（整数）を割り当てることができることを意味します。この数字を出力配列に記述し、この出力配列を演算子の暗黙的な変換を超えて引き出すと、数字が再び型に変換されます。これはとても簡単なアイデアです。

実装が完了しました。これを行うには、ubiq構造を変更します。

 template <std::size_t I> struct ubiq_val { std::size_t* ref_; template <class Type> constexpr operator Type() const noexcept { ref_[I] = typeid_conversions::type_to_id(identity<Type>{}); return Type{}; } };

現在、出力配列へのポインタがあり、この出力配列は恐ろしい名前ref_を持っていますが、それは起こりました。暗黙的な型変換演算子も変更されました：type_to_id関数を呼び出すようになりました。型を識別子に変換し、この識別子を出力配列ref_に書き込みます。 type_to_idメソッドの束を生成するために残っています。マクロを使用してこれを行います。

 #define BOOST_MAGIC_GET_REGISTER_TYPE(Type, Index) \ constexpr std::size_t type_to_id(identity<Type>) noexcept { \ return Index; \ } \ constexpr Type id_to_type( size_t_<Index > ) noexcept { \ Type res{}; \ return res; \ } \ /**/

マクロは、type_to_id関数を生成します。これにより、タイプが識別子になり、id_to_type関数も生成されます。これにより、識別子がタイプに戻ります。このマクロはユーザーには表示されません。使用するとすぐに、定義を解除します。基本タイプを登録します（すべてがここにリストされているわけではありません）：

 BOOST_MAGIC_GET_REGISTER_TYPE(unsigned char , 1) BOOST_MAGIC_GET_REGISTER_TYPE(unsigned short , 2) BOOST_MAGIC_GET_REGISTER_TYPE(unsigned int , 3) BOOST_MAGIC_GET_REGISTER_TYPE(unsigned long , 4) BOOST_MAGIC_GET_REGISTER_TYPE(unsigned long long , 5) BOOST_MAGIC_GET_REGISTER_TYPE(signed char , 6) BOOST_MAGIC_GET_REGISTER_TYPE(short , 7) BOOST_MAGIC_GET_REGISTER_TYPE(int , 8) BOOST_MAGIC_GET_REGISTER_TYPE(long , 9) BOOST_MAGIC_GET_REGISTER_TYPE(long long , 10) ...

つま先を使用しません。理由は後で説明します。すべての基本タイプを登録しました。ここで、型Tをこの型T内のフィールド識別子の配列に変換する関数を作成します。最も興味深いのは、この関数の本体です。

 template <class T, std::size_t N, std::size_t... I> constexpr auto type_to_array_of_type_ids(std::size_t* types) noexcept -> decltype(T{ ubiq_constructor<I>{}... }) { T tmp{ ubiq_val< I >{types}... }; return tmp; }

一時変数の初期化を集約し、そこにubiqインスタンスを渡します。今回は、出力配列へのポインターを保持します。ここで、typesはフィールド型の識別子を書き込む出力配列です。この行の後（一時変数を初期化した後）、types出力配列は各フィールドの型識別子を保存します。 type_to_array_of_type_ids関数はconstexprです。つまり、すべてがコンパイル段階で使用できます。美人！識別子を型に戻す必要があります。これは次のように行われます。

 template <class T, std::size_t... I> constexpr auto as_tuple_impl(std::index_sequence<I...>) noexcept { constexpr auto a = array_of_type_ids<T>(); // #0 return std::tuple< // #3 decltype(typeid_conversions::id_to_type( // #2 size_t_<a[I]>{} // #1 ))... >{}; }

ゼロ行：ここで識別子の配列を取得します。ここで、変数aの型はstd ::配列に似ていますが、constexpr式で使用できるように強く拡張されています（ほとんどの問題がconstexprにあるC ++ 17ではなくC ++ 14があるため） std :: arrary fixed）。

1行目では、配列の要素から整数定数を作成します。積分定数はstd :: Integral_constantで、最初のパラメーターはsize_t_で、2番目のパラメーターはa [I]だけです。 size_t_は宣言、エイリアスを使用しています。 2行目で識別子を型に変換し、3行目でstd :: tupleを作成します。このタプルの各要素は、T構造内のデータ型と完全に一致します。今、私たちは非常に愚かなことをすることができます。たとえば、reinterpret_castユーザー構造をtuple'uに変更します。そして、タプルのようにユーザー構造を扱うことができます。まあ、それは少し厄介です：reinterpret_cast。

コードが少し単純化されているため、コピーして実行しようとしないでください。たとえば、std :: tupleは引数の作成と破棄の順序を規制しません。一部の実装では、引数を末尾から先頭に初期化し、間違った順序で格納します。そのため、std :: tupleは機能しません。あなたは自分で作らなければなりません。

さらに進みましょう。ポインターをどうするか：定数ポインターへのポインター、intへのポインターなど？

type_to_id関数があります。 std :: size_tを返し、このstd :: size_tからのビットの束は使用しませんでした。32個の基本型にのみ使用しました。したがって、これらのビットを使用して、ポインターに関する情報をエンコードできます。たとえば、ユーザー構造にunsigned char型のフィールドがある場合、バイナリ形式では次のようになります。

unsigned char c0; // 0b00000000 00000000 00000000 000 00001

最下位ビットには、char識別子が含まれます。これは1つです。したがって、マクロで割り当てました。 unsigned charポインターがある場合、最上位ビットにはこれがポインターであるという情報が格納されます。

unsigned char* 1; // 0b 001 00000 00000000 00000000 000 00001

定数ポインターがある場合、最上位ビットには、これが定数ポインターであるという情報が格納されます。

const unsigned char* 2; // 0b 010 00000 00000000 00000000 000 00001

追加のインデックスレベル（別のポインター）を追加すると、他の最上位ビットが変更され、ポインターがあるという情報が格納されます。

const unsigned char** 3; // 0b 010001 00 00000000 00000000 000 00001

基になる型を変更します。最上位ビットは変更されず、最下位ビットには識別子7が含まれるようになりました。これは、shortで作業していることを意味します。

const short** s0; // 0b 010001 00 00000000 00000000 000 00111

型を識別子に変換する関数を追加します（それに応じてこれらのビットを追加します）。

 template<class Type> constexpr std::size_t type_to_id(identity<Type*>) template<class Type> constexpr std::size_t type_to_id(identity<const Type*>) template<class Type> constexpr std::size_t type_to_id(identity<const volatile Type*>) template<class Type> constexpr std::size_t type_to_id(identity<volatile Type*>)

そして、識別子を型に戻す逆関数を追加します。

 template<std::size_t Index> constexpr auto id_to_type(size_t_<Index>, if_extension<Index, native_const_ptr_type> = 0) noexcept; template<std::size_t Index> constexpr auto id_to_type(size_t_<Index>, if_extension<Index, native_ptr_type> = 0) noexcept; template<std::size_t Index> constexpr auto id_to_type(size_t_<Index>, if_extension<Index, native_const_volatile_ptr_type> = 0) noexcept; template<std::size_t Index> constexpr auto id_to_type(size_t_<Index>, if_extension<Index, native_volatile_ptr_type> = 0) noexcept;

ここで、if_extensionはstd :: enable_ifであり、エイリアスと多くの魔法があります。魔法は、識別子に応じて、提示された関数の1つだけを呼び出すことができるということです。

enum'amiをどうすればいいのかわかりません。私が思いついた唯一のことは、std ::根本的なタイプを呼び出すことでした。つまり、列挙型の種類に関する情報を失っています。すべてのユーザー列挙型を基本型のリストに登録することはできません。これは単に不可能です。代わりに、この列挙型の格納方法のみをエンコードします。 intの場合、intとして保存します。ユーザーがclass enum：charを指定した場合、charを取得してcharのみをエンコードし、enumのタイプに関する情報は失われます。

複雑な構造とクラスにも同じ問題があります。すべてを基本型のリストに登録することはできません。したがって、クラス内をもう一度見て、このクラスにあるすべてのフィールドを、ゼロレベルクラスにあるかのようにエンコードします。

構造aがあり、型が構造bであるフィールドがあり、bの中を見て、すべてのフィールドをbからaにドラッグするとします。単純化：アライメントにはまだ多くのロジックがあり、壊れないようにしています。

これは次のように行われます：type_to_id関数が1つ追加されます：

 template <class Type> constexpr auto type_to_id(identity<Type>, typename std::enable_if< !std::is_enum<Type>::value && !std::is_empty<Type>::value>::type*) noexcept { return array_of_type_ids<Type>(); // Returns array! }

今回は配列を返すことができます（過去のものはすべてsize_tを返しました）。 ubiq構造を変更して、配列を操作し、オフセットを決定する方法にロジックを追加し、オフセットを書き込む場所、および作業している部分構造に関する情報を追加する必要があります。これはすべて長く、あまり面白くありません。それがどうなるかについての例がいくつかありますが、これらも技術的な詳細です。

これは私たちに何を与え、これはすべてどこで使用できますか？いいえ、これをすべて実装する既製のライブラリがあるため、これを自分で記述する必要はありません。このライブラリが提供するものを次に示します。

まず、比較：手動で比較を記述する必要がなくなりました

POD構造。 3つの方法があります。つまり、まったく何も記述せずに、1つのヘッダーファイルを接続するだけで、すべてのPOD構造について、すぐに比較できます。

異種比較があります。同じフィールドを持つ2つの構造を持つことができますが、

さまざまなタイプのデータを互いに比較します。

普遍的なハッシュ関数があります：ユーザー構造をそこに渡し、そこからのハッシュを考慮します。

I / O演算子 ：導入部ですでに見たものもすべて揃っており、動作します。

このメタプログラムの魔法について初めて話したとき、鉄の一部の開発者はとても幸せでした（覚えていないだけです）。彼らは、異なるプロトコルを表す1000の異なる平面構造を持っていると言います。つまり、1対1の構造がプロトコルにマップされます。これらの各構造には、3つのシリアライザーがあります（将来使用されるハードウェアとワイヤによって異なります）。また、3,000個のシリアライザーがあります。彼らはこれにとても不満でした。このライブラリを使用して、3,000のシリアライザーを3つのシリアライザーに簡素化することができました。彼らはとても幸せでした。

これらのメタプログラミングトリックにより、基本的なリフレクションの可能性が開かれます。たとえば、is_continuous_layout <T>、is_padded <T>、has_unique_object_representations <T>のように、新しいtype_traitsを記述できます（C ++ 17のように）。

ライブラリにはない素晴らしい関数punch_hole <T、Index>を記述し、ユーザー構造内の未使用のビットとバイトを定義し、それらへのリンクを返し、他の人が使用できるようにすることができます。

最後に、より一般化されたアルゴリズムを書くことができます：たとえば、boost :: spiritはユーザー構造にすぐに解析されるように変更でき、boost :: fusionおよびboost :: spiritのマクロを使用してこの構造を宣言する必要はありません。ちなみに、ブースト::スピリット開発者の1人が私のところに来て言った。私はこのことを望んでいます。図書館へのリンクをください。」彼にあげた。

いくつかの例。そのような恐ろしい構造があります：

 namespace foo { struct comparable_struct { int i; short s; char data[50]; bool bl; int a,b,c,d,e,f; }; } // namespace foo std::set<foo::comparable_struct> s;

たくさんのフィールドがあります。問題は、この構造を何らかのコンテナに転送したいということです。たとえば、std :: setの場合。ライブラリがなければ、この構造に対して恐ろしいコンパレータを作成する必要があります。std :: tieを使用してコンパレーターを作成できますが、構造が変更された場合、適切な変更を行う必要があるすべての場所を覚えておく必要があります。地獄。考えないほうがいいすべてがそのままライブラリで機能します。構造を取得し、std :: setに押し込みます。すべて機能します。この構造のシリアル化も機能します。

 std::set<foo::comparable_struct> s = { /* ... */ }; std::ofstream ofs("dump.txt"); for (auto& a: s) ofs << a << '\n';

何も考えずにただのストリームドライブ変数で。

逆シリアル化も機能します。ただストリームから、値を構造に戻し、使用するコンテナに挿入します。

 std::set<foo::comparable_struct> s; std::ifstream ifs("dump.txt"); foo::comparable_struct cs; while (ifs >> cs) { char ignore = {}; ifs >> ignore; s.insert(cs); }

美しさ：最小限のコード。

私のお気に入りの例は、最も意味のないものですが、見た目が美しいからです。関数flat_tie：std :: tupleから構造を初期化できます。

 template <class T> auto flat_tie(T& val) noexcept; struct my_struct { int i, short s; }; my_struct s; flat_tie(s) = std::tuple<int, short>{10, 11};

これで、my_struct :: iは値10を保存し、my_struct :: sはs構造内に11を保存します。

したがって、現時点では、ある種のリフレクションを実行できるライブラリがありますが、C ++ 14で動作し、使用できる場所の例です。

ただし、ライブラリはreinterpret_castを使用します。そして、私はreinterpret_castsが好きではありません。それらはconstexpr関数を許可せず、それもevenいです。

それを修正してみましょう。これを迅速かつ簡単に修正します：半メガバイトのコードに入るだけです。これはC ++ 17で行います。考え方は次のとおりです。C++ 17では、構造バインディングが追加されました。これは、構造をフィールドに分解し、フィールドへのリンクを取得できるようにするものです。唯一の問題は、構造内のフィールドの数を正確に知る必要があることです。そうしないと、すべてが収集されず、enable_ifを介してこの構造バインディングを使用することができません。しかし、記事の冒頭で、構造内のフィールド数を取得する方法を既に学びました。フィールドの数からデータ型を作成し、タグディスパッチを使用します。

 template <class T> constexpr auto as_tuple(T& val) noexcept { typedef size_t_<fields_count<T>()> fields_count_tag; return detail::as_tuple_impl(val, fields_count_tag{}); }

一連のas_tuple_impl関数を生成します。

 template <class T> constexpr auto as_tuple_impl(T&& val, size_t_<1>) noexcept { auto& [a] = std::forward<T>(val); return detail::make_tuple_of_references(a); } template <class T> constexpr auto as_tuple_impl(T&& val, size_t_<2>) noexcept { auto& [a,b] = std::forward<T>(val); return detail::make_tuple_of_references(a,b); }

これらの関数as_tuple_implの場合、2番目のパラメーターは構造T内のフィールド数です。構造T内に1つのフィールドがあると判断した場合、最初の関数as_tuple_implが呼び出されます。彼女は構造バインディングを使用し、最初のフィールドを取得し、このフィールドへのリンクがあるタプルを作成し、このタプルをユーザーに返します。構造内に2つのフィールドがある場合、2つのフィールドに対して構造バインディングを呼び出します。これは2番目の関数です。ユーザーを構造的にフィールドaとbに分解し、最初のフィールドと2番目のフィールドへのリンクを格納するタプルを返します。美人！

最良の部分は、このすべてがconstexprであり、カスタムフィールドとカスタム構造で動作するstd :: getを記述できることです。これはすべてコンパイル段階で行われます。信じられないほどの美しさ。唯一の問題は、構造バインディングを持つコードがまだテストされていないことです。コンパイラはまだ構造バインディングをサポートしていません。したがって、これは美しい理論であり、おそらく2、3の変更で機能します。

アントンによって元のレポートantoshkka Polukhina - https://youtu.be/jDI5CHKFKd0

図書館正確かつフラットリフレクション（magic_get）

C ++ 14のリフレクション

More articles: