アカウント名:
パスワード:
いまのところWindowsの模倣なんだから開発言語も模倣すれば よかったのに。言い古された意見ですが。
COOLと言ってみるテスト(Bonoboと言ってみるテスト、 でもいいんだけど)。
格好いいですか? closureあたりはどう書く/使うのか知らないけど、単にひとつのクラスを書くだけでも (Gtk+-1.xとあまり変わっていないみたいですね) 手で書くコードが 多すぎて [dunkelhain.de] 萎えてしまいますわ。C++で 無理矢理reflection [garret.ru] があまり面白くないのに似た気分。
XXX言語で出来そうにないことをやってのける、ってのが面白いという意見には同意なんですけど、COOLやGObjectさんは手で書くコード量が多すぎないですか。 俺閾値超えちゃってます。面倒だしバグ入れそうだしうーん。 C言語の限界を越えたというよりはC言語の限界を改めて見せつけられているだけに思えてしまいます。
出来そうもないことをやってのけ、かつコード量も減るっていう方が個人的には格好いいです。例えば C++ だけど Boost Lambda Library [cppll.jp] とか。
# CでOOは勘弁してくれと言っているだけな気もするけどID
単にひとつのクラスを書くだけでも (Gtk+-1.xとあまり変わっていないみたいですね) 手で書くコードが 多すぎて 萎えてしまいますわ。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
にわかな奴ほど語りたがる -- あるハッカー
プラットフォーム非依存GUIアプリ (スコア:1, 参考になる)
できるだけソースそのままでwin32でも動いて欲しいのです。
現状のgnomeでそれは可能なんでしょうか?
それとも、gtk+のレイヤまで落とさないとだめでしょうか?
それとも、linuxのGUI tool kitでwin32にそのままport可能な他のよい手段はあるでしょうか? (C, C++で)
Re:プラットフォーム非依存GUIアプリ (スコア:2, 興味深い)
ツールキットの選択も重要だが、フォント命名規則やフォントメトリクスの非互換の方がはるかに問題が大きい。
またツールキット+標準ライブラリで事足りるような場合はともかく、OSの機能をある程度利用
Re:プラットフォーム非依存GUIアプリ (スコア:0)
そんなときに、「ポリモルフィズム [google.com]」。
Re:プラットフォーム非依存GUIアプリ (スコア:0)
それをC言語でやる方法を教えて。
Re:プラットフォーム非依存GUIアプリ (スコア:1)
いまのところWindowsの模倣なんだから開発言語も模倣すれば よかったのに。言い古された意見ですが。
Re:プラットフォーム非依存GUIアプリ (スコア:1)
Re:プラットフォーム非依存GUIアプリ (スコア:1)
げ。最近はそこまで濃ゆいことやってるんですか。
かっこいい。RTTIだの動的Load型だのClosureだのをサラリといってのけるとは…
ただまあ、そこまで重装備(?)でなくても、それこそ関数ポインタというか、関数ポインタの配列へのポインタというか、
そういうのが有るだけでもだいぶ色々と良いですね。
#関数ポインタを各Instanceに持たせるのが馬鹿らしいので、クラス(?)1つ毎に1箇所だけで関数ポインタ配列を抱える。
#で、そう考えると、Delphiに有るようなクラス(static)メソッドの多態も、別に難しい概念じゃないことに気付く…はずなんだけどなあ>C++、java
あとは、ちょっと遅くても我慢するなら、ポインタ配列じゃなくポインタHash表にすると、色々遊べます(^^;
#Hash表の実装は(全然知識が無くても:俺だな)作法本を読めばなんとかなるかと。
Re:プラットフォーム非依存GUIアプリ (スコア:0)
Re:プラットフォーム非依存GUIアプリ (スコア:2, すばらしい洞察)
>
>げ。最近はそこまで濃ゆいことやってるんですか。
>かっこいい。RTTIだの動的Load型だのClosureだのをサラリといってのけるとは…
格好いいですか? closureあたりはどう書く/使うのか知らないけど、単にひとつのクラスを書くだけでも (Gtk+-1.xとあまり変わっていないみたいですね) 手で書くコードが 多すぎて [dunkelhain.de] 萎えてしまいますわ。C++で 無理矢理reflection [garret.ru] があまり面白くないのに似た気分。
XXX言語で出来そうにないことをやってのける、ってのが面白いという意見には同意なんですけど、COOLやGObjectさんは手で書くコード量が多すぎないですか。 俺閾値超えちゃってます。面倒だしバグ入れそうだしうーん。 C言語の限界を越えたというよりはC言語の限界を改めて見せつけられているだけに思えてしまいます。
出来そうもないことをやってのけ、かつコード量も減るっていう方が個人的には格好いいです。例えば C++ だけど Boost Lambda Library [cppll.jp] とか。
# CでOOは勘弁してくれと言っているだけな気もするけどID
Re:プラットフォーム非依存GUIアプリ (スコア:1)
だからと言って即Cステということにはならないと思うのですが。GNOMEの目標の一つにlanguage bindingsを用意して様々な言語から利用できるようにするというのがありますけど、そうなると.NET CLIとかParrotみたいなものを別にすれば、現状では選択肢はCとC++くらいしかなくなりますが。
ちなみにGObjectの効用の一つはlanguage bindingsのglue codeを書く手間が省けることで、その辺りの説明はWrap GObjects in Python [ibm.com]に出ています。