私たちのチームはC ++プロジェクトを専門としています。また、C ++コンポーネントへのHTTPエントリポイントを作成する必要が時々ありました。どのようなツールが使用されたか。古き良きCGIと、さまざまな組み込みライブラリ（サードパーティ製と自己記述型の両方）がありました。これはすべてうまくいきましたが、そのようなことはより簡単に、より速く、より生産的に行われるべきだという感覚が常にありました。

その結果、私たちは見回すのをやめる時間であると判断し、 ~~好みと遊女、~~クロスプラットフォーム、非同期、生産的、人間の態度で、エンドユーザーに対して自分で何かをしようとする必要がありました。その結果、小さなC ++ 14 RESTinioライブラリを取得しました。これにより、わずか数行のコードでC ++アプリケーション内でHTTPサーバーを起動できます。たとえば、ここに、「Hello、World」ですべての要求に応答する最も単純なサーバーがあります。

#include <restinio/all.hpp> int main() { restinio::run( restinio::on_this_thread() .port(8080) .address("localhost") .request_handler([](auto req) { return req->create_response().set_body("Hello, World!").done(); })); return 0; }

RESTinioの実装では、C ++テンプレートが積極的に使用されています。これについては、今日少しお話ししたいと思います。

RESTinioについての一般的な言葉

RESTinioは、BSD-3-CLAUSEライセンスの下で配布される小さなオープンソースプロジェクトです。 RESTinioは2017年の春から積極的に開発されています。この間、いくつかの公開リリースを作成し、徐々にRESTinioに機能を追加しました。最新のリリースが今日行われました。これは、バージョン0.4のリリースであり、おそらく、必要な最小限の機能を実現しました。

RESTinioは、いくつかのサードパーティコンポーネントを使用します。ネットワークを操作するには、Asio（スタンドアロンバージョンのAsio）を使用し、HTTPプロトコルの解析にはNode.jsのhttp-parserを使用します。また、内部でfmtlibを使用し、テスト用にCatch2ライブラリを使用します。

RESTinioはまだバージョン1.0に達していないという事実にもかかわらず、私たちはRESTinioの品質と安定性に非常に注意しています。たとえば、同僚はRESTinioに基づくソリューションを使用してMail.ruコンテストHighloadCupに参加しました。この決定は45位から決勝に達し、決勝で44位になりました。私は間違っているかもしれませんが、ファイナリストの中には、ユニバーサルHTTPフレームワークに基づいて構築された2つまたは3つのソリューションしかありませんでした。それらの1つはRESTinioに基づくソリューションであることが判明しました。

一般に、パフォーマンスに関して言えば、REStinioの速度は開発の最優先事項ではありませんでした。それにもかかわらず、パフォーマンスに注意を払いましたが、それでも、使いやすいソリューションを取得することがより重要でした。同時に、合成ベンチマークではRESTinioはそれほど悪く見えません。

ただし、この記事では、REStinioライブラリ自体とその機能についてはあまり触れません（この情報の詳細については、こちらを参照してください）。 C ++言語のそのような重要な機能をテンプレートとしてどのように実装するのか。

なぜパターンなのか？

RESTinioコードはテンプレートに基づいています。したがって、上記の例では、テンプレートはどこにでもありますが、表示されていません。

関数restinio :: run（）テンプレート化;
関数restinio :: on_this_thread（）テンプレート化;
request_handler（）メソッドも定型です。
create_response（）メソッドもテンプレートです。

RESTinioがテンプレートをそれほど多く使用するのはなぜですか？おそらく最も深刻なのは、次の2つの理由です。

まず、REStinioを広くカスタマイズできるようにしたかったのです。しかし、そのため、カスタマイズの実行時のコストは最小限に抑えられます。ここでのテンプレートは、単に競争を超えているように思えます。

第二に、私たちの中には、どうやらアレクサンドレスクに噛まれたようです。そして、これはまだ影響を及ぼしていますが、それ以来多くのことが経過しています。

