アカウント名:
パスワード:
C++BuilderとかDelphiは、そのうちMacOS X対応版が出ると予測しているのですが、いかがなものでしょうか？
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
にわかな奴ほど語りたがる -- あるハッカー
噂を信じちゃいけないよ (スコア:1, 興味深い)
Intel版のDarwinをソコソコ使えるようにするかもしれないけど。
AT互換機用MacOS Xが出たら (スコア:1)
軽そうだし、デザインもきれいだし。
移行する問題点は一太郎とAircraftが無いことか。
C++BuilderとかDelphiは、そのうちMacOS X対応版が出ると予測しているのですが、いかがなものでしょうか？
Re:AT互換機用MacOS Xが出たら (スコア:0)
いや、分かりませんけどね。
Re:AT互換機用MacOS Xが出たら (スコア:2, すばらしい洞察)
俺の乏しく一面的な知識(笑)の範囲では、Borlandが得意なのは別にコンパイラというわけじゃない、と思っています。
一緒にならんかもだが大昔にゃ、Turbo Pascal For Macなんてものも有ったわけだし。
また、Delphiについて言えば、はっきり言ってあれ、コンパイラそのものの質で飯食っているわけじゃないでしょう。
最適化ろくにやってないという噂(^^;も有りますし、またそんなに必要ないだろうなという推測もしたくなります。
必要ないってのは、コンパイルは「そこそこ」やっておけばいいのであって、それよりも
言語としての使いやすさとかそういう(下流じゃなく上流を向いた)方向を追求してるんじゃないかなと。
最適化を深く追求しなければコンパイルそのものの速度も稼げるでしょうし。(あの速さは圧倒的っす)
これ、CPU速度が上がった現代ならなおさら光る選択だと思っています。コンパイラとRADとを両立するっていうアレね。
#C++的な考え方で最適化をしようとすると、Delphiみたいなライブラリ間の動的結合を重んじる言語は、困るんだろうな。
それにJBuilderのようなPureJavaで飯食う(まだ言うか俺)ようなものを主力製品にしてるところからも憶測するに、
BorlandはCPUそのものに深く首突っ込む方向は(今は)目指してないんじゃないかと。
となると、x86以外のコンパイラを作ろうとする際も、その「そこそこのコンパイラ」路線で来る
んじゃないかな？と思ったり。
移植のコストは低めになるんじゃないかな？と。
余談：
今のOSXのAPIって、ObjectiveCベース、なのでしたっけ？
となるとC++よりDelphiのほうが少々相性が良いかもかも。
というか、APIセットと開発言語仕様とが直交たり得るのって、(高級アセンブラな)C言語までが限界だと思う。
そっから上(?)になると、API仕様を策定したときに使う言語と違う言語での開発は、どっかこっかに
意味論(?)的なインピーダンスミスマッチを引き起こすだろうな。
たとえばOOPにしても、OOPの実現形態は言語ごとに百家争鳴状態なのだから…
Re:AT互換機用MacOS Xが出たら (スコア:0)
ObjectiveC ベースな部分(Cocoa) は、API っちゃー
API ですが、アプリケーションフレームワークって
言ったほうが妥当でしょう。