アカウント名:
パスワード:
そんなに使いづらいかな。Cでオブジェクト指向をやるってのは面白いアプローチだと思った。
タレコミに> 本家/.ではGObjectの使いづらさとありますが,これ誤読です.
元のコメント(の前半)は,大雑把にまとめると
c++とか objective-c 等の言語がすでにあるのに,わざわざCでオブジェクト指向な実装を行う方針がそもそもの間違い.なぜなら,Cで無理やりオブジェクト指向な実装を行うとGObjectのようなマクロを駆使した変態的実装が不可避になり,次の2つの問題が発生するから.- コーディングが大変.苦痛でしかない- コンパイラによる最適化が期待できない.ビルドしたバイナリの質は低く,動作速度も遅い.GNOMEの開発陣って,センス
> - コンパイラによる最適化が期待できない.ビルドしたバイナリの質は低く,動作速度も遅い.
むかし COBOL のプログラムを C に変換してからコンパイルする処理系で出来上がった実行ファイルが激おそだったときがあった。
このシステムは某日本メーカの UNIX だったけど同じ処理系の Solaris 版で同じ COBOL プログラムをコンパイルすると某日本メーカの UNIX と比べてはるかに早くなった。
普通の C プログラムだとどっこいの性能がでたので原因は某日本メーカ製 UNIX の C コンパイラの最適化が機械生成されたプログラムに対応してなかったのだろうと思う。
何がいいたいのかというと、C コンパイラ側がGObject を考慮した最適化を行うようにしたら性能が改善する余地があるんだろうか?という話。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
犯人はmoriwaka -- Anonymous Coward
GObject (スコア:2)
そんなに使いづらいかな。
Cでオブジェクト指向をやるってのは面白いアプローチだと思った。
Re: (スコア:2)
タレコミに
> 本家/.ではGObjectの使いづらさ
とありますが,これ誤読です.
元のコメント(の前半)は,大雑把にまとめると
c++とか objective-c 等の言語がすでにあるのに,わざわざCでオブジェクト指向な実装を行う方針がそもそもの間違い.
なぜなら,Cで無理やりオブジェクト指向な実装を行うとGObjectのようなマクロを駆使した変態的実装が不可避になり,次の2つの問題が発生するから.
- コーディングが大変.苦痛でしかない
- コンパイラによる最適化が期待できない.ビルドしたバイナリの質は低く,動作速度も遅い.
GNOMEの開発陣って,センス
Re:GObject (スコア:2)
> - コンパイラによる最適化が期待できない.ビルドしたバイナリの質は低く,動作速度も遅い.
むかし COBOL のプログラムを C に変換してから
コンパイルする処理系で出来上がった実行ファイルが
激おそだったときがあった。
このシステムは某日本メーカの UNIX だったけど
同じ処理系の Solaris 版で同じ COBOL プログラムを
コンパイルすると某日本メーカの UNIX と比べて
はるかに早くなった。
普通の C プログラムだとどっこいの性能がでたので
原因は某日本メーカ製 UNIX の C コンパイラの
最適化が機械生成されたプログラムに対応して
なかったのだろうと思う。
何がいいたいのかというと、C コンパイラ側が
GObject を考慮した最適化を行うようにしたら
性能が改善する余地があるんだろうか?という話。