議論/言語乗り換え


Top / 議論 / 言語乗り換え

議論/言語乗り換え

言語dynamic castGCC言語APIC++APIライブラリDLL化@Mona移植性アプリサイズ※
C++未実装なし問題なし
Java (gcj)実装済あり煩雑なCNI問題あり×
D (gdc)未実装ありお手軽×問題なし

※Cやアセンブラと比べて

項目リンクリーダー
gcj の研究公開ハック/200610Tinoさん
BayGUI のリライトここbayside

コメント

最新の1000件を表示しています。 コメントページを参照

お名前:
  • gccがサポートしていて、Cの完全上位互換でgcc-4.1.1ならC++とも混ぜ書き出来るオブジェクト指向言語ならあるけど? -- Yume 2006-10-05 (木) 16:53:07
    • ついにObjective-C++がマージされたということでしょうか? -- Tino 2006-10-05 (木) 17:26:58
    • NEWSファイルを読んでみたら追加されたって書いてありましたよ。 -- Yume 2006-10-05 (木) 17:33:24
    • なるほど、知りませんでした。夢が広がりますね。 -- Tino 2006-10-05 (木) 17:39:18
  • 私の意見ですが、baysideさんがみんなを引っ張るのが良いと思います。俺について来い、と(w。それはともかく、私はgcjへの乗り換えに賛成なので、乗り換えに成功すれば、MonaFormsのアプリを移植して、MonaFormsを廃止できる状態にしたいと考えています。それから上の言語比較表で、C++APIについての項目があると良いと思います。 -- Tino 2006-10-05 (木) 08:37:31
    • C++APIの列を追加しました。 -- bayside 2006-10-05 (木) 11:31:41
    • ありがとうございます。 -- Tino 2006-10-05 (木) 13:41:10
    • お二人の認識を理解できた上で考えたのですが、Tinoさんが指摘されている通り、やはりどちらか一方が音頭をとった方がうまくまわるように思います。 -- ひげぽん 2006-10-05 (木) 13:49:06
  • 質問はここでよいでしょうか。?BayGUI言語乗り換えの首謀者って誰でしょう?baysideさん?Tinoさん?。質問の意図としては今後だれが中心にメンテナンスをしてくれるのかなというのが気になったもので。 -- ひげぽん 2006-10-03 (火) 21:14:11
    • 言語乗り換えと全然関係ない方向に話が行っていますよね・・・。自分が知りたいのは BayGUI を実際に使っている方たちの意見なんですけどね・・・。BayGUI のリライトに関しては私です。それ以外は Tino さんになると思います。 -- bayside 2006-10-03 (火) 21:34:23
    • この辺りの意識がみんなと合っているか、再確認が必要な気がします。誰が何のために何をするのか。首謀者は誰なのかとか。とりあえずその確認だけでも舵取りをお願いできませんか?>baysideさん -- ひげぽん 2006-10-03 (火) 21:40:54
    • ちなみに言語乗り換え自体は面白そうなので、そのあたりがクリアになればぜひすすめてほしいです。 -- ひげぽん 2006-10-03 (火) 21:46:05
    • 僕の理解をまとめます。以下のように理解しているのですがあっていますでしょうか。>baysideさん、Tinoさん -- ひげぽん 2006-10-04 (水) 23:55:03
      • baysideさんは、「言語を乗り換えるべきか迷っている」「選択肢としては乗り換えない、C++とGC, Java, Dなどを考えている」という状態で公開ハックにのぞむ感じ。
      • Tinoさんは、「baysideさんの言語乗り換えをサポートしようと考えている」「BayGCと書く、もしくはD方向辺りが良いのではないかと思っている」という状態でハックに望む感じ。
      • はい。 -- Tino 2006-10-05 (木) 08:33:04
      • はい、あっています。 -- bayside 2006-10-05 (木) 11:26:05
      • 回答ありがとうございました。 -- ひげぽん 2006-10-05 (木) 13:47:40
  • 【業務連絡】以下→公開ハック/200610に移動しました。
  • Monaの過去の遺産を引き継がない精神でいけばDや新言語をどんどん取り入れてくべきじゃないと考えてますが -- 350N? 2006-09-28 (木) 23:37:33
    • Mona自身に過去の遺産があるのですよ。たとえば350Nさんが作ったアプリが次のバージョンで動かなくなって、しかも別の言語で書き直さないといけなくなったら、どう思いますか? -- Tino 2006-09-28 (木) 23:49:13
  • 私はC++に拘っているように見えるかもしれませんが、ぶっちゃけ、C++や既存のアプリに拘るのはMonaのポリシーである「Monaはなるべく過去の負の遺産を引き継がないように努めています。」に反するのではないかという気持ちがあります。当時はC++が先進的なイメージだったかもしれませんが、状況は日進月歩なので、この機会に見直すのもアリだとは思います。そういう意味で、私はD言語に反対しているわけじゃないのです。単にgcjだったら手伝えそうだということを言っているのに過ぎません。 -- Tino 2006-09-28 (木) 12:52:52
  • 懸案事項は http://caffe-latte.sourceforge.jp/pukiwiki/index.php?JMona%2Fpending にまとめてあります。 -- bayside 2006-09-27 (水) 16:21:20
    • (ageました)当時私がJMonaでやりたかったことは、どこまでカーネルにgcjが使えるかという、gcjの限界を見極めるということでした。そのためMona本流とあまり関係ないので、フォークが妥当だという判断をしました。今回問題になっているのはユーザー側のことで、フォークとか関係ないですから、こちらで続けたいと思います。 -- Tino 2006-09-28 (木) 12:13:35
    • 懸案事項にお答えします。スレッド&DLL⇒gcjを使う気持ちがまだあるということでしたら、一緒に研究しましょう。共有メモリ系⇒生ポインタをフィールドに保持するためgnu.gcj.RawDataというクラスが用意されています。これを使えばビット依存のint変換を避けることができます。GUIでの共有メモリということはウィンドウバッファを指していると思いますが、setPixel()など直接触る部分だけCNIに追い出せば問題ないでしょう。 -- Tino 2006-09-28 (木) 12:36:16
    • CNI を使えば、Java のいいところを全部使えて、いままでどおり C++ で書けるし、delete からも解放されるという理解であっていますか?gnu.gcj.RawData クラスを使えば、確かにずっとスマートに書けそうですね。 -- bayside 2006-09-28 (木) 14:25:53
    • はい、私はそのように理解しています。ただそのような過激なCNIの使い方は見たことがないので、色々と実験しながら確認していくことになるでしょう。 -- Tino 2006-09-28 (木) 16:27:11
  • そもそもC++のクラスを他の言語から扱おうとする事自体無謀じゃないのかと。gccのバージョンの違いですらABIが違うのに。 -- Yume 2006-09-27 (水) 17:24:55
    • gcjに関してはgccで公式にサポートされていてC++の仕様変更にも追随するので(というかマングリング規則がC++と同じ)、再コンパイル前提であれば利用者が仕様変更を意識する必要はないです。 -- Tino 2006-09-28 (木) 09:54:15
  • baysideさんに質問です。純粋に疑問なのですが、gcjではなくgdcを選択した理由を教えていただけないでしょうか?私がgcjをお勧めしている理由の一つとして、従来のC++のアプリも言語書き直しをせずにC++のままで使いまわせるという理由がありますが、この件についてはどうお考えでしょうか? -- Tino 2006-09-27 (水) 15:19:11
    • gcj で C++ のまま使いまわせるというのがよくわからないのですが・・。JMona で gcj を使った感じでは、C や C++ を使うための JNI が非常に面倒くさく、配列は配列のまま、C言語の関数もそのまま呼べる gdc に興味が湧きました。あと、gcj が DLL 化できなかったのも要因の一つです。 -- bayside 2006-09-27 (水) 15:22:15
    • ライブラリはJavaで書いても、アプリはC++で書けるということです。ArrayList* list = new ArrayList();list->add(new Object());のようなコードをC++で書くことができます。そのため従来のC++のアプリも言語を書き換えずにC++のまま、若干の修正(delete削除等)だけで再コンパイルすることが可能です。これはJNIではなくCNIだからこそ可能な技です。 -- Tino 2006-09-27 (水) 15:39:31
    • 確かにD言語の中に直接C言語の関数呼び出しなどを含めることができるので、その点ではD言語の方が有利です。しかしC++の資産を使うことを考えると、D言語から直接C++のクラスには触れないので、どうしても使う場合はextern "C"付きで作ったC++の関数を通して使うことになるはずです。この点、CNIで別ファイルに実装するgcjの方が、面倒かもしれませんがまだましなように思えます。 -- Tino 2006-09-27 (水) 15:59:38
    • そもそもgcjを使えばアプリはC++で書けるため、Cの関数を使いまくりたいアプリの場合は、アプリをC++で書いてC言語もJavaも両方呼ぶことができます。これはgcjの有利な点です。また、アプリをC++で書いてJavaを使う場合、ArrayList* list = new ArrayList();のようにしたlistにはGCが働きます。 -- Tino 2006-09-27 (水) 16:01:15
    • DLL化はWindowsでできているので、原理的にMonaでもできるはずです。当時は私はMonaの実装に手を出さないという方針だったので、わざと手を付けませんでした。 -- Tino 2006-09-27 (水) 16:04:04
  • 私はD言語は良く知らないのですが、BayGUIがD言語に移行するのを機会に、私含めてみんなでD言語をお勉強というのもアリかなという気はします。とりあえずgdcでちょっとつついたところ、Phobosに依存しないレベルならD言語は使える状態にはなりましたが、Yumeさんによると「Phobosが使えない限りD言語はC以下ですよ」とのことなので、微妙です。D言語大作戦をやるのであれば、ぜひともプロジェクトリーダー(?)をYumeさんにお願いしたいですね。 -- Tino 2006-09-27 (水) 13:09:59
    • BayGUI程度なら gdc の成果でも十分いけそうな気がします。sms_gc はスレッドに対応していないと聞いたことがあるのですが、スレッドにするとどの辺りに不具合が出るのかはちょっと気になりますが。それと、Phobos を移植するとなると、Mesa の時と同様 DLL が巨大になりすぎて、FD に入らないのも心配しています。 -- bayside 2006-09-27 (水) 15:07:00
    • マルチスレッドでsms_gcを使う場合、サブスレッドではnewを一切使えないという制約が付きます。ちょっとでもnewしたらアプリが落ちる危険があります。この辺の仕組みや対策は私が勝手に考えるよりも、baysideさんと一緒に考えた方が良いという気がします。 -- Tino 2006-09-27 (水) 15:23:58
    • 「BayGUI程度なら gdc の成果でも十分いけそうな気がします。」とのことですが、調べたところinstanceofに相当するのはcast()のようですが、これはPhobosを移植しないと使えないようです。 -- Tino 2006-09-27 (水) 15:55:43
    • そうなんですか・・・。残念・・・。たかが cast されど cast ですね・・・。 -- bayside 2006-09-27 (水) 16:06:44
  • C++でsms_gcを使う実験をしたところ、_P以上に扱いが厄介だという結論になったのでまったくお勧めしません。詳しいことは⇒MonaForms/sms_gc -- Tino 2006-09-27 (水) 12:46:31
  • gcjで書いていただくと嬉しいです。今回の選択肢に入っていませんが、足りない部分などあればサポートします。gcjで書くと今までのC++で書かれたアプリも、deleteを削除するなど簡単な修正で、C++のままJavaに書き直さずに再コンパイルできるので、従来の資産の活用と言う観点からも望ましいです。 -- Tino 2006-09-27 (水) 12:44:52
    • D言語のことに言及してから気が変わりました。もしYumeさんがD言語を引っ張っていただけるなら、私が中途半端な知識でgcjを振りかざすよりも好ましいのではないでしょうか。アグレッシブ(ひげぽんさんの言う「攻め」)なイメージとしては、D言語の方が良いかもしれません。 -- Tino 2006-09-27 (水) 14:35:11
  • どういう意図の作り変えでしょうか。設計からまるごと作り直しなのか、現バージョンの延長線上でAPIはほぼ変わらないとか。 -- ひげぽん 2006-09-26 (火) 21:52:40
    • API 自体はほとんどかわらないです。方向としては BayGUI/rewrite の続きです。いちいち delete 書きたくないのと、instanceof を使いたいなぁというのがありまして・・。 -- bayside 2006-09-26 (火) 22:03:20
    • なるほど。ところでdynamic castやinstance of に拘られているようですが type tag を使ってましたっけ。BayGUIの規模であればtype tag である程度カバーが出来そうな気がします。 -- ひげぽん 2006-09-26 (火) 22:57:18
    • type tag というのは これ の type() のことですか?ええと自分がやりたいのは、そのオブジェクトがあるインターフェースを実装しているかどうかが知りたいのです。こんな感じです。しかしこの方法でも、インターフェースを実装するときは各クラスで instanceof の上書きをしないといけないんですよね・・。そういう意味で設計が汚いということです。 -- bayside 2006-09-26 (火) 23:20:52
    • なるほど、instanceofの上書きが必要=設計が汚いなのですね。 -- ひげぽん 2006-09-26 (火) 23:26:28

MENU

now: 2

リンク


最新の20件
2018-10-07 2018-09-20 2018-09-03 2018-05-09 2017-09-29 2017-01-10 2016-12-11 2016-10-04 2016-08-14 2016-05-29 2015-12-28 2013-02-25 2013-02-21 2013-02-20 2013-02-12 2013-02-11 2013-02-10
最新の20件
2010-02-01 2010-01-31 2010-01-30 2010-01-29 2010-01-16

Counter: 3866, today: 1, yesterday: 0

リロード   新規 編集 凍結 差分 添付 複製 改名   トップ 一覧 検索 最終更新 バックアップ   ヘルプ   最終更新のRSS

Last-modified: 2008-03-28 (金) 15:48:03 (3859d);  Modified by mona
PukiWiki 1.4.6 Copyright © 2001-2005 PukiWiki Developers Team. License is GPL.
Based on "PukiWiki" 1.3 by yu-ji
Powered by PHP 5.2.17
HTML convert time to 0.082 sec.