アカウント名:
パスワード:
曖昧な記憶なんですが、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)
> ではfloat×16の行列を多用するのですが,これはSSEへの最
> 適化のため16byteアライメントするように推奨されています.
> これをC#から使えるようにしたとき,Microsoftがライブラリ
> にどういう実装を行うかには結構興味がありますね.
> 個人的にはアライメント用の属性を作るんじゃないかと思って
> ます.
アライメントの指定すること自体は属性で簡単にできると思いますが、問題は仮想マシンをどうつくるかです。
ガーベージコレクションの対象となるヒープ空間上では、GC によってオブジェクトが度々 移動します。そのたびにアライメントを考えてデータの構造や大きさまでをも組み替える必要があります。これは骨ですよ。
特定のデータに特化する手法を用いる場合なら、float×16の行列を扱う専用のクラスを作ってやればよいと思います。ヘッダーが 8バイトだとすると、オブジェクトの大きさを32バイト固定にしてアライメントによって行列部を前に詰めたり、後ろに詰めたりすれば実装可能です。
# CLR も 8バイト境界を採用しているでしょうから、詰め方は 2パターンしかない。
任意のクラスに任意のアライメントを指定する場合は面倒になります。
私ならオブジェクト毎にアライメントに関する情報を持たせる方法か、オリジナルのクラスからアライメントを特化させたサブクラスを作成する方法のどちらかを取ると思います。
前者の場合、オブジェクト毎にアライメント用のフィールドを余分に持つ必要がありますしアライメント指定のない通常のオブジェクトのアクセスに余分なオーバーヘッドが掛かるので後者の方が効率はよいでしょう。
p.s.
まったくの余談ですが、float 型の配列の配列部は 8n + 4 となる境界に載るという、数値演算系の人からみると冗談としか思えないような JavaVM の実装があります。
# オブジェクトが 8 バイトアライメントに揃っていて、各オブ
# ジェクトは 8 バイトのヘッダー情報を持ち、配列の場合は配
# 列長をしめす領域が 1 ワード(4バイト)が余分についていて、
# その直後から行列のデータ部分がはじまる。
## ということは double 型の配列も 8n + 4 境界からはじまる?、
コンタミは発見の母