アカウント名:
パスワード:
曖昧な記憶なんですが、C#を設計した人って、Delphiを設計した人と同じじゃありませんでしたっけ。言語としては非常に素晴らしい出来だ、とその方が自信を持っているという話を聞いたことがあります。
...そろそろ.NETもさわってみようかなぁ。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲはアレゲを呼ぶ -- ある傍観者
結構使える (スコア:4, 参考になる)
言語としてもよく考えられていると思うし、開発効率もいいし。
自分はC, C++, DelphiといろいろとやったのですがDelphiがRADとして比重を置いていますがC#はC,C++の中間みたいな感じで非常にバランスよく感じます。
自分が公開しているソフトもC#で書かれたものがありますが……。
あまり見かけないですがどのくらいの人が
Re:結構使える (スコア:2, 興味深い)
曖昧な記憶なんですが、C#を設計した人って、Delphiを設計した人と同じじゃありませんでしたっけ。言語としては非常に素晴らしい出来だ、とその方が自信を持っているという話を聞いたことがあります。
...そろそろ.NETもさわってみようかなぁ。
C# の言語 設計者は James Gosling なのでは... (スコア:3, 参考になる)
僕が検証したところ文法だけ見て C# が Java と根本的に違うのは 5点のみ。
多次元配列の存在、primitive 型(C# では predefind 型)の call by reference、unsafe 構文の存在、check/uncheck、goto 文。
あと小さな違いとしては decimal 型とか、文字列定数の書き方とか、文字列を case にした switch 構文の存在とか。
残りは糖衣構文(syntax suger) のある/なしだと思います。
# 糖衣構文というのは、同じ書き方がもっと基本的な構文の
# 組み合わせで書けるの
コンタミは発見の母
Re:C# の言語 設計者は James Gosling なのでは... (スコア:0)
あと、理論的な根本的違いは多くないかもしれませんが、現実として大きく異なってくる部
Re:C# の言語 設計者は James Gosling なのでは... (スコア:1)
私自身が .NET framework については学習中なので何かを言えるレベルには達していません。
# でも デジャビューの連続なのですが...
> あと、大きく違う部分としてユーザ定義の値型struct(C++のそれとは全く異なる)、
> これを入れないでどうしますか
あ、struct を書き忘れていました。でも概念的には C++ の struct そのものですよ。ポインタが取れないことを除いては。
私自身、C# の仕様を一読したときに "struct" を見つけた時には感激したものです(*1)。ただ struct は参照がとれない制限や、固定長であっても配列
コンタミは発見の母
スタック割り付け (スコア:0)
escape analysis (スコア:1)
unsafe はユーザー責任とはいえ、GC のある言語で dangeling pointer なんぞ作られたらたまりません。デバッグ不能です。
# でも似たような機構を realtime Java の仕様で見たことがあるような、ないような。
セキュアなスタックアロケーションをやるためには C# の struct のように制限をもうけてやる方法以外に、コードを解析することによ
コンタミは発見の母
Re:escape analysis (スコア:0)
うーん,そこまで言われると困りますなぁ.
いまこの場での議論でC#の規格を決められたらいいのですが.
で,まずは「stack allocation によるパフォーマンスの改善(可能性)」から「デバッグコスト」へと話題が増えてますしね.
私から見れば「dangeling pointer なんぞ作られたらたまりません」な人も「stack allocation によるパフォーマンス改善」を望む人もわりと他人事なので,何書いてもそれなりに妥当な返答が返ってくる当事者の方か
Re:escape analysis (スコア:1)
> のかですかねぇ.
> 私が配列ベースで作業する場合は,記述性から Fortran とか
> Mathematica 使いますから.
C# の場合、多次元配列がはじめからあるので FORTRAN のプログラムをそのまま MSIL に変換してしまっているのではないでしょうか?
プログラムを一つのクラスとして、共通ブロックはグローバルなクラス変数、プロシージャ・変数を static メソッドとして置換すればよいと思われます。
無論、問題は最適化。
ループ最適化など高レイヤーの最適化は中間言語レベルでもある程度有効だと思いますが、software pipeling 等の命令レベルの最適化はレジスタが見えないとほとんど無理です。
# 少なくとも私は書けない。手袋を着けた状態で盲牌するようなもの。
CLR 側の JIT コンパイラは、売り物のコンパイラと比べると簡単な最適化しか入っていないようです。また、FORTRAN が相手にするようなプログラムだと JIT のメリットはそんなにありません。AOT コンパイルをじっくりやった方が特です。
# FORTRAN77 は virtual function call 以前に recusive call すらないので、
# 静的にコントロールフローグラフがきっちり書ける。
# 条件分岐もループ由来のものが多いので分岐方向は予測可能。
実際に Lahey/Fujitsu Fortran for .NET [lahey.com]のパフォーマンスに関する問言は非常に控えめです。ただ、native code に変換してしまう機能があるようなので、そちらを使えば従来と同様のパフォーマンスが出るのではないでしょうか?
p.s.
余談ですが、FORTRAN はコンパイラに演算の実行順序を入れ替えるような最適化を認めているので、浮動小数点演算ユニットが IEEE754 に準拠していたとしてもコンパイラによって計算結果が異なることがあります。
一方、Java は "Write Once, Run Anywhere" を掲げて、浮動小数点が誤差のレベルまで一致させんという高邁な理想を持っています。多次元配列がないのも痛いのですが、コンパイラ最適化の多くが禁止されるのがさらに痛いです。
売り物の FORTRAN for JavaVM が出ない理由の一つですね。
コンタミは発見の母