Qiita 7 - キータぞ、来たぞ、キータだぞー (765ﾚｽ)
上下前次1-新
366: 2025/10/22(水)02:24 ID:W6apSoTE(1) AAS
最新のCPUでも10GHz行かないので1秒間に100億回のカウントが無理だよな
オーバーフローするまでもっとかかる
367: 2025/10/22(水)02:29 ID:kkMCRZ3c(1) AAS
フィボナッチはオーバーフローする
368: 2025/10/22(水)02:49 ID:DMZH9rqW(1) AAS
オーバーフローチェック関数を呼び出せばいい
369: 2025/10/22(水)07:42 ID:pPjVNDwq(1/3) AAS
> 64bitを使うと1秒間に100億カウントを100年間ずっと続けてもオーバーフローしない
こういうマヌケが今後もいなくなることはないからオーバーフローチェックは常に行うのが安全。
370: 2025/10/22(水)08:11 ID:UieYLCLo(1) AAS
溢れないんだからチェックは無駄じゃん
だから昔からチェックしない言語が使われてるんだろ
文句があるならここで暴れずに各言語に公式に言えばいい
371: 2025/10/22(水)09:13 ID:hPyx8jr0(1/3) AAS
Rustは多段階に対応しているよ
デフォルトはデバックモードになりオーバーフロー含めた様々なチェックが充実
プロジェクト毎に常にオーバーフローチェックをする指定が可能
オーバーフローを扱う関数も多数あり
372: 2025/10/22(水)09:20 ID:pPjVNDwq(2/3) AAS
> 64bitを使うと1秒間に100億カウントを100年間ずっと続けてもオーバーフローしない
こういうマヌケはプロジェクトにオーバーフローチェックを行う指定なんてしないしオーバーフローを扱う関数を呼ぶこともないんだよなあ。
373: 2025/10/22(水)09:30 ID:hPyx8jr0(2/3) AAS
安全性の対策ができるかどうかが重視されている
安全性の対策のためにRustは次々と採用されている
対抗できるプログラミング言語が他にないからね
374: 2025/10/22(水)09:37 ID:pPjVNDwq(3/3) AAS
Rustを使えば安全という勘違い
375: 2025/10/22(水)09:41 ID:hPyx8jr0(3/3) AAS
Rustに勝てるプログラミング言語がないんだよ
だからこそIT大手がこぞってRustを採用した
376: 2025/10/22(水)16:35 ID:h019lk2V(1/2) AAS
○bitまで演算できるから大丈夫
だったのが、整数型をオーバーする●年問題とか起きたんだよ
そして今度は◯bitまで使えるから安心と結局は同じ事を繰り返してるだけ
なのに「ずっと使い続けても大丈夫」とか言えるものなんだな
377: 2025/10/22(水)16:36 ID:h019lk2V(2/2) AAS
それプログラム言語で勝ちとか
何が言いたいのだか
378(1): 2025/10/22(水)18:57 ID:Hv/mNdUH(1/5) AAS
>>279
> オーバーフローチェックのコストはとんでもなく高いんだよ。
> 劇的に遅くなることが判っているよ。
このスレのRust信者はコードが書けない馬鹿しかいないのでオーバーフローチェックのコストとやらがとんでもなく高いことの例示すらできないんだよなあ。俺が代わりに確認してやったぞ。
最適化レベル3 オーバーフローチェックなし(-Copt-level=3)
外部ﾘﾝｸ:wandbox.org
最適化レベル3 オーバーフローチェックあり(-Copt-level=3 -Coverflow-checks=yes)
外部ﾘﾝｸ:wandbox.org
379(2): 2025/10/22(水)20:39 ID:TnWf0U/l(1) AAS
>>378
コードを書けないのはおまえだろ
その出力結果を見ろよ
999999999 0.000000 sec.
380: 2025/10/22(水)21:14 ID:Hv/mNdUH(2/5) AAS
> コードを書けないのはおまえだろ
> その出力結果を見ろよ
何が起こってるか分からんとこういう反応ｗ
381(1): 2025/10/22(水)21:44 ID:5MvhTmyF(1) AAS
実行時間0秒ということはコンパイル時の定数化だろうね
コードを正しく書けない人が定数データをそのまま使って正しくベンチマーク計測できていない典型的な失敗例
382: 2025/10/22(水)22:01 ID:Hv/mNdUH(3/5) AAS
>>379
>>381
「とんでもなく高い」と>>279が言ってるオーバーフローチェックをコンパイル時にやれてることが理解できない低能ｗ
383: 2025/10/22(水)22:11 ID:wCiIvwD8(1) AAS
比較ベンチを測るプログラムでコンパイル時に定数になってしまってるのは初心者あるあるでちよっと恥ずかしい
さらに定数になったことでオーバーフローチェックは軽いと主張している人は恥ずかしいを通り越してキチガイ
384: 2025/10/22(水)22:25 ID:Hv/mNdUH(4/5) AAS
> さらに定数になったことでオーバーフローチェックは軽いと主張している人は恥ずかしいを通り越してキチガイ
コスト0でできるオーバーフローチェックの例を挙げただけだけど馬鹿だとこういう理解になんのなｗ
385: 2025/10/22(水)22:40 ID:aaZcXuwG(1) AAS
連投クンは3つの過ちを犯している
①実行時間の比較をすべきところでコンパイル時に定数となるコードを書いてしまった
②その結果をもってコスト0だと主張
③その事例をもってオーバーフローチェックは重くないと主張
386: 2025/10/22(水)22:53 ID:Hv/mNdUH(5/5) AAS
> ?実行時間の比較をすべきところでコンパイル時に定数となるコードを書いてしまった
オーバーフローチェックのコストの話だからコンパイル時にできるんなら御の字なんだよなあ。
> ?その結果をもってコスト0だと主張
俺が挙げた例ではその通り。
> ?その事例をもってオーバーフローチェックは重くないと主張
省2
387: 2025/10/22(水)23:22 ID:MJsEo9z/(1) AAS
定数の同士の計算をコンパイル時にできるだけでしょ
普通は定数同士ではないためオーバーフローのチェックをコンパイル時にできるわけではないよ
388: 2025/10/23(木)00:01 ID:F7QtUS8E(1/3) AAS
> 定数の同士の計算をコンパイル時にできるだけでしょ
同じコードで「最適化レベル3 オーバーフローチェックなし」では定数の同士の計算をコンパイル時にできていないので場合による。rustcは最適化が控えめなのでオーバーフローチェックを行ったほうがデータフロー解析を深いレベルで行なって効率良いコードを吐いてくれる可能性まである。
> 普通は定数同士ではないためオーバーフローのチェックをコンパイル時にできるわけではないよ
できる場合もあればできない場合もある。
安全性を蔑ろにして良いわけはないのでコンパイル時にできないのであれば実行時のオーバーフローチェックは行うべき。そのコストが問題になるのであればプログラマがオーバーフローしないことを保証してやれば良い。
389: 2025/10/23(木)00:05 ID:OBXMa/ZD(1) AAS
言い訳ばかりだな
オーバーヘッドを比較するための実行時間ベンチマークで
まともなプログラマーならばコンパイル時定数になるコードを書かない
390: 2025/10/23(木)00:08 ID:F7QtUS8E(2/3) AAS
コンパイル時にオーバーフローチェックされた例が余程悔しかったと見えるｗ
391: 2025/10/23(木)00:10 ID:F7QtUS8E(3/3) AAS
つか何で
> オーバーフローチェックのコストはとんでもなく高いんだよ。
という具体的を提示しないんだろうか?
392: 2025/10/23(木)01:00 ID:eRkhgGUb(1) AAS
>>379
実行時間を比較しようとして定数計算で実行時間0.000秒は草
それをそのまま貼るのは慌てん坊
393: 2025/10/23(木)22:48 ID:qJPQXYyn(1) AAS
最適化レベル3 オーバーフローチェックなし
外部ﾘﾝｸ:wandbox.org
> 999999999 0.000000 sec.
最適化レベル3 オーバーフローチェックなし
外部ﾘﾝｸ:wandbox.org
> 999999999 0.192019 sec.
なるほど、確かに最適化控えめだなｗ
394: 2025/10/24(金)10:56 ID:1/8UQp8U(1/2) AAS
> オーバーフローチェックのコストはとんでもなく高いんだよ。
clangより遅いRustがますます遅くなっちゃうってことか。
でもそれで安全性と天秤に掛けて安全性捨てて良いって理屈にはならんと思うが。
395(1): 2025/10/24(金)11:39 ID:pf7VrHln(1) AAS
Rustはオーバーフローに関しても最も充実している言語
まずデフォルトではデバッグモードとなりオーバーフローを含めた様々な問題をチェックして指摘してくれる
次にオーバーフローを取り扱う関数が30個以上と充実しておりオーバーフロー時に様々な対処ができるようになっている
さらにオーバーフローチェック強制モードを指定することもできる
396: 2025/10/24(金)12:33 ID:1/8UQp8U(2/2) AAS
肝心のユーザーが
> 64bitを使うと1秒間に100億カウントを100年間ずっと続けてもオーバーフローしない
こんなこと言ってるようじゃせっかくの機能も台無し。
こういうユーザーはオーバーフローを軽視しているので、それを扱う関数を呼んだりオーバーフローチェック強制モードを指定することもしない。
397: 2025/10/24(金)12:54 ID:yjIuofsm(1) AAS
Rustより優れているプログラミング言語がなく出現しそうにない
IT大手をはじめとして各社が次々とRust採用に踏み切った理由
398: 2025/10/24(金)21:32 ID:Rjl1Yp+F(1) AAS
何をもって優れてるというのか知らんけど
採用される率だったら圧倒的に Python や JavaScript じゃないの？
399: 2025/10/24(金)22:24 ID:sOhxBEuL(1) AAS
普及している言語を採用するのは当たり前
普及してない言語をわざわざ採用するのは他の言語では代わりにならないほどメリットがある時
400: 2025/10/24(金)23:11 ID:dp05dd3l(1) AAS
> 64bitを使うと1秒間に100億カウントを100年間ずっと続けてもオーバーフローしない
この程度の実行時検出もできなくて「メリットがある」と言い張ってて草ｗ
401: 2025/10/25(土)00:27 ID:dZEZZMvJ(1) AAS
見ていてなんとなくわかってきた
プログラミング言語として敵わないからよくわからない言いがかりをつけてずっと粘着しているだけのような
402(1): 2025/10/25(土)08:20 ID:7tgM5Cd8(1) AAS
言語の優劣（笑）にこだわってる子が一人だけおるっていう状況かな
自己のアイデンティティを借り物で満たそうとしちゃってるね
自分がRustの作者ってんならともかく、単なるユーザでしかないのにね
403: 2025/10/25(土)08:45 ID:0A7PnaiQ(1) AAS
>>395
オーバーフローに関してそこまで充実していない言語も多いけど、なぜか充実している言語の方をしつこく叩いてるコンプレックス持ちがおるから面白い。
404: 2025/10/25(土)11:38 ID:APUPz67M(1/5) AAS
安全性分かってない奴がRust盲信してて笑われてるだけｗ
405(1): 2025/10/25(土)11:52 ID:HsDC01zZ(1) AAS
>>52
> Rustが広まってる理由はC並みの高速実行をゼロコスト抽象化によるコードの可読性・保守性・開発効率の高さで実現したことにあるからね
> 安全性などはついでのオマケ
IDコロコロ君安全性は屁のように考えてるみたいだけど、だったら配列アクセスのたびに範囲チェックで無駄なコスト払ってるRustは良い言語ではないんじゃね? それかunsafeでポインタアクセスするのが正義?
406: 2025/10/25(土)11:53 ID:H3w3YKY0(1) AAS
安全性のためにRustを採用するところが世界的にどんどん増えているのはなぜだろう？
407: 2025/10/25(土)11:59 ID:APUPz67M(2/5) AAS
Rustの普及と
> 安全性などはついでのオマケ
とか言っちゃう馬鹿が笑われてるのは別の話だゾｗ
408(1): 2025/10/25(土)12:07 ID:LnBfHi83(1) AAS
>>405
Rustは配列などのアクセスもゼロコスト抽象化で速さと安全性を両立してるよん
409: 2025/10/25(土)12:58 ID:APUPz67M(3/5) AAS
>>408はrustcの出力見たことない人かな?
配列の範囲チェックって
外部ﾘﾝｸ:godbolt.org
> cmpq %rsi, %rdx
> jae .LBB0_7
↑がそれ。
ちなみにCだとこんなだ。
外部ﾘﾝｸ:godbolt.org
410: 2025/10/25(土)13:03 ID:APUPz67M(4/5) AAS
rustcが最適化控えめという話は既出か。
rustc
外部ﾘﾝｸ:godbolt.org
clang
外部ﾘﾝｸ:godbolt.org
411(1): 2025/10/25(土)17:01 ID:L+Kq+g5v(1) AAS
C言語は、ポインタが、ヤバイくて、危ないよね。
RUST言語は、ポインタが、無いのなら、安全ぢゃねえ?
412: 2025/10/25(土)17:40 ID:zF/r+ywr(1/2) AAS
>>402
マジでこれ
関数型言語あたりに多いけど、自分が好きな言語をアイデンティティにしてる奴にまともなのはいない
自分は何を作れるか・何を作ったかの方がプログラマにとっての価値だろ
413: 2025/10/25(土)18:04 ID:zF/r+ywr(2/2) AAS
個人開発ならともかく、仕事で使う言語は自分の好みじゃなくて組織によって決まるものだよね
Rustが好きでも、Goのプロジェクトに入ったらGoを書く、Javaのプロジェクトに入ったらJavaを書くのがプロ
宣言的なコードが好きだからといって、OOPの言語や、for文 と if文 をひたすら書かされる言語では仕事したくないです、なんてのは社会人としてだめでしょ
(Rustを使える企業に転職する、という選択ができる人は別だけど)
414: 2025/10/25(土)19:23 ID:KXTmWn4e(1) AAS
企業や立場によってピンキリだよ
そういう歯車として使われる人もいればそうでない人もいる
415: 2025/10/25(土)19:50 ID:SFAxzZT/(1) AAS
どの分野でもAとBの比較の話をしている時に同じことが起きてるな
純粋にそれぞれの特徴やメリットで優劣を比較すればいい
ところが不利になった側はどの話でもこう言い出す
Aを使うやつはXXXだ！Aの価値よりおまえの価値はどうなんだ！
AとBの比較から逃避して人間の攻撃を始める
416: 2025/10/25(土)19:55 ID:waw5U/cg(1) AAS
なんか話がズレまくってるなここ
417: 2025/10/25(土)19:56 ID:N83OYtmK(1/2) AAS
> オーバーフローチェックのコストはとんでもなく高いんだよ。
> 劇的に遅くなることが判っているよ。
とか
> 安全性などはついでのオマケ
とか言ってる人は根本的なところがわかってないので言語を選定したりプロジェクトを先導する立場に立たせてはダメ。
418: 2025/10/25(土)20:04 ID:nC0XVvFS(1) AAS
安全性と速さの両立が最重要だもんな
利害対立し合うIT大手企業が珍しく揃ってそのために選択したRustを用いるのが正しい
419: 2025/10/25(土)20:25 ID:N83OYtmK(2/2) AAS
> 安全性と速さの両立が最重要だもんな
↑馬鹿発見ｗ
420: 2025/10/25(土)20:33 ID:TVzQqIlO(1) AAS
安全性と速さだけではダメ
高い抽象度で読み書きしやすいことが大切
Rustはそこを満たしたからこそ新たな移行先になった
421(1): 2025/10/25(土)22:07 ID:APUPz67M(5/5) AAS
>>411
Rustもポインタが使えるし場合によっては危険。
外部ﾘﾝｸ:godbolt.org
422: 2025/10/25(土)22:29 ID:OtGrSoGw(1) AAS
>>421
生ポインタの指す先を読み書きできるのはunsafe Rust
unsafe RustではC言語と同じ状態という点で危険だが普通のプログラミングでunsafeを使うことはない
423(1): 2025/10/25(土)22:31 ID:vZIJ37nc(1/2) AAS
言語の良し悪しを語ってる時点で草なんよね
だって俺らは与えられた言語で仕事するだけだから
C++でもPerlでもPHPでも書くだけだから
You play with the cards you're dealt.
424: 2025/10/25(土)22:36 ID:Oc43Pjaf(1) AAS
>>423
IT土方は仕事を選べないもんな
425: 2025/10/25(土)22:58 ID:vZIJ37nc(2/2) AAS
はい（真顔）
426: 2025/10/25(土)23:15 ID:9ui6NOtA(1) AAS
土方が無理に言語の優劣の話にクビを突っ込まなくてもいいけど
新たな優秀な言語が出現したチャンスと捉えて習得して土方を脱出する手もある
427(1): 2025/10/25(土)23:23 ID:RL99M0X7(1/2) AAS
> 普通のプログラミングでunsafeを使うことはない
と言ってる人はunsafeが使われてる標準ライブラリも使わないのかな?
428: 2025/10/25(土)23:28 ID:JGY3STeT(1) AAS
>>427
それは真逆だよ
Rustでunsafeが使われるのは標準ライブラリの内部やそれに準じる基盤クレートの内部
普通のRustプログラミングでunsafeは使われない
429: 2025/10/25(土)23:40 ID:RL99M0X7(2/2) AAS
> 普通のRustプログラミングでunsafeは使われない
ああ低レイヤに縁のない人か
430: 2025/10/25(土)23:53 ID:EfkNjJ0Z(1) AAS
低レイヤの意味は複数あるけど
いずれも可能な限りunsafeは使われないね
効率面でunsafe必要になるパターン一般化されてプログラムの外部へ切り出されてライブラリ化されるよ
そうしてできたのがRustの標準ライブラリ
431: 2025/10/26(日)01:56 ID:GI8xQK7J(1/2) AAS
画像処理でピクセルを走査するようなケースだと unsafe なポインタ操作は必須じゃないの？
インデックスアクセスだと範囲チェックのコストがかかるし
単に1画素を1画素にマップするだけならほぼノーコストでイテレーターを使えるだろうけど、周辺画素を参照する操作もよくあるから単純なイテレーターは使えないし
432: 2025/10/26(日)01:59 ID:GI8xQK7J(2/2) AAS
あとはCとのFFI
過去に書かれたC/C++資産の利用はRustでやりたいことの一つだろうし、これは流石に標準ライブラリのような「一般的なユーザーは使わない」ものでは無いと思う
433: 2025/10/26(日)02:39 ID:PJJMD6bT(1) AAS
Rustのunsafeは他の言語と同じ様の状況になりますよという意味で、コンパイルが通っても安全性を保証しませんという意味。
つまり他の言語と同様に、unsafeな部分の安全性は人間が保証してください、がRustのunsafe。
したがって他の言語とリンクする場合にその境界部分がunsafeになるのは当たり前でこれを避けることはできない。
しかしパターン化できる場合はunsafe使用部分をライブラリの中に閉じ込めてそれを安全に用いることもできる。
例えばPythonのライブラリをRustのPyO3クレートで作成する場合など。
434: 2025/10/26(日)03:35 ID:uL5v2PLc(1) AAS
低レイヤに縁がない人がオーバーフローチェックを否定してるのがわけわからんのよねｗ
低レイヤ担当は色々手段を尽くして実行効率が良くて安全なものを提供してると思うんだけどそれに乗っかってる側は自分が書いてるコードの実行効率を気にするよりは安全性を重視するべきではないの?
435: 2025/10/26(日)04:33 ID:SK2IH7bS(1) AAS
また言語の話で不利になったため逃げて、
妄想上の人の話へとすり替えようとしてる
436: 2025/10/26(日)09:10 ID:+y7r90/A(1) AAS
もうQiita関係ないな
437: 2025/10/26(日)20:55 ID:v+5C5Bjl(1) AAS
IDコロコロくんは面白いなｗ
438: 2025/10/27(月)06:58 ID:x+p8Wgca(1) AAS
せやな
439(2): 2025/10/29(水)20:12 ID:oGx2PQGm(1) AAS
『Cから学ぶRustの良さ』
3年前に書かれた記事だがトレンドに挙がってたので初めて見た。
酷い記事だなあ。なんで90人もいいねしてんの?
440(3): 2025/10/29(水)23:35 ID:xnDexBBj(1) AAS
>>439
C/C++は弱い型付け言語なのでサイズの異なる型への自動変換が起きることに加えて8bit環境以外では
Cでは sizeof('a') == sizeof(123)
C++では sizeof('a') != sizeof(123)
などの無茶苦茶な仕様が混乱に拍車をかけているよな
441(1): 2025/10/29(水)23:46 ID:kkKNfkqN(1) AAS
AIに聞いたら聞き返された
もしよろしければ、あなたが特に「酷い」と感じた記事の具体的な内容や論点について教えていただけますか？
それについて、Rustの技術的な視点から掘り下げて解説することもできます。
442(2): 2025/10/30(木)01:06 ID:Hkp2/Mla(1/3) AAS
ChatGPTに
> この記事読めますか? 外部ﾘﾝｸ:qiita.com
> 前述の記事には誤りと思われる個所が複数あると思います。気が付いた点があれば挙げてみてください。
と訊いたら
> 確認できた範囲で、記事「Rust と C の比較（著：ushijima ryosuke／uv_ussy）に 誤りまたは誤解を招きやすい記述 がいくつかあります。いくつか挙げますので、もしよければさらに掘り下げましょう。
省1
443(1): 2025/10/30(木)01:16 ID:L8pN1QHs(1) AAS
>>442
レスの全文を正確にコピペしただけ
AIに聞いた質問は誤りと思われる個所を探すことでない
レスをよく読んでみてね
444: 2025/10/30(木)01:40 ID:Hkp2/Mla(2/3) AAS
>>443
俺はお前が「AIに聞いたら聞き返された」って馬鹿なこと言ってるから面白がってるだけよ?
445: 2025/10/30(木)01:43 ID:Hkp2/Mla(3/3) AAS
> レスの全文を正確にコピペしただけ
アドレスも貼らんでAIが理解してくれるって認識かｗ
446: 2025/10/30(木)02:40 ID:pCIdJOGw(1) AAS
>>440
CとC++で色々と違っているのを知らずに誤解する人多いよね
>>442
Rustの問題ではなくて
Cの問題点と不備な点と間違えやすい点に加えて誤解してる点と間違ってる点のフルコースの記事だね
447(1): 2025/10/30(木)08:28 ID:lzfhCIfj(1) AAS
> C/C++は弱い型付け言語なので
それはそう。
> サイズの異なる型への自動変換が起きることに加えて
サイズの同じ異なる型への自動変換もあるからサイズ関係ないぞ。件の記事はなんでかサイズで説明してるが。
> 8bit環境以外では
> Cでは sizeof('a') == sizeof(123)
省4
448: 2025/10/30(木)08:58 ID:DCpoislO(1) AAS
Cの時点でぐちゃぐちゃなのにC++が互換性を持たせずに変えてしまった部分だからめちゃくちゃになってるところ
449: 2025/10/31(金)08:16 ID:dfFjY6H8(1/2) AAS
>>439の記事の筆者名検索するとFaceBookのページ出てくるけど国立大学で情報工学専攻でこれというのはいろいろ考えてしまうな。
450: 2025/10/31(金)23:01 ID:dfFjY6H8(2/2) AAS
IDコロコロ君はRustスレにも迷惑掛けてるのかｗ
もう自分を迷惑な人材として認識しておとなしくすりゃ良いのにねｗ
451: 2025/11/01(土)10:19 ID:QCwdg/pu(1) AAS
12月1日から25日まで、みんなで技術記事を投稿して、カレンダーを埋め尽くそう
qiita.com/advent-calendar/2025
完走チャレンジ賞の達成条件は以下です。
・1人で15～24記事投稿した方を表彰します。
プレゼントカレンダーは2025/10/31～2025/12/31に記事を投稿
期間が2つある
452(1): 2025/11/01(土)12:59 ID:wOU/NDvb(1) AAS
>>447
それが意味不明で分からないなら馬鹿はお前の方では？
453: 2025/11/01(土)13:07 ID:KM9f//71(1) AAS
『stdio.hやiostream.hの中身を見る方法』
/usr/include/ かINCLUDEが指してる先見に行った方が早くね?
454: 2025/11/01(土)13:40 ID:IJ9tr23i(1) AAS
> 8bit環境以外では
> Cでは sizeof('a') == sizeof(123)
> C++では sizeof('a') != sizeof(123)
8bit環境に限っては↑のようにならないとでも言いたげだがC言語では'a'の型はintなので
sizeof('a') == sizeof(123)
は常に1となる。
C++では'a'の型はcharなのでcharのサイズがintと同一な環境でもない限りは
sizeof('a') != sizeof(123)
は常にtrueとなる。C++は規格としてintのサイズは最小でも16bitあるから仮にcharのサイズがintと同一の環境であれば
sizeof('a') != sizeof(123)
省2
455(1): 2025/11/01(土)13:50 ID:B/e2fvdA(1) AAS
そういう基本的な部分でCとC++の扱いが違うなんて失敗言語だよなあ
456: 2025/11/01(土)15:57 ID:QSMh1nGC(1) AAS
C++では'a'の型はchar
知らんまま書いとったわｗ
457(1): 2025/11/02(日)13:42 ID:zw4M8eHQ(1/3) AAS
『データ構造入門(1) - ポインタ・配列・構造体』
外部ﾘﾝｸ:qiita.com
> 学習のためなら、一度はコンパイルして実行した方がよいと思います。
> C++ならコンパイルエラーになってくれます。
コンパイル確認しろはその通りだがCのタグついててC++のタグはない記事のコードになんでC++でコンパイルなんて言うかなあ?
>>455 同様CとC++が違う言語と認識できてない人かな。
458: 2025/11/02(日)14:35 ID:Z91049yH(1/2) AAS
>>457
int genderに"man" や"woman"を入れようとしてるんだぞ
エラーにする言語が正しい
459(1): 2025/11/02(日)14:53 ID:zw4M8eHQ(2/3) AAS
CとC++が違う言語と認識できてない人が早速現れたｗ
460: 2025/11/02(日)15:01 ID:QN/Mkn5m(1) AAS
>>459は誰に対して言ってるんだ？
461: 2025/11/02(日)15:18 ID:Z91049yH(2/2) AAS
CでもC++でもint genderに"man" や"woman"を入れるべきではない
エラーにできない言語を使うべきではない
462: 2025/11/02(日)20:42 ID:qZwCnQv/(1/2) AAS
C言語でポインタ値をintのオブジェクトに代入するべきでないという話はCの規格やコンパイラの吐いた警告で説明できるのだしルールも異なる他の言語引き合いに出す意味はないんだよなあ。
また、C言語は使うべきでないという個人の主張はC言語を学ぼうとしてるQiitaの記事とは関係ないから他所でやるべき。
463(1): 2025/11/02(日)22:02 ID:wB1CjVuc(1) AAS
Cコンパイラしかない組み込み用CPUを使う場合しかCを使う機会ないよな
ほとんどの人にCは不要という現実を教えてあげたほうがよい
464: 2025/11/02(日)22:10 ID:qZwCnQv/(2/2) AAS
>>463は主要な部分をCで組まれたLinuxも使わないで済む世界の住人かな
465: 2025/11/02(日)22:27 ID:ONf1Jw+O(1) AAS
現在LinuxのカーネルモジュールはRustで書くのがメインとなってるよ
カーネルコアはCのままだけど我々がコードを書く部分はカーネルモジュール
上下前次1-新書関写板覧索設栞歴
あと 300 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.030s