さて、 GTK +のバージョン0.60の後、設計者は、将来の開発と進歩のために、ツールキット全体をオブジェクト指向に書き直す必要があることに気づきました。
現在、CはOOPをサポートしていないため、オブジェクト指向と継承の継承を提供するために、GObjectシステムを作成しました。ここで、GObjectシステムを作成するには、開発時間、依存関係、問題が必要でしたが、Cプログラミング言語にオブジェクト指向機能を提供するためにGObjectシステムを作成する必要がありました。しかし、当時、まさにそれを提供する別のソリューション、C ++がありました！
GTK+の開発者がC++だけを使用しなかったのはなぜですか？
つまり、多くのプロジェクトで採用されている実績のあるソリューションを使用するのではなく、ライブラリ全体を作成するのに時間を無駄にするのはなぜですか？誤解しないでください。私はこの投稿をC対C++のものに変えようとはしていません（フォーラムではそれで十分です、ありがとう）。GTK+の設計者が決定を下した理由と問題を知りたいだけです。
少なくともGTKに関しては、質問に直接答えることはできません。その答えはGTK+開発者にあるので、彼らを追い詰めて尋ねる必要があります。しかし、C ++を使用する代わりに、オブジェクト指向システムをCに追加したい理由については、多くの理由があります。私がすぐに思いつく3つは
言語の複雑さ：Cは非常に単純な言語ですが、C ++は非常に複雑で、ほとんどの（すべてではない）Cのもの、参照などの便利さ、オブジェクト指向機能、複雑なテンプレート言語をサポートしています。そして、新しい値のシステムを見たことがありますか：左辺値、右辺値、glvalues、prvalues、xvalues-え？私が話すことができることはもっとたくさんあります。時間が経つと、C ++は管理しやすくなりますが、Cのオブジェクト指向機能が必要なだけではまだやり過ぎです。
コントロール：設計者がC ++を使用した場合、C++の哲学に固執することになります。たとえば、多重継承は物議を醸す考えであり、正当な理由があります。設計上、GObjectシステムは単一の継承のみをサポートするように構築されているため、継承階層を大幅に簡素化できます。設計者がC++を使用した場合、ユーザーを単一の継承システムに制限する方法はありません。多重継承は単なる例です-GObjectシステムがC++のイデオロギーと異なる場所は他にもたくさんあると思います。
相互運用性：これはおそらく大きな問題です。C ++がきれいに相互運用できる言語はいくつかありますが、実際には、C++は相互運用性がそれほど優れていません。ただし、Cとの相互運用性はほぼ当然のことと考えられています。Cは、相互運用のデファクトスタンダードを形成するため、プログラミング言語の共通語として説明されることがよくあります。C APIを設計することにより、GObjectの設計者は任意の数の言語でGTK+開発への扉を開きました。
GObjectsは、言語に依存しないことを目的としています。動的型付けがあり、特定の言語ではなく、COM、.NET、CORBAなどのランタイムシステムと比較する必要があります。言語に入ると、機能はC++側よりもObjective-Cにあります。
GObject型システムは、C++では実行できないことを実行します。1つには、実行時に新しいクラスを作成でき、言語に依存しない方法でこれを実行できます。実行時にPythonで新しいクラスを定義し、Cで記述された関数内でそのクラスのインスタンスを操作できます。 Pythonが関与したことを意識する必要さえありません。
質問にリンクされているwikiから：
GTK +は元々、Motifツールキットの代わりとしてGNU Image Manipulation Program（GIMP）で設計され、使用されていました。ある時点で、Peter MattisはMotifに夢中になり、GIMPツールキットと呼ばれる独自のGUIツールキットを書き始め、Motifを0.60リリースのGIMPに置き換えることに成功しました。[3]最後に、GTKはオブジェクト指向になるように書き直され、GTK+に名前が変更されました。これは、GIMPの0.99リリースで最初に使用されました。
これはobject-oriented paradigm、GTK（GTK +とは異なります）の言語を選択するための最も重要な基準ではなく、その機能がずっと後に追加されたことを示しているはずです。