まあ、私たちはRESTinioのかなりの部分がテンプレートコードであるという事実の結果も気に入りました。ライブラリはヘッダーのみであることが判明しました。現在のC ++では、ヘッダーのみのライブラリを自分の（または他の誰かの）プロジェクトに接続する方が、コンパイルする必要があるものよりもはるかに簡単です。この動物園は、ビルドシステムと依存関係管理システムをC ++で提供します。そして、これらの動物園のヘッダーのみのライブラリは、はるかに良い感じです。コンパイル時間を増やしてこれにお金を払わなければならない場合でも、これはすでに完全に異なる会話のトピックです...

簡単な例でのテンプレートのカスタマイズ

上記で、テンプレートを使用してRESTinioをカスタマイズできると述べました。いくつかの簡単な例の意味を示しましょう。

チャンクエンコーディングのモードで答えを出します

create_response（）メソッドは定型的であると既に述べました。このメソッドは、HTTP応答を生成するメソッドによってパラメーター化されます。デフォルトはrestinio_controlled_output_tです。このメソッドは、Content-Length HTTPヘッダーの値を個別に計算し、プログラマーが応答全体を完全に作成してdone（）メソッドを呼び出した後、ソケットへの応答の書き込みを開始します。

ただし、RESTINIOは、user_controlled_output_tおよびchunked_output_tのメソッドをさらにサポートしています。たとえば、chunked_output_tモードを使用すると、次のようになります。

 auto handler = [&](auto req) { auto resp = req->create_response<restinio::chunked_output_t>(); resp .append_header(restinio::http_field::server, "MyApp Embedded Server") .append_header_date_field() .append_header(restinio::http_field::content_type, "text/plain; charset=utf-8"); resp.flush(); //   . for(const auto & part : fragments) { resp.append_chunk(make_chunk_from(part)); resp.flush(); //    . } return resp.done(); //  . };

特に、create_response（）はresponse_builder_t <Output_Type>オブジェクトを返します。このオブジェクトのパブリックAPIはOutput_Typeに依存しています。したがって、response_builder_t <restinio_controlled_output_t>にはpublic flush（）メソッドがなく、response_builder_t <user_controlled_output_t>のみにpublicメソッドset_content_length（）があります。

ロギングをオンにする

記事の冒頭で、最も単純なシングルスレッドHTTPサーバーを紹介しました。これは「ブラックボックス」として機能し、デバッグシールや診断ログはありません。開始HTTPサーバーに、発生したすべてのアクションを標準出力ストリームに記録させましょう。これを行うには、テンプレートを使用したちょっとしたトリックが必要です。

 #include <restinio/all.hpp> int main() { struct my_traits : public restinio::default_single_thread_traits_t { using logger_t = restinio::single_threaded_ostream_logger_t; }; restinio::run( restinio::on_this_thread<my_traits>() .port(8080) .address("localhost") .request_handler([](auto req) { return req->create_response().set_body("Hello, World!").done(); })); return 0; }

ここで何をしましたか？

HTTPサーバーに対して独自の特性クラスを定義し、必要なロガーのタイプを設定します。次に、restinio :: run（）内でHTTPサーバーを構築するときにRESTinioにこのクラスのプロパティを使用するように強制しました。その結果、restino :: run（）内にHTTPサーバーが作成され、single_threaded_ostream_logger_t型で実装されたロガーを介してすべてのイベントがログに記録されます。

修正された例を実行し、サーバーに単純な要求（wget localhost：8080など）を発行すると、次のように表示されます。

 [2017-12-24 12:04:29.612] TRACE: starting server on 127.0.0.1:8080 [2017-12-24 12:04:29.612] INFO: init accept #0 [2017-12-24 12:04:29.612] INFO: server started on 127.0.0.1:8080 [2017-12-24 12:05:00.423] TRACE: accept connection from 127.0.0.1:45930 on socket #0 [2017-12-24 12:05:00.423] TRACE: [connection:1] start connection with 127.0.0.1:45930 [2017-12-24 12:05:00.423] TRACE: [connection:1] start waiting for request [2017-12-24 12:05:00.423] TRACE: [connection:1] continue reading request [2017-12-24 12:05:00.423] TRACE: [connection:1] received 141 bytes [2017-12-24 12:05:00.423] TRACE: [connection:1] request received (#0): GET / [2017-12-24 12:05:00.423] TRACE: [connection:1] append response (#0), flags: { final_parts, connection_keepalive }, bufs count: 2 [2017-12-24 12:05:00.423] TRACE: [connection:1] sending resp data, buf count: 2 [2017-12-24 12:05:00.423] TRACE: [connection:1] start waiting for request [2017-12-24 12:05:00.423] TRACE: [connection:1] continue reading request [2017-12-24 12:05:00.423] TRACE: [connection:1] outgoing data was sent: 76 bytes [2017-12-24 12:05:00.423] TRACE: [connection:1] should keep alive [2017-12-24 12:05:00.423] TRACE: [connection:1] start waiting for request [2017-12-24 12:05:00.423] TRACE: [connection:1] continue reading request [2017-12-24 12:05:00.424] TRACE: [connection:1] EOF and no request, close connection [2017-12-24 12:05:00.424] TRACE: [connection:1] close [2017-12-24 12:05:00.424] TRACE: [connection:1] destructor called [2017-12-24 12:05:16.402] TRACE: closing server on 127.0.0.1:8080 [2017-12-24 12:05:16.402] INFO: server closed on 127.0.0.1:8080

私たちは何をしましたか？実際、HTTPサーバーのプロパティの1つのパラメーターを修正し、追加の機能を受け取りました。 HTTPサーバーのデフォルトプロパティを使用した最初のケースでは、これはまったくありませんでした。さらに、「一般」とは、正確に「一般」を意味します。例で説明しましょう。

RESTinioコードでは、サーバー操作のログが散らばっています。ここで、言いましょう：

 void close_impl() { const auto ep = m_acceptor.local_endpoint(); m_logger.trace( [&]{ return fmt::format( "closing server on {}", ep ); } ); m_acceptor.close(); m_logger.info( [&]{ return fmt::format( "server closed on {}", ep ); } ); }

ログ用のメッセージを生成するラムダ関数を転送するロガーへの呼び出しがあります。ただし、restinio :: null_logger_tがロガーとして使用されている場合（およびこれはデフォルトで発生します）、trace（）、info（）などのメソッドはnull_logger_tで何もしません。

 class null_logger_t { public: template< typename Message_Builder > constexpr void trace( Message_Builder && ) const {} template< typename Message_Builder > constexpr void info( Message_Builder && ) const {} template< typename Message_Builder > constexpr void warn( Message_Builder && ) const {} ...

したがって、通常のコンパイラはロガーへのすべての呼び出しを単にスローし、ロギング用のコードを生成しません。「使用しない-支払わない」という純粋な形。

エクスプレスルーターの正規表現エンジンの選択

RESTinioにあるエクスプレスルーターを使用したテンプレートによるカスタマイズの別の例を示します。 Express JavaScriptフレームワークに基づいてRESTinioで作成されたExpressルーター。エクスプレスルーターを使用すると、URLを使用して適切なハンドラーを選択する作業が大幅に簡素化されます。特に、ハンドラーに必要なパラメーターがURL内で「保護」されている場合。

以下に、エクスプレスルーターを使用して、/ measure /：idおよび/ measure /：year /：month /：dayの形式のGETリクエストのハンドラーを設定する方法を示す小さな例を示します。

 #include <restinio/all.hpp> using my_router_t = restinio::router::express_router_t<>; auto make_request_handler() { auto router = std::make_unique<my_router_t>(); router->http_get(R"(/measure/:id(\d+))", [](auto req, auto params) { return req->create_response() .set_body( fmt::format("Measure with id={} requested", restinio::cast_to<unsigned long>(params["id"]))) .done(); }); router->http_get(R"(/measures/:year(\d{4})/:month(\d{2})/:day(\d{2}))", [](auto req, auto params) { return req->create_response() .set_body( fmt::format("Request measures for a date: {}.{}.{}", restinio::cast_to<int>(params["year"]), restinio::cast_to<short>(params["month"]), restinio::cast_to<short>(params["day"]))) .done(); }); router->non_matched_request_handler([](auto req) { return req->create_response(404, "Unknown request") .connection_close() .done(); }); return router; } int main() { struct my_traits : public restinio::default_single_thread_traits_t { using request_handler_t = my_router_t; }; restinio::run( restinio::on_this_thread<my_traits>() .port(8080) .address("localhost") .request_handler(make_request_handler())); return 0; }

リクエストからURLを解析するには、エクスプレスルーターにある種の正規表現の実装が必要です。デフォルトでは、std :: regexが使用されますが、現時点では、残念ながら、優れたパフォーマンスを誇ることはできません。たとえば、PCRE / PCRE2はstd :: regexよりもはるかに高速です。

したがって、RESTinioでは、express_router_tに別の正規表現実装を指定できます。方法を尋ねますか？正しい：テンプレートパラメーターを使用。たとえば、std :: regexの代わりにPCRE2を使用するには：

 #include <restinio/all.hpp> #include <restinio/router/pcre2_regex_engine.hpp> using my_router_t = restinio::router::express_router_t< restinio::router::pcre2_regex_engine_t<>>;

さらに、注意深い読者は、pcre2_regex_engine_tもテンプレートであることに気付くかもしれません。今回は、pcre2_regex_engine_tがデフォルトのパラメーターを持つコンテンツです。しかし、簡単に修正できます...

pcre2_regex_engine_tは、PCRE2に固有の独自のプロパティクラスによってパラメーター化されます。現在、pcre2_regex_engine_tのプロパティを使用して、正規表現をコンパイルするオプション、pcre2_matchのオプション、およびmax_capture_groupsなどの重要なパラメーターなどのパラメーターを設定できます。このパラメーターは、ストリングから抽出されるフラグメントの最大数を決定します。デフォルトでは、max_capture_groupsは20です。これは、pcre2_regex_engine_tがすぐに20フラグメントのスペースを割り当てることを意味します。私たちの場合、これは多すぎます。なぜならこの短い例では、URL文字列の要素の最大数は3です。特定のケースに固有の設定を行いましょう：

 #include <restinio/all.hpp> #include <restinio/router/pcre2_regex_engine.hpp> struct my_pcre2_traits : public restinio::router::pcre2_traits_t<> { static constexpr int max_capture_groups = 4; // +1     URL. }; using my_router_t = restinio::router::express_router_t< restinio::router::pcre2_regex_engine_t<my_pcre2_traits>>;

そして、特性について

上記では、特定のエンティティの動作を制御するためにプロパティクラス（つまり、特性）を使用する例がすでに示されています。しかし、一般に、REStinioのHTTPサーバーの動作全体を決定するのは特性です。上記のrestinio :: run（）関数の内部では、テンプレートクラスrestinio :: http_server_tのインスタンスの作成を隠します。また、Traitsテンプレートパラメーターは、HTTPサーバーのパラメーターを定義するだけです。

大きなトップを見ると、次の型名がTraitsで定義されているはずです。

timer_manager_t 。 HTTPサーバーがサーバー接続に関連するタイムアウトをカウントするために使用するタイプを定義します。 RESTinioはデフォルトでasio_timer_manager_tを使用し、標準のAsioタイマーメカニズムを使用します。 SObjectizerタイマーメカニズムを使用するso_timer_manager_tもあります。 null_timer_manager_tもあります。これはまったく何もせず、ベンチマークに役立ちます。

logger_t 。 HTTPサーバーの内部アクティビティを記録するメカニズムを定義します。デフォルトはnull_logger_t、つまりデフォルトでは、HTTPサーバーは何も記録しません。非常に単純なostream_logger_tロガーのフルタイム実装があり、デバッグに役立ちます。

request_handler_t 。 HTTP要求ハンドラーのタイプを定義します。デフォルトはdefault_request_handler_tであり、これは単なるstd :: function <request_handling_status_t（request_handle_t）>です。ただし、このタイプが演算子（）に必要な署名を提供する場合、ユーザーは別のタイプを指定できます。たとえば、上で説明したエクスプレスルーターは、HTTPサーバーのTraitsでrequest_handler_tとして設定する必要がある要求ハンドラーのタイプを定義します。

strand_t いわゆるのタイプを決定しますマルチスレッドモードでの作業時にAsioのジブルを保護するためのストランド。デフォルトでは、これはasio :: strand <asio :: executor>であり、複数の作業スレッドでHTTPサーバーを一度に安全に実行できます。例：

 restinio::run( restinio::on_thread_pool(std::thread::hardware_concurrency()) .port(8080) .address("localhost") .request_handler(make_request_handler()));

HTTPサーバーがシングルスレッドモードで動作する場合、Traits :: strand_tをrestinio :: noop_strand_t（restinio :: default_single_thread_traits_tで実行）として定義することで、追加のオーバーヘッドを回避できます。

stream_socket_t 。 RESTinioが動作するソケットのタイプを定義します。デフォルトでは、これはasio :: ip :: tcp :: socketです。ただし、HTTPSを使用するには、このパラメーターをrestinio :: tls_socket_tとして設定する必要があります。

一般に、その中心である中央クラスhttp_server_t-RESTinioでも、C ++テンプレートにポリシーベースの設計を適用します。したがって、このアプローチの反響がRESTinioの他の多くの部分にも見られることは驚くことではありません。

さて、CRTPのない3階建ての建物は何ですか？

3階建てのテンプレートは記事のタイトルで言及されていますが、これまでのところ、テンプレートがRESTinioでどの程度広く使用されているかについてのみでした。 3階建ての建物自体の例はありませんでした。この省略をなくす必要があります;）

C ++には、 CRTP（Curiously recurring template patternの略）などのトリッキーなものがあります。ここでRESTinioのこのことの助けを借りて、サーバーパラメータを使用した作業を実装しました。

HTTPサーバーを起動する前に、いくつかの必須パラメーターを設定する必要があります（+オプションのパラメーターも設定できます）。たとえば、この例では、HTTPサーバーがリッスンするポートとアドレス、リクエストのハンドラー、およびさまざまな操作のタイムアウトを設定します。

 restinio::run( restinio::on_this_thread() .port(8080) .address("localhost") .request_handler(server_handler()) .read_next_http_message_timelimit(10s) .write_http_response_timelimit(1s) .handle_request_timeout(1s));

実際、ここでは特に複雑なことはありません。on_this_thread関数はserver_settingsオブジェクトを構築して返します。このオブジェクトは、setterメソッドを呼び出すことでさらに変更されます。

ただし、「特に複雑なものは何もない」と言うと、on_this_threadがこのタイプのインスタンスを返すため、少しずるいです。

 template<typename Traits> class run_on_this_thread_settings_t final : public basic_server_settings_t<run_on_this_thread_settings_t<Traits>, Traits> { using base_type_t = basic_server_settings_t< run_on_this_thread_settings_t<Traits>, Traits>; public: using base_type_t::base_type_t; };

すなわちすでにCRTPの耳があります。しかし、basic_server_settings_tの定義を見るとさらに面白いです。

 template<typename Derived, typename Traits> class basic_server_settings_t : public socket_type_dependent_settings_t<Derived, typename Traits::stream_socket_t> { ... };

ここで、ベースタイプとして使用される別のテンプレートを見ることができます。それ自体では、何も興味深いものを表していません。

 template <typename Settings, typename Socket> class socket_type_dependent_settings_t { protected : ~socket_type_dependent_settings_t() = default; };

ただし、設定とソケットのさまざまな組み合わせに特化することができます。たとえば、TLSをサポートするには：

 template<typename Settings> class socket_type_dependent_settings_t<Settings, tls_socket_t> { protected: ~socket_type_dependent_settings_t() = default; public: socket_type_dependent_settings_t() = default; socket_type_dependent_settings_t(socket_type_dependent_settings_t && ) = default; Settings & tls_context(asio::ssl::context context ) & {...} Settings && tls_context(asio::ssl::context context ) && {...} asio::ssl::context tls_context() {...} ... };

そして、たとえば、この状況でこれらすべてをまとめると：

 struct my_pcre2_traits : public restinio::router::pcre2_traits_t<> { static constexpr int max_capture_groups = 4; }; using my_router_t = restinio::router::express_router_t< restinio::router::pcre2_regex_engine_t<my_pcre2_traits>>; using my_traits_t = restinio::single_thread_tls_traits_t< restinio::asio_timer_manager_t, restinio::single_threaded_ostream_logger_t, my_router_t>; ... restinio::run( restinio::on_this_thread<my_traits_t>() .address("localhost") .request_handler(server_handler()) .read_next_http_message_timelimit(10s) .write_http_response_timelimit(1s) .handle_request_timeout(1s) .tls_context(std::move(tls_context)));

そして、確かに、テンプレートはテンプレートの上に置かれ、テンプレートを駆動します。コンパイラエラーメッセージで特に目立つのは、誤ってどこかに印刷してしまった場合です...

おわりに

C ++プログラマーを練習しているC ++テンプレートに対する態度が非常に異なると言っても、私たちが間違っていることはまずありません。誰かがどこでもテンプレートを使用し、時々誰かがそれに対して断固として反対しています。通常のフォーラム/リソース参加者は、特にC ++開発に専門的に関与していないが意見を持っている人の間では、C ++テンプレートに対してさらに曖昧な態度を持っています。したがって、確かに、この記事を読んだ人の多くは、「それだけの価値はあったのか？」という疑問を抱くでしょう。

私たちの意見では、はい。たとえば、C ++コードのコンパイル時間にはあまり混乱していませんが。ちなみに、REStinio + Asioのコンパイルは通常の速度です。これは、これにCatch2も追加された場合です。そうすると、コンパイル時間は大幅に増加します。そして、特に年々これらの同じメッセージがますます健全になっているため、C ++コンパイラからのエラーメッセージを恐れていません。

いずれにせよ、C ++は非常に異なる方法でプログラムされています。そして、誰もが彼に最も合ったスタイルを使用できます。純粋にキャッシュされたライブラリ（ mongooseやcivetwebなど）またはJavaのような「クラスを持つC」で記述されたC ++ライブラリ（ POCOなどで発生）のラッパーから開始します。そして、C ++テンプレートCROW 、 Boost.BeastおよびRESTinioを積極的に使用して終了します。

一般的に、現代では、Rust、Go、Dなどの競合他社や、C＃やJavaはもちろんのこと、C ++には多くの深刻で客観的な利点はないという意見に固執しています。 C ++テンプレートは、おそらく、特定のアプリケーションでのC ++の使用を正当化できる、C ++の数少ない競争上の利点の1つです。もしそうなら、C ++テンプレートを放棄したり、使用を制限したりするポイントは何ですか？私たちはそのような意味を理解していないため、常識が許す限り積極的にRESTinio実装でテンプレートを使用します（ここではどちら側から見てもいいのですが）。

人間の顔をした組み込み非同期HTTPサーバーの実装における3階建てC ++テンプレート