アカウント名:
パスワード:
未だに Xt + Xaw でちょこちょこ小物を書いたりする人が言うのもナンですが。
GTK+「だけ」でアプリケーションが書けるのであれば別ですが、なんだかんだ unistd.h やらを #include したりすることが多かったりしませんか? Qt にしても同じで、Windows モノと本当に互換に作ろうとすると、Qt + ISO-C++ で書くことになる (VC++ の ISO 準拠度についてはここでは論じないものとしませう :-) わけですが、素人目で見る限り、そうそう簡単なことではないと思います。
I18N なコードがなかなか増えない事から察するに、理論上 Win/Unices 互換なコードが書ける事が即ち Win/Unices 互換なコードが増えることに直結するとは思いません (労力の節減にはつながるので歓迎はしますが)。
# なんだかんだで嫌いではあるけれど、現状では # Java 使うのが最短距離のような気がする。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
にわかな奴ほど語りたがる -- あるハッカー
先例で占おう… (スコア:3, 参考になる)
>非常に多くのX WindowアプリケーションがMac OS Xでネイティブアプリケーションとして動作させることができるようになるかもしれない。
GTK+とかって、Winには随分前から移植済み、でしたよねえ。
で、Winにおいて、X
Re:先例で占おう… (スコア:2, 参考になる)
未だに Xt + Xaw でちょこちょこ小物を書いたりする人が言うのもナンですが。
GTK+「だけ」でアプリケーションが書けるのであれば別ですが、なんだかんだ unistd.h やらを #include したりすることが多かったりしませんか? Qt にしても同じで、Windows モノと本当に互換に作ろうとすると、Qt + ISO-C++ で書くことになる (VC++ の ISO 準拠度についてはここでは論じないものとしませう :-) わけですが、素人目で見る限り、そうそう簡単なことではないと思います。
I18N なコードがなかなか増えない事から察するに、理論上 Win/Unices 互換なコードが書ける事が即ち Win/Unices 互換なコードが増えることに直結するとは思いません (労力の節減にはつながるので歓迎はしますが)。
# なんだかんだで嫌いではあるけれど、現状では
# Java 使うのが最短距離のような気がする。
Re:先例で占おう… (スコア:1)
MFCとは目的が違うし、libcの役割まで要求するのはナンセンス。
# rm -rf ./.
Re:先例で占おう… (スコア:1)
つまり、元コメントは「GUI toolkitだけが互換になっても、libcあたりが互換でないと互換ソフトは生まれにくい」って言ってるわけだが。
Re:先例で占おう… (スコア:0)
っていうのは、具体的にはどういう点を指してのことなんでしょうかね?(本気で質問してます)私がそれほどコアなプログラマじゃないからだと思いますけど、過去の経験から思うに、例えばIRIXとLinuxの互換性とかと比較して、Win2K/XPとそこいらのUNIXの(libc的なレベルでの)互換性がそれほど極端に低いとも思えないのですが
Re:先例で占おう… (スコア:1)
たとえば、unistdな関数って存在しなかったりするでしょ。
お行儀良くANSIな関数だけで書いてあるプログラムなら、あるいはうまく行くでしょうけど、それはいろいろ困難なわけでして。
> autoconfとかって何のためにあるの?っつー話もありますよねぇ。
根本のところがわかってらっしゃらないようですね。
autoconfは魔法の杖じゃないですよ。原理や使い方を見たらわかると思いますけどね。autoconfは「互換性を考慮したプログラムを書く手段」ではありますが、「それを使えば互換性はバッチリ」というものではありませんよ。
Re:先例で占おう… (スコア:0)
いや、ogochanが私の書いた意図をわかっていらっしゃらないようです。
>> autoconfは「互換性を考慮したプログラムを書く手段」ではありますが、
というのを知った上で書いたつもりです。つまり、「UNIX同士ですら、こういうものが必要なレベルでの互換性なわけでしょ?」ってことを言いたかったんですけどね。ま、現状だとreadlineとかcursesとかそれこそ(本題の)gtk,qt,tcl/tkとかのwidget周りまでautoconfで面倒を見ている場合もあるので、libc的互換性の話でautoconfを持ち出すのは反則気味か
Re:先例で占おう… (スコア:1)
そこまでわかってるんだったら、ますます元の意味の取り違いかと。
「UNIX同士ですら、こういうものが必要なレベルでの互換性でしかない。だったら、Windowsにtoolkitが移植されてもその互換性ってあんまり役に立たない」とは思わないです?
> 「このソースはLinuxで動いてるから、UNIX全般で動くはずだ」
そーゆー人には、黙ってemacsのコードでも読ませてあげればそれで十分かと。論より証拠ですよ。
Re:先例で占おう… (スコア:0)
全く思わないですね。だってUNIX同士でも非互換性を乗り越えていろんなソフトが移植されてるわけじゃないですか。「UNIX同士ですら、こういうものが必要なレベルでの互換性でしかない。UNIX同士での移植と似たような苦労でGTKアプリがWindows上で動くのであれば大歓迎」と思います。
というか、そもそもGIMPはすでに数年前にWindowsに移植されていた(正確にはGIMPの移植のた
Re:先例で占おう… (スコア:0)
>動くのであれば大歓迎
なんでUNIX同士での移植の苦労とUNIX->WINの移植が同じような
苦労と思うのか不思議。
似てるはず(互換性が高い)のUNIX同士で苦労があるなら、
似ていない(互換性が低い)Winとならもっと大変ってはなしでしょ?
Re:先例で占おう… (スコア:0)
苦労と思うのか不思議。
なんでUNIX同士の移植の苦労よりUNIX->WINの移植の方がそれほど大変と思うのか不思議。
>> 似てるはず(互換性が高い)のUNIX同士で苦労があるなら、
>> 似ていない(互換性が低い)Winとならもっと大変ってはなしでしょ?
ogochanが書いてたunistd.hだって、VCには「unistd.hという名前のヘッダ」が無いだけで、unistd.hに入っていそうな関数は別のヘッダに(場合によっては別の名前の同じ機能の関数が)存在することも多いわけで、
Re:先例で占おう… (スコア:1, 参考になる)
> 自分は別OSへの移植作業なんてしたことないクセに
> 聞きかじった話だけで書いてるんだろうなぁ...
私も昔は先入観で超えられない壁があると思っていましたが、
実際にやってみると想像以上にWindowsはUNIXに近くて
拍子抜けした記憶があります。
GUI周り?やっぱり書きな直ししかないっす。(泣)
マルチプラットフォームツールキットだと
OSの標準的UIから外れることが多くて、
特定用途向けのニッチなら便利とは思いますけど、
一般ユーザーを対象にはできないという結論に達しました。
WindowsではMFCかWinForms、UNIXではGTK+、MacではCocoaを使って、
残りの部分でいかに共通化するかって古典的な世界。(号泣)