QtがシグナルとスロットにMOCを使用する理由

テンプレートは、C++に組み込まれたメカニズムであり、渡された引数の型に応じてコンパイラが動的にコードを生成することを可能にします。そのため、テンプレートはフレームワーク開発者にとって非常に興味深いものであり、Qtでも多くの場所で高度なテンプレートが使用されています。しかし、制限もあります： テンプレートで簡単に表現できるものもあれば、テンプレートでは表現不可能なものもあります。汎用的なベクタコンテナクラスは、ポインタ型に対する部分特化があっても簡単に表現できますが、文字列として与えられたXML記述に基づいてグラフィカルユーザーインターフェースを設定する関数は、テンプレートとして表現できません。 そして、その中間にはグレーゾーンが存在します。コードのサイズ、可読性、移植性、使いやすさ、拡張性、堅牢性、そして最終的には設計の美しさを犠牲にすることで、テンプレートを駆使して何とか実現できるものもあるのです。テンプレートもCプリプロセッサも、信じられないほど賢く、驚くようなことを行うために限界まで使いこなすことができます。 しかし、そうしたことが可能だからといって、それを実行することが必ずしも正しい設計上の選択であるとは限りません。残念ながら、コードは本に掲載されるためのものではなく、現実世界のオペレーティングシステム上で、現実世界のコンパイラによってコンパイルされるためのものです。

Qtがmocを採用している理由をいくつか挙げます：

構文の重要性

構文は単なる「飾り」ではありません。アルゴリズムを表現するために使用する構文は、コードの可読性や保守性に大きな影響を与える可能性があります。Qtのシグナルとスロットに使用されている構文は、実践において非常に成功していることが証明されています。この構文は直感的で、使いやすく、読みやすいものです。 Qtを学ぶ人々は、その構文が、シグナルとスロットの概念が極めて抽象的かつ汎用的な性質を持つにもかかわらず、その理解と活用に役立つと感じています。これにより、プログラマーはデザインパターンについて考える必要さえなく、最初から正しい設計を行うことができます。

コードジェネレータは有用である

Qt XMLのmoc （Meta-Object Compiler）は、コンパイル言語の機能の枠を超えて活用するための洗練された手段を提供します。これは、任意の標準C++コンパイラでコンパイル可能な追加のC++コードを生成することで実現されます。moc はC++ソースファイルを読み込みます。Q_OBJECT マクロを含む1つ以上のクラス宣言が見つかった場合、それらのクラス用のメタオブジェクトコードを含む別のC++ソースファイルを生成します。moc によって生成されたC++ソースファイルは、コンパイルされ、クラスの実装とリンクされる必要があります（あるいは、#included を使用してクラスのソースファイルに組み込むことも可能です）。通常、moc は手動で呼び出されるのではなく、ビルドシステムによって自動的に呼び出されるため、プログラマーによる追加の作業は必要ありません。

moc は、Qtが使用している唯一のコードジェネレータではありません。もう1つの代表的な例として、uic （User Interface Compiler ）があります。これは、XML形式のユーザーインターフェース記述を受け取り、フォームを設定するC++コードを生成します。Qt以外でも、コードジェネレータは一般的に使用されています。 例えば、rpc やidl は、プログラムやオブジェクトがプロセスやマシンの境界を越えて通信できるようにするものです。あるいは、lex やyacc が最もよく知られている、多種多様なスキャナおよびパーサジェネレータもあります。これらは文法仕様を入力として受け取り、ステートマシンを実装するコードを生成します。 コードジェネレータの代替手段としては、ハックされたコンパイラ、プロプライエタリな言語、あるいはコンパイル時ではなく設計時に不明瞭なコードを生成する、一方向のダイアログやウィザードを備えたグラフィカルプログラミングツールなどが挙げられます。私たちは、顧客をプロプライエタリな C++ コンパイラや特定の統合開発環境（IDE）に縛り付けるのではなく、顧客が好むあらゆるツールを使用できるようにしています。 プログラマーに生成されたコードをソースリポジトリに追加するよう強制するのではなく、当社のツールをビルドシステムに組み込むことを推奨しています。そうすることで、よりクリーンで安全になり、UNIXの精神にも沿ったものとなります。

GUIは動的である

C++は、標準化され、強力かつ精巧な汎用言語です。オペレーティングシステム全体、データベースサーバー、ハイエンドのグラフィックスアプリケーションから一般的なデスクトップアプリケーションに至るまで、あらゆる種類のアプリケーションを網羅する、これほど幅広いソフトウェアプロジェクトで活用されている唯一の言語です。 C++の成功の鍵の一つは、ANSI Cとの互換性を維持しつつ、最高のパフォーマンスと最小限のメモリ消費に重点を置いた、スケーラブルな言語設計にあります。

こうした利点がある一方で、いくつかの欠点も存在します。コンポーネントベースのグラフィカルユーザーインターフェース（GUI）プログラミングにおいて、C++の静的オブジェクトモデルは、Objective Cの動的メッセージングアプローチに比べて明らかな不利な点となります。 ハイエンドのデータベースサーバーやオペレーティングシステムに適したものが、必ずしもGUIフロントエンドにとって正しい設計選択であるとは限りません。『moc 』では、この欠点を利点へと転換し、安全かつ効率的なグラフィカルユーザーインターフェースプログラミングという課題に対応するために必要な柔軟性を追加しました。

