C言語なら俺に聞け 154
■ このスレッドは過去ログ倉庫に格納されています
>>129
ARMのCPUでアラインメントの整合を怠ったら
偶数番地/奇数番地か、その2倍のアドレス値だったか
データの半分しか書き込まれなくて…って事態を目撃したことがある。
素朴なビットマップグラフィックのプログラムだったので
画面がシマシマになるのが文字通り目で見えた。
同じソースをx86系で実行すると期待通りの結果になるんだよ。 >>130
>>133
// x64 linux
volatile int x[2];
int main () {
asm("pushf");
asm("btsl $18, (%rsp)"); // set AC
asm("popf");
// *(int*)((char*)x+1)=1; // SIGBUS
asm("pushf");
asm("btrl $18, (%rsp)"); // clear AC
asm("popf");
return 0;
} >>135
130です
130のように書くとバスエラーがなければ ip を破壊する可能性が高いし、最適化でコードが生成されないためのケアもされていて思慮深いコードですね…
しかしGASのオベランドは逆に見えてしまって… やはりアセンブラの領域にまで踏み込まないと無理なんでしょうね >>138
本当ですか？
二方向以上への再帰をループに起こせる自信は私にはありません 枝分かれするとき、「今は進まない」方向を待ち行列に並ばせておいて
あとで対応しにくればええやん 複数関数をまたがる再帰
関数コールがたくさんの箇所で行われる
こんなヤツだとループにするのは非常にメンディー
可能ではあるけど クイックソートの非再帰実装とかあちこちに転がってるから勉強しとけ。
待ち行列じゃなくスタックな。 >>144
キューでも再帰実装できるし別に良くね？ >>148
太い枝から積んで順にやってけばええんやで 一般的には
パラメーターとローカル変数とコール位置
などの情報をスタックに積んでいく
機械的にやるならこれしかない
ほぼ再帰と同じ処理になる
機械的にやらないなら場合によっていろいろな方法がある >>149
太い枝の意味が分からんが、処理の順序が変わってしまうような変更はダメじゃね？
元の再帰のコードが必ずしもその太い枝の順とは限らないし、そもそも木構造とは限らないだろう。 再帰の代替なら素直にスタックでやった方が楽だよな。ポインタ１つで済むし 再帰ではスタックを使うからって
そこで脳硬化症にかかると。。。 本物の再帰を実現可能なマシンなんて存在しない
全部はスタックに還元するしか無いんだから
再帰だなんだと騒いでも結局現行のスタックやアドレスでどうにかなるじゃん
本当に再帰でしか書けなくなるのは本物の再帰を実行可能な再帰マシンが出来てからの話 >>156
よく分からないんだけど、本物の再帰ってどういうもの？
スタックが有限だということを除いて、今のC言語の再帰関数の実現方法と本質的には何が異なるの？ 再帰ソムリエの俺からすれば疑似再帰など下の下
本物再帰こそコードに埋め込まれるに相応しい
芳醇な香りと甘酸っぱい味わい たとえ64bit空間（16EiB）でも「真の」再帰はできんぞ？
どこかで必ず再帰を諦めるかクラッシュする可能性が排除できない 俺、斎藤再帰、17歳
今日も玄関から出続ける登校が始まるぜ！
エンドレスナイト！ >>160
真の再帰ってなんですか？160がどくじにかんがえたさいきょう再帰ってことでいいですか？ >>172
必ず再帰を諦めずクラッシュしないという定義が>>160に書かれてあるように、オラには見える。 赤い目を光らせて再起動
I will be back! どっちかつーと溶鉱炉で自分で自分を吐いているT-1000の姿が再帰に近いだろう お前ら再帰してるときのプログラムの気持ち考えたことあるの？
俺はある
ちょっと恥ずかしいんだよな、自分を省みるみたいで 俺はCPUの気持ちになってるよ。
「ちょ、おま、いまのとこほっといて、またそっち行くわけ？」
「え、戻れるように退避してる？ならいいけど……」
みたいな。 結んでいたはずの命綱をたぐり寄せると全部手元に来てしまったｗ AIは兵士をメカで作らない。たぶん生物兵器であろう。
ターミネータは嘘っぽい。エイリアンの方が本当っぽい。 c言語で書く金融アプリケーションの事例がいくつか知りたいのですが！ >>187
金融なら、Haskell・OCamlでC言語ソース生成くらいグリグリやってんとちゃう？ >>187
疑問文なのに何で末尾に！を付けるの？
質問していると言うよりクレームつけてるみたいだなw 4GLとか使って「COBOLの範疇」で書いたつもりになってるやつらが
縁の下の力持ちを知らないのか無視しているのかどっちでもいいが
悪いが鼻で笑わせてもらってたね
俺が見てた事例ではCじゃなくアセンブラだったが 元来、俺はそんなに皮肉屋じゃないはずなんだが
連中の上から目線がそうさせていた いや、まあ、CでCOBOLコンパイラ作る事は可能だろうけどね。 何十年か前、ＧＣCをベースにシステムを作った金融サイトがあることはある
GPLに触れないようライブラリは全部自前で用意してた
端末、サバクラのやり取り、サーバー間のデータ交換、全部Cで作ってた みなさんありがとうございます
(googleもみると）あるにはありそうな気もするけど
やっぱあまりよくないのかな。強烈に速度がほしい。 一方でIoTや組込的な決済プログラムは結構あるそうな。
C言語は安心して使えるから好きなんだよね。 業務アプリケーションまで持って行くのが割と大変だと思う
例えばお金の計算させるにしても、概算で良いなんてことは普通無いし
そのライブラリ作っても、信頼性の検証もしないと行けなくなる
預金システムなら、安全堅牢なファイルシステムも工夫しないといけない
趣味や学習として作る分にはとても興味深いものがあるけれど
実用するには、それを得意とするミドルを利用する方が無難だと思う >>202
＞お金の計算させるにしても、概算で良いなんてことは普通無いし
今は uint64_t があって、ほとんどカバーできますよ なにそのトンチンカンな発言
足し算引き算しかしないと思ってるの？ 1844京6744兆0737億0955万1615円まで扱えるなら
全人類の富を表現できるけど
10銭が循環小数になっちゃ困るね 10銭を1単位にすりゃいいんじゃね？
表現できる最高金額が1桁減っちゃうけど じゃあ1銭は循環小数でいいのかって話
きりねえだろ >>208
じゃぁ今現在のシステムではどうなってんの？ >>209
１０進数で計算するんだよ、２進数じゃなく >>211
そうじゃない
例えば円を単位としたとき小数点以下何桁まで保証してるのかって話 >>212
それは場面場面で色々だ
任意精度演算ってやつ >>213
はぁ？
きりがないんじゃなかったのか？ 一銭二銭、あるいはそれ未満を扱うのなら、uint64_t を固定小数点で使えばいいだけでしょうね
>>205
＞足し算引き算しかしないと思ってるの？
お金の計算なんて 9 割が加減乗除で済むのでは？
お金の計算で特に必要で特別な計算ってなにかありますか？ >>211
10進で計算しなければならない、その必要性はなんですか？ >お金の計算で特に必要で特別な計算ってなにかありますか？
複利計算で累乗 >>215
例えば複利計算とかなら小数の計算の精度を厳密に規定しないと問題になるはず。専門外だから詳しくは知らないが、法律か金融機関ごとにでも決められているんだろう。
お前みたいにお金の計算はお小遣い帳をつけるくらいにしか使わないなら整数だけで問題ないだろうけど。 古い言語なのに意外と10進演算ライブラリとかもないですよね
個別に作ってるだけかもしれませんが >>218
小数点以下の丸めでは、例えば「五捨五入」のもあるみたいですし
でも「厳密に規定」とかいうほどの難しい方法はないとおもいますよ、普通に固定小数点の整数で問題ないのでは？
>>219
10進演算、って普通の整数の加減乗除とどう違うのですか？ 計算機ができる前は人が筆算してたんだよ、勿論10進で
それと合わなきゃならないの
だからBCDとかやるの
精度が確保されてればより正確なんだけど、「本当はこっちの方がより正確です」はダメなんだわ
それまでと変わっちゃダメなの >>220
色々種類はあると思うけど10進数で小数点を扱えるんですよ
また丸め処理も10進数で出来るのですよ >>221
はい、8086 AAA, AAD, AAM, AAS 等の10進補正命令は知っていますが、今から考えても何故にアンパック形式10進なる形式を作ったのか、普通に2進整数＋固定小数点では何故だめだったのか、納得できる理由をずっと探しているのです >>222
つまり「人の作業との突合せ・検算のために10進演算や BCD があった」ということですか？
でも、そうであっても普通に 2 進整数＋固定小数点の演算で問題ないと思うのですが
>>223
BCD で出来る、ということを知りたいのではなく（なぜならばそれはすでに知っているから）、なぜ BCD が必要だったのか、という理由が知りたいのです 金融業界の習わしの発端について知りたいなら、それ関係のスレで聞けばいいんじゃね？
金融関係システムが10進で計算してるのは常識なんだし要求要件なんだから
それに疑問挟んでごねるプログラマーにはシステム開発発注したくねぇなぁ 単純に考えて、「(10進)小数点以下N桁目で四捨五入する」なんて規定があるときに
2進固定小数でやるのは面倒くさいじゃん。 >>214
どこで四捨五入するかなんて
プログラムじゃなく経理さんのルールだかんね
プログラマはそれに合わせるってだけのこと >>228
だったら固定小数点で良くね？
きりが無いなんてことはない そもそもお金に０．１円とかないから四捨五入は必要ない 固定か浮動かって問題じゃない
10進の0.1が2進では0.00011001100110011001100110011...という循環小数になり
金の話では出てこないはずの誤差が出るって話だ
最小単位が1円のときは10銭、10銭のときは1銭が2進演算では正しく扱えない
最小単位をいくらにしても同じことというのをキリがないと言ったんだ >>231
最小単位以下の誤差なんて累乗計算でも出るじゃん >>230
\1,000,500_に源泉税率10.21%を掛けたらいくらになる？ ■ このスレッドは過去ログ倉庫に格納されています
