Qiita 7 - キータぞ、来たぞ、キータだぞー (768ﾚｽ)
上下前次1-新
262: 2025/10/06(月)08:49 ID:0Xz/SJfu(1) AAS
この先生はElixirみたいなニッチな言語研究するより先にアルゴリズムの勉強したほうが良いと思う。
現状では学部の学生並みの知識もある気がしない。
263: 2025/10/09(木)14:36 ID:/RUFLlG7(1) AAS
『【C言語】char型の落とし穴~オーバーフロー~』
charの変数の値はintに昇格されてから加算されるのでこの場合オーバーフローしないし、intからcharに型変換する際にビットが捨てられるのもオーバーフローじゃないけど、この記事は何をオーバーフローと呼んでいるのか?
264: 2025/10/09(木)15:40 ID:KD7T9yPY(1) AAS
Cしか使えない特殊な環境ならともかく
勝手に異なる型へ自動変換されて困ったことになる弱い型付け言語のCを使ってる情弱の知識はそんなもんだ
265: 2025/10/10(金)00:22 ID:SqpOO1WH(1/2) AAS
外部ﾘﾝｸ:qiita.com
> ご指摘ありがとうございます。数値を修正しました...
コンパイルエラーが出るよう修正するとかｗ
外部ﾘﾝｸ:gcc.godbolt.org
266: 2025/10/10(金)01:56 ID:3qfmD/kK(1) AAS
今となっては未定義動作だらけの欠陥言語Cにこだわる人はほぼ異常者だな
残りは特定の環境・コンパイラ・設定で偶然動けばいい特殊な状況の人だけ
267(1): 2025/10/10(金)08:25 ID:ckTDD7bx(1/7) AAS
組み込みの世界知らない人かな
268(1): 2025/10/10(金)09:05 ID:FYVFXot6(1) AAS
C以外は特定の環境・コンパイラ・設定で偶然動けばいい特殊な状況の人って事?
269: 2025/10/10(金)09:11 ID:9zFqUBbx(1) AAS
>>267
それはコレやね
>>特定の環境・コンパイラ・設定で偶然動けばいい特殊な状況の人だけ
270: 2025/10/10(金)09:17 ID:JrlTg/8e(1) AAS
>>268
C以外に未定義動作だらけなクソ言語あるの？
271: 2025/10/10(金)09:30 ID:ckTDD7bx(2/7) AAS
> C以外に未定義動作だらけなクソ言語あるの？
C++も聞いたことない人かあ
272: 2025/10/10(金)10:03 ID:Joie9IL1(1) AAS
C/C++は同罪だね
C++が失敗した理由はいくつも挙げられてきたけど
拡張方法の失敗に加えてCの未定義動作を埋めきれなかったことが響いてる
273(1): 2025/10/10(金)10:10 ID:EYYPWczZ(1) AAS
Javaでもメソッド無いの初期化されていない変数とかで失敗するけど
未定義動作になるのを言語のせいとか言ってるけど自分が必用な値が自動でセットされるわけじゃないのだからそういう奴ってバグを作り出す
274: 2025/10/10(金)10:23 ID:c258Qk98(1) AAS
>>273
Javaでは未定義動作にならないため問題は起きません
ローカル変数は初期化しないとエラー
インスタンス変数はデフォルト値で自動的に初期化されます
デフォルト値は各型により0やfalseやnullなど定まっています
Cの実行するたびに値が変わる問題はJavaでは起きません
275(4): 2025/10/10(金)12:28 ID:ckTDD7bx(3/7) AAS
最適化のなしかありかで挙動の変わる言語があるらしいけどそういうのは最悪。
fn main() {
let mut sum: i8 = 0;
let mut num: i8;
num = 100;
sum += num;
num = -10;
省7
276: 2025/10/10(金)12:45 ID:AslPjXj+(1) AAS
その辺見越して大きい値扱える変数使って明示的にうまいことやるからどうでもいいんだよなあ
277: 2025/10/10(金)12:56 ID:BIOy5Wv+(1) AAS
>>275
debug modeとrelease modeの違い
標準状態ではdebug modeで動作
実行時コストをかけて様々な検出をしてくれる
release modeでは明示的な実行時コスト指定ex. checked_add()などがある時のみ
278(1): 2025/10/10(金)17:34 ID:ckTDD7bx(4/7) AAS
x86やARMでオーバーフローチェックのコストなんて大したものではないので、最適化有効の場合でもオーバーフローチェックは行うのがフェイルセーフ的に正しいな。
オーバーフローチェックのコストが問題になるレアケースでは記述を変える対応が良い。
そういう判断できなかった辺りが残念言語なんだよなあ。
279(5): 2025/10/10(金)19:59 ID:EwscZStB(1/4) AAS
>>278
オーバーフローチェックのコストはとんでもなく高いんだよ。
演算命令1つ行なう毎に、そこで立った条件フラグによる条件分岐を毎回行なう必要がある。
これはコンパイラが行なうコードの並べ替えやループの展開やベクトル化などを全て阻止してしまう。
劇的に遅くなることが判っているよ。
さらにアセンブリ言語を書いたりコンパイル結果を見たりしたことがあれば理解しやすいけど、
条件フラグを変更せず保持したまま演算を行ないたいことが多いんだよ。
そのため条件フラグを変更しない演算命令が一部用意されていて、それらが活用されている。
常にオーバーフローフラグを必要とするならそれもできなくなってしまう。
条件フラグをレジスタやメモリに一時退避させるコストもかかってくるんだよ。
280(1): 2025/10/10(金)21:05 ID:ckTDD7bx(5/7) AAS
いまどきのプロセッサは分岐予測も優秀だし分岐しない条件分岐命令は大してペナルティならねぇよアホか。
281(1): 2025/10/10(金)21:12 ID:ckTDD7bx(6/7) AAS
＞条件フラグを変更せず保持したまま演算を行ないたいことが多いんだよ。
＞そのため条件フラグを変更しない演算命令が一部用意されていて、それらが活用されている。
知らないこと想像で書いてて大変宜しいｗ
上下前次1-新書関写板覧索設栞歴
あと 487 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.056s