私たちのアプローチは、テンプレートで実現できることをはるかに超えています。例えば、オブジェクトのプロパティを持つことができます。また、シグナルとスロットのオーバーロードも可能であり、オーバーロードが重要な概念である言語でプログラミングする際には、これが自然な感覚として受け入れられます。私たちのシグナルはクラスインスタンスのサイズに0バイトも追加しないため、バイナリ互換性を損なうことなく新しいシグナルを追加することができます。

もう一つの利点は、実行時にオブジェクトのシグナルやスロットを調査できることです。 接続するオブジェクトの正確な型を知らなくても、型安全な「名前による呼び出し（call-by-name）」を使用して接続を確立できます。これは、テンプレートベースのソリューションでは不可能です。この種のランタイム内省により、Qt Widgets Designer のXML UIファイルから生成・接続されるGUIなど、新たな可能性が開かれます。

呼び出しのパフォーマンスがすべてではない

Qtのシグナルとスロットの実装は、テンプレートベースのソリューションほど高速ではありません。一般的なテンプレート実装では、シグナルの発信にかかるコストは通常の関数呼び出し4回分程度ですが、Qtでは約10回の関数呼び出しに相当する処理が必要です。 これは驚くべきことではありません。Qtのメカニズムには、汎用マーシャラー、イントロスペクション、異なるスレッド間のキュー化された呼び出し、そして最終的にはスクリプト化機能が含まれているからです。Qtは過度なインライン化やコード展開に依存せず、比類のない実行時の安全性を提供します。 Qtのイテレータは安全ですが、より高速なテンプレートベースのシステムのイテレータは安全ではありません。複数の受信者に対してシグナルを発行している最中であっても、プログラムがクラッシュすることなく、それらの受信者を安全に削除することができます。この安全性がなければ、アプリケーションは最終的に、デバッグが困難な「解放済みのメモリへの読み取りまたは書き込みエラー」によりクラッシュすることになるでしょう。

とはいえ、テンプレートベースのソリューションであれば、シグナルとスロットを使用するアプリケーションのパフォーマンスを向上させることができるのではないでしょうか？ Qt では、シグナルを介してスロットを呼び出す際にわずかなオーバーヘッドが生じることは事実ですが、その呼び出しコストはスロットの総コストのうちごく一部に過ぎません。 Qtのシグナル・スロットシステムとのベンチマーク比較は、通常、空のスロットを用いて行われます。スロット内で何か実用的な処理（例えば、いくつかの単純な文字列操作など）を行うようになると、呼び出しのオーバーヘッドは無視できる程度になります。 Qtのシステムは高度に最適化されているため、operator newやoperator deleteを必要とする処理（例えば、文字列操作やテンプレートコンテナへの挿入・削除など）は、シグナルを発行するよりもはるかにコストが高くなります。

余談ですが、パフォーマンスが重要なタスクの高速な内部ループ内でシグナルとスロットの接続があり、その接続がボトルネックであると判明した場合は、シグナルとスロットの代わりに標準的なリスナー・インターフェースパターンの使用を検討してください。このようなケースでは、おそらく1対1の接続で十分でしょう。 例えば、ネットワークからデータをダウンロードするオブジェクトがある場合、要求されたデータが到着したことを示すためにシグナルを使用するのは、極めて合理的な設計です。しかし、消費者にバイト単位で1つずつデータを送信する必要がある場合は、シグナルとスロットではなく、リスナーインターフェースを使用してください。

制限なし

シグナルやスロット用にmoc を持っていたため、テンプレートでは実現できなかった他の便利な機能を追加することができました。その中には、生成されたtr() 関数を介したスコープ付き変換や、イントロスペクションと拡張された実行時型情報を備えた高度なプロパティシステムなどが含まれます。 プロパティシステムだけでも大きな利点です。Qt Widgets Designer のような強力で汎用的なユーザーインターフェース設計ツールは、強力でイントロスペクション機能を備えたプロパティシステムがなければ、作成がはるかに困難になるでしょう。いや、不可能にさえなるかもしれません。しかし、利点はこれだけにとどまりません。 また、システムの RTTI に依存しないため、その制限を受けない動的なqobject_cast<T>() メカニズムも提供しています。 これを利用して、動的に読み込まれたコンポーネントからインターフェースを安全に取得します。もう一つの応用分野は動的メタオブジェクトです。例えば、ActiveXコンポーネントを取り込み、実行時にその周囲にメタオブジェクトを作成することができます。あるいは、Qtコンポーネントのメタオブジェクトをエクスポートすることで、QtコンポーネントをActiveXコンポーネントとしてエクスポートすることも可能です。テンプレートでは、これらのいずれのことも実現できません。

moc を備えたC++は、C++特有のパフォーマンスとスケーラビリティの利点を維持しつつ、本質的にObjective-CやJavaランタイム環境と同等の柔軟性を提供します。これこそが、Qtを今日のような柔軟で使いやすいツールにしている理由です。