Rust part33

**デフォルトの名無しさん** · 2025/08/15(金) 17:49:30.70

公式
https://www.rust-lang.org/
https://blog.rust-lang.org/
https://github.com/rust-lang/rust

公式ドキュメント
https://www.rust-lang.org/learn

Web上の実行環境
https://play.rust-lang.org

※Rustを学びたい人はまず最初に公式のThe Bookを読むこと
https://doc.rust-lang.org/book/

※Rustを学ぶ際に犯しがちな12の過ち
https://dystroy.org/blog/how-not-to-learn-rust

※Rustのasyncについて知りたければ「async-book」は必読
https://rust-lang.github.io/async-book/

※次スレは原則>>980が立てること

前スレ
Rust part32
https://mevius.5ch.net/test/read.cgi/tech/1755057787/
Rust part31 https://mevius.5ch.net/test/read.cgi/tech/1751545806/
Rust part30 https://mevius.5ch.net/test/read.cgi/tech/1748392296/

ﾜｯﾁｮｲスレ
プログラミング言語 Rust 4【ﾜｯﾁｮｲ】
https://mevius.5ch.net/test/read.cgi/tech/1514107621/

**デフォルトの名無しさん** · 2025/11/24(月) 10:00:06.15

>>881
あのな、言いたい事は分かるし、プログラマはシステムが止まらないよう最大限の努力しろというのはその通りだが、超新星爆発や太陽フレアやコーヒーが零れるのは止められないからな。それを念頭に運用は速やかにシステムを復旧出来るようにしとけよ。それが出来ずにプログラムやプログラマを非難するだけの運用なら無能というはなし。

**デフォルトの名無しさん** · 2025/11/24(月) 10:32:10.42

>>876
いらんからmod.rsは非推奨になったのでは
ディレクトリと同名ファイルで管理するようになって
Facadeパターンとして使いやすくなった

**デフォルトの名無しさん** · 2025/11/24(月) 10:45:36.91

>>882
なんのために制約キツくてコーティング面倒臭いRustを使っているのか、という話だわな。

Rustを採用するマネジメント層からすれば、トラブルの無い安定運用がRustに期待するところであって、Cloudflareみたいなサービス停止トラブルはあってはならない悪夢でしかない。その原因が無能コーダーが不用意に突っ込んだunwrapなんだから、管理側が「SafeRustではpanic禁止にしたい」と考えるのは当然じゃないんかね。

**デフォルトの名無しさん** · 2025/11/24(月) 10:54:15.58

>>881
>「panicは最小限度にしろ」「panicが発生するコードは全て明記して管理しろ」「管理できなければpanicさせるな」
クリティカルなサービスなら当然の要求な気がする
障害につながらない仕組みが用意されてるpanicと即障害になるpanicは扱いが違うだろうけど管理は必要
ポストモータムにある対策の4番目に該当する

>>882
最大限の努力をしないと無効な入力値が渡されただけでサービス全体が停止するシステムを作ってしまうようなら無能と言われても仕方ない

**デフォルトの名無しさん** · 2025/11/24(月) 11:23:49.40

>>883
ファイル名と配置のルールが変わっただけだぞ
エディタのクイックオープン機能なんかで同名ファイルが大量に並ぶのは見づらいというしょーもない理由

**デフォルトの名無しさん** · 2025/11/24(月) 12:50:03.58

>>883
非推奨化はしてないと思うが
インテグレーションテストから共有されるモジュールなんかは mod.rs 方式しか使えなかったりするし

**デフォルトの名無しさん** · 2025/11/24(月) 12:51:36.71

Rustが保証するのはメモリ安全であって、それ以上の機能を言語自体に期待してはいけないね

**デフォルトの名無しさん** · 2025/11/24(月) 13:52:56.65

3年かけて数多のスレを潰してようやく分かったか？

**デフォルトの名無しさん** · 2025/11/24(月) 15:25:42.29

今後Rustは使用必須のスタートラインに過ぎないからな

**デフォルトの名無しさん** · 2025/11/24(月) 17:08:28.30

Rustの次の言語に期待

**デフォルトの名無しさん** · 2025/11/24(月) 17:14:22.69

実際、Rust以降ってこれといった言語出てなくない？

**デフォルトの名無しさん** · 2025/11/24(月) 17:19:31.65

Rustより安全性の高い言語でないと企業が採用しない
Rustのような書きやすさと両立したプログラミング言語は出現しそうにない

**デフォルトの名無しさん** · 2025/11/24(月) 17:45:09.92

メモリの安全性だけでなくnull safetyやmatchのexhaustivenessなど堅牢なソフトウェアを作るための機能が言語に備わっている

にもかかわらずそれらバイパスする間違ったunwrapやpanicの使い方を「正しい」と思い込んでる人たちを少なからず作り出しているということと、その誤った使い方を構造的に防止する方法がないということがソフトウェアの安全性に対するRustの問題点

**デフォルトの名無しさん** · 2025/11/24(月) 18:01:28.20

unsafeの中以外は⊂（＾ω＾）⊃ ｾﾌｾﾌ!!

**デフォルトの名無しさん** · 2025/11/24(月) 18:21:57.08

>>894
理解できていないのは君だろ
null safetyは必ずnullチェックがなされることを指す
unwrapは必ずnullチェックをする安全な方法
安全でないのはnullチェックをしないunwrap_unchecked()

**デフォルトの名無しさん** · 2025/11/24(月) 18:37:03.11

>>896
つまり他言語でも

*nullptr = 123;

で「終了」すればnull safetyだとの主張ですな

**デフォルトの名無しさん** · 2025/11/24(月) 18:43:35.39

>>892
Zigがあるじゃん

**デフォルトの名無しさん** · 2025/11/24(月) 18:48:01.50

>>897
それはnullチェックをしていないため安全でない
unwrapは必ずnullチェックをする安全な方法

**デフォルトの名無しさん** · 2025/11/24(月) 18:53:21.46

>>898
何年前に出て、現在どれだけ使われてるの？

**デフォルトの名無しさん** · 2025/11/24(月) 19:30:54.35

>>900
JavaScriptランタイムのBun
あと、SUSEがZigでSSHの再実装するらしい

**デフォルトの名無しさん** · 2025/11/24(月) 19:58:53.90

>>901
聞いたのは個別具体な事例ではなく、どれだけ使われているか、つまり普及のいかんについてであるのと、あと出た時期Rustと変わんなくない？

**デフォルトの名無しさん** · 2025/11/24(月) 21:00:06.05

Crate.ioには、std::fmt::Debugをインプリしていないクレートが一杯あるんやね。
UartDriverだけかと思いきや、結構ある。
Wrapper作ってのインプリ作業がマンドクセ。
でないと、クレート、モジュールの外部変数Mutex.setもできん。
いろいろ手間のかかる言語だ。

**デフォルトの名無しさん** · 2025/11/24(月) 21:14:00.28

ラップして Debug を実装するだけならマクロでかなり自動化できると思う。
というかそういうクレートはありそう。知らんけど。

**デフォルトの名無しさん** · 2025/11/24(月) 22:02:41.96

>>896
言語に機能は備わっているけど誤った使い方でそれを活用できていない人たちがいるという話に対して「unwrapは必ずnullチェックをする」という言語に備わった機能を紹介しても意味ないでしょ

ちなみにnull safetyは必ずnullチェックがなされることを指すわけではないよ
null safetyを実現するための一手段ではあるけれどね

**デフォルトの名無しさん** · 2025/11/24(月) 22:03:30.71

>>903
これまで誰も困っていないのならば
あなたがおかしい可能性を疑ってみてはいかが

**デフォルトの名無しさん** · 2025/11/24(月) 22:07:33.53

>>905
その件は一方的な特定の価値観によって「誤った使い方」と断言してる人がおかしい
まずケースバイケースであり更に同じケースでも価値観の相違がある話なので技術的な話ではない

**デフォルトの名無しさん** · 2025/11/24(月) 22:25:07.64

>>907
ケースバイケースなのは当然の話なんだがunwrapの誤った使い方によって大障害につながったCloudflareのケースを念頭に話をしてるわけで

あれが「誤った使い方」と断言できない人がこんなスレだけで複数いることがRustの抱えてる問題

**デフォルトの名無しさん** · 2025/11/24(月) 22:28:17.91

>>908
本気で言ってるなら正気を疑う
まず思い込みの前提から解放されよう

**デフォルトの名無しさん** · 2025/11/24(月) 22:31:40.94

>>906
Rust API Guidelines でもパブリックな型にはDebugトレイトを実装することを推奨してるけど
https://rust-lang.github.io/api-guidelines/debuggability.html

**デフォルトの名無しさん** · 2025/11/24(月) 22:32:27.20

>>908
その無理矢理な「Rustの抱えている問題」との書き込みからアンチらしき人にみえます

**デフォルトの名無しさん** · 2025/11/24(月) 22:41:07.93

「所有権の複製」の人って
その発言の前はそもそもクソコードいっぱいこのスレに書いてた人よな？
あの人よくunwrap書いてたような記憶あるけど記憶違いかな

**デフォルトの名無しさん** · 2025/11/24(月) 23:02:06.99

unwrap使わない人はassertも使わないのかな
条件が破れた時にpanicの発生源になるし

**デフォルトの名無しさん** · 2025/11/25(火) 00:13:09.71

除算は常にchecked_div使ってそう

**デフォルトの名無しさん** · 2025/11/25(火) 00:17:03.45

物事を点でしかとらえられない知的障害者が大勢いるのがよくわかってかなしい
早くAIに置換したい

**デフォルトの名無しさん** · 2025/11/25(火) 00:21:51.64

0か100か思考の例

**デフォルトの名無しさん** · 2025/11/25(火) 01:08:59.76

>>909
Cloudflareのunwrapの使い方が誤った使い方でないと思ってるならそう思う根拠を述べて反論できないの？

**デフォルトの名無しさん** · 2025/11/25(火) 03:59:13.06

>>917
あちこちでの議論くらい読め
Resultを返す関数の中で意図的にResultをunwrapしていることから
そこでエラーは起きないと確信していて起きたら停止すべき事態とみなしている
現実にもありえない重複行が発生してサイズオーバーという異常事態になっていた
あとは運用側の問題でありpanicによりどこで何が起きたか確実に判明して直ぐに対応できる話だがここでは対象外

**デフォルトの名無しさん** · 2025/11/25(火) 07:01:05.47

>>918
そのあたりはコーダーの都合であって、運用を危険にさらす理由にならない。

Cloudflareの場合で言うなら、
https://blog.cloudflare.com/ja-jp/18-november-2025-outage/
ボット管理モジュールのフィーチャー設定ファイルは長さに上限が無いにもかかわらず固定長のメモリに保存する仕様にしているのだから、固定長を超えるフィーチャー設定ファイルが来るのは当然ありえるケースとしてカバーする必要がある。それをコーダーの都合で雑にpanicさせて、なおかつ「panicのあとは運用側の問題」と放り投げるなら>881>884という話だわな。

**デフォルトの名無しさん** · 2025/11/25(火) 07:48:13.19

運用上マズい結果を招きかねないコードがそのまんまテストやレビューを通過していることから、これは組織体制の問題でもある
どのようなテスト結果をもってどのように承認されたのか、今回の事象に至る前提条件はその時に把握されていたのか、等が気になる

**デフォルトの名無しさん** · 2025/11/25(火) 07:52:14.10

>>919
理解できない人なのかな？
そんな憶測の話はどうでもいい
きりがない
重要なことは何を意図して今回のコードを書いているかどうか

今回はResultを返す関数の中で意図的にResultをunwrapしていることから
そこでエラーは起きないと確信していて起きたら停止すべき事態とみなしている
そして異常事態が実際に起きてここで食い止めることができている

もちろんこれらの事象が起きて事後知識を得た後には別の判断をする可能性がある
その一つがボット判断の無効化など異常事態でも動かし続けることを優先するだろう
これらの事後知識を得た後の話をしても意味がない

**デフォルトの名無しさん** · 2025/11/25(火) 08:15:03.85

>>921
コーダー視点からすればそうなのね。

それならなおさらのこと、マネジメント視点や運用視点からすればpanicは厳重に管理しなければならない対象ということになり、>881という結論になるわな。
さらに言えば>920の指摘の通りで、雑に実装された緊急停止コードがレビューでそのまま本番環境に投入されたのは組織体制の問題があるかもしれん。実際にはRustのバッドノウハウの普及遅れのせいだと思うけど。

**デフォルトの名無しさん** · 2025/11/25(火) 10:56:07.08

>>921
>そこでエラーは起きないと確信していて起きたら停止すべき事態とみなしている
めっちゃ憶測やん

**デフォルトの名無しさん** · 2025/11/25(火) 11:05:24.61

複おじの憶測が当たってても誤ったunwrapの使い方であることに変わりはないよね

**デフォルトの名無しさん** · 2025/11/25(火) 11:49:12.51

クラウドフレアって良く落ちるよね

**デフォルトの名無しさん** · 2025/11/25(火) 13:01:07.06

>>921
コードは（もっと言えば仕様も）意図を100%反映するものではない
コードにunwrap()があるからといってそこから背景の意図を一意に読み取れるとする前提は、ソフトウェア工学の現実にまったく即していない

**デフォルトの名無しさん** · 2025/11/25(火) 13:11:04.76

設定ファイルはデフォルトのものは用意出来なかったのだろうか
デフォルトの設定を使ったら動作変わるだろうけどそれよりはpanicのほうがマシということかな

**デフォルトの名無しさん** · 2025/11/25(火) 14:14:13.80

panicさせれば確実に問題を把握できるからベストだけど
どこでpanicしたかわかっているのに対応に時間がかかった運用体制がダメだよな

**デフォルトの名無しさん** · 2025/11/25(火) 14:28:01.35

リリースビルドでも行番号出るんだっけ？

**デフォルトの名無しさん** · 2025/11/25(火) 14:36:29.79

fmt::Debug実装されてないとき
Compile errorで落とすのをデフォに出来ないの

**デフォルトの名無しさん** · 2025/11/25(火) 14:43:06.35

>>877
pythonのモジュール設計はtcl/tkのパクリ

**デフォルトの名無しさん** · 2025/11/25(火) 15:49:19.46

>>910
だね。
例えば、UartDriverのインスタンスを関数外にグローバル変数(static)として設け、各関数でシェアする場合、
OnceLock<Mutex>などで排他する必要がある。
これをnew()内でmutex setしようとするとそのset関数にはunwrapも.exceptも使えない。
そこで、sft::fmt::DEBUGインプリメント推奨となる。

**デフォルトの名無しさん** · 2025/11/25(火) 16:57:37.23

>>930
一応要求される使い方では、COMPILE ERRORでニッチもサッチも行かなくなる。
unwrap()系必須の仕様は多い。

**デフォルトの名無しさん** · 2025/11/25(火) 18:06:26.30

refcellとかの内部可変性はズルいような感じする

**デフォルトの名無しさん** · 2025/11/25(火) 18:07:51.70

unwrap禁止おじさんw

**デフォルトの名無しさん** · 2025/11/25(火) 18:29:54.26

まぁ　クレートのラッパーにstd::fmt:DEBUG入れ込むのは、VScode　AIコパイロットで一度パターンを覚えてくれれば、楽になるが、あちきのようなvim使いにはテンプレートでやるしかない。
意外と手間がかかるのでマンドクサイ。

**デフォルトの名無しさん** · 2025/11/25(火) 18:43:51.50

>>928
ベストなわけあるか
握りつぶすのが最悪でその次に悪い対応

**デフォルトの名無しさん** · 2025/11/25(火) 18:50:48.51

>>927
わざわざデフォルト値にフォールバックする必要がないと思う
まさに今使ってる設定があるんだからそれを使い続ければいい
動作も変わらなず設定が無効な値に更新されないだけ

**デフォルトの名無しさん** · 2025/11/25(火) 19:15:28.03

まあRustだから安全ですよ
そんなに心配していません

**デフォルトの名無しさん** · 2025/11/26(水) 01:42:28.68

panic panic panic みんなが慌ててる
Rustは凄いぞ天才的だぞ将来楽しみだ

**デフォルトの名無しさん** · 2025/11/26(水) 02:55:05.14

認証せえ～！！

**デフォルトの名無しさん** · 2025/11/26(水) 07:57:42.58

>>930
https://doc.rust-lang.org/rustc/lints/listing/allowed-by-default.html#missing-debug-implementations

デフォルトだとallowになってるからdenyにしておくといい
lintルールは暇なときに眺めてみると勉強になるかもしれない

**デフォルトの名無しさん** · 2025/11/26(水) 08:33:59.66

>>934
まぁ　ファームウェア系などの、スマートポインタ多用の開発では必須なんだわ。
それなら、CやC++でやれば良いのにとは思うが、Rust信者はどうしようもない。
はやくC++開発に戻りたい。

**デフォルトの名無しさん** · 2025/11/26(水) 09:47:04.35

>>937
上位でエラーハンドリングしなければいけないという事実をunwrapで隠蔽してるのでこれもある種の握りつぶし

**デフォルトの名無しさん** · 2025/11/26(水) 11:03:01.70

safe panicで安心安全

**デフォルトの名無しさん** · 2025/11/26(水) 11:25:19.54

>>904
[derive(Debug)]
じゃだめなん？

**デフォルトの名無しさん** · 2025/11/26(水) 11:28:14.69

unwrapの何が悪いって言うと
コンパイル通って実行も出来てうまく処理したつもりになってるアマグラマーを量産してることだな

**デフォルトの名無しさん** · 2025/11/26(水) 11:46:54.66

>>946
まず「新しい型を定義する」ということをやらないといけないだろ。
元の型で取り出すのをいちいち明示するのもわずらわしいから Deref も実装したほうが良いかもしれない。
そのあたりも込みでの話。
Debug 自体をどう実装するか以前の部分で自動化したいってこと。

**デフォルトの名無しさん** · 2025/11/26(水) 12:10:39.11

proc_macro2で割と簡単に出来た気がするが

**デフォルトの名無しさん** · 2025/11/26(水) 13:51:04.55

|&x| ってやるとxが参照じゃなくなるんだけどなんで？

**デフォルトの名無しさん** · 2025/11/26(水) 13:56:50.66

>>950
Rust の引数はパターンマッチのメカニズムをそのまま適用しているから。
参照を &x の形で受けると参照でない部分が x として取り出される。

**デフォルトの名無しさん** · 2025/11/26(水) 14:40:21.92

&はコンストラクターだったってことか

**デフォルトの名無しさん** · 2025/11/26(水) 15:29:16.94

え？

**デフォルトの名無しさん** · 2025/11/26(水) 16:14:24.08

Rustはシンプルに出来ている
C++のバカな考え方に捕らわれてる人はなかなか理解できないか間違った複雑な捉え方をしてしまい正しく理解できないままの人もいる

**デフォルトの名無しさん** · 2025/11/26(水) 16:30:37.62

結局は、プログラムを完成できるかという事と維持のためのクリーンアーキが体現できるかという事で能力が決まる。
仕方なくRustでやってているが、C++がやり易いのは体感だ。　理解の問題ではない。Rustも理解している

**デフォルトの名無しさん** · 2025/11/26(水) 18:23:06.20

>>954
せめてunwrapの使い方くらいは理解してから出直してくれ

**デフォルトの名無しさん** · 2025/11/26(水) 18:56:04.77

クロージャーの引数の型を省略するとFnMutに渡したときライフタイムが正しく推論できなくなるみたいだな

**デフォルトの名無しさん** · 2025/11/26(水) 18:59:06.33

【海外記事紹介】Rustにはガッカリしている
> 11月24日、bykozyが「Blog - Rust is a disappointment」と題した記事を公開した。この記事では、Rustが期待されてきた「C++の後継候補」としての役割を十分に果たしていないのではないかという問題提起を行い、とくにコンパイル速度の遅さ、言語としての複雑さ、メモリ安全性と信頼性のトレードオフ、可変共有状態の扱いにおける限界について詳しく紹介している。

**デフォルトの名無しさん** · 2025/11/26(水) 19:33:52.84

複雑に屋上屋を重ねたC++との比較なのに、Rustに対して「言語としての複雑さ」とか、かなり偏向した人が書いてるな

**デフォルトの名無しさん** · 2025/11/26(水) 19:53:02.22

C++は複雑かつUBだらけで最悪だと書いてるよ
そのうえでRustは万能ではないと述べてる
ただし代替策を示しているわけではない
現状Rustしかないことになる

**デフォルトの名無しさん** · 2025/11/26(水) 21:19:43.49

googolleでchromeos作ってる人がもうc++書きたくないrustてゆってた

**デフォルトの名無しさん** · 2025/11/26(水) 21:43:11.86

>>946
>>903 にあるように、ライブラリが公開してる型がDebugを実装してない場合に困るという話
自作型に derive(Deaug) で自動的にDebugを実装できるのは、その構造体のフィールド全てがDebugを実装してる時だけ
なので、外部ライブラリの型をフィールドとして持つ構造体の場合は、ライブラリ側でDebugを実装してないとダメ
かつ、外部の型に対して impl Debug することもできないから、ラップした構造体が要る

よく使われてるライブラリだと >>910 のガイドに従って Debug を実装してるとは思うけど、実際のところどうなんだろ

**デフォルトの名無しさん** · 2025/11/26(水) 22:06:33.26

自分でももう分かってるでしょう
よく使われてないライブラリだとそんなもんってことです

**デフォルトの名無しさん** · 2025/11/26(水) 22:28:50.07

>>962
Debugの実装くらいならプルリクエスト投げれば対応してくれるのでは？

Debugの表示内容がわかりにくくてラッパー作ったことはあるけど
実装そのものがなくて困った経験は一度もないな

**デフォルトの名無しさん** · 2025/11/27(木) 00:27:00.56

Rustしかないのが問題だよな
Web用のスクリプトといえばPerlしかなかった時代と一緒

**デフォルトの名無しさん** · 2025/11/27(木) 00:54:12.31

それについては >>892 にでも言及している

**デフォルトの名無しさん** · 2025/11/27(木) 04:19:51.35

Rustは良い言語だけどC++の後継にならないのは同意
RustはCの後継にはとても良い

**デフォルトの名無しさん** · 2025/11/27(木) 05:41:05.69

c++後継と言うならテンプレートとコンセプトは欲しいところ。静的ダックタイプの無いc++とか触りたくない。

**デフォルトの名無しさん** · 2025/11/27(木) 05:55:29.12

>>892
今注目されているのはCangjie言語だな
文法がRustっぽいし、企業の全面的なバックアップを受けてるから将来性もある

**デフォルトの名無しさん** · 2025/11/27(木) 09:07:34.98

>>969
中国以外で使われる気がしない･･･

**デフォルトの名無しさん** · 2025/11/27(木) 09:29:28.57

もうコードはAIが書く時代だからね
今更新しい言語を作ったところで学習データがないから圧倒的に不利だし、そもそも人間のコードに対する関心が失われつつある

**デフォルトの名無しさん** · 2025/11/27(木) 09:31:35.09

AIがコード書くんならRustはいらない子だよなあ

**デフォルトの名無しさん** · 2025/11/27(木) 09:43:48.00

>>972
実際、去年ぐらいにrust書かせてみたけど圧倒的にクソコードしか出ないしな
コンパイル通らないし、ライフタイムミスるし

結局俺たちが手でコーデしてる方がはるかに完成度は高いよ
それでAI幻想は完全に消えた
去年の時点でAI崩壊を確信したもん

**デフォルトの名無しさん** · 2025/11/27(木) 09:44:52.90

>>971
試したらわかるがシェルスクリプト、PythonくらいだからなAIが書けるの
コンパイルするやつは何故か下手くそ

**デフォルトの名無しさん** · 2025/11/27(木) 09:52:41.32

Rust が妥当かどうかは別として AI なら過去の (不十分な) 言語で上手くやれるというのは誤った認識だ。
プログラミング言語の進歩というのは要するに大きなプログラムに対して複雑さを抑えて手に負えるものにするという部分が大きい。
特にカプセル化 (それを支える言語機能) が大きな発明だった。

複雑なものを組み合わせると複雑さが爆発的に増大して AI でも全然取り扱えないよ。
よく整理されたものに比べて難易度が無量大数倍とかもっとすごいとんでもない規模で超爆発する。
それを是とするくらいのスーパー AI がいずれ誕生しないとも限らないけど、今のところ人間の専門家ほどではないくらいなんだから言語のほうでもほどほどにいい感じにする必要はある。

**デフォルトの名無しさん** · 2025/11/27(木) 10:33:11.90

やったことないけどAIに機械語かかせたら品質どうなん

**デフォルトの名無しさん** · 2025/11/27(木) 10:39:07.18

>>973
コンパイラや実行環境と連動してないからでしょ
MCP連携してコンパイル結果や実行結果、テスト結果、修正内容なんかを学習していくとすぐに状況変わると思うよ

**デフォルトの名無しさん** · 2025/11/27(木) 10:46:16.01

>>975
人間がやるのと同じでモジュール分割や関数への分解を行わせるステップと、個々のモジュールや関数を書かせるステップを分ければいいだけでは？

AIに使えるプログラムを作らせるためにどういうステップに分けてやるのがいいか自体もAIに聞いたほうがその辺のプログラマーより整理された答えが返ってくる

**デフォルトの名無しさん** · 2025/11/27(木) 11:04:31.44

「思う」とか、末尾疑問符とか、エヌワンな想像と希望的観測でしかない
AIによって作られたサービスの具体的成功例でもあれば別だが

**デフォルトの名無しさん** · 2025/11/27(木) 12:22:46.08

>>979
こういうくだらない批評をするやつがいるから
何でも断定口調で言い切るバカが増えるんだぞ

**デフォルトの名無しさん** · 2025/11/27(木) 12:26:14.65

次スレ
https://mevius.5ch.net/test/read.cgi/tech/1764213923/

**デフォルトの名無しさん** · 2025/11/27(木) 12:29:33.00

va_list で va_arg() 上書きして遊んで観た
やっぱり C おもろいわ最強