最近、 SObjectizerの新しいバージョンに取り組んでいる間に、コンパイル時に開発者のアクションを制御するタスクに直面しました。 一番下の行は、以前はプログラマーが次の形式の呼び出しを行うことができたということでした。

receive(from(ch).empty_timeout(150ms), ...); receive(from(ch).handle_n(2).no_wait_on_empty(), ...); receive(from(ch).empty_timeout(2s).extract_n(20).stop_on(...), ...); receive(from(ch).no_wait_on_empty().stop_on(...), ...);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

receive（）操作には、上記のfrom(ch).empty_timeout(150ms)



またはfrom(ch).handle_n(2).no_wait_on_empty()



など、一連のメソッドが使用された一連のパラメーターが必要でした。 同時に、抽出/処理されるメッセージの数を制限するhandle_n（）/ extract_n（）メソッドの呼び出しはオプションでした。 したがって、上記のチェーンはすべて正しいものでした。

しかし、新しいバージョンでは、ユーザーが抽出および/または処理するメッセージの数を明示的に指定することを強制する必要がありました。 つまり from(ch).empty_timeout(150ms)



のフォームのチェーンが正しくfrom(ch).empty_timeout(150ms)



。 from(ch).handle_all().empty_timeout(150ms)



に置き換える必要があります。

そして、プログラマーがhandle_all（）、handle_n（）またはextract_n（）の呼び出しを忘れた場合にコンパイラーがプログラマーの手を打つようにしたかったのです。

C ++はこれを助けることができますか？

はい そして、誰かがまさにその方法に興味があるなら、あなたは猫の下で歓迎されています。

receive（）関数以上のものがあります

上記のreceive（）関数は、呼び出しチェーン（ ビルダーパターンとも呼ばれます ）を使用して設定されたパラメーターを示しています。 しかし、ほぼ同じパラメーターセットを受け取るselect（）関数もありました。

 select(from_all().empty_timeout(150ms), case_(...), case_(...), ...); select(from_all().handle_n(2).no_wait_on_empty(), case_(...), case_(...), ...); select(from_all().empty_timeout(2s).extract_n(20).stop_on(...), case_(...), case_(...), ...); select(from_all().no_wait_on_empty().stop_on(...), case_(...), case_(...), ...);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

したがって、select（）とreceive（）の両方に適した1つのソリューションを取得したかったのです。 さらに、コピーアンドペーストを回避するために、select（）およびreceive（）自体のパラメーターは既にコードで表されていました。 ただし、これについては以下で説明します。

可能な解決策

したがって、タスクは、ユーザーがhandle_all（）、handle_n（）またはextract_n（）を必ず呼び出すことです。

原則として、これは複雑な決定に頼ることなく達成できます。 たとえば、select（）およびreceive（）に追加の引数を入力できます。

 receive(handle_all(), from(ch).empty_timeout(150ms), ...); select(handle_n(20), from_all().no_wait_on_empty(), ...);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

または、ユーザーに強制的にreceive（）/ select（）呼び出しを行わせることもできます。

 receive(handle_all(from(ch).empty_timeout(150ms)), ...); select(handle_n(20, from_all().no_wait_on_empty()), ...);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ただし、ここでの問題は、SObjectizerの新しいバージョンに切り替えると、ユーザーがコードをやり直す必要があることです。 原則として、コードは手直しを必要としませんでした。 この状況では次のように言います：

 receive(from(ch).handle_n(2).no_wait_on_empty(), ...); select(from_all().empty_timeout(2s).extract_n(20).stop_on(...), case_(...), case_(...), ...);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

私の意見では、これは非常に深刻な問題です。 別の方法を探します。 そして、この方法を以下に説明します。

それでは、CRTPはどこから来るのでしょうか？

記事のタイトルはCRTPに言及しています。 彼はまた、不思議な繰り返しのテンプレートパターンです（この興味深いが、少し脳に寛容なテクニックに精通したい人は、Fluent C ++ブログのこの一連の投稿から始めることができます）。

CRTPに言及したのは、CRTPを介してreceive（）およびselect（）関数のパラメーターを使用した作業を実装したためです。 receive（）およびselect（）のパラメーターの大部分は同じであったため、コードは次のようなものを使用しました。

 template<typename Derived> class bulk_processing_params_t { ...; //     . Derived & self_reference() { return static_cast<Derived &>(*this); } ... public: auto & handle_n(int v) { to_handle_ = v; return self_reference(); } ... auto & extract_n(int v) { to_extract_ = v; return self_reference(); } ... }; class receive_processing_params_t final : public bulk_processing_params_t<receive_processing_params_t> { ...; //   receive . }; class select_processing_params_t final : public bulk_processing_params_t<select_processing_params_t> { ...; };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここでCRTPが必要なのはなぜですか？

ここでCRTPを使用して、基本クラスで定義されたセッターメソッドが、基本型ではなく派生型への参照を返すようにする必要がありました。

つまり、CRTPを使用せず、通常の継承を使用する場合、次のようにしか書くことができません。

 class bulk_processing_params_t { public: //      bulk_processing_params_t, //     . bulk_processing_params_t & handle_n(int v) {...} bulk_processing_params_t & extract_n(int v) {...} ... }; class receive_processing_params_t final : public bulk_processing_params_t { public: //      //   bulk_processing_params_t,    // receive_processing_params_t. ... //       //  receive_processing_params_t. receive_processing_params_t & receive_payload(int v) {...} }; class select_processing_params_t final : public bulk_processing_params_t { public: //      //   bulk_processing_params_t,    // select_processing_params_t. ... };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

しかし、このような原始的なメカニズムでは、同じビルダーパターンを使用できません。

 receive_processing_params_t{}.handle_n(20).receive_payload(0)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

コンパイルされていません。 handle_n（）メソッドはbulk_processing_params_tへの参照を返しますが、そこでreceive_payload（）メソッドはまだ定義されていません。

ただし、CRTPでは、ビルダーパターンに問題はありません。

最終決定

最終的な解決策は、receive_processing_params_tやselect_processing_params_tなどの最終型がテンプレート型になることです。 そのため、次の形式のスカラーでパラメーター化されます。

 enum class msg_count_status_t { undefined, defined };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして、最終型をT <msg_count_status_t :: undefined>からT <msg_count_status_t :: defined>に変換できるようにします。

これにより、たとえばreceive（）関数でreceive_processing_params_tを受信し、comp-timeでStatus値を確認できます。 次のようなもの：

 template< msg_count_status_t Msg_Count_Status, typename... Handlers > inline mchain_receive_result_t receive( const mchain_receive_params_t<Msg_Count_Status> & params, Handlers &&... handlers ) { static_assert( Msg_Count_Status == msg_count_status_t::defined, "message count to be processed/extracted should be defined " "by using handle_all()/handle_n()/extract_n() methods" );
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

一般的に、すべてがいつものように単純です：実行してください;）

行われた決定の説明

SObjectizerの詳細から切り離された最小限の例を見てみましょう。

そのため、メッセージ数の制限を設定するかどうかを決定するタイプが既にあります。

 enum class msg_count_status_t { undefined, defined };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

次に、すべての共通パラメーターが格納される構造が必要です。

 struct basic_data_t { int to_extract_{}; int to_handle_{}; int common_payload_{}; };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

basic_data_tの内容はまったく異なります。 たとえば、上記の最小限のフィールドセットが適しています。

basic_data_tに関連して、特定の操作（receive（）、select（）、またはその他）に対して、basic_data_tを継承する独自の具象型が作成されることが重要です。 たとえば、抽象化された例のreceive（）の場合、これは次の構造になります。

 struct receive_specific_data_t final : public basic_data_t { int receive_payload_{}; receive_specific_data_t() = default; receive_specific_data_t(int v) : receive_payload_{v} {} };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

basic_data_t構造とその子孫が問題を引き起こさないと仮定します。 したがって、ソリューションのより複雑な部分に進みます。

ここで、getterメソッドを提供するbasic_data_tのラッパーが必要です。 これは、次の形式のテンプレートクラスになります。

 template<typename Basic_Data> class basic_data_holder_t { private : Basic_Data data_; protected : void set_to_extract(int v) { data_.to_extract_ = v; } void set_to_handle(int v) { data_.to_handle_ = v; } void set_common_payload(int v) { data_.common_payload_ = v; } const auto & data() const { return data_; } public : basic_data_holder_t() = default; basic_data_holder_t(Basic_Data data) : data_{std::move(data)} {} int to_extract() const { return data_.to_extract_; } int to_handle() const { return data_.to_handle_; } int common_payload() const { return data_.common_payload_; } };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このクラスは定型であるため、basic_data_tの継承者を含めることができますが、basic_data_tにあるフィールドに対してのみgetterメソッドを実装します。

ソリューションのさらに複雑な部分に進む前に、basic_data_holder_tのdata（）メソッドに注意する必要があります。 これは重要な方法であり、後で説明します。

ここで、キーテンプレートクラスに移ります。これは、現代のC ++にあまり熱心ではない人にとってはかなり恐ろしいものです。

 template<typename Data, typename Derived> class basic_params_t : public basic_data_holder_t<Data> { using base_type = basic_data_holder_t<Data>; public : using actual_type = Derived; using data_type = Data; protected : actual_type & self_reference() { return static_cast<actual_type &>(*this); } decltype(auto) clone_as_defined() { return self_reference().template clone_if_necessary< msg_count_status_t::defined >(); } public : basic_params_t() = default; basic_params_t(data_type data) : base_type{std::move(data)} {} decltype(auto) handle_all() { this->set_to_handle(0); return clone_as_defined(); } decltype(auto) handle_n(int v) { this->set_to_handle(v); return clone_as_defined(); } decltype(auto) extract_n(int v) { this->set_to_extract(v); return clone_as_defined(); } actual_type & common_payload(int v) { this->set_common_payload(v); return self_reference(); } using base_type::common_payload; };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このbasic_params_tはメインのCRTPテンプレートです。 現在のみ、2つのパラメーターによってパラメーター化されています。

最初のパラメーターは、内部に含める必要があるデータ型です。 たとえば、receive_specific_data_tまたはselect_specific_data_t。

2番目のパラメーターは、CRTPでよく知られている後続のタイプです。 self_reference（）メソッドで使用して、派生型への参照を取得します。

basic_params_tテンプレートの実装の重要なポイントは、そのclone_as_defined（）メソッドです。 このメソッドは、相続人がclone_if_necessary（）メソッドを実装することを想定しています。 そして、このclone_if_necessary（）は、オブジェクトT <msg_count_status_t :: undefined>をオブジェクトT <msg_count_status_t :: defined>に変換するように設計されています。 そして、そのような変換は、セッターメソッドhandle_all（）、handle_n（）、extract_n（）で開始されます。

さらに、clone_as_defined（）、handle_all（）、handle_n（）およびextract_n（）が戻り値のタイプをdecltype（auto）として決定するという事実に注意を払うことができます。 これは別のトリックです。これについてはすぐに説明します。

これで、これらすべてが考え出された最終型の1つをすでに見ることができます。

 template< msg_count_status_t Msg_Count_Status > class receive_specific_params_t final : public basic_params_t< receive_specific_data_t, receive_specific_params_t<Msg_Count_Status> > { using base_type = basic_params_t< receive_specific_data_t, receive_specific_params_t<Msg_Count_Status> >; public : template<msg_count_status_t New_Msg_Count_Status> std::enable_if_t< New_Msg_Count_Status != Msg_Count_Status, receive_specific_params_t<New_Msg_Count_Status> > clone_if_necessary() const { return { this->data() }; } template<msg_count_status_t New_Msg_Count_Status> std::enable_if_t< New_Msg_Count_Status == Msg_Count_Status, receive_specific_params_t& > clone_if_necessary() { return *this; } receive_specific_params_t(int receive_payload) : base_type{ typename base_type::data_type{receive_payload} } {} receive_specific_params_t(typename base_type::data_type data) : base_type{ std::move(data) } {} int receive_payload() const { return this->data().receive_payload_; } };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

最初に注意する必要があるのは、base_type :: data_typeを取るコンストラクターです。 このコンストラクターを使用すると、現在のパラメーター値はT <msg_count_status_t :: undefined>からT <msg_count_status_t :: defined>への変換中に転送されます。

概して、このreceive_specific_params_tは次のようなものです。

 template<typename V, int K> class holder_t { V v_; public: holder_t() = default; holder_t(V v) : v_{std::move(v)} {} const V & value() const { return v_; } }; holder_t<std::string, 0> v1{"Hello!"}; holder_t<std::string, 1> v2; v2 = v1; //   ,   v1  v2   . v2 = holder_t<std::string, 1>{v1.value()}; //    .
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

また、前述のコンストラクタreceive_specific_params_tでは、receive_specific_params_t <msg_count_status_t :: defined>をreceive_specific_params_t <msg_count_status_t :: undefined>の値で初期化できます。

receive_specific_params_tで2番目に重要なことは、2つのclone_if_necessary（）メソッドです。

なぜ2つあるのですか？ SFINAE-vskayaのすべての魔法は、その定義で何を意味しますか？

不要な変換を避けるために、2つのclone_if_necessary（）メソッドが作成されました。 プログラマーがhandle_n（）メソッドを呼び出し、すでにreceive_specific_params_t <msg_count_status_t :: defined>を受け取ったとします。 そして、extract_n（）を呼び出しました。 これは許可されており、handle_n（）とextract_n（）はわずかに異なる制限を設定します。 extract_n（）の呼び出しは、receive_specific_params_t <msg_count_status_t :: defined>も提供する必要があります。 しかし、すでにあります。 では、既存のものを再利用しないのはなぜですか？

そのため、2つのclone_if_necessary（）メソッドがここにあります。 最初の方法は、変換が本当に必要なときに機能します。

  template<msg_count_status_t New_Msg_Count_Status> std::enable_if_t< New_Msg_Count_Status != Msg_Count_Status, receive_specific_params_t<New_Msg_Count_Status> > clone_if_necessary() const { return { this->data() }; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

コンパイラーは、例えば、状況が未定義から定義済みに変わるときに、それを選択します。 そして、このメソッドは新しいオブジェクトを返します。 そして、はい、このメソッドの実装では、basic_data_holder_tと早く定義されたdata（）呼び出しに注意を払います。

2番目の方法：

  template<msg_count_status_t New_Msg_Count_Status> std::enable_if_t< New_Msg_Count_Status == Msg_Count_Status, receive_specific_params_t& > clone_if_necessary() { return *this; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ステータスを変更する必要がない場合に呼び出されます。 そして、このメソッドは既存のオブジェクトへの参照を返します。

これで、多くのメソッドのbasic_params_tで戻り型がdecltype（auto）として定義された理由が明らかになるはずです。 結局、これらのメソッドはclone_if_necessary（）の特定のバージョンが派生型で呼び出されることに依存しており、オブジェクトまたはリンクのいずれかが返される可能性があります...事前に予測することはできません。 そして、ここでdecltype（auto）が助けになります。

小さい免責事項

説明した最小限の例は、選択したソリューションの最も単純で最も理解しやすいデモを目的としています。 したがって、コードに組み込まれることを請う非常に明白なものはありません。

たとえば、basic_data_holder_t :: data（）メソッドは、データへの定数参照を返します。 これにより、T <msg_count_status_t :: undefined>からT <msg_count_status_t :: defined>への変換中にパラメーター値がコピーされます。 パラメータのコピーが高価な操作である場合、移動セマンティクスに戸惑う必要があり、data（）メソッドは次の形式になります。

 auto data() { return std::move(data_); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

また、すべての最終型（receive_specific_params_tやselect_specific_params_tなど）に、clone_if_necessaryメソッドの実装を含める必要があります。 つまり この場所では、まだコピーペーストを使用しています。 おそらく、同じタイプのコードの重複を避けるために、何か考えるべきことがあります。

確かに、「構文のオーバーヘッド」を減らすためにnoexceptはコードに記述されていません。

それだけです

ここで説明した最小限の例のソースコードは、ここにあります 。 そして、例えば、 ここでオンラインコンパイラで遊ぶことができます （163行目でhandle_all（）の呼び出しをコメントアウトして、何が起こるかを見ることができます）。

私が実装したアプローチが唯一の正しいアプローチであるとは言いたくありません。 しかし、まず、コピーアンドペーストでない限り、私は代替案を見ました。 そして、第二に、これを行うことはまったく難しくありませんでした。幸いなことに、多くの時間はかかりませんでした。 しかし、古いテストと例がSObjectizerの最新バージョンの新しい機能に適応したため、コンパイラのパンチはすぐに非常に役立ちました。

それで、私に関しては、C ++はそれが複雑であることをもう一度確認しました。 しかし、それだけではなく、開発者により多くの機会を与えるためです。 まあ、これがすべて私よりも簡単な方法で最新のC ++で取得できたとしても驚かないでしょう。

PS。 読者の1人がSObjectizerをフォローしている場合、5.5ブランチとの互換性が大幅に侵害された新しいバージョン5.6は、すでにかなり息づいていると言えます。 BitBucketで見つけることができます。 このリリースはまだ長い道のりですが、SObjectizer-5.6はすでに意図されていたものです。 あなたの印象を取り、試して、共有することができます。