新しいものを表示
orange さんがブースト

さっきも書いたけどそういうのは lookup とかそういう別名がちゃんと付けられるはずで,基本的に setter/getter ってただのフィールドアクセスだと思ってたのだけれども

orange さんがブースト
orange さんがブースト

100倍遅いのはデータ構造が悪いけど、でも getter の中身がフィールドアクセスとは限らない、例えば Dictionary のルックアップなこともあるでしょ?

スレッドを表示

メソッドでも軽いか重いかわかんないけどメソッドは重い覚悟をする(?)みたいな感じ?><; プロパティも同様に考えればよくない・・・?><

プロパティだと中味の処理が軽いか重いか、何らかの結果をキャッシュしたりしてるかしてないか、そういうのが不安というか、「プロパティの方が軽いことを期待しちゃう」みたいな意味かも・・・?><

orange さんがブースト

代入式が使えるプロパティより、 GetHoge, SetHoge メソッドの形式を推すのは、どちらにしてもメソッド呼び出しだからです。メソッドの契約は名前だけ(言い過ぎ)であって、内部の実装はなんでもいい、例えば通常の変数へのアクセスより、その getter のほうが 100 倍遅い可能性だってあるわけで、それをばんばか使われるわけには行かない。そういう意味で、メソッド形式であるべきで、呼び出した結果は、呼び出し元がしばらく持っておけと思うわけです。

GetHoge, SetHoge 方式だと、プロパティ方式よりもコンパイラがバグを見つけにくいかも?><

orange さんがブースト

プロパティ自体はあんまり好きじゃなくて、 GetHoge, SetHoge のほうが好きなんですけどね。メソッド呼び出し感があるので。それはそれとして自動実装プロパティは、 public メンバーとしてあるべき契約のあり方(つまり getter, setter。値を記録するストレージを隠蔽する)でフィールドを公開できるという点でうまい

orange さんがブースト

getter, setter が必要か、わからないから必要なのであって、そういう意味で自動実装プロパティというのは正解

orange さんがブースト

たとえば
*foo(a, b) += 1;
のような式は += がないと一時変数を用意することになってしまうので、そこはさすがに

AdaもPascalと同じく++とか+=とか無いっぽい><

orange さんがブースト

たとえば Rust でも ++ 演算子がなくて += 1 を使えみたいなデザインだったり、条件演算子がなくて if の値を使えという感じだったりして、あまり本質的でない拡張を言語機能から除外するというのはアリなのかなと最近は思っている

いまさら気づいたけど、単に32bit floatに変換だとDACも32bitじゃないとオーディオデバイスのドライバ内(?)で丸め誤差が出ちゃうけど、24bit-int on 32bit-floatに変換するようにすれば、一般的な24bit DACでも出口まで16bit精度を保てる・・・?><(ソフトウェアは作れるけど検証できる機材持って無い・・・><)

ハードウェア作るの大変そうだけど><;(計測機材でさえほとんど24bitっぽいのに><;)

MSが公式で64bit float入力対応DACを出したらさらにおもしろそう><

WindowsのWASAPIというかWindowsCoreAudio、どうせなら内部64bitモードにも対応したら世の中のオーディオマニアをぎゃふんと言わせられそうだけど、やらないのかな?><
(でも、その意味が理解できてぎゃふんといえるような人はそもそもオカルトに近いオーディオマニアにはならない説><;)

そういえば、前に書いた「16bitの音源をWASAPI共有モードで32bit floatに変換して再生する事で、WASAPI共有でもビットパーフェクトと理屈の上で同じ精度で再生できるプレイヤー><」って、かなり前にエンジン部分は完成してるんだけど、GUI作るのがめんどくなって放置されてる><;(ファイル選択すら無くてdrag and dropだよ!><;)

orange さんがブースト

音関連の処理が整数で計算してるのって、昔はDSPで整数ないしは固定小数点で扱うしかなかったからとかかな。

”のが特徴><”というか当然内部floatで作るのが制度を考えたらむしろ当たり前だと思ってたんだけど、わりとそうでもないことに気づいてわりとびっくり><(音関連のプログラマって、整数精度派(?)がかなり多いっぽさ><)

古いものを表示
:realtek:

思考の /dev/null