探検

Rust part37

レス数が1000を超えています。これ以上書き込みはできません。
1デフォルトの名無しさん
垢版 |
2026/07/17(金) 19:12:31.24ID:yl11920u
公式
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 part36
https://mevius.5ch.io/test/read.cgi/tech/1779974768/

ﾜｯﾁｮｲスレ
プログラミング言語 Rust 4【ﾜｯﾁｮｲ】
https://mevius.5ch.io/test/read.cgi/tech/1514107621/
2デフォルトの名無しさん
垢版 |
2026/07/17(金) 19:16:09.76ID:wUIgB8Rm
複オジが荒らしていた証拠はまだ無いぞ
3デフォルトの名無しさん
垢版 |
2026/07/17(金) 19:18:12.72ID:s2PzIlCn
と複おじが申しておりますｗ
2026/07/17(金) 19:22:38.40ID:w8fD7+NN
いい加減Rustの話しろよ
2026/07/17(金) 19:30:13.46ID:vF10ryxK
ゴミ言語にお似合い
6デフォルトの名無しさん
垢版 |
2026/07/17(金) 19:31:53.17ID:+JpeMOO1
米国防総省DARPA、C言語のコードからRustへの自動変換実現を目指す「TRACTOR」プログラム開始
https://www.publickey1.jp/blog/24/darpacrusttractor.html

NASAのSpaceWasm
github.com/nasa/spacewasm
宇宙船上でWasmバイナリを解釈・実行することを目的とした、Wasm 1.0仕様のインタープリタ

静的サイトジェネレータ「Astro 7.0」正式リリース、ビルドシステムがVite 8/Rolldownに、Rust製コンパイラ採用で高速化 － Publickey
https://www.publickey1.jp/blog/26/astro_70vite_8rolldownrust.html
7デフォルトの名無しさん
垢版 |
2026/07/17(金) 19:33:03.63ID:k26R6pke
😭
https://i.imgur.com/QdnVOt2.png
8デフォルトの名無しさん
垢版 |
2026/07/17(金) 19:36:14.23ID:ChSEsaXo
>>5
またRustの話にいちいち文句付けにきて、信者が騒いでるんだと喚き立てるけど、実は自分達しか騒いでないRustアンチの方が湧いてますね
2026/07/17(金) 20:56:15.35ID:c4bxgt3n
AI「Claude」を使って開発ツールの「Bun」の53万行のZigコード全てをRustへ書き換え
https://gigazine.net/news/20260712-bun-zig-rust/
2026/07/17(金) 21:41:20.51ID:Ql5I3ieQ
>>9
出た、書き換え前のコードも書き換え後のコードも品質に疑問がついてるプロジェクト
2026/07/17(金) 21:45:10.48ID:JC9tgoTJ
>>5
Rustアンチスレ
https://mevius.5ch.io/test/read.cgi/tech/1509028624/
2026/07/17(金) 21:50:41.40ID:dajIDJ3L
>>1
O2
2026/07/17(金) 22:01:03.33ID:VYu7/3A8
>>9
Zigで書かれたひどいコードをAIでRustに移植したらひどくなったプロジェクトかｗ
14デフォルトの名無しさん
垢版 |
2026/07/17(金) 22:03:29.72ID:oePP6y3I
国防総省がやれって言ったんですぅ🥺
15デフォルトの名無しさん
垢版 |
2026/07/17(金) 22:05:15.51ID:oePP6y3I
Claudeは3流AIだからね（笑）

「ChatGPT Images 2.0」発表、AIが"考えてから描く"画像生成モデル　日本語テキストもより正確に
ttps://news.yahoo.co.jp/articles/91802a943832eb571a5b8fe53cb9213931cf653b

OpenAI、サイバー防御向けAI「GPT-5.5-Cyber」を更新　Claude Mythos 5の公表値を上回る
ttps://ledge.ai/articles/openai_gpt_5_5_cyber_codex_security_update
ttps://i.imgur.com/xPmzqDL.png

OpenAIとGoogle、東大理3「首席合格」数学は満点　得意科目に違い
ttps://www.nikkei.com/article/DGXZQOUC307OD0Q6A330C2000000/
2026/07/17(金) 22:05:35.34ID:tHtT3YIU
>>14
JavaScriptランタイムごときに即座にRustに書き換えろとは言わんし、仮に言われるとしてもこんな元々品質の悪いプロジェクトにその話は回ってこないでしょ
2026/07/17(金) 22:06:42.45ID:tHtT3YIU
>>15
AIコーディング・システム設計・運用★7
https://mevius.5ch.io/test/read.cgi/tech/1783239862/l50
2026/07/17(金) 22:12:23.75ID:pA9/Bt95
>>10
>>13
ウソをつくな
Rustへの書き換えで劇的に改善されたぞ
2026/07/17(金) 22:13:05.97ID:jMlbKqfB
>>18
じゃあ改善されても実用レベルに達してないくらい元がひどかったんだろｗ
20デフォルトの名無しさん
垢版 |
2026/07/17(金) 22:13:20.78ID:iEQoz0fM
な？中華系五毛工作員だろ？
デマ流しだし
2026/07/17(金) 22:15:46.64ID:0pKyX/f9
まだ陰謀論唱えてる奴いて草
2026/07/17(金) 22:16:16.31ID:0pKyX/f9
Bunとかいうコードの品質が悪いって話は聞いてもいいって話は聞かないプロジェクト
23デフォルトの名無しさん
垢版 |
2026/07/17(金) 22:16:23.15ID:QhkwTaXN
品質云々よりClaudeの実験台に成り果てたことのほうが影響大きい
24デフォルトの名無しさん
垢版 |
2026/07/17(金) 22:16:49.97ID:1/U5mzJQ
工作員必死だなw
25デフォルトの名無しさん
垢版 |
2026/07/17(金) 22:17:28.60ID:1/U5mzJQ
90連投はよw
2026/07/17(金) 22:17:56.00ID:UUisrM5G
>>23
まあ、元から実用レベルじゃないからどうでもいいわ
実際に使うならNode.jsかDenoだよ
2026/07/17(金) 22:18:28.21ID:1q27v1if
>>25
もうバレてるからやめたら複おじは
2026/07/17(金) 22:19:13.31ID:1q27v1if
今日の複おじID

ID:1/U5mzJQ, ID:5sdmefcx, ID:wUIgB8Rm, ID:eC4f19uq, ID:Fl+jbuiJ, ID:vMRcoCXV, ID:5x3qJX75, ID:CkPxQ3Fs, ID:LF99Jrp3, ID:zFw4SsZH, ID:c5gAJDF2, ID:445eRKs4, ID:WwJl9Mdv, ID:R+0qGLKV, ID:rgZeOBea
2026/07/17(金) 22:19:46.63ID:eJfcvx1B
君ら複おじ好きすぎるだろｗ
見つけちゃったの私だけど
30デフォルトの名無しさん
垢版 |
2026/07/17(金) 22:20:20.75ID:qMEOcDWP
Rustアンチは障害者ってハッキリわかんだね😂
31デフォルトの名無しさん
垢版 |
2026/07/17(金) 22:20:45.52ID:oZBUbB1X
Zig「ドラ息子のBun太郎が出てってくれて清々したわい」
2026/07/17(金) 22:33:29.01ID:eJfcvx1B
アンチスレのリンク貼られてから急にアンチスレ伸びてて草
アンチスレが見つからなかったからここで暴れてたのかな？
33デフォルトの名無しさん
垢版 |
2026/07/17(金) 22:36:33.24ID:0CzXqmPG
今度からアンチスレのリンク貼った方がいいなｗ
34デフォルトの名無しさん
垢版 |
2026/07/17(金) 22:40:45.88ID:y4vHq5F7
Zigのスポンサーが減って名を連ねていた日本企業も消えてるな
2026/07/17(金) 22:43:28.23ID:D2rqlFwL
今日はID変えてないっていうのと、普段はID変えてるってのは両立するからな
5chの1つのスレに、一人で99レスするような執着心持った人間がいるというのを見た他人は
今後スレが単発ID同士で謎に伸びてるのを見るたびに、当然あいつかって思うわけで
2026/07/17(金) 22:43:42.33ID:M0a9nixd
>>34
次世代言語27 Nim Zig Pony Carbon Gleam
https://mevius.5ch.io/test/read.cgi/tech/1659660050/
2026/07/17(金) 22:44:34.94ID:jW2PjOsb
>>35
IDコロコロ変えてる複おじが他にいたことはもうバレてるんだよ
必死で擁護しようとしてるお前は何だろうな？
38デフォルトの名無しさん
垢版 |
2026/07/17(金) 22:45:10.38ID:WAzBosh0
複おじ疑い ID:D2rqlFwL
2026/07/17(金) 22:49:29.76ID:uAxKjlsB
214 デフォルトの名無しさん 2026/07/17(金) 22:42:15.20 ID:FeAkE0rE
>212
the bookも読んだことなかったやつがそこまでイキれるのはすごいな

215 デフォルトの名無しさん 2026/07/17(金) 22:43:41.03 ID:moKvXkjK
そんな専門書を読むほどRustに関心ないからね


複おじ、馬脚を現してしまう

https://mevius.5ch.io/test/read.cgi/tech/1779631921/214-215
2026/07/17(金) 22:50:02.86ID:uAxKjlsB
The bookが専門書は流石に笑っちゃうわ
41デフォルトの名無しさん
垢版 |
2026/07/17(金) 22:57:22.69ID:fQ2Yu4On
RustアンチはRustオンチ
2026/07/17(金) 22:59:01.84ID:4qY+/Zo/
アンチはアンチスレ行こうね

Rustアンチスレ
https://mevius.5ch.io/test/read.cgi/tech/1509028624/
43デフォルトの名無しさん
垢版 |
2026/07/17(金) 23:01:06.48ID:ePVtrIBy
1日に100回も書き込んでスレ荒らし
2026/07/17(金) 23:02:44.33ID:zU+D5K4c
>>43
複おじの投稿数はちゃんと数えられないからってイキってて草
お前の方が荒らしだろ
2026/07/17(金) 23:03:34.48ID:eJfcvx1B
>>44
もしかしたら複おじ側の話かもしれないぞ
46デフォルトの名無しさん
垢版 |
2026/07/17(金) 23:09:24.78ID:2YFyx8fa
rustupが楽すぎてRustから離れられない
2026/07/17(金) 23:10:07.40ID:/C70xpGw
「アンチ」「障害者」の単発レスも複オジ
最近は絵文字使うとオジバレしにくいと思ってるらしい
48デフォルトの名無しさん
垢版 |
2026/07/17(金) 23:11:29.47ID:217WOtru
autoconfから移行した
2026/07/17(金) 23:16:42.10ID:LYxF0rZT
rustup + Cargo でほぼ完結するのが強いよな
2026/07/18(土) 01:20:15.03ID:BkyklCKZ
C書いてた身からすると、構文が式に変わるだけでも書きやすいと思うわ
51デフォルトの名無しさん
垢版 |
2026/07/18(土) 03:10:49.63ID:3wFsDlQx
おじいちゃん明日も暴れるのかな
52デフォルトの名無しさん
垢版 |
2026/07/18(土) 03:43:27.53ID:5+KZhigP
お前らなにに使ってる？web？ベアメタル？CLIツールとか？
2026/07/18(土) 06:26:51.58ID:UAxBgc/R
優秀なプログラマーでも、本番コードで雑なunwrap()してクラッシュやらかすんだな
https://bugzilla.mozilla.org/show_bug.cgi?id=2054317
54デフォルトの名無しさん
垢版 |
2026/07/18(土) 06:51:40.28ID:ZpHbzI7Q
意図的なギャグだろ
これ以上デクリメントできないかもしれないから正しくchecked_subを使ってチェックしつつデクリメントしてるのになぜかunwrap

let remaining = remaining_pre.checked_sub(1).unwrap();
2026/07/18(土) 10:01:16.19ID:z74KpRL6
外部のライブラリのコードを取り込んでいるだけみたいだけどAIがチェックしてたら一発で見つかる類のミスだな
FirefoxにはAIレビューのプロセスはないようだが老害が阻んでるのかな
2026/07/18(土) 10:12:08.27ID:9jLLccHz
AIは何でも見つけられる、見つけられないのはAIを使ってない老害とか発想が池沼かよ
バイブぶるぶるしてGMOの社長レベルのコーディングしかしてなさそう
2026/07/18(土) 10:17:36.64ID:vQ03Z169
さすがに>>54は字面から推測されるセマンティクスのレベルで明らかにおかしいからAIなら余裕で検出できるよ
58デフォルトの名無しさん
垢版 |
2026/07/18(土) 10:21:58.21ID:5+KZhigP
>>56
反AIの前に発言を意図的にねじ曲げる老害だなこりゃ
2026/07/18(土) 11:46:18.99ID:lS2iRe4g
RustはHaskellと同じ道を辿ってる
60デフォルトの名無しさん
垢版 |
2026/07/18(土) 11:50:25.23ID:trQgil6/
​###結論
​RustとHaskellは「プログラミング言語の信頼性を次のステージへ引き上げる」という同じ方向を向いていますが、Haskellは「数学的モデル」という極地へ、Rustは「システムプログラミングの現実的解」という極地へそれぞれ突き進んでいるといえます。

​RustがHaskellの思想を「実用的なシステム開発」に落とし込んだことで、プログラミング言語の世界は「安全性か、性能か」という二者択一の時代を卒業しつつあります。
2026/07/18(土) 11:59:00.59ID:lS2iRe4g
コンパイルの遅さが致命的
62デフォルトの名無しさん
垢版 |
2026/07/18(土) 12:17:09.73ID:fPN4/Wjq
また工作員かよ
63デフォルトの名無しさん
垢版 |
2026/07/18(土) 12:37:50.10ID:O0UMHi+3
RAM爆喰いデブrust-analyzer
2026/07/18(土) 13:15:37.23ID:USe5j2/U
>>59-63
Rustアンチスレ
https://mevius.5ch.io/test/read.cgi/tech/1509028624/
2026/07/18(土) 13:16:42.16ID:JmWwBdWU
>>61 コンパイルが速ければその後どんだけバグってもいい環境ってどこ？ｗ
2026/07/18(土) 13:19:09.20ID:P4UFFXlb
>>54-58
こういうコードはたいていとりあえず動かしてみて検証する時に書いて、そのまま忘れてるってだけだからコードレビューが見落としたのが悪い
AIじゃなくても見つけられて当然のやつ
67デフォルトの名無しさん
垢版 |
2026/07/18(土) 13:19:53.09ID:40i/Za2Z
>>59
アンチの妄想としても流石に現実味がなさすぎるｗ
2026/07/18(土) 13:29:45.06ID:Rn+4EUNx
>>66
これよな
ある程度コード書いてたらとりあえず一旦 .unwrap() はやったことあると思うんだが、はて
2026/07/18(土) 13:36:47.68ID:ZXXBBD3q
>>61
お前はどんな大層なもん作ってるんだ？ｗ
2026/07/18(土) 14:22:23.90ID:1g6Wq8b2
>>61
意図せず遅いのであれば欠陥とも言えるけど
安全性と最適化のために意図してそうなってることなので
2026/07/18(土) 14:47:15.36ID:UQs5GKIu
>>70
それはちょっと違う
Rustのコンパイルが遅い最大の理由は、コードベースやアーキテクチャが複雑で性能改善が困難であること
安全性や最適化とのトレードオフとしてコンパイル速度が犠牲になっているというのは間違いではないが、
それは必ずしもそれらの間に本質的な相反関係があるというより、
開発リソースが前者に消費されてきて後者に手が回っていないという面が大きい
2026/07/18(土) 15:03:51.63ID:tnY5WOXG
RustはAIが無かったらワンチャンあったかもな
ご愁傷様
73デフォルトの名無しさん
垢版 |
2026/07/18(土) 15:16:31.00ID:7NE5BBp7
>>72
信者「いや、AIがあるからこそ！」
2026/07/18(土) 17:10:02.91ID:7HxZyfkA
>>54
remaining_preが1以上であるという不変条件を呼び出し側が守るべきものであればchecked_sub(1).unwrap()は別に不思議ではない
万が一守られなかった場合にoverflowするよりpanicのほうがいいという選択をしてるだけ
2026/07/18(土) 17:17:43.68ID:nLPySRVY
Rustが契約プログラミングをサポートしていない為に起きた悲劇
2026/07/18(土) 17:24:07.82ID:hZhXFCLr
>>71
またRust知識ない奴がイキってて草
ボローチェッカーと比べたら型推論やジェネリクスなんて誤差程度だぞ
2026/07/18(土) 17:24:38.19ID:hZhXFCLr
>>72-73
Rustアンチスレ
https://mevius.5ch.io/test/read.cgi/tech/1509028624/
2026/07/18(土) 17:25:40.86ID:H+oNVQGR
>>75
契約プログラミングについて知らないのはわかった
2026/07/18(土) 17:27:48.29ID:iyTLYbfT
>>72-73
AIがあったら危険物が安全になるとかそういう魔法じゃないんだよｗ
君らはAIを魔法だと思いすぎ
2026/07/18(土) 17:28:23.17ID:5qH6NPW7
>>75
なぜ知らない言葉を使ってしまうのか……
81デフォルトの名無しさん
垢版 |
2026/07/18(土) 17:31:54.51ID:raruskcO
そもそも契約プログラミングって実装継承やりまくりながらどうやって安全性を保つかって話でしょ
Rustではそもそも追跡できない実装継承自体がない
2026/07/18(土) 17:33:17.34ID:gO/u6R2h
>>71
じゃあもっと複雑なC++がRustよりコンパイル速いのはなあぜ？ｗ
2026/07/18(土) 17:34:10.54ID:QMmSWHd4
AIの話はAIのスレでやれよｗ
2026/07/18(土) 17:38:08.79ID:BkyklCKZ
Rustのコンパイルは時間かかるっちゃかかるけど、通ったらメモリ管理のバグがないってことでもあるから、何十倍ものデバッグ時間をなくしてくれてるんだよな
2026/07/18(土) 17:38:49.26ID:pN8HW/1F
>>81
どうやったらそんな理解になってしまうのか逆に興味がある
これが複おじか
2026/07/18(土) 17:43:59.25ID:3ztype1H
>>85
とりあえず気に入らない奴に複おじって言うの、昨日の複おじっぽいムーブだな
2026/07/18(土) 17:48:39.56ID:fVFvrkBl
>>75
アサーションができればできることなんだから、それで書くなりクレート入れるなりすればいいじゃん
何でもかんでも言語仕様に入れろってのはシステムプログラミング言語を知らないから言えること
2026/07/18(土) 17:50:26.24ID:xwwma1Ld
そもそも動的言語じゃないんだからコンパイル時に確定させろよ
2026/07/18(土) 18:01:25.33ID:wTJhW28K
> Rustが契約プログラミングをサポートしていない
ｗｗｗ
2026/07/18(土) 18:24:37.32ID:vQ03Z169
>>82
それは71と何も矛盾しなくて、要は経路依存性があるってことだ
C++の処理系は昔のマシンでも現実的な時間でビルドできるように元々設計されているし、
長い時間と多大な労力をかけて最適化されてきた歴史がある
対してRustは最初から一貫してコンパイル時間よりも実行時のパフォーマンスや機能性や安全性を優先して設計開発されてきたために、
結果的に今更コンパイル時間の最適化をしようとしても困難なコードベースになっちゃってるんだよ
2026/07/18(土) 18:36:34.06ID:Q9n5B/NX
>>86
めちゃくちゃ頓珍漢なことを書いておいて
それを指摘されると気に入る・気に入らないの問題に矮小化する
これが典型的複おじ仕草
2026/07/18(土) 18:47:53.89ID:ByxftqPr
>>87
アサート -> パニック -> クラッシュ
同じじゃん
93デフォルトの名無しさん
垢版 |
2026/07/18(土) 18:49:05.12ID:6FY6jDFX
>>91
自閉症スペクトラム総合スレ86【ASD】発達障害
https://mevius.5ch.io/test/read.cgi/utu/1782020264/
2026/07/18(土) 18:49:07.13ID:bRRjkWzq
>>90
全く説明になっていない
C++にもRustと同様の機能はあるが全部無視している
2026/07/18(土) 18:50:01.93ID:wzNzpPqh
>>92
契約プログラミングについて知らないのはわかった
2026/07/18(土) 18:50:30.55ID:a1xgjEAj
>>92
バカなんだからもう黙っとけばいいのに……
2026/07/18(土) 18:51:13.91ID:qocqIcbB
>>90-92
複おじ激おこで草
98デフォルトの名無しさん
垢版 |
2026/07/18(土) 18:52:45.24ID:KAx9BmlG
>>90
Rustアンチスレ
https://mevius.5ch.io/test/read.cgi/tech/1509028624/
99デフォルトの名無しさん
垢版 |
2026/07/18(土) 18:52:50.06ID:oZOIX5k8
なるほど確かに複おじだ🤔
100デフォルトの名無しさん
垢版 |
2026/07/18(土) 18:54:05.38ID:SCmvlB4y
複おじ=Rustスレのアンチ工作員（障害者）
なるほど🤔
2026/07/18(土) 18:57:23.11ID:Fb+zTE0R
>>94 これなんだよな
RustにあってC++にない機能を探す方が難しいのに、>>90のC++の機能はコンパイル速度を意識して作られてるからだ！は説明になってない
2026/07/18(土) 19:01:47.07ID:xKUzYjr2
処理系って言葉の意味も間違ってるしな
103デフォルトの名無しさん
垢版 |
2026/07/18(土) 19:05:22.72ID:6Xtw014v
C++のエコシステムのモダンなデファクトって何？
crates.io並にライブラリのアップデートがすぐ降りてきたら、結局コンパイル時間は延びるのでは～と思ったんだけど
2026/07/18(土) 19:06:13.40ID:G0DCqtMr
>>90
ボローチェッカーと比べたら型推論やジェネリクスなんて誤差程度だって言われてるのにスルーしてて草
105デフォルトの名無しさん
垢版 |
2026/07/18(土) 19:07:35.61ID:YUvvpBC6
ライブラリのアップデートはあまり関係なくないか
2026/07/18(土) 19:09:40.74ID:Y/lCXk2Z
C++がコンパイル時間を速くするように開発されてきたなんて聞いたことなくて笑う
107デフォルトの名無しさん
垢版 |
2026/07/18(土) 19:22:05.71ID:nqHGciLl
複おじと書き込んでいるスレはいつも単発ID
つまり自演である
2026/07/18(土) 19:24:06.24ID:BkyklCKZ
>>107
また変な奴が湧いてて草
2026/07/18(土) 19:26:49.63ID:7t0C9qmg
>>107お前やｗｗ
110デフォルトの名無しさん
垢版 |
2026/07/18(土) 19:37:12.29ID:O7lnt+k6
複乳おじさん
2026/07/18(土) 19:37:52.44ID:JPI1iXaL
乳は複数あるのが当たり前だろ
112デフォルトの名無しさん
垢版 |
2026/07/18(土) 19:39:17.85ID:tnY5WOXG
Rsut応援隊って一人で何人分の自演してるんだろうな
2026/07/18(土) 19:41:43.80ID:BkyklCKZ
>>112
Rustアンチスレ
https://mevius.5ch.io/test/read.cgi/tech/1509028624/
2026/07/18(土) 19:42:43.18ID:931bcglY
Rustの話もせず荒らしばっかりしてるアンチはアンチスレに帰れよ
2026/07/18(土) 19:45:52.48ID:pzm2C79Q
>>112 隔離場所から出てくるな
2026/07/18(土) 19:49:21.85ID:wpx955w8
隔離場所ｗ
2026/07/18(土) 19:50:37.89ID:csslsvGN
おおよそ180レスのうち、最低でも99レスを1人でやってるって
昨日自分で証明したからな
2026/07/18(土) 19:52:08.75ID:4mwq3zHV
>>117
複おじはもうバレてるんだから黙ってろよｗｗ
2026/07/18(土) 19:53:25.43ID:BkyklCKZ
>>117

複おじこれしか言わないよな
120デフォルトの名無しさん
垢版 |
2026/07/18(土) 19:55:28.63ID:eUVpoTL8
IDをコロコロ変えてずっと罵倒を繰り返してた自分は棚に上げてイキってて草
2026/07/18(土) 19:57:57.48ID:GuXnqFYy
昨日途中までバレてなかったのにバラされたのが気に食わないんだろ
ずっと同じ奴に粘着してスレまで跨いで同じ悪口言い続けてバレないと思ってたのがすごいけど
2026/07/18(土) 19:58:22.65ID:nLPySRVY
Rustが依存型をサポートしていない為に起きた悲劇
2026/07/18(土) 19:59:17.84ID:DC/rUfP8
Rustの話を一切しないくせに自分が正しいと思ってる複おじさんｗ
2026/07/18(土) 20:00:29.49ID:csslsvGN
そんなにIDコロコロ変えて顔真っ赤にするぐらいなら
最初からあんなことやらなきゃよかったのに・・・
2026/07/18(土) 20:01:09.57ID:yQUBEgHM
>>122
お前ってそれっぽいことをテキトーに書き散らしてるだけだよな結局
2026/07/18(土) 20:01:57.62ID:oKNzfSWv
>>124
複おじ、なおも言い訳する模様ｗ
2026/07/18(土) 20:04:28.22ID:KP0FT1Dz
どれだけ言い訳したところで粘着荒らしだという事実は変わらんのにな
2026/07/18(土) 20:06:53.33ID:PfPDuUrP
元々「参照はライフタイム制約を受けない」「任意の参照をその関数に与えて使うことができる」とか吹いてた奴だからな
いかに荒らしと思われたくなくても、複おじには語れるほどのrust知識はありませんw
2026/07/18(土) 20:07:57.95ID:PfPDuUrP
'static はライフタイムとは関係がないとか、どんなスレッドでも先に死なないことを保証できるとかも言ってたな
とにかく何の知識もないくせに知ったかして、指摘されたら粘着荒らしになっただけの奴だから
2026/07/18(土) 20:09:14.34ID:Fn0np0a4
>>124 複おじ一人でどれだけ伸ばしてんだよ
Rustの話しない奴は出て行っていいよｗ
131デフォルトの名無しさん
垢版 |
2026/07/18(土) 20:11:14.99ID:vw5JPlts
障害者は自分の障害を理解できない
何度も同じことをする
周りは学習してるにも関わらず
2026/07/18(土) 21:11:03.37ID:iSIiD7KK
上げる奴が出る度に複おじが出てたから、上げない方が無難かもな
2026/07/18(土) 21:17:46.93ID:58CEps+E
1.97.1が出てたけど、.1リリースなんて久々じゃね
134デフォルトの名無しさん
垢版 |
2026/07/18(土) 21:20:44.19ID:BvQkq3B/
>>133
1.96.1出てただろ
2026/07/18(土) 21:24:45.33ID:5IfudTfu
脆弱性修正したやつあったな
2026/07/18(土) 21:25:13.54ID:mpqSgeiL
>>134
また荒らしが出るからあんま上げんなよ
137デフォルトの名無しさん
垢版 |
2026/07/18(土) 21:25:20.15ID:oKB3ZhEO
572 デフォルトの名無しさん sage 2026/07/01(水) 01:14:29.65 ID:E4CfZuIc
Announcing Rust 1.96.1
https://blog.rust-lang.org/2026/06/30/Rust-1.96.1/

573 デフォルトの名無しさん sage 2026/07/01(水) 02:21:36.27 ID:5WKZWNdO
原因が辛いな

CVE-2025-15661
Updated: 2026-06-23
Title: libssh2 - Heap Buffer Over-read via sftp_symlink() in sftp.c

CVE-2026-55200
Updated: 2026-06-18
Title: libssh2 - Out-of-Bounds Write via Unchecked packet_length in transport.c
2026/07/18(土) 21:26:14.67ID:LnTcQuPa
Cのせいにするなとか被害妄想してる奴が湧いたアプデだろ
2026/07/18(土) 21:31:04.33ID:bhJjxK5U
sshもRustで書き直すしか
140デフォルトの名無しさん
垢版 |
2026/07/18(土) 21:37:05.31ID:3wFsDlQx
おじいちゃん起きたのね
2026/07/18(土) 21:37:44.33ID:66OI5PtW
複オジが逆認定するようになったのか
書いてる内容バレてるのにな

複オジが不要にスレ伸ばすときは
その直前の恥ずかしいレスを流したいとき
2026/07/18(土) 21:40:15.59ID:/BwM9PLt
ID:S/Q9GBk8, ID:bhJjxK5U, ID:PQcA2rQz, ID:9maZOq/z, ID:csslsvGN, ID:tnY5WOXG, ID:nqHGciLl, ID:3wFsDlQx

今日の複おじID
2026/07/18(土) 21:40:45.93ID:mxZyxsu9
>>141
これ
2026/07/18(土) 21:41:17.55ID:dsXaqiMB
だから複おじはスレ上げたがる
2026/07/18(土) 21:45:40.96ID:vuvFx/eF
その脆弱なlibsshをRust化すべき
2026/07/18(土) 21:50:55.20ID:IzFYUrTj
授乳してくる
2026/07/18(土) 21:57:30.52ID:X21kI3ky
複オジは荒らしでかつIDコロコロするから印象が悪い
148デフォルトの名無しさん
垢版 |
2026/07/18(土) 22:02:57.35ID:5aZfHUDW
Rustアンチの障害者
脳みそC++
2026/07/18(土) 22:03:11.70ID:H0jNYHKI
>>147
もしかして複おジ
2026/07/18(土) 22:04:36.67ID:999Zs8cJ
>>149
何言ってんだこいつ
2026/07/18(土) 22:05:12.36ID:NkcqNtb5
>>145
既存資産が一斉に入れ替わらんのはしゃーない
2026/07/18(土) 22:12:32.82ID:BkyklCKZ
Rustは書きやすいからいいわ
Pythonくらい当たり前になっていい
2026/07/18(土) 22:15:20.74ID:oDuxzRvZ
Pythonで書いて、AIにRustへ移植させた方がいい
2026/07/18(土) 22:59:40.08ID:XKrPaHgp
あっちこっちのスレが複おじに汚染されてるな
伸びてるスレは特に
2026/07/18(土) 23:24:01.55ID:oDuxzRvZ
自分が気に食わない奴を雑に複おじ認定してるだけだろ
2026/07/18(土) 23:30:11.78ID:qacgjZ69
Pythonで書いてRustに移植させるとか無駄すぎる
最初からRustで書けばいい
2026/07/18(土) 23:46:18.98ID:qLwxAYh5
慣れてしまえば制約がキツイと思い込んでいたRustがほとんど自由に書けることに気付く
2026/07/18(土) 23:47:26.65ID:ZwCHK2vP
自然とイメージできるようになるよな
2026/07/18(土) 23:58:11.26ID:aTA5mv7+
Rustはかなり自由
どんな寿命の参照でも、それを関数の引数で受け取ったら、その参照や一部の参照を、関数から必ず返せる
どんな値でも、それが自分で作ったものでも、関数の引数として受け取ったものでも、他の関数から返ってきたものでも、関数から必ず返せる
2026/07/18(土) 23:59:00.72ID:LVaDdD2c
>>159
また複おじがめちゃくちゃ言ってるな
2026/07/19(日) 00:00:03.14ID:NTqXfncQ
もう放っとけよ、前スレからずっと同じコピペで荒らしてる奴だし
2026/07/19(日) 00:01:50.45ID:pcmNMsjJ
>>159
まあそう思うならRust書いてみたら？
入門書のリンクも貼っといてやるからさ
https://doc.rust-jp.rs/book-ja/
163デフォルトの名無しさん
垢版 |
2026/07/19(日) 00:03:36.85ID:QfQD4mwM
>>159
それは出来て当たり前
出来ないことは手元にある値の参照を返すことだけ
2026/07/19(日) 00:03:47.21ID:lZWKkSc7
ライフタイムについて知らないド素人もおるんやなあ
2026/07/19(日) 00:05:50.51ID:RWX6Mgcf
>>163
出来て当たり前じゃなくて、同期処理してる時だけだぞ
2026/07/19(日) 00:09:24.83ID:qvC4J9mt
同期処理してれば当然できる
親の方が子より長生きで当然

非同期だとできないこともある
親の方が子より長生きとは限らない
2026/07/19(日) 00:13:38.84ID:PmbNkHZM
非同期でも>>159の文章は必ず成り立つ
168デフォルトの名無しさん
垢版 |
2026/07/19(日) 00:14:25.51ID:M9KOhBFP
>>167
ArcやRcも参照に入れればそうやな
2026/07/19(日) 00:28:34.18ID:efdwttHT
参照カウント式の管理を「参照」だけで語るのは流石に無理かな
それも「必ず」と言ってしまってるわけで
2026/07/19(日) 00:40:34.45ID:liYBpHZW
関数って呼ばれるものの幅って結構広いからね
たぶん>>167の想像にないものがある
2026/07/19(日) 01:21:09.10ID:e7yB+pI/
そもそも参照って曖昧にせずに借用って言えば解決する
172デフォルトの名無しさん
垢版 |
2026/07/19(日) 01:23:36.03ID:jaOC3QMl
cargo check通れば安全と同じこと言いたいんじゃね
2026/07/19(日) 01:30:57.28ID:GVCMKu1f
>>159の関数がasync関数でも成立してる
2026/07/19(日) 01:32:36.58ID:c6sxkJh6
流石に色々無理が生じてきてるなあ
2026/07/19(日) 01:32:50.70ID:GVCMKu1f
>>168
ArcやRcは参照ではなく所有
2026/07/19(日) 01:33:42.90ID:0R5aWyYh
>>172
どんなテストでもツールでもそれだけを妄信しちゃいかんのにな
「必ず」とか言い出す奴はだいたいダメ
2026/07/19(日) 01:35:51.00ID:GVCMKu1f
>>159は必ず成立する
反例はない
2026/07/19(日) 01:37:32.53ID:JZtLLXX2
関数の範囲をできるだけ狭めて、参照の範囲をできるだけ広げれば、はい
2026/07/19(日) 01:38:17.82ID:L9V97nS8
定義を都合よく曲げるのはよくない
2026/07/19(日) 01:39:33.10ID:GVCMKu1f
参照は&Tだろ
関数はfnだろ
async fnでも同様に>>159は成立
2026/07/19(日) 01:41:54.40ID:iHrJKnes
いかなるライフタイムでもと言い切ってるからなあ
それだと成立しないと思われる
「コンパイルが通れば」みたいな言ってない条件を勝手に追加してそう
2026/07/19(日) 01:45:00.32ID:JZtLLXX2
「どんな参照でも必ず返せる」は「いずれかの参照なら必ず返せる」とは真逆の意味なんでなあ
全部返せないと成立しない
2026/07/19(日) 01:46:06.97ID:GVCMKu1f
少なくとも>>159は任意のライフタイムで必ず成立する
成立しないと思う人は反例コードを示せばいい
2026/07/19(日) 01:54:15.82ID:RCcAcUe+
弱参照を受け取ってそれを通常の参照に変換して返す関数を書いてみて
2026/07/19(日) 01:56:48.64ID:RCcAcUe+
今のAIだとこのくらいは簡単か
2026/07/19(日) 02:01:08.20ID:2iSHfWbm
しょうがないにゃあ

fn foo<'a, 'b, T>(o: &'a mut Option<&'b mut T>, v: &'b mut T) -> &'b mut T {
*o = Some(v);
v
}
2026/07/19(日) 02:56:53.38ID:GVCMKu1f
>>184
弱参照は指す先が無効になってる場合も安全に扱えるようにするためのもの
だから参照への変換は原理的に不可能
弱参照自体は返すことがてきる
2026/07/19(日) 02:58:13.82ID:GVCMKu1f
>>186
それは可変参照が借用中に同時に可変参照を使えないだけ
借用を終えたら可変参照も返すことができる
2026/07/19(日) 03:11:42.53ID:GVCMKu1f
ここまでに>>159の反例コードを示せた人なし
2026/07/19(日) 05:23:51.53ID:JZtLLXX2
どんどん条件付け足して反例なしって言うの不毛すぎる
2026/07/19(日) 05:25:16.00ID:JZtLLXX2
どんな参照でも返せるって言ったんだから、ID:GVCMKu1fは言い訳してないで条件を変えずに通せる方法を書けよ
2026/07/19(日) 05:30:54.76ID:R3XW/jFb
そもそもどんな参照でもどんな関数でもって条件だから、他のスレッドから借用した場合も対象だよね
しかも条件を何もしてしてないから、本体側のスレッドが先に死んでもいい
これはコンパイルを絶対に通らない条件なので不成立だけど、どんな参照でもどんな関数でも返せるという主張の反例にはなってる
まあ、また条件を増やすかもしれないがｗ
2026/07/19(日) 05:32:39.47ID:GVCMKu1f
>>191
新たな条件を一つも加えていない
引数で受けた弱参照も必ず返せる
引数で受けた可変参照も必ず返せる
今回の元の文章は以下のように書かれている

>>159
>>どんな寿命の参照でも、それを関数の引数で受け取ったら、その参照や一部の参照を、関数から必ず返せる
2026/07/19(日) 05:34:18.67ID:GVCMKu1f
>>192
それは以下の反例になっていない

>>159
>>どんな寿命の参照でも、それを関数の引数で受け取ったら、その参照や一部の参照を、関数から必ず返せる
2026/07/19(日) 05:34:52.88ID:uDfx31sS
そのうち「コンパイルを通る場合で」とか言い出しそう
コンパイルを通るならボローチェッカーの検証済みだから必ず成立する、だからこの条件でトートロジーにできる
2026/07/19(日) 05:37:02.31ID:hgCgzwLk
>>194
thread::spawnは関数じゃマヌケ
2026/07/19(日) 05:38:10.14ID:JZtLLXX2
早すぎて笑った
2026/07/19(日) 05:40:08.69ID:lZWKkSc7
つまり>>192は
どんな寿命の参照でも → 当然 ○
それを関数の引数で受け取ったら → thread::spawnは関数なので ○
その参照や一部の参照を、関数から必ず返せる → 本体側のスレッドが先に死んだら不成立 ×
ってことか
2026/07/19(日) 05:41:27.23ID:GVCMKu1f
>>196
参照を引数に取らない関数も参照を返さない関数も無数にあるのは当たり前
それは無関係な話
自分で作る関数が引数で受けた参照を常に返せるかの話しかなされていない
2026/07/19(日) 05:43:17.97ID:pVNBiKRX
>>199
また勝手に条件増やしてて草
2026/07/19(日) 05:43:42.64ID:GVCMKu1f
>>200
条件は一切増えていない
2026/07/19(日) 05:44:10.89ID:8bVK7uZA
>>199
スレッドを作る関数を自分で作れないとする根拠がないと成り立たない主張だということは気付いてるのか？ｗ
2026/07/19(日) 05:44:51.96ID:8bVK7uZA
>>201
ハイ嘘
> 自分で作る関数が引数で受けた参照を常に返せるかの話しかなされていない
こんなことはここまで言っていない
2026/07/19(日) 05:46:07.72ID:GVCMKu1f
>>202
もちろん何を作っても構わない
以下は必ず成立する

>>159
>>どんな寿命の参照でも、それを関数の引数で受け取ったら、その参照や一部の参照を、関数から必ず返せる
2026/07/19(日) 05:47:07.17ID:8bVK7uZA
>>204
ハイ嘘
thread::spawnと同じ機能を持つ関数を作ると不成立
2026/07/19(日) 05:48:30.91ID:ksx89YE4
しかもシステムコールするだけの結構簡単な関数なの草
2026/07/19(日) 05:50:20.75ID:GVCMKu1f
>>205
それは以下に明記されてる前提を満たせないから明らかに対象外
「関数の引数で受け取ったら、」

>>159
>>どんな寿命の参照でも、それを関数の引数で受け取ったら、その参照や一部の参照を、関数から必ず返せる
2026/07/19(日) 05:50:21.46ID:OKx6aoV/
>>195
そろそろ本当に「返せるように書けば」って言いそうｗ
2026/07/19(日) 05:51:43.97ID:ChE1xJ7G
>>207
どう見てもthread::spawnは引数で受け取ってますねｗ
2026/07/19(日) 05:52:50.17ID:JZtLLXX2
関数の引数で受け取ったら ←これは疑う余地ない件
むしろ参照をスレッドに渡す設計はよくないとか言って話をそらした方がまだ戦えるレベル
2026/07/19(日) 05:54:28.00ID:GVCMKu1f
>>209
spawnの引数が何なのか知らない無知な人は勉強して出直してきてね
2026/07/19(日) 05:56:49.23ID:Rf75bjax
>>211
「引数で受け取ったら」って書いたのはお前じゃいｗ
「引数に参照を取る関数」なんて書いてない
2026/07/19(日) 05:57:55.40ID:Rf75bjax
thread::spawnの引数で参照を扱うことはもちろん可能
実際 'static ライフタイムになっていれば受け渡せる
2026/07/19(日) 05:58:01.87ID:GVCMKu1f
Rustでは付加条件なく必ず成り立ちます

>>159
>>どんな寿命の参照でも、それを関数の引数で受け取ったら、その参照や一部の参照を、関数から必ず返せる
2026/07/19(日) 05:59:31.74ID:Rf75bjax
>>214
ついに反論できなくなって逃げたな
反例: thread::spawn()
2026/07/19(日) 06:01:44.05ID:Jl4j9YwN
そもそも「引数に参照を取る関数」に書き換えたところでそういう引数を受け取るようにスレッドを作る自作関数を作ればそれで成り立たなくなる模様
2026/07/19(日) 06:03:21.76ID:GVCMKu1f
>>215
反例になっていない
まずspawnの場合は引数はクロージャ
クロージャでキャプチャされてきた参照は必ず返すことができる
2026/07/19(日) 06:04:15.48ID:EmK47w2v
>>217
「引数で受け取ったら」って書いたのはお前
「引数に参照を取る関数」なんて書いてない
2026/07/19(日) 06:04:45.12ID:GVCMKu1f
>>216
まずは>>159の反例コードを作ってみたら？
まだ誰も示せてないから
220デフォルトの名無しさん
垢版 |
2026/07/19(日) 06:05:39.46ID:G8pyxalB
Pin止め忘れたFutureの参照はどう？
条件に合ってるけど死なないかな
だからUnpin設計する羽目になったわけだし
2026/07/19(日) 06:05:55.54ID:lZWKkSc7
「どんな寿命の参照でも」って言いきった以上今更「返せる寿命なら」って言ったらそれはそれで条件を変えてる
2026/07/19(日) 06:06:21.26ID:GVCMKu1f
>>218
論理が苦手なのかな
>>159の反例を示せないといけないんだよ
2026/07/19(日) 06:08:09.37ID:Uh8aYRzM
>>222
アホめ
そっちは「他の関数から返ってきたものでも」とも書いてるから余計にドツボなんじゃ
2026/07/19(日) 06:08:26.36ID:GVCMKu1f
>>221
どんな寿命の参照でも大丈夫
Rustではそれを関数の引数で受け取ったら関数から必ず返せる

>>159
>>どんな寿命の参照でも、それを関数の引数で受け取ったら、その参照や一部の参照を、関数から必ず返せる
2026/07/19(日) 06:09:15.94ID:ksx89YE4
元より条件狭めてもなお敗北してるの草
2026/07/19(日) 06:09:27.47ID:GVCMKu1f
>>223
もし反例があるならRustコードで示しましょう
2026/07/19(日) 06:09:47.03ID:ksx89YE4
>>224
反例: thread::spawn()
2026/07/19(日) 06:10:09.25ID:ksx89YE4
>>226
反例: thread::spawn()
2026/07/19(日) 06:10:41.97ID:GVCMKu1f
>>225
条件は以下の元の文章一切変更していない
この元の文章のまま必ず成り立つ

>>159
>>どんな寿命の参照でも、それを関数の引数で受け取ったら、その参照や一部の参照を、関数から必ず返せる
2026/07/19(日) 06:11:42.73ID:UBIO/xPU
>>229
反例: thread::spawn()
2026/07/19(日) 06:13:16.83ID:GVCMKu1f
>>227
spawnでも成り立ってますよ
指定クロージャがキャプチャしてきた参照は必ず'staticになるため必ず返すことができます
2026/07/19(日) 06:15:09.80ID:MjpkG5aN
>>231
あ、ついにやったな
バレないと思ったかもしれないがそれは渡された参照が 'static の場合だけ
こっそり「どんな寿命の参照でも」を消してる
2026/07/19(日) 06:16:27.03ID:wLxs3A5R
なんでこんな偉そうにしてる奴がいたら全力で叩きたい連中のたまり場でここまでツッコミどころ満載のイキり発言をしてしまったのか……
2026/07/19(日) 06:16:35.28ID:GVCMKu1f
>>232
もちろん
どんな寿命の参照でも
『それを関数の引数で受け取ったら』
必ず返せます

元の書き込み
>>159
>>どんな寿命の参照でも、それを関数の引数で受け取ったら、その参照や一部の参照を、関数から必ず返せる
2026/07/19(日) 06:18:50.69ID:3mnun1V8
>>234
反例: thread::spawn()

あと、元の書き込みを印籠にしたいなら
> どんな値でも、それが自分で作ったものでも、関数の引数として受け取ったものでも、他の関数から返ってきたものでも、関数から必ず返せる
もちゃんと書いとけマヌケ
2026/07/19(日) 06:21:17.49ID:GVCMKu1f
>>235
まずspawnの仕様をよく見ようよ
spawnには'staticしか来ない
だからspawnの場合も以下が成立している

>>159
>>どんな寿命の参照でも、それを関数の引数で受け取ったら、その参照や一部の参照を、関数から必ず返せる
2026/07/19(日) 06:23:19.38ID:kyJHd/y9
>>236
ついに言ったぞ！
>>195の「コンパイルを通る場合で」のやつだ
ついにトートロジーを始めましたｗｗ
2026/07/19(日) 06:23:54.02ID:YCyVvPUO
劣化するの早かったなあｗ
2026/07/19(日) 06:27:11.78ID:GVCMKu1f
おまえら日本語をどう捉えてるんだい？
俺はこう解釈した

【前提】どんな寿命の参照でも、それを関数の引数で受け取ったら、
【恒真】その参照や一部の参照を、関数から必ず返せる

>>159
>>どんな寿命の参照でも、それを関数の引数で受け取ったら、その参照や一部の参照を、関数から必ず返せる
2026/07/19(日) 06:28:57.71ID:5AkW9j9X
>>239
その主張は流石に無理があるわ
それだと「どんな寿命の参照でも」はほぼ嘘になる
2026/07/19(日) 06:29:58.00ID:GVCMKu1f
>>240
どんな寿命の参照でも成り立つよ
明記されてるように、関数の引数として受け取ったものに関しては
2026/07/19(日) 06:30:14.48ID:JmLpZhD6
>>239
必死で言い訳しても、主張がコロコロ変わってる時点でもう見苦しいだけなんだよな
最初の主張通り thread::spawn() で 'static 以外を返してみろよ
2026/07/19(日) 06:31:52.52ID:GVCMKu1f
>>242
spawnの場合は'static以外は前提が成り立たないことを理解できないのか？

【前提】どんな寿命の参照でも、それを関数の引数で受け取ったら、
【恒真】その参照や一部の参照を、関数から必ず返せる

>>159
>>どんな寿命の参照でも、それを関数の引数で受け取ったら、その参照や一部の参照を、関数から必ず返せる
2026/07/19(日) 06:34:09.30ID:iGuMvbCY
>>243
そう主張したいなら>>183の「任意のライフタイムで必ず成立する」は嘘だったって言わないとなｗ
「本体の寿命が参照よりも長い場合に限って」に書き換えとけマヌケ
2026/07/19(日) 06:35:13.01ID:GVCMKu1f
>>244
これは任意のライフタイムで必ず成立する

【前提】どんな寿命の参照でも、それを関数の引数で受け取ったら、
【恒真】その参照や一部の参照を、関数から必ず返せる

>>159
>>どんな寿命の参照でも、それを関数の引数で受け取ったら、その参照や一部の参照を、関数から必ず返せる
2026/07/19(日) 06:35:33.30ID:JUSFYQBq
そんなことも言ってたのか
「任意のライフタイムで必ず成立する」なら「どんな寿命の参照でも」だけで前提と捉えるべきだな
2026/07/19(日) 06:37:32.58ID:qD6+yINI
>>245
主張変わってて草
thread::spawn() でも>>214で「Rustでは付加条件なく必ず成り立ちます」と言ってる
でも今「どんな寿命の参照でも」は実は「コンパイラが通してくれたら」って意味だったんですよ、と条件を足してる
2026/07/19(日) 06:37:54.40ID:GVCMKu1f
>>246
『それを関数の引数で受け取ったら、』と条件が明記されてるだろ
これは任意のライフタイムで常に成立

>>159
>>どんな寿命の参照でも、それを関数の引数で受け取ったら、その参照や一部の参照を、関数から必ず返せる
2026/07/19(日) 06:38:13.17ID:JZtLLXX2
案の定条件足してて草
もう何も言わない方が埋もれていくからマシなのに
2026/07/19(日) 06:39:39.62ID:k7o4mZYf
>>248
「任意のライフタイムで必ず成立する」(>>183)
「Rustでは付加条件なく必ず成り立ちます」(>>214)
「『それを関数の引数で受け取ったら、』と条件が明記されてるだろ」(>>248)
やってますなあｗ
2026/07/19(日) 06:40:05.35ID:GVCMKu1f
>>247
>>248
条件を一切変えていない
条件を加えてもいない
Rustで以下は常に成り立つ

【前提】どんな寿命の参照でも、それを関数の引数で受け取ったら、
【恒真】その参照や一部の参照を、関数から必ず返せる

最初に書き込まれた文章
>>159
>>どんな寿命の参照でも、それを関数の引数で受け取ったら、その参照や一部の参照を、関数から必ず返せる
2026/07/19(日) 06:41:40.08ID:GVCMKu1f
>>250
どこに新たな条件が加わってるんだ？
最初から書き込まれているぞ

>>159
>>どんな寿命の参照でも、それを関数の引数で受け取ったら、その参照や一部の参照を、関数から必ず返せる
2026/07/19(日) 06:41:42.36ID:j73AhSk6
>>251
元の書き込みを印籠にしたいなら
> どんな値でも、それが自分で作ったものでも、関数の引数として受け取ったものでも、他の関数から返ってきたものでも、関数から必ず返せる
もちゃんと書いとけマヌケ
そんな条件とやらはこの文章には書いてないけどなｗ
曲解もいいところｗｗ
254デフォルトの名無しさん
垢版 |
2026/07/19(日) 06:43:17.79ID:fpgmEylb
おじいちゃん早起き
2026/07/19(日) 06:43:40.66ID:j73AhSk6
元の書き込み（正しいもの）>>159
> Rustはかなり自由
> どんな寿命の参照でも、それを関数の引数で受け取ったら、その参照や一部の参照を、関数から必ず返せる
> どんな値でも、それが自分で作ったものでも、関数の引数として受け取ったものでも、他の関数から返ってきたものでも、関数から必ず返せる

どんな値でも、とも言いきってるから「実は『コンパイルが通ったら』という条件が付いてる」という主張は通らんな
2026/07/19(日) 06:44:42.15ID:GVCMKu1f
反例が出ないようなので
アンチもRustでは以下が必ず成立することを認めるしかないよね

>>159
>>どんな寿命の参照でも、それを関数の引数で受け取ったら、その参照や一部の参照を、関数から必ず返せる
2026/07/19(日) 06:48:57.23ID:JHxWwbLd
>>256
お前が騙せてるの自分だけだぞｗ
2026/07/19(日) 06:53:33.70ID:GVCMKu1f
>>257
反例を出せなきゃあなたの負け
2026/07/19(日) 06:55:35.55ID:DrMR6SBy
>>258
もう出まくってるだろ
言い訳してなかったことにしようとしてそれでも反論できなくなってついに何も聞かずに「あなたの負け」って言い続けるbotになったお前の負け
2026/07/19(日) 06:57:21.58ID:GVCMKu1f
>>259
反例どれだよ？
spawnの場合も前提を満たすものは必ず成り立つぞ

【前提】どんな寿命の参照でも、それを関数の引数で受け取ったら、
【恒真】その参照や一部の参照を、関数から必ず返せる

>>159
>>どんな寿命の参照でも、それを関数の引数で受け取ったら、その参照や一部の参照を、関数から必ず返せる
2026/07/19(日) 06:57:54.47ID:ue61OBhB
「任意のライフタイムで必ず成立する」(>>183)
「Rustでは付加条件なく必ず成り立ちます」(>>214)
「『それを関数の引数で受け取ったら、』と条件が明記されてるだろ」(>>248)
2026/07/19(日) 06:59:13.58ID:hEDHzyU0
>>260
> spawnの引数が何なのか知らない無知な人は勉強して出直してきてね (>>211)
ここで一旦参照を受け取るって部分の条件変えて逃げようとしたのも忘れてないからなｗ
2026/07/19(日) 06:59:59.37ID:GVCMKu1f
>>261
その通り
Rustでは任意のライフタイムでも付加条件なく以下が必ず成立する

>>159
>>どんな寿命の参照でも、それを関数の引数で受け取ったら、その参照や一部の参照を、関数から必ず返せる
2026/07/19(日) 07:00:02.07ID:SrO1Zqc0
最初から「コンパイルが通ればコンパイルが通る」ってトートロジーだったならこの逃げいらないの草
2026/07/19(日) 07:01:05.91ID:CxcVSvRk
>>263
最初から「コンパイルが通ればコンパイルが通る」ってトートロジーだったなら
> spawnの引数が何なのか知らない無知な人は勉強して出直してきてね (>>211)
ここで一旦参照を受け取るって部分の条件変えて逃げようとしたのは説明できないよね
嘘吐きミッケ！
2026/07/19(日) 07:02:28.07ID:vgx8yFVs
なんでこんな偉そうにしてる奴がいたら全力で叩きたい連中のたまり場でここまでツッコミどころ満載のイキり発言をしてしまったのか……
2026/07/19(日) 07:02:37.07ID:GVCMKu1f
>>265
その主張したい意味がわからない
以下は崩れないよ
Rustでは必ず成り立つことだから

>>159
>>どんな寿命の参照でも、それを関数の引数で受け取ったら、その参照や一部の参照を、関数から必ず返せる
2026/07/19(日) 07:03:43.17ID:vgx8yFVs
>>267
わからないってことにして逃げてて草
最初から「コンパイルが通ればコンパイルが通る」って進次郎構文だったなら何で条件変えて逃げようとしたんだって言われてんだよ
後からそういうことにした以外に理由ないだろうが
2026/07/19(日) 07:04:14.54ID:X+Nh8ZgR
最初から「コンパイルが通ればコンパイルが通る」ってトートロジーだったなら
> spawnの引数が何なのか知らない無知な人は勉強して出直してきてね (>>211)
ここで一旦参照を受け取るって部分の条件変えて逃げようとしたのは説明できない
2026/07/19(日) 07:05:20.29ID:GVCMKu1f
>>268
コンパイルは関係ないだろ
このどこに出てくるんだよ？

>>159
>>どんな寿命の参照でも、それを関数の引数で受け取ったら、その参照や一部の参照を、関数から必ず返せる
2026/07/19(日) 07:06:17.88ID:ZWUPg6E2
>>270
お前が 'static しか受け取れないから成立するって吹いたんだろうがｗ
もう忘れたのか
2026/07/19(日) 07:06:50.85ID:ehvtZBcJ
>>270
はいはい、えらいでちゅねー
ID:GVCMKu1fがただしかったってことで、いいとおもいます！
2026/07/19(日) 07:07:47.41ID:3OzOrXHp
>>272
おっ、そうだな
2026/07/19(日) 07:07:55.58ID:GVCMKu1f
>>269
どこに逃げがあるんだい
元の書き込まれた文章から一字一句変えてない
そのまま常に成立している

>>159
>>どんな寿命の参照でも、それを関数の引数で受け取ったら、その参照や一部の参照を、関数から必ず返せる
2026/07/19(日) 07:09:33.53ID:7T4bhUIg
>>274
spawnの引数がクロージャだから参照は受け取れないって逃げ打ってたのごまかしてて草
2026/07/19(日) 07:09:36.28ID:GVCMKu1f
>>271
そのどこに以下のRustでの常識を崩す要素があるのかね

>>159
>>どんな寿命の参照でも、それを関数の引数で受け取ったら、その参照や一部の参照を、関数から必ず返せる
2026/07/19(日) 07:10:12.89ID:7dGloKYE
>>274
もう頑張ったから正解ってことでいいんじゃね
正解正解、よくできましたｗ
2026/07/19(日) 07:12:03.36ID:7dGloKYE
>>276
「どんな寿命の参照でも」「どんな値でも」「他の関数から返ってきたものでも」(>>159)
「任意のライフタイムで必ず成立する」(>>183)
「Rustでは付加条件なく必ず成り立ちます」(>>214)

これについて説明はよｗ
2026/07/19(日) 07:12:14.14ID:GVCMKu1f
>>275
そんなウソをついてまで叩きたいのかね
2026/07/19(日) 07:12:38.17ID:D64cpFCR
>>278
おいおい、正解ってことにしてあげるんじゃなかったのかｗ
2026/07/19(日) 07:13:15.97ID:8u5SMf+8
>>279
全部書き込み残ってるのに今更嘘だと言い張って逃げられると思ってるのは流石に笑うしかない
2026/07/19(日) 07:13:48.75ID:Hvp4Yrmg
>>279
えらいねー
いじめてくるひとひどいねーｗ
2026/07/19(日) 07:14:40.53ID:tK5f88Vh
>>279
おー、はなまるだねぇ
えらいぞえらいぞー
2026/07/19(日) 07:14:48.83ID:GVCMKu1f
>>278
もちろんRustにおいては任意のライフタイムで以下が成立するよ

>>159
>>どんな寿命の参照でも、それを関数の引数で受け取ったら、その参照や一部の参照を、関数から必ず返せる
2026/07/19(日) 07:15:43.84ID:tK5f88Vh
>>284
> どんな値でも、それが自分で作ったものでも、関数の引数として受け取ったものでも、他の関数から返ってきたものでも、関数から必ず返せる
これはどこに行ったんだよｗ
2026/07/19(日) 07:16:14.97ID:qTzUVwoN
ID:GVCMKu1fくんはよく頑張ったのではなまるです！
2026/07/19(日) 07:16:26.99ID:GVCMKu1f
>>281
証拠があるなら示せばいい
どうせキミが読み間違いか曲解か妄想しただけだろ
2026/07/19(日) 07:17:27.16ID:GVCMKu1f
>>285
それは並列するもう一つの話だよね
2026/07/19(日) 07:17:34.01ID:yZ5c9xlM
>>287
こんだけ書かれてるのに見事に都合の悪い部分はスルーしてるなｗ
ずっと曲解してるのはお前だしｗｗ
2026/07/19(日) 07:18:32.08ID:GVCMKu1f
>>289
証拠があるならダイレクトに示しなさい
2026/07/19(日) 07:18:47.17ID:2IPBj72V
>>288
そんなわけなくて草
どう見ても「関数から必ず返せる」だけじゃ何を返せるのか書いてないから前のものの続きとしか解釈できない
「それは並列するもう一つの話だよね」←国語のテストなら0点
2026/07/19(日) 07:19:34.28ID:lR4pMYKt
>>290
示されてるのにずっと逃げてる奴が偉そうで草
曲解以外にお前の回答ってないじゃんｗ
2026/07/19(日) 07:19:46.77ID:GVCMKu1f
>>291
そんなこと俺に言われてもな
2026/07/19(日) 07:20:16.37ID:nnBRRqIz
>>293
お前がめちゃくちゃな読み方したんだろうがｗ
2026/07/19(日) 07:21:17.05ID:ak5oibCb
がんばってるID:GVCMKu1fくんがえらいにきまってるでしょ！
ひとつあてはまらないからってえらそうですよ！！
2026/07/19(日) 07:21:38.63ID:GVCMKu1f
まずRustでは以下が常に成り立つという話は合意でいいんだな？
以下に明記されてる前提を満たす反例が出て来ないため

>>159
>>どんな寿命の参照でも、それを関数の引数で受け取ったら、その参照や一部の参照を、関数から必ず返せる
2026/07/19(日) 07:21:47.35ID:PrEgWlO6
草
2026/07/19(日) 07:22:09.50ID:PrEgWlO6
>>296
もうそれでいいんじゃね、お前の中ではｗ
2026/07/19(日) 07:22:33.99ID:d4DOYcOx
>>296
そういう妄想をするのは自由だと思うよ
2026/07/19(日) 07:22:51.18ID:GVCMKu1f
>>295
例外は一つもない
Rustで以下は絶対に成り立つ

>>159
>>どんな寿命の参照でも、それを関数の引数で受け取ったら、その参照や一部の参照を、関数から必ず返せる
2026/07/19(日) 07:23:20.62ID:CbyOkROJ
ID:GVCMKu1fくんはがんばってるから100てんなのです！
えらいのですよ〜
2026/07/19(日) 07:23:58.26ID:ead1Jdp1
>>300
お前の世界ではそうなんだなｗ
2026/07/19(日) 07:25:29.52ID:NsPSD/p5
荒らしを弄って遊ぶ会
2026/07/19(日) 07:25:39.44ID:GVCMKu1f
普段Rustでプログラムを書いていたら以下が成り立ってることくらいわかるはず
返せない例がないので

>>159
>>どんな寿命の参照でも、それを関数の引数で受け取ったら、その参照や一部の参照を、関数から必ず返せる
2026/07/19(日) 07:26:19.73ID:FFXH6LmV
ID:GVCMKu1fくんはがんばってるからえらいんですよ！
だからあらしじゃありません！ｗ
2026/07/19(日) 07:26:32.40ID:cWtPimWQ
>>303
もう尾張だねこの言語
2026/07/19(日) 07:27:45.14ID:NFhUPYue
>>304
お前が書いたことあるコードとか知らんがなｗ
thread::spawn() すら思いつかない時点でどうせ大したもん書いてないだけ
2026/07/19(日) 07:28:29.57ID:Jcyfean4
>>307
言ってやるなよ可哀想だろ
2026/07/19(日) 07:29:17.38ID:uowPgdJa
>>306
こっそり書いても何書いてるかバレないわけじゃないんだぞ

Rustアンチスレ
https://mevius.5ch.io/test/read.cgi/tech/1509028624/
2026/07/19(日) 07:29:51.08ID:TeHdH/FF
がんばってるID:GVCMKu1fくんがただしいとおもいます！
2026/07/19(日) 07:30:15.91ID:GVCMKu1f
>>307
明記されてる条件『それを関数の引数で受け取ったら、』を満たす反例が出て来ない
spawnでも受け取った参照は返せる

>>159
>>どんな寿命の参照でも、それを関数の引数で受け取ったら、その参照や一部の参照を、関数から必ず返せる
2026/07/19(日) 07:32:01.38ID:DoYz9Jmg
>>311
一生その妄想に浸ってればいいと思うよ
2026/07/19(日) 07:33:08.45ID:GVCMKu1f
>>312
あんたこそ前提を満たす反例を持ってこいよ
2026/07/19(日) 07:33:48.23ID:79NbkuOh
>>313
後から勝手にトートロジーにしておいてなんか言ってて草
2026/07/19(日) 07:34:20.15ID:GVCMKu1f
>>314
後から？
一字一句変えてないが
2026/07/19(日) 07:34:42.00ID:vv4RgEGt
もうID:GVCMKu1fが頑張ってるから勝ちでいいよマジで
どうせ何言っても聞く気ないし同語反復するだけの壊れたラジオじゃん
2026/07/19(日) 07:35:09.52ID:w2KdlMOm
>>315
一字一句変えてない（曲解しまくったから）
2026/07/19(日) 07:36:04.90ID:loiaJuTI
ID:GVCMKu1fの勝ち
理由: なんか頑張ってるから
2026/07/19(日) 07:36:39.03ID:GVCMKu1f
Rustアンチの人はたった一つの反例を示せばいいのに示せないまま
Rustにおいては以下が必ず成り立つからね

>>159
>>どんな寿命の参照でも、それを関数の引数で受け取ったら、その参照や一部の参照を、関数から必ず返せる
2026/07/19(日) 07:37:23.79ID:64rRBRf+
>>319
はいはい、そう思うんならそれでいいんじゃね
2026/07/19(日) 07:38:01.10ID:J0w23NZl
>>319勝手にそう思ってていいからもう黙っていいぞ
2026/07/19(日) 07:39:36.76ID:J0w23NZl
>>319
お前の書いてるRustはそうなんだろ？
そんなに怒って何が言いたいんだい？ｗ
2026/07/19(日) 07:41:21.68ID:Pbg4OqFR
>>319
こんなすれにまじになっちゃってどうするの
2026/07/19(日) 07:41:26.89ID:GVCMKu1f
Rustアンチの人は反例を示せないままデタラメに否定してたからね
以下のRustにおける常識を

>>159
>>どんな寿命の参照でも、それを関数の引数で受け取ったら、その参照や一部の参照を、関数から必ず返せる
2026/07/19(日) 07:42:42.31ID:IR1/PVyP
>>324
お前の中ではそれで正しいんだろ？
だったらもうそれでいいじゃん
2026/07/19(日) 07:43:09.98ID:8KySyXbb
ID:GVCMKu1fがただしかったってことで、いいとおもいます！
2026/07/19(日) 07:43:13.02ID:GVCMKu1f
>>321
>>322
時々IDを変え忘れて同じIDのまま二度レスしてるね
2026/07/19(日) 07:44:26.57ID:Xc6J5cNr
>>327
単に同一人物なだけだろ
矛盾したことも言ってないし
2026/07/19(日) 07:45:11.59ID:10Ib5hsB
>>327
そうだねー、いじめられてかわいそかわいそ
2026/07/19(日) 07:47:05.41ID:yPYKroD9
>>323
たけしの挑戦状で草
2026/07/19(日) 07:47:17.32ID:GVCMKu1f
全ての書き込みが
ID変えての単発IDか
あるいは
ID変え忘れての二度レスで興味深い
2026/07/19(日) 07:48:10.78ID:K1yXWzaM
>>331
根拠のない罵倒に連続投稿
また一昨日の荒らしか
2026/07/19(日) 07:49:40.10ID:yGu++aw2
50連投は草
2026/07/19(日) 07:50:16.07ID:M8lmk12L
>>333
連投はしてないだろ
複おじイライラで草
2026/07/19(日) 07:50:53.84ID:GfhyrCtm
>>331
お前の中ではそうなんだろ
それでいいんじゃねえの
2026/07/19(日) 07:51:39.32ID:GTBlq3YJ
>>332
一昨日も昨日も荒らしてたのはお前だろ複おじ
2026/07/19(日) 07:52:33.46ID:JZtLLXX2
君ら複おじ好きすぎるだろ
2026/07/19(日) 07:54:16.21ID:V0ek7EzL
結局ID:hgCgzwLkが有能だっただけで他の奴は大差ないの笑う
2026/07/19(日) 07:56:24.24ID:/Dz3Bvfl
もう複おじの話はいいよ
2026/07/19(日) 07:59:04.69ID:GVCMKu1f
>>338
thread::spawnの場合でも受け取った参照については必ず返せる

>>159
>>どんな寿命の参照でも、それを関数の引数で受け取ったら、その参照や一部の参照を、関数から必ず返せる
2026/07/19(日) 08:01:06.65ID:GVCMKu1f
つまりspawnは反例にならない
342デフォルトの名無しさん
垢版 |
2026/07/19(日) 08:28:03.53ID:ycEFamLP
別の言語に興味を持たずに今日もRustスレを荒らすのはなぜなの
C言語なら俺に聞けスレとかでもいいのに
2026/07/19(日) 08:30:38.68ID:JZtLLXX2
めちゃくちゃな主張をしてもバレにくいとでも思ってんだろ
2026/07/19(日) 08:38:32.80ID:GVCMKu1f
Rustアンチは反例を出せなかったから結局バレた
2026/07/19(日) 10:01:28.27ID:vdzNEn7I
Rustアンチが複おじに負けてて草
2026/07/19(日) 10:32:27.41ID:l5OZ/Qwd
そもそも複おじって、IDコロコロ変えてしょうもない自演で戦ってスレを無駄に伸ばしてるとされる人のことを言ってたんだし
それでいうと一人で50レス＆この流れはまさに・・・
2026/07/19(日) 10:42:53.76ID:PwXam1IO
そうなの？
所有権の複製とかいう謎概念を言い始めたから複おじって呼ばれてるんだと思ってたけど
348デフォルトの名無しさん
垢版 |
2026/07/19(日) 11:01:45.06ID:RtDKlvqZ
Rustは最高言語😸
349デフォルトの名無しさん
垢版 |
2026/07/19(日) 11:12:53.98ID:fpgmEylb
おじいちゃんお昼寝タイム❓🌚
2026/07/19(日) 11:50:22.70ID:HBIq5jKD
仮におじ本人だとしたら、往事に比べてもだいぶ壊れてるよな
さすがに彼といえどもRustを書けること自体には何の価値もなくなったことを理解し、
Rust戦士としてのアイデンティティが崩壊しちゃったんだろうか
2026/07/19(日) 12:00:54.91ID:ykm2t8xC
Rustは最高だけどrust-analyzerは必須だなぁ
コンパイルエラーがてんこ盛りだから
352デフォルトの名無しさん
垢版 |
2026/07/19(日) 12:19:36.22ID:vDHqozbJ
>>351
最近はラストアナライザーは切ってるな
勝手に裏でコンパイルして評価されるのが鬱陶しくて
俺が書き終わってから評価してくれと！

で、書き終わってからclippy すりゃいいことに気づいた
353デフォルトの名無しさん
垢版 |
2026/07/19(日) 12:34:00.26ID:i5K4NMON
###結論
「書くときは書くことに集中し、チェックするときはチェックに集中する」というこのスタイルは、実は非常に効率的なフローだと思います。やはり、道具に使われるのではなく、自分のリズムで道具を使うのが一番ですよね。
354デフォルトの名無しさん
垢版 |
2026/07/19(日) 12:43:32.66ID:cyLx0GKO
RLS
rust-analyzer

くだらないLSPで終わっちゃったね、また
355デフォルトの名無しさん
垢版 |
2026/07/19(日) 13:11:17.66ID:jaOC3QMl
最近のラスアナはエラーコード書き換えても前のエラー参照してずっと表示してくる
2026/07/19(日) 13:19:14.38ID:iDkpn0RY
>>355
それがラストの穴だから
2026/07/19(日) 14:27:41.67ID:JZtLLXX2
>>345
どう考えてもアンチなわけないから同一人物なの笑う
やっぱりお前が複おじやんけｗ
2026/07/19(日) 14:29:17.49ID:JZtLLXX2
>>344-350
複おじ一人でイライラだなｗ
2026/07/19(日) 14:31:03.17ID:fPLQxaiR
>>352
コンパイルはされてないぞ
2026/07/19(日) 14:36:22.22ID:I7xcD3n3
まあ、Rustアンチの複おじは thread::spawn() という反例に何も反論できなかったんだから何でもいいよｗ
thread::spawn() を出すなんてRustアンチだ！は流石に笑っちゃうけどなｗ
2026/07/19(日) 14:41:16.37ID:XEDFF+lN
複おじ理論「thread::spawn() を使う奴はRustアンチ！」
2026/07/19(日) 14:48:45.23ID:BPBrTdsT
rust-analyzerは必須
でも今時LSPなしで書ける言語も少ないよな
2026/07/19(日) 14:57:22.06ID:NrnuMet5
それはそう
2026/07/19(日) 15:37:30.55ID:Tdbz2ykv
おデブanalyzer
2026/07/19(日) 16:34:03.63ID:PwXam1IO
C++ を書くときにエディタのリアルタイム支援を有効にはしているけど昔は無しでやっててそんなに不満には思ってなかったからな。
Rust も慣れれば割と言語サーバ無しでもなんとかなるんじゃないの。
366デフォルトの名無しさん
垢版 |
2026/07/19(日) 16:37:14.05ID:4IUrVmbW
>>359
コンパイルは間違いだったな
rustcにコード差分をチェックさせてる！だったわ
コンパイラーに仕事させてるけどコンパイルはしてないね
2026/07/19(日) 16:41:38.99ID:FEE5w7By
>>365
まあRustの場合はどうせコンパイラが丁寧に検証して教えてくれるから、コンパイルしてみれば済む話ではあるな
C++の方がコンパイラは場所を教えにくいからLSPの価値がありそう
2026/07/19(日) 16:50:14.50ID:c/SQma4a
でもrustcは厳しいからエディタ段階で気付いておかないとコンパイルが通らない地獄にはなりそう
369デフォルトの名無しさん
垢版 |
2026/07/19(日) 16:53:55.64ID:kq45OUMy
Emacs使いだけどlsp-modeをeglotに替えたら実用的になった　しばらくこれで行こう
2026/07/19(日) 17:45:50.87ID:1+L0WTZx
Rustアンチが複おじに負けてて草
2026/07/19(日) 18:19:18.24ID:IsykKjXQ
複おじの存在ってunsafeだよな
2026/07/19(日) 19:18:58.49ID:ykm2t8xC
Rustのおかげで開発のストレスがだいぶ減ったな
あるのはcloneしなきゃいけないときのストレスだけ
2026/07/19(日) 19:26:06.30ID:ebabxpEA
気兼ねなくcloneできるようになったら初心者卒業
2026/07/19(日) 19:26:33.94ID:JZtLLXX2
>>370
複おじ理論「thread::spawn() を使う奴はRustアンチ！」
2026/07/19(日) 19:27:33.13ID:eN9zKrjg
.clone() は必要かどうかはよく考えるべきだが必要ならガンガン使うべき
376デフォルトの名無しさん
垢版 |
2026/07/19(日) 19:34:30.03ID:jaOC3QMl
例えばどういう状況？
2026/07/19(日) 19:35:21.35ID:QnNtyJGa
>>376
複製が必要な状況
378デフォルトの名無しさん
垢版 |
2026/07/19(日) 19:41:32.14ID:jaOC3QMl
複製が必要な状況とは？
2026/07/19(日) 19:46:01.58ID:TWU6a9dA
>>378
色々あるけど元の値を保持しつつ値を書き変えたい場合なんかそうなるよね
2026/07/19(日) 19:54:49.43ID:gP7Ct9SI
複製が必要な設計になったら複製は必要だよな
流石に多岐に渡りすぎてて列挙することはできんくらいどこでもやってる
2026/07/19(日) 20:00:16.99ID:02kdCh2u
>>375
これ
コンパイラに勧められるがままに追加してたらめちゃくちゃになる
2026/07/19(日) 20:01:05.05ID:02kdCh2u
>>380
プログラムの本質はどこかからどこかへのコピーだとも言われてるからな
2026/07/19(日) 20:23:16.75ID:IqRjnUGO
spawn_uncheckedなら複おじ理論でも「どんな寿命の参照でも、それを関数の引数で受け取ったら」という条件に合致する

でもspawn_uncheckedは「その参照や一部の参照を、関数から必ず返せる」には合致しない
必ず返せるわけではないから

結局「コンパイルが通れば」という追加条件や「Safetyルールを守ったコードを書いていれば」という追加条件が必須
つまり全く自由ではない
2026/07/19(日) 20:43:13.08ID:GVCMKu1f
thread::spawnの場合でももちろん成り立っている

【前提】どんな寿命の参照でも、それを関数の引数で受け取ったら、
【恒真】その参照や一部の参照を、関数から必ず返せる

>>159
>>どんな寿命の参照でも、それを関数の引数で受け取ったら、その参照や一部の参照を、関数から必ず返せる
385デフォルトの名無しさん
垢版 |
2026/07/19(日) 20:43:37.50ID:udZTQXdf
ここまで自演までしてRustを盛り上げようとしなきゃいけない理由って？
2026/07/19(日) 20:49:47.77ID:FUMmfMWk
民家への飛び込み営業って、営業になりたがるような陽キャでもすぐ精神病むような過酷な仕事だけど
宗教の信者はそれを無報酬で喜んでやるわけじゃん？
2026/07/19(日) 21:00:34.15ID:ead1Jdp1
>>385-386
イミフ
2026/07/19(日) 21:01:15.47ID:poG3JtmY
アンチはアンチスレ行こうね

Rustアンチスレ
https://mevius.5ch.io/test/read.cgi/tech/1509028624/
2026/07/19(日) 21:02:06.86ID:NvpRR0fJ
>>386
飛び込んできてるのはお前らアンチじゃ
2026/07/19(日) 21:02:43.73ID:NvpRR0fJ
>>384
もうそんなこと言ってなかったバレてる主張の曲解はやめた方がいいよ
2026/07/19(日) 21:03:31.26ID:3dUSjAXg
>>384
最初から「コンパイルが通ればコンパイルが通る」ってトートロジーだったなら
> spawnの引数が何なのか知らない無知な人は勉強して出直してきてね (>>211)
ここで一旦参照を受け取るって部分の条件変えて逃げようとしたのは説明できないよね
嘘吐きミッケ！
2026/07/19(日) 21:04:09.13ID:5S+kz4RV
>>383
これ
2026/07/19(日) 21:05:33.34ID:vpQOXcwB
複おじ理論
1. 任意のライフタイムの参照を関数の引数で受け取って必ず返せる！
2. 実は「コンパイルを通ったら」って条件がありました〜！
3. thread::spawn() を使う奴はRustアンチ！
2026/07/19(日) 21:09:41.48ID:vzV+upno
>>384
「どんな寿命の参照でも」「どんな値でも」「他の関数から返ってきたものでも」(>>159)
「任意のライフタイムで必ず成立する」(>>183)
「Rustでは付加条件なく必ず成り立ちます」(>>214)
↓
実は関数の引数で受け取るコードがコンパイル通ったらってことでした！

これが複おじクオリティ
2026/07/19(日) 21:10:05.58ID:GVCMKu1f
Rustでこれは常に成り立つ
反例はない

【前提】どんな寿命の参照でも、それを関数の引数で受け取ったら、
【恒真】その参照や一部の参照を、関数から必ず返せる

>>159
>>どんな寿命の参照でも、それを関数の引数で受け取ったら、その参照や一部の参照を、関数から必ず返せる
2026/07/19(日) 21:10:35.04ID:GuAPWwpe
「コンパイル通ったらコンパイル通るんですよ」ｗ
2026/07/19(日) 21:11:07.49ID:TOwZLZwq
複オジ進次郎説
2026/07/19(日) 21:12:37.37ID:99/0zBmI
>>395
> どんな寿命の参照でも、それを関数の引数で受け取ったら、
thread::spawn() が 'static 以外の参照を受け取れないのがなぜか「コンパイルが通らないから」以外に言ってみろよｗ
最初は「ライフタイムの制約なんかない」って言ってたのも忘れてねえからな荒らし野郎
2026/07/19(日) 21:13:36.24ID:PQepZPK1
複おじ理論
1. 任意のライフタイムの参照を関数の引数で受け取って必ず返せる！
2. 実は「コンパイルを通ったら」って条件がありました〜！
3. thread::spawn() を使う奴はRustアンチ！
2026/07/19(日) 21:15:08.45ID:MOY7Z+S9
>>398
言えば言うほど過去の悪行が掘り返されるの草
2026/07/19(日) 21:18:38.37ID:Bfcytze+
>>395
「どんな寿命の参照でも」「どんな値でも」「他の関数から返ってきたものでも」「関数から必ず返せる」 (>>159)
「任意のライフタイムで必ず成立する」(>>183)
「Rustでは付加条件なく必ず成り立ちます」(>>214)
↓
実は関数の引数で受け取るコードがコンパイル通ったらってことでした！
ほら、rustcでコンパイルが通ったら成り立ってるでしょ

これの納得いく説明を早くしてくれよｗ
2026/07/19(日) 21:23:08.15ID:GVCMKu1f
>>398
それは明らかに違う
Safetyに明記されてるようにunsafe関数を呼び出しても安全な諸条件の一つであってそこでの特有の問題
2026/07/19(日) 21:23:34.26ID:jXclQgm1
>>395
別スレで粘着始めた頃に
> ライフタイム制約を受けない
> 任意のライフタイムの参照をその関数に与えて使うことができる
って言ってたのもバレてますよ
2026/07/19(日) 21:24:32.46ID:ZeJG5C6f
>>402
「どんな寿命の参照でも」「どんな値でも」「他の関数から返ってきたものでも」「関数から必ず返せる」 (>>159)
「Safetyに明記されてるようにunsafe関数を呼び出しても安全な諸条件の一つであってそこでの特有の問題」(>>402)

また例外作ってて草
2026/07/19(日) 21:25:34.09ID:4Up8DX7h
こいつ無限に例外作るやんｗ
「コンパイル通ったらコンパイル通るんですよ」でも足りないのかｗｗ
2026/07/19(日) 21:26:43.70ID:GVCMKu1f
>>404
例外はない
それはunsafeの問題
2026/07/19(日) 21:29:07.55ID:crEjxtUS
>>406
thread::spawn() はunsafeじゃねえよｗ
2026/07/19(日) 21:30:15.93ID:BsVgSgWn
>>406
まだ「親スレッドが子スレッドよりも先に死ぬかもしれないからそうでないことを保証する必要がある」ってことがわかんないのか
ライフタイムについてThe Book読んで勉強して来いよｗ
2026/07/19(日) 21:31:50.96ID:GVCMKu1f
Rustで安全が保証されてる諸事項も
unsafeを無条件に使えば当然保証されなくなる
それを「例外あるじゃん！」「付加条件が加わってるじゃん！」と叩く人はいないぞ
2026/07/19(日) 21:34:24.95ID:GVCMKu1f
>>407
unsafe関数を用いてsafe関数を作り出したのがthread::spawn()
その時のSafety条件として'staticの縛りがある
2026/07/19(日) 21:38:40.24ID:JZtLLXX2
>>409-410
全然違う
たとえOS側がRustで書かれていてunsafeなしでスレッドを作る機能を提供していても、「親スレッドが子スレッドよりも先に死ぬかもしれないからそうでないことを保証する必要がある」ので 'static しか渡せない
2026/07/19(日) 21:40:02.16ID:plV8i0R+
そもそもunsafe関数には渡せないなら
「どんな寿命の参照でも」「どんな値でも」「他の関数から返ってきたものでも」「関数から必ず返せる」 (>>159)
不成立だから>>409-410は本当にただ揚げ足取りできないか探ってるだけ
2026/07/19(日) 21:41:11.81ID:Stx9Cdrd
「どんな寿命の参照でも」「どんな値でも」「他の関数から返ってきたものでも」「関数から必ず返せる」 (>>159)
「任意のライフタイムで必ず成立する」(>>183)
「Rustでは付加条件なく必ず成り立ちます」(>>214)
↓
実は関数の引数で受け取るコードがコンパイル通ったらってことでした！
ほら、rustcでコンパイルが通ったら成り立ってるでしょ！
あ、あとunsafeは別だから！

こんなん笑うわ
2026/07/19(日) 21:41:41.03ID:VA46Ce8q
最初になかった条件が無限に増えてるの草
2026/07/19(日) 21:43:04.44ID:Mw9uDXPU
「ライフタイムの制約なんかない
どんな寿命の参照でもどんな値でも他の関数から返ってきたものでも関数から必ず返せる」
↓
「実は関数の引数で受け取るコードがコンパイル通ったらってことでした！
ほら、rustcでコンパイルが通ったら成り立ってるでしょ！」
↓
「unsafeは別だから！」

ｗ
2026/07/19(日) 21:43:40.95ID:Mw9uDXPU
もう次はどんな条件が増えるのか楽しみにした方が良さそう
2026/07/19(日) 21:44:33.02ID:GVCMKu1f
そうだよ
勝手に条件を増やされても困る
Rustでこれは常にこれが成り立つとしか元から書かれていない

【前提】どんな寿命の参照でも、それを関数の引数で受け取ったら、
【恒真】その参照や一部の参照を、関数から必ず返せる

>>159
>>どんな寿命の参照でも、それを関数の引数で受け取ったら、その参照や一部の参照を、関数から必ず返せる
2026/07/19(日) 21:50:24.89ID:bC8P0fo4
関数の引数で受け取ったら関数から必ず返せる → thread::spawn() はクロージャ越しに受け取ってるから引数だけど違う
1嘘

他の関数から返ってきたものでも → thread::spawn() はクロージャが返せるという部分だけ成り立てば thread::spawn() が返せなくてもいい
2嘘

ライフタイムの制約なんかない → ライフタイムが合わなくてコンパイル通らないもののことは言ってない
3嘘

付加条件なく必ず成り立ちます → unsafeは例外だから成り立たなくてもいい
4嘘
2026/07/19(日) 21:51:10.56ID:bC8P0fo4
>>409
最初からunsafeはメモリ安全が成り立たないって言われとるわマヌケ
2026/07/19(日) 21:52:04.54ID:GVCMKu1f
>>418
thread::spawn()でもこれは成立している

【前提】どんな寿命の参照でも、それを関数の引数で受け取ったら、
【恒真】その参照や一部の参照を、関数から必ず返せる

>>159
>>どんな寿命の参照でも、それを関数の引数で受け取ったら、その参照や一部の参照を、関数から必ず返せる
2026/07/19(日) 21:52:29.83ID:iUD075MM
>>417
「どんな寿命の参照でも」「どんな値でも」「他の関数から返ってきたものでも」「関数から必ず返せる」 (>>159)
「任意のライフタイムで必ず成立する」(>>183)
「Rustでは付加条件なく必ず成り立ちます」(>>214)
↓
thread::spawn() はクロージャ越しに受け取ってるから引数だけど違うよね……やっぱなし！
実は関数の引数で受け取るコードがコンパイル通ったらってことでした！　ほら、rustcでコンパイルが通ったら成り立ってるでしょ！
あ、あとunsafeは別だから！

これの納得いく説明を早くしてくれよｗ
2026/07/19(日) 21:53:09.52ID:PUeWuqJn
>>420
じゃあ 'static 以外の参照を渡して帰ってくる、コンパイル通るコードを出してくれるんだな？ｗ
2026/07/19(日) 21:53:31.42ID:xp53Un+N
>>420
コード楽しみにしてまーすｗｗ
2026/07/19(日) 21:54:42.61ID:xp53Un+N
>>421
違うぞ

「どんな寿命の参照でも」「どんな値でも」「他の関数から返ってきたものでも」「関数から必ず返せる」 (>>159)
「任意のライフタイムで必ず成立する」(>>183)
「Rustでは付加条件なく必ず成り立ちます」(>>214)
↓
thread::spawn() はクロージャ越しに受け取ってるから引数だけど違うよね、クロージャが返してるからセーフ……やっぱなし！
実は関数の引数で受け取るコードがコンパイル通ったらってことでした！　ほら、rustcでコンパイルが通ったら成り立ってるでしょ！
あ、あとunsafeは別だから！

だぞｗ
2026/07/19(日) 21:55:06.42ID:ZjuEXGnE
どんどんみっともなくなるの草
2026/07/19(日) 21:55:12.44ID:GVCMKu1f
>>422
それはthread::spawn()が課している制約だろ
そしてそのthread::spawn()でも以下が成り立ってる

【前提】どんな寿命の参照でも、それを関数の引数で受け取ったら、
【恒真】その参照や一部の参照を、関数から必ず返せる

>>159
>>どんな寿命の参照でも、それを関数の引数で受け取ったら、その参照や一部の参照を、関数から必ず返せる
2026/07/19(日) 21:55:56.48ID:MiHfChZr
「どんな寿命の参照でも」「どんな値でも」「他の関数から返ってきたものでも」「関数から必ず返せる」 (>>159)
「任意のライフタイムで必ず成立する」(>>183)
「Rustでは付加条件なく必ず成り立ちます」(>>214)
↓
thread::spawn() はクロージャ越しに受け取ってるから引数だけど違うよね……やっぱなし！
クロージャが返してるからセーフ……これもなし！
実は関数の引数で受け取るコードがコンパイル通ったらってことでした！　ほら、rustcでコンパイルが通ったら成り立ってるでしょ！
あ、あとunsafeは別だから！

こうでしょ
2026/07/19(日) 21:57:00.22ID:GtPpdQ0V
>>426
標準ライブラリの関数が「使えるけど使えなくしまーす」って意地悪で言ってると思ってるんだ
新しすぎる発想だなｗｗ
2026/07/19(日) 21:57:49.28ID:GtPpdQ0V
「どんな寿命の参照でも」「どんな値でも」「他の関数から返ってきたものでも」「関数から必ず返せる」 (>>159)
「任意のライフタイムで必ず成立する」(>>183)
「Rustでは付加条件なく必ず成り立ちます」(>>214)
↓
thread::spawn() はクロージャ越しに受け取ってるから引数だけど違うよね……やっぱなし！
クロージャが返してるからセーフ……これもなし！
↓
実は関数の引数で受け取るコードがコンパイル通ったらってことでした！　ほら、rustcでコンパイルが通ったら成り立ってるでしょ！
あ、あとunsafeは別だから！
↓
うーん、やっぱり説得力ないから全部なし！　標準ライブラリの関数が「使えるけど使えなくしまーす」って意地悪で言ってるんです！

今ここ
2026/07/19(日) 21:59:15.05ID:GVCMKu1f
追い込まれてるからといってそんな捏造するのはよくない
unsafeの話はthread::spawnがなぜそうしているかの話の時だろ

以下はthread::spawnでもunsafe fnでもasync fnでも必ず成立する

【前提】どんな寿命の参照でも、それを関数の引数で受け取ったら、
【恒真】その参照や一部の参照を、関数から必ず返せる

>>159
>>どんな寿命の参照でも、それを関数の引数で受け取ったら、その参照や一部の参照を、関数から必ず返せる
2026/07/19(日) 21:59:18.01ID:Cn6y/N+/
>>426
今標準ライブラリ以外でスレッドに任意のライフタイムの参照を渡す関数が作れるって約束したな？
システムコール叩くだけなんだからお前がコード書いてきたら信じてやるよｗ
2026/07/19(日) 21:59:46.81ID:Cn6y/N+/
>>430
捏造してるのはずっとお前だよ
なんでバレないと思ったんだｗｗ
2026/07/19(日) 22:00:15.16ID:CIKtWkX4
>>431
それに加えて戻り値で参照を返す必要もあるぞ
2026/07/19(日) 22:00:58.26ID:8NkIp6ei
「どんな寿命の参照でも」「どんな値でも」「他の関数から返ってきたものでも」「関数から必ず返せる」 (>>159)
「任意のライフタイムで必ず成立する」(>>183)
「Rustでは付加条件なく必ず成り立ちます」(>>214)
↓
thread::spawn() はクロージャ越しに受け取ってるから引数だけど違うよね……やっぱなし！
クロージャが返してるからセーフ……これもなし！
↓
実は関数の引数で受け取るコードがコンパイル通ったらってことでした！　ほら、rustcでコンパイルが通ったら成り立ってるでしょ！
あ、あとunsafeは別だから！
↓
やっぱり標準ライブラリの関数が「使えるけど使えなくしまーす」って意地悪で言ってるんです！

これの納得いく説明を早くしてくれよｗｗ
2026/07/19(日) 22:02:08.29ID:GVCMKu1f
>>431
そんな発言はしていない
以下が任意のライフタイムでもunsafe関数であろうがasync関数であろうが成り立つ
これしか主張していない

【前提】どんな寿命の参照でも、それを関数の引数で受け取ったら、
【恒真】その参照や一部の参照を、関数から必ず返せる

>>159
>>どんな寿命の参照でも、それを関数の引数で受け取ったら、その参照や一部の参照を、関数から必ず返せる
2026/07/19(日) 22:02:32.59ID:6Svg2Dea
>>430
これは確かに標準ライブラリ以外でスレッドに任意のライフタイムの参照を渡して返せる関数が作れるって言ってるな
システムコール叩くだけなら実装も楽だし、お前がコード書いてみんなを黙らせること、応援してるよ！ｗ
2026/07/19(日) 22:03:06.91ID:yi67bobM
>>435
「実は関数の引数で受け取るコードがコンパイル通ったらってことでした！　ほら、rustcでコンパイルが通ったら成り立ってるでしょ！」ｗ
2026/07/19(日) 22:03:19.07ID:GVCMKu1f
>>436
言ってもいないことを捏造するな
2026/07/19(日) 22:03:46.85ID:vzUecOLD
>>435
バカの世界ではこれで人が騙せると思われているらしい
2026/07/19(日) 22:04:29.21ID:GVCMKu1f
>>439
反例を出してみろ
2026/07/19(日) 22:04:31.06ID:pu9lYGke
>>438
捏造じゃねえだろｗ
お前が「thread::spawn()が勝手に制限かけてるからできないだけ」って言ってたんじゃんｗｗ
2026/07/19(日) 22:05:21.44ID:pu9lYGke
>>440
出た！
「反例を出してもコピペで永遠に聞かないで勝利宣言してやるから反例を出してみろ！」だｗｗｗｗ
2026/07/19(日) 22:05:58.29ID:C/0UxDMQ
>>440
一回もお前が反例を潰せたことないだろ
いい加減にしろ荒らし野郎
2026/07/19(日) 22:06:18.59ID:l5ye4LOC
「どんな寿命の参照でも」「どんな値でも」「他の関数から返ってきたものでも」「関数から必ず返せる」 (>>159)
「任意のライフタイムで必ず成立する」(>>183)
「Rustでは付加条件なく必ず成り立ちます」(>>214)
↓
thread::spawn() はクロージャ越しに受け取ってるから引数だけど違うよね……やっぱなし！
クロージャが返してるからセーフ……これもなし！
↓
実は関数の引数で受け取るコードがコンパイル通ったらってことでした！　ほら、rustcでコンパイルが通ったら成り立ってるでしょ！
あ、あとunsafeは別だから！
↓
やっぱり標準ライブラリの関数が「使えるけど使えなくしまーす」って意地悪で言ってるんです！

これの納得いく説明を早くしてくれよｗｗ
2026/07/19(日) 22:07:13.82ID:GVCMKu1f
>>441
勝手にではないぞ
ちゃんとそれぞれの関数の固有の理由がある
2026/07/19(日) 22:07:14.39ID:MJtW4T88
300レスもこれで荒らし続けてるのか
ID:GVCMKu1fは嘘吐きの代名詞だなｗ
2026/07/19(日) 22:07:52.50ID:MJtW4T88
>>445
固有の事情ってなんだよｗ
「どんな寿命の参照でも」「どんな値でも」「他の関数から返ってきたものでも」「関数から必ず返せる」んじゃなかったのか？ｗｗ
2026/07/19(日) 22:08:38.04ID:Djh5FEvH
>>447
そりゃ「unsafeは別だから！」だろｗ
2026/07/19(日) 22:09:20.59ID:NI8kFB3Y
「どんな寿命の参照でも」「どんな値でも」「他の関数から返ってきたものでも」「関数から必ず返せる」 (>>159)
「任意のライフタイムで必ず成立する」(>>183)
「Rustでは付加条件なく必ず成り立ちます」(>>214)
↓
thread::spawn() はクロージャ越しに受け取ってるから引数だけど違うよね……やっぱなし！
クロージャが返してるからセーフ……これもなし！
↓
実は関数の引数で受け取るコードがコンパイル通ったらってことでした！　ほら、rustcでコンパイルが通ったら成り立ってるでしょ！
あ、あとunsafeは別だから！
↓
やっぱり標準ライブラリの関数が勝手に「使えるけど使えなくしまーす」って意地悪で言ってるんです！
↓
そんなことないです！　固有の事情！　そう、固有の事情です！

これの納得いく説明を早くしてくれよｗｗ
2026/07/19(日) 22:09:54.58ID:1BBaabLV
>>449
ひでえなあｗ
2026/07/19(日) 22:10:17.20ID:GVCMKu1f
>>443
反例を持ってこいよ
おまえらRustアンチはたった一つの反例を示すだけでいいんだぞ
Rustでは以下が必ず成り立つ

【前提】どんな寿命の参照でも、それを関数の引数で受け取ったら、
【恒真】その参照や一部の参照を、関数から必ず返せる

>>159
>>どんな寿命の参照でも、それを関数の引数で受け取ったら、その参照や一部の参照を、関数から必ず返せる
2026/07/19(日) 22:11:11.81ID:zr2PrtJM
「どんな寿命の参照でも」「どんな値でも」「他の関数から返ってきたものでも」「関数から必ず返せる」 (>>159)
「任意のライフタイムで必ず成立する」(>>183)
「Rustでは付加条件なく必ず成り立ちます」(>>214)
↓
thread::spawn() はクロージャ越しに受け取ってるから引数だけど違うよね……やっぱなし！
クロージャが返してるからセーフ……これもなし！
↓
実は関数の引数で受け取るコードがコンパイル通ったらってことでした！　ほら、rustcでコンパイルが通ったら成り立ってるでしょ！
あ、あとunsafeは別だから！
↓
やっぱり標準ライブラリの関数が勝手に「使えるけど使えなくしまーす」って意地悪で言ってるんです！
コンパイル通ったらッて条件も残ってます！
↓
そんなことないです！　固有の事情があるんです！　そう、固有の事情です！

ちょっときれいに整理してみた
2026/07/19(日) 22:11:44.61ID:zr2PrtJM
>>451
もう300レスも前に示されてるよ
お前はまだそれに答えてないだけｗ
2026/07/19(日) 22:12:08.90ID:GVCMKu1f
>>452
捏造しだしたら君の負け
2026/07/19(日) 22:12:24.24ID:GVCMKu1f
>>453
どれですか？
2026/07/19(日) 22:12:53.75ID:K5dJ0PBv
>>451
じゃあ thread::spawn() と同じ機能を持った任意のライフタイムの参照を受け取って返せる関数を出せよ
お前が言ってるのは「僕の頭の中にはあるんだい！」で反証可能性がない
2026/07/19(日) 22:13:27.57ID:Hr73tPpm
>>454-455
捏造してるのはずっとお前
まだ thread::spawn() という反例に答えてない
2026/07/19(日) 22:14:00.95ID:3qV+/qVC
「どんな寿命の参照でも」「どんな値でも」「他の関数から返ってきたものでも」「関数から必ず返せる」 (>>159)
「任意のライフタイムで必ず成立する」(>>183)
「Rustでは付加条件なく必ず成り立ちます」(>>214)
↓
thread::spawn() はクロージャ越しに受け取ってるから引数だけど違うよね……やっぱなし！
クロージャが返してるからセーフ……これもなし！
↓
実は関数の引数で受け取るコードがコンパイル通ったらってことでした！　ほら、rustcでコンパイルが通ったら成り立ってるでしょ！
あ、あとunsafeは別だから！
↓
やっぱり標準ライブラリの関数が勝手に「使えるけど使えなくしまーす」って意地悪で言ってるんです！
コンパイル通ったらッて条件も残ってます！
↓
そんなことないです！　固有の事情があるんです！　そう、固有の事情です！

早くこれに納得いく説明をしてくれよｗｗ
2026/07/19(日) 22:14:42.08ID:GVCMKu1f
>>456
そんな主張をしていないだろ
前提を恒真へ含めるなよ

【前提】どんな寿命の参照でも、それを関数の引数で受け取ったら、
【恒真】その参照や一部の参照を、関数から必ず返せる

>>159
>>どんな寿命の参照でも、それを関数の引数で受け取ったら、その参照や一部の参照を、関数から必ず返せる
2026/07/19(日) 22:14:50.31ID:3qV+/qVC
>>451
複おじ理論「thread::spawn() を使う奴はRustアンチ！」
2026/07/19(日) 22:15:16.97ID:jnkqq9MC
>>459
「実は関数の引数で受け取るコードがコンパイル通ったらってことでした！　ほら、rustcでコンパイルが通ったら成り立ってるでしょ！」ｗ
2026/07/19(日) 22:15:25.36ID:GVCMKu1f
>>457
thread::spawn()も受け取った参照を返せます
2026/07/19(日) 22:15:43.38ID:+Fv0Z1+W
>>459
「どんな寿命の参照でも」「どんな値でも」「他の関数から返ってきたものでも」「関数から必ず返せる」 (>>159)
「任意のライフタイムで必ず成立する」(>>183)
「Rustでは付加条件なく必ず成り立ちます」(>>214)
↓
thread::spawn() はクロージャ越しに受け取ってるから引数だけど違うよね……やっぱなし！
クロージャが返してるからセーフ……これもなし！
↓
実は関数の引数で受け取るコードがコンパイル通ったらってことでした！　ほら、rustcでコンパイルが通ったら成り立ってるでしょ！
あ、あとunsafeは別だから！
↓
やっぱり標準ライブラリの関数が勝手に「使えるけど使えなくしまーす」って意地悪で言ってるんです！
コンパイル通ったらッて条件も残ってます！
↓
そんなことないです！　固有の事情があるんです！　そう、固有の事情です！

早くこれに納得いく説明をしてくれよｗｗｗ
2026/07/19(日) 22:16:26.77ID:+Fv0Z1+W
>>462
「どんな寿命の参照でも」「どんな値でも」「他の関数から返ってきたものでも」「任意のライフタイムで必ず成立する」
本当だな？
これで 'static しか返せなかったら嘘吐き確定だぞ
2026/07/19(日) 22:17:54.28ID:5Y4SYvdz
「付加条件なく必ず成り立ちます」ｗ
2026/07/19(日) 22:19:58.42ID:GVCMKu1f
>>464
spawnでは受け取る参照を制限していますが
その参照についても以下は必ず成り立ちます

【前提】どんな寿命の参照でも、それを関数の引数で受け取ったら、
【恒真】その参照や一部の参照を、関数から必ず返せる

>>159
>>どんな寿命の参照でも、それを関数の引数で受け取ったら、その参照や一部の参照を、関数から必ず返せる
2026/07/19(日) 22:20:02.56ID:c6ZpTEik
>>462
「どんな寿命の参照でも」「どんな値でも」「他の関数から返ってきたものでも」「任意のライフタイムで必ず成立する」「付加条件なく必ず成り立ちます」
この条件で返せるって証明してくれよ
2026/07/19(日) 22:20:42.70ID:c6ZpTEik
>>466
「どんな寿命の参照でも」「どんな値でも」「他の関数から返ってきたものでも」「任意のライフタイムで必ず成立する」「付加条件なく必ず成り立ちます」
この条件で返せるって証明してくれよ
お前が言ったんだからさ、「受け取る参照を制限していますが」なんて逃げはいらないんだわ
2026/07/19(日) 22:21:35.77ID:XResoogo
「どんな寿命の参照でも」「どんな値でも」「他の関数から返ってきたものでも」「関数から必ず返せる」 (>>159)
「任意のライフタイムで必ず成立する」(>>183)
「Rustでは付加条件なく必ず成り立ちます」(>>214)
↓
thread::spawn() はクロージャ越しに受け取ってるから引数だけど違うよね……やっぱなし！
クロージャが返してるからセーフ……これもなし！
↓
実は関数の引数で受け取るコードがコンパイル通ったらってことでした！　ほら、rustcでコンパイルが通ったら成り立ってるでしょ！
あ、あとunsafeは別だから！
↓
やっぱり標準ライブラリの関数が勝手に「使えるけど使えなくしまーす」って意地悪で言ってるんです！
コンパイル通ったらって条件も残ってます！
↓
そんなことないです！　固有の事情があるんです！　そう、固有の事情です！
受け取る参照を制限しているから、受け取ったら返せるんです！

早くこれに納得いく説明をしてくれよｗｗｗ
2026/07/19(日) 22:21:39.57ID:GVCMKu1f
早く反例コードを出してくださいよ
2026/07/19(日) 22:23:05.98ID:r4QFGOjn
>>466
その主張だと今度
std::thread::Builder::spawn_unchecked()
では受け取る参照を制限していないから不成立だぞ
2026/07/19(日) 22:23:43.09ID:r4QFGOjn
>>470
ずっと出てるだろ
thread::spawn() だと 'static じゃないどの参照でも返せない
2026/07/19(日) 22:24:28.65ID:GVCMKu1f
>>471
返せるよ
やってみ
2026/07/19(日) 22:25:04.76ID:lSihsm4A
「どんな寿命の参照でも」「どんな値でも」「他の関数から返ってきたものでも」「関数から必ず返せる」 (>>159)
「任意のライフタイムで必ず成立する」(>>183)
「Rustでは付加条件なく必ず成り立ちます」(>>214)
↓
thread::spawn() はクロージャ越しに受け取ってるから引数だけど違うよね……やっぱなし！
クロージャが返してるからセーフ……これもなし！
↓
実は関数の引数で受け取るコードがコンパイル通ったらってことでした！　ほら、rustcでコンパイルが通ったら成り立ってるでしょ！
あ、あとunsafeは別だから！
↓
やっぱり標準ライブラリの関数が勝手に「使えるけど使えなくしまーす」って意地悪で言ってるんです！
コンパイル通ったらって条件も残ってます！
↓
そんなことないです！　固有の事情があるんです！　そう、固有の事情です！
受け取る参照を制限しているから、受け取ったら返せるんです！

早くこれに納得いく説明をしてくれよｗｗ
下2つは std::thread::Builder::spawn_unchecked() では成り立たないぞｗｗｗ
2026/07/19(日) 22:25:52.00ID:GVCMKu1f
>>472
それは以下に明記されてる前提を満たしてないからだろ

【前提】どんな寿命の参照でも、それを関数の引数で受け取ったら、
【恒真】その参照や一部の参照を、関数から必ず返せる

>>159
>>どんな寿命の参照でも、それを関数の引数で受け取ったら、その参照や一部の参照を、関数から必ず返せる
2026/07/19(日) 22:26:01.71ID:HI6IurVy
>>473
ついに完全な嘘を吐いたな
チェックはされないが返せないケースはなくなってない
2026/07/19(日) 22:26:27.39ID:BHraHSW4
>>475
どう見ても満たしとるわマヌケ
2026/07/19(日) 22:27:25.01ID:GVCMKu1f
>>474
実際にやって見ろよ
std::thread::Builder::spawn_unchecked() でも返せるぞ
2026/07/19(日) 22:27:55.87ID:F0MnotzK
>>473
std::thread::Builder::spawn_unchecked() で任意の参照を受け取って返せるって言うなら、当然それを受け取って返して読めるコードができるってことだよな
これやってみようぜｗｗ
動かなかったらID:GVCMKu1fは嘘吐きな
2026/07/19(日) 22:28:23.95ID:GVCMKu1f
>>477
前提条件「それを関数の引数で受け取ったら」を満たしてない
2026/07/19(日) 22:28:44.70ID:7X0+qiIb
>>478
嘘吐きは何とやらと言うけど、ここまで堂々とバレてる嘘を吐けるのは逆に才能だなｗ
2026/07/19(日) 22:29:32.31ID:7X0+qiIb
>>480
thread::spawn() はクロージャ越しに受け取ってるから引数だけど違うって言い訳して逃げようとした時点でその解釈は成り立たないんだわ
2026/07/19(日) 22:29:54.38ID:GVCMKu1f
>>479
ちゃんと返せた
もちろんunsafe関数なので結果は常にunsafe
2026/07/19(日) 22:30:30.82ID:GVCMKu1f
>>482
そんな発言していない
2026/07/19(日) 22:32:55.52ID:XbKlswJJ
まぁ詰まるところは言い回しの問題なんだろうけどさ
2026/07/19(日) 22:35:37.37ID:BeY+J4Fb
>>484
嘘吐いてもバレるのに……
2026/07/19(日) 22:36:11.37ID:GVCMKu1f
>>486
その書き込みを持ってこいよ
2026/07/19(日) 22:36:50.30ID:7jkxblcL
ちなみに>>184で書いた「弱参照を受け取って通常の参照にして返す関数」も普通に書けるからね
「必ず返せる」はもちろん成立しないけれど

unsafe fn get_ref<T>(weak: &Weak<T>) -> &T {
unsafe { &*weak.as_ptr() }
}
2026/07/19(日) 22:38:12.03ID:BeY+J4Fb
>>483
たまたまメモリの領域が生きてただけだろ
2026/07/19(日) 22:39:23.63ID:GVCMKu1f
>>488
引数として受け取った弱参照は必ず返すこたができる
Rustでは以下が常に成立する

【前提】どんな寿命の参照でも、それを関数の引数で受け取ったら、
【恒真】その参照や一部の参照を、関数から必ず返せる

>>159
>>どんな寿命の参照でも、それを関数の引数で受け取ったら、その参照や一部の参照を、関数から必ず返せる
2026/07/19(日) 22:40:16.24ID:GVCMKu1f
>>489
unsafe関数だからそれは許されるのがRust
2026/07/19(日) 22:43:01.84ID:+EgGKzCN
>>491
おい、お前の言ってる条件満たしてるのに動かねえぞ

use std::thread;
use std::time::Duration;

fn main() {
let handle;

{
let mut local_data = 100;
let mut local_data_ref = &mut local_data;

println!("スレッド内の値: {}", local_data);

unsafe {
handle = thread::Builder::new()
.name("dangerous_thread".to_string())
.spawn_unchecked(move || {
thread::sleep(Duration::from_millis(50));

*local_data_ref = 200;

println!("スレッド内の値: {}", local_data_ref);
})
.unwrap();
}
}

handle.join().unwrap();
}
2026/07/19(日) 22:45:23.06ID:J5fxakd4
まだ参照返してもいないのに条件満たしてかつ動かないのおもろいな
2026/07/19(日) 22:48:29.00ID:CA6RNpNI
渡した時点で動かないじゃん
>>491 unsafe関数だからそれは許されるのがRust
このイキりは一体ｗ
2026/07/19(日) 22:52:26.39ID:Q7jr2sjS
不要なmutがあるし色々雑なコードだけど反例としては十分だな
2026/07/19(日) 22:53:19.34ID:GVCMKu1f
>>492
Rust初心者かい？
エラー出てるだろ
try 'rustc --explain E0502'
2026/07/19(日) 22:57:26.40ID:Q7jr2sjS
>>496　ごめんごめん、手打ちしたのが良くなかったな

use std::thread;
use std::time::Duration;

fn main() {
let handle;

{
let mut local_data = 100;
println!("スレッド内の値: {}", local_data);
let local_data_ref = &mut local_data;

unsafe {
handle = thread::Builder::new()
.name("dangerous_thread".to_string())
.spawn_unchecked(move || {
thread::sleep(Duration::from_millis(50));

*local_data_ref = 200;

println!("スレッド内の値: {}", local_data_ref);
})
.unwrap();
}
}

handle.join().unwrap();
}

これでクラッシュした理由を教えてくれや
2026/07/19(日) 23:00:33.97ID:9N1Mvpqx
>>497
どう見ても未定義動作です本当にありがとうございます
2026/07/19(日) 23:02:12.84ID:gOfZIriO
「どんな寿命の参照でも」「どんな値でも」「他の関数から返ってきたものでも」「関数から必ず返せる」 (>>159)
「任意のライフタイムで必ず成立する」(>>183)
「Rustでは付加条件なく必ず成り立ちます」(>>214)

おかしいなあ、返すまでもなく壊れてるぜ
2026/07/19(日) 23:03:42.88ID:d0lr3qJ1
ちゃんとコンパイルは通るな
2026/07/19(日) 23:05:01.54ID:eHBdU/kr
Windowsでは動くな
未定義動作らしくなってきた
2026/07/19(日) 23:06:23.23ID:GVCMKu1f
>>497
こちらでは以下が表示されて正常終了するが
スレッド内の値: 100
スレッド内の値: 200
動かないこともあるだろうね
unsafe関数を使う時はそのSafety条件を守ることがRustでは必須
2026/07/19(日) 23:08:41.34ID:EPUrWbSR
>>502
お前が言った「Rustでは付加条件なく必ず成り立ちます」には反してる結論だな
納得できたか？
2026/07/19(日) 23:10:37.48ID:GVCMKu1f
>>503
反例になってない
Rustでは以下が常に成立する

【前提】どんな寿命の参照でも、それを関数の引数で受け取ったら、
【恒真】その参照や一部の参照を、関数から必ず返せる

>>159
>>どんな寿命の参照でも、それを関数の引数で受け取ったら、その参照や一部の参照を、関数から必ず返せる
2026/07/19(日) 23:11:11.06ID:+39tuTEu
>>504
ついに「成り立たないが成り立つから成り立つ」って言い始めてて草
1行矛盾
2026/07/19(日) 23:13:19.88ID:d6fluU/x
>>497
地味に無駄mut外されて洗練されてんの笑う
2026/07/19(日) 23:14:11.45ID:d6fluU/x
ただ、上は「スレッド外の値」やな
2026/07/19(日) 23:25:15.72ID:R2LtKg8E
use std::thread;
use std::time::Duration;

fn main() {
let handle;
let mut local_data = 100;
println!("スレッド外の値: {}", local_data);
let local_data_ref = &mut local_data;
unsafe {
handle = thread::Builder::new()
.name("dangerous_thread".to_string())
.spawn_unchecked(move || {
thread::sleep(Duration::from_millis(500));
println!("スレッド内の値: {}", local_data_ref);
*local_data_ref = 200;
println!("スレッド内の値: {}", local_data_ref);
})
.unwrap();
}
}
println!("local_data消失");
handle.join().unwrap();
}

何が起こってるかわかりやすくした
これで動いてしまった場合でも未定義動作だとわかる
2026/07/19(日) 23:25:32.10ID:2iSHfWbm
mut汚染は鉄板だけどunsafe使うのは趣旨に反するよな
Cellとか使うと気持ち悪くできそうだけど複雑になる

fn foo<'a, T, F>(f: F, x: &'a mut T, y: &'a mut T) -> &'a mut T
where
F: FnOnce(&'a mut T, &'a mut T) -> bool
{
if f(x, y) { x } else { y }
}
2026/07/19(日) 23:26:27.45ID:GVCMKu1f
>>497が反例になってない証拠は
簡略化したこのコードをみるとわかる

fn main() {
let handle;
{
let mut local_data = 100;
println!("スレッド内の値: {}", local_data);
let local_data_ref = &mut local_data;
{
handle = Some(local_data_ref);
}
}
handle.unwrap();
}

スコープルールに反しているだけにすぎない
2026/07/19(日) 23:27:18.23ID:bxzaHrV9
条件決めた奴が spawn_unchecked() でも成り立つと明言している以上趣旨には反してない
2026/07/19(日) 23:28:30.71ID:GsL396XN
>>510
スレッド立ててない時点で簡略化できてないぞ
2026/07/19(日) 23:28:33.09ID:GVCMKu1f
>>511
spawn_unchecked()の問題ではないことを
>>510で既に示した
2026/07/19(日) 23:29:11.11ID:MI3knhkj
>>510
そんなスコープにはなってねえよマヌケ
スレッドが何か知らねえのか
2026/07/19(日) 23:29:32.14ID:MI3knhkj
>>513
また新しい嘘が始まったな
2026/07/19(日) 23:29:43.26ID:GVCMKu1f
>>512
handleがスコープ外にあるのに
そこへ参照を入れられないのは当たり前
2026/07/19(日) 23:30:23.43ID:MI3knhkj
>>516
お前の書いたコードじゃなくて元のコードの話してるんだけど
2026/07/19(日) 23:30:57.41ID:GVCMKu1f
>>514
そのスコープ関係になっている
handleとlocal_dataのスコープの食い違いを見なさい
2026/07/19(日) 23:30:58.78ID:UGHA3+tz
勝手に名前だけ似せた関係ないコードにすり替えて話してるのヤバすぎるだろ
2026/07/19(日) 23:31:39.85ID:UGHA3+tz
>>518
お前の書いた妄想コードはhandle = Some(local_data_ref);がある部分のスコープが元のコードと一致してない
2026/07/19(日) 23:31:44.43ID:GVCMKu1f
>>517
元のコードもhandleとlocal_dataのスコープが食い違っている
2026/07/19(日) 23:33:29.24ID:uxNzkEWb
>>510のコードはthread::scopeを使った場合にしか起きないスコープになってる
2026/07/19(日) 23:33:59.63ID:L0YtsTIP
>>521
スレッドとスコープの見わけもつかんのかたわけ
2026/07/19(日) 23:39:08.66ID:GVCMKu1f
本質部分だけ取り出すと理解できない人のために
>>497から一番外側の不要な鍵カッコ2つを取り外すして参照を返すとこうなる

use std::thread;
use std::time::Duration;

fn main() {
let handle;

let mut local_data = 100;
println!("スレッド内の値: {}", local_data);
let local_data_ref = &mut local_data;

unsafe {
handle = thread::Builder::new()
.name("dangerous_thread".to_string())
.spawn_unchecked(move || {
thread::sleep(Duration::from_millis(50));
*local_data_ref = 200;

println!("スレッド内の値: {}", local_data_ref);
local_data_ref
})
.unwrap();
}

let result = handle.join().unwrap();
println!("result: {result}");
}

こうなる
result: 200
2026/07/19(日) 23:39:35.33ID:Je9ZT3pN
どれだけ曲解したところで handle = Some(local_data_ref); がある部分のスコープが local_data より先に終わってる時点でスレッドを理解してないとしか言えない
2026/07/19(日) 23:40:36.64ID:xeU/443Z
>>524
不要な { } と言ってスコープを破壊してコードを書き換えるのは流石に無法すぎる
嘘吐きここに極まれり
2026/07/19(日) 23:41:25.28ID:pTqrx0Og
>>524
お前は一度くらい嘘を吐かずに話せないのか
2026/07/19(日) 23:42:07.87ID:pTqrx0Og
>>524
複オジ理論「不要なスコープを取り除いたらスコープが壊れてるんだ！」
2026/07/19(日) 23:42:38.37ID:GVCMKu1f
>>525
先に終わっても返さない限りは問題なくコンパイルが通る
返した時だけhandleとスコープが食い違っていてコンパイルできなくなる
2026/07/19(日) 23:43:28.52ID:GVCMKu1f
>>526
スコープ外に参照を持ち出せないのはRustの常識
2026/07/19(日) 23:43:33.36ID:lrKY9Hhf
>>529
> 先に終わっても返さない限りは問題なくコンパイルが通る
じゃああのスコープはただの目くらましで笑う
自分から嘘吐きであることを暴露していくのか
2026/07/19(日) 23:44:10.12ID:9U0PzD1P
>>530
何言ってんだこいつ
スコープ内にスレッドはありますけどｗ
勝手にお前が書き換えたコードじゃなくてもな
2026/07/19(日) 23:44:45.44ID:VYuhTwcT
>>530
じゃあRustのコンパイラは無能だからスコープが壊れててもコンパイルを通すと？ｗ
2026/07/19(日) 23:45:13.52ID:Do2V15MU
複オジなんてどうせ隠れアンチだからな
2026/07/19(日) 23:45:58.75ID:jmKhuzp4
>>530
お前がいかに嘘を吐いても事実は変わらない
スレッドはスコープ内
2026/07/19(日) 23:47:10.55ID:GVCMKu1f
俺は>>524のコードで
spawn_unchecked()でも参照を返せることを示した
もちろんunsafe関数だから未定義動作

反例はここまでになく
Rustでは以下が常に成立する

【前提】どんな寿命の参照でも、それを関数の引数で受け取ったら、
【恒真】その参照や一部の参照を、関数から必ず返せる

>>159
>>どんな寿命の参照でも、それを関数の引数で受け取ったら、その参照や一部の参照を、関数から必ず返せる
2026/07/19(日) 23:47:11.26ID:2YvNcuM/
>>530
どう見てもスコープ内で渡されてますねえ

use std::thread;
use std::time::Duration;

fn main() {
let handle;
{
let mut local_data = 100;
println!("スレッド外の値: {}", local_data);
let local_data_ref = &mut local_data;
unsafe {
handle = thread::Builder::new()
.name("dangerous_thread".to_string())
.spawn_unchecked(move || {
thread::sleep(Duration::from_millis(500));
println!("スレッド内の値: {}", local_data_ref);
*local_data_ref = 200;
println!("スレッド内の値: {}", local_data_ref);
})
.unwrap();
}
}
println!("local_data消失");
handle.join().unwrap();
}
2026/07/19(日) 23:48:41.40ID:A/rr6nbt
>>536

「どんな寿命の参照でも」「どんな値でも」「他の関数から返ってきたものでも」「関数から必ず返せる」 (>>159)
「任意のライフタイムで必ず成立する」(>>183)
「Rustでは付加条件なく必ず成り立ちます」(>>214)
↓
thread::spawn() はクロージャ越しに受け取ってるから引数だけど違うよね……やっぱなし！
クロージャが返してるからセーフ……これもなし！
↓
実は関数の引数で受け取るコードがコンパイル通ったらってことでした！　ほら、rustcでコンパイルが通ったら成り立ってるでしょ！
あ、あとunsafeは別だから！
↓
やっぱり標準ライブラリの関数が勝手に「使えるけど使えなくしまーす」って意地悪で言ってるんです！
コンパイル通ったらって条件も残ってます！
↓
そんなことないです！　固有の事情があるんです！　そう、固有の事情です！
受け取る参照を制限しているから、受け取ったら返せるんです！
↓
やっぱり違う！　俺の書いた見た目の似たコードではスコープから外れてるから違うんだ！

早くこれに納得いく説明をしてくれよｗｗ
2026/07/19(日) 23:48:47.51ID:im9d/ITc
>>536

「どんな寿命の参照でも」「どんな値でも」「他の関数から返ってきたものでも」「関数から必ず返せる」 (>>159)
「任意のライフタイムで必ず成立する」(>>183)
「Rustでは付加条件なく必ず成り立ちます」(>>214)
↓
thread::spawn() はクロージャ越しに受け取ってるから引数だけど違うよね……やっぱなし！
クロージャが返してるからセーフ……これもなし！
↓
実は関数の引数で受け取るコードがコンパイル通ったらってことでした！　ほら、rustcでコンパイルが通ったら成り立ってるでしょ！
あ、あとunsafeは別だから！
↓
やっぱり標準ライブラリの関数が勝手に「使えるけど使えなくしまーす」って意地悪で言ってるんです！
コンパイル通ったらって条件も残ってます！
↓
そんなことないです！　固有の事情があるんです！　そう、固有の事情です！
受け取る参照を制限しているから、受け取ったら返せるんです！
↓
やっぱり違う！　俺の書いた見た目の似たコードではスコープから外れてるから違うんだ！

早くこれに納得いく説明をしてくれよｗｗ
2026/07/19(日) 23:49:03.84ID:GVCMKu1f
>>537
println!("local_data消失");の意味がわからない
消失してないから表示されるぞ
2026/07/19(日) 23:49:22.03ID:RywEX15a
>>536

「どんな寿命の参照でも」「どんな値でも」「他の関数から返ってきたものでも」「関数から必ず返せる」 (>>159)
「任意のライフタイムで必ず成立する」(>>183)
「Rustでは付加条件なく必ず成り立ちます」(>>214)
↓
thread::spawn() はクロージャ越しに受け取ってるから引数だけど違うよね……やっぱなし！
クロージャが返してるからセーフ……これもなし！
↓
実は関数の引数で受け取るコードがコンパイル通ったらってことでした！　ほら、rustcでコンパイルが通ったら成り立ってるでしょ！
あ、あとunsafeは別だから！
↓
やっぱり標準ライブラリの関数が勝手に「使えるけど使えなくしまーす」って意地悪で言ってるんです！
コンパイル通ったらって条件も残ってます！
↓
そんなことないです！　固有の事情があるんです！　そう、固有の事情です！
受け取る参照を制限しているから、受け取ったら返せるんです！
↓
やっぱり違う！　俺の書いた見た目の似たコードではスコープから外れてるから違うんだ！

早くこれに納得いく説明をしてくれよｗｗ
2026/07/19(日) 23:49:45.50ID:RywEX15a
>>540
RAIIとスコープについて学んでおいでｗ
2026/07/19(日) 23:50:23.19ID:RywEX15a
540 デフォルトの名無しさん 2026/07/19(日) 23:49:03.84 ID:GVCMKu1f
>>537
println!("local_data消失");の意味がわからない
消失してないから表示されるぞ

複おじの知能ではスコープはわからない
544デフォルトの名無しさん
垢版 |
2026/07/19(日) 23:51:23.22ID:9D3is3z1
煽りコピペがうざいので減らしてくれ
荒らしはID:GVCMKu1fだけで足りてる
2026/07/19(日) 23:51:50.05ID:GVCMKu1f
>>524のコードで
unsafeのspawn_unchecked()でも参照を返せることを示した
つまり反例は存在しない
意義があるなら反例を持ってきなさい

Rustでは以下が常に成立する

【前提】どんな寿命の参照でも、それを関数の引数で受け取ったら、
【恒真】その参照や一部の参照を、関数から必ず返せる

>>159
>>どんな寿命の参照でも、それを関数の引数で受け取ったら、その参照や一部の参照を、関数から必ず返せる
2026/07/19(日) 23:52:03.24ID:LIGzNvxy
>>540
スコープが壊れてるってイキってたくせにスコープがわかってないのおもろい
2026/07/19(日) 23:52:16.91ID:GVCMKu1f
意義→異議
2026/07/19(日) 23:52:56.65ID:LIGzNvxy
>>545
spawn_unchecked() は一切参照を扱えないって話に勝手にすり替えてて草
> どんな寿命の参照でも、それを関数の引数で受け取ったら、その参照や一部の参照を、関数から必ず返せる
このバカげた主張の話をしてるんだぞｗ
2026/07/19(日) 23:53:01.64ID:GVCMKu1f
>>546
わかっていないのはおまえ
こちらはコード>>924で示している
2026/07/19(日) 23:53:27.17ID:2yWTRs2r
「どんな寿命の参照でも」「どんな値でも」「他の関数から返ってきたものでも」「関数から必ず返せる」 (>>159)
「任意のライフタイムで必ず成立する」(>>183)
「Rustでは付加条件なく必ず成り立ちます」(>>214)

↑ これが複おじのウソ
2026/07/19(日) 23:53:50.01ID:GVCMKu1f
>>548
参照を返せないという反例コードはどれ？
2026/07/19(日) 23:54:04.40ID:2yWTRs2r
>>549
成り立たないコードが示されてるのに勝手に成り立つコードに書き換えて「どんなケースでも成り立つ！」は嘘吐きすぎる
2026/07/19(日) 23:54:35.61ID:GVCMKu1f
>>550
なぜ元の>>159を混ぜるんだよ
2026/07/19(日) 23:54:56.33ID:GVCMKu1f
>>552
参照を返せないコードはどれですか？
2026/07/19(日) 23:56:34.41ID:GVCMKu1f
unsafeのspawn_unchecked()でも参照を返せることを>>524で示した
このケースでも反例はない
2026/07/19(日) 23:57:23.89ID:gTGt9p2I
>>554
勝手に寿命変えたら返せて当たり前だろ
スコープを壊さずに返せよ無能
2026/07/19(日) 23:57:41.89ID:gTGt9p2I
>>555
また嘘吐きか
2026/07/19(日) 23:58:46.18ID:HimEHeoN
「どんな寿命の参照でも」「どんな値でも」「他の関数から返ってきたものでも」「関数から必ず返せる」 (>>159)
↓
「スコープで寿命が変わってるから返せないんだ！　こんなのは反例にならない！」

もう嘘しか吐いてない
2026/07/19(日) 23:59:07.13ID:GVCMKu1f
>>556
handleが外スコープにあるから
内スコープにあるものの参照を返さないのは当たり前
スコープ則を学びなさい
2026/07/19(日) 23:59:21.63ID:GVCMKu1f
Rustでは以下が常に成立する
ここまでに反例なし

【前提】どんな寿命の参照でも、それを関数の引数で受け取ったら、
【恒真】その参照や一部の参照を、関数から必ず返せる

>>159
>>どんな寿命の参照でも、それを関数の引数で受け取ったら、その参照や一部の参照を、関数から必ず返せる
2026/07/19(日) 23:59:24.81ID:HimEHeoN
「どんな寿命の参照でも」「どんな値でも」「他の関数から返ってきたものでも」「関数から必ず返せる」 (>>159)
「任意のライフタイムで必ず成立する」(>>183)
「Rustでは付加条件なく必ず成り立ちます」(>>214)
↓
thread::spawn() はクロージャ越しに受け取ってるから引数だけど違うよね……やっぱなし！
クロージャが返してるからセーフ……これもなし！
↓
実は関数の引数で受け取るコードがコンパイル通ったらってことでした！　ほら、rustcでコンパイルが通ったら成り立ってるでしょ！
あ、あとunsafeは別だから！
↓
やっぱり標準ライブラリの関数が勝手に「使えるけど使えなくしまーす」って意地悪で言ってるんです！
コンパイル通ったらって条件も残ってます！
↓
そんなことないです！　固有の事情があるんです！　そう、固有の事情です！
受け取る参照を制限しているから、受け取ったら返せるんです！
↓
スコープで寿命が変わってるから返せないんだ！　こんなのは反例にならない！

早くこれに納得いく説明をしてくれよｗｗ
2026/07/20(月) 00:00:01.10ID:ePIKrZ+R
>>560
×ここまでに反例なし
○ここまでにID:GVCMKu1fの主張の証拠なし
2026/07/20(月) 00:00:59.52ID:WgMKnyG7
>>560
「ここまでに反例なし」じゃなくて「ここまでに僕が聞きたい降伏宣言なし」だろｗｗ
お前がやってることは反例に対して「僕が思ってたのと違う！！」って発狂しただけ
2026/07/20(月) 00:01:22.56ID:yjKLz6QF
日付変わったからID変わるし逃げるチャンスだぞｗ
565デフォルトの名無しさん
垢版 |
2026/07/20(月) 00:04:25.07ID:uo5Y2Bx6
鳩に餌をあげないでください
2026/07/20(月) 00:26:23.15ID:+KK2qof4
>>562-563
これだな
2026/07/20(月) 01:03:36.24ID:whsYlLNP
すっげー伸びてるじゃん
友達ができてよかったね複くん
2026/07/20(月) 01:29:30.72ID:FTzidL2p
RustとPythonってみんなどっちが書きやすいんだろ
個人的には断然Rustなんだが
569デフォルトの名無しさん
垢版 |
2026/07/20(月) 02:28:01.91ID:SUSKKYlc
コンパイルエラーとフォーマッタに依存しきった書き方してるからクレートあるものに関してはRustかなー
pythonのインデント調整を筆頭に色々とめんどくさいん、でもBlender関連は諦めてpythonで拡張してるし、obsidian関連はtypescriptで拡張してる
2026/07/20(月) 07:13:02.37ID:xinP/7ux
https://atmarkit.itmedia.co.jp/ait/spv/2605/08/news038.html
図1　プログラミング言語の案件別平均年収ランキング
1位　Rust　月額84万　年収1008万円
2026/07/20(月) 07:18:33.55ID:bz7XXARi
Pythonは軽く書くにはいいけど数百行でつらくなるからなあ
それ以上書くならRustだなあ
572デフォルトの名無しさん
垢版 |
2026/07/20(月) 07:42:00.48ID:guFOVLdG
>>568
パイソンいいよ
書き味がC#に似てる
573デフォルトの名無しさん
垢版 |
2026/07/20(月) 07:42:40.75ID:guFOVLdG
>>571
他人のコード渡されても安心なのがラスト
他人のコードでランタイムエラーになってキレそうになるのがパイソン
2026/07/20(月) 07:46:30.86ID:NK50dKXH
Rustに移ったら実行時エラー実行時デバッグが激減した
575デフォルトの名無しさん
垢版 |
2026/07/20(月) 08:00:48.22ID:guFOVLdG
>>574
ちょっとわかる
パイソンのときだと修正加えた瞬間に動いたような気がしたけど、細かい条件分岐に入ってランタイムエラーとかあるよねー
テストしろ！って怒られるのは覚悟の投稿
2026/07/20(月) 08:26:00.87ID:7Rhw2qA3
糞つまんねーサッカーやっと終わった
仕事サボってサッカーの話ばっかしてる派遣プログラマーは今月で契約終了
こいつに月50万も払って割に合わねーわ
577デフォルトの名無しさん
垢版 |
2026/07/20(月) 08:27:15.99ID:0sKavqd3
rustがスペインでclangがアルゼンチン
2026/07/20(月) 08:38:16.51ID:LWHvvzEG
ひとりで書く → Python
みんなで書く → Rust

※但し１か月前の自分は他人とする
2026/07/20(月) 09:04:09.07ID:RcARJTFP
Rustアンチが複おじに負けてて草
2026/07/20(月) 12:18:10.16ID:whsYlLNP
ウザくなってきたらissue#25860って言っとけば死ぬよ
延々関係ない方向で突っ走ってるけど>>159結局そういうことやろ
581デフォルトの名無しさん
垢版 |
2026/07/20(月) 15:59:06.97ID:szQO4V1s
確かにrust案件爆増中だが、GUI絡むとそうでもなかんべ？
汎用というにはまだほど遠い。
スペシャリストの世界。
2026/07/20(月) 15:59:48.85ID:sLwgYfCK
おじ(111)がいなくなると、あれだけ無尽蔵に人が湧いてきて
おじのテーマに沿ってレスバしてたのが嘘のようだな
583デフォルトの名無しさん
垢版 |
2026/07/20(月) 16:03:58.56ID:a2WJC20F
GUIは発展してるでしょ
無駄な装飾がなくて結構
2026/07/20(月) 16:28:36.12ID:pPSg1Dki
eguiて(笑)
2026/07/20(月) 17:14:59.49ID:PL45+lRs
>>581
何を言ってるんだこいつは……
ブラウザなんかGUIの最たるものだろ
2026/07/20(月) 17:16:09.17ID:VhtRD10G
>>580
未定義動作と言語仕様の差がわかってないの笑う
2026/07/20(月) 17:19:19.28ID:dl1I1D3P
どうせそういう変なこと言ってる奴は荒らしたいだけでまともな話したいわけじゃないからスルーした方がいい
2026/07/20(月) 17:57:06.05ID:t0i6pd/k
>>578
結局メンテするならRustってことか
589デフォルトの名無しさん
垢版 |
2026/07/20(月) 18:27:45.40ID:BxRlG/zJ
>>582
本人は自演がばれてないと思ってるっぽい
2026/07/20(月) 19:43:06.66ID:whsYlLNP
「どんな寿命の参照でも」って表現がまず曖昧でこれ単独じゃ何の意味も取れないんだけど
複おじとそのお友達はお互い何か意味のあることを言っていると思って、連休の2/3と数百レスを費やした挙句何の理解も得られてないってのはだいぶおもろいかもしれん
591デフォルトの名無しさん
垢版 |
2026/07/20(月) 19:47:20.49ID:PnKnKpht
>>590
後世の人がたまたま過去ログが詰まったハードディスク拾ってこのスレのログ見つけたとき、一体何をレスバしてたのか解読に苦しみそうだな
ロゼッタストーン並みに難解と言われそう
2026/07/20(月) 19:52:05.14ID:DWavJb6G
>>590
関数が参照を受け取った時
それが任意のライフタイムであっても関数から返せる
という当たり前の原則に見えたが
2026/07/20(月) 19:53:58.77ID:KaxLJD1L
新しいスレ住人のみんなはこれでご理解いただけたであろうか？
不毛？　徒労感？
これが複おじの提供する機能である
認知のゆがみがある人との対話が無駄に終わることを学べただろうか？

こいつはしょっぱなから「所有権の複製」とかいうアホ概念について
長きにわたり同じようなやりとりを既にやってるのである
594デフォルトの名無しさん
垢版 |
2026/07/20(月) 20:00:36.85ID:jeQChXBT
オレなら不毛な議論をせずに一発で証明できる

fn foo1<'a, T>(x: &'a T) -> &'a T {
x
}

fn foo2<'a, T>(x: &'a mut T) -> &'a mut T {
x
}

ライフタイムがどんなに短くても長くても受け取った関数にとっては中立
2026/07/20(月) 20:17:52.73ID:whsYlLNP
それだけですか？
それだけなんだろうな
2026/07/20(月) 20:21:57.37ID:whsYlLNP
ライフタイムについて真面目に勉強したい人向け資料

https://github.com/pretzelhammer/rust-blog/blob/master/posts/translations/jp/common-rust-lifetime-misconceptions.md
597デフォルトの名無しさん
垢版 |
2026/07/20(月) 20:24:42.75ID:uo5Y2Bx6
>>585
Rust製ブラウザとかあったっけ？
2026/07/20(月) 21:25:03.36ID:uGn3+DFY
Rust製ブラウザと言えばServo
そもそもRust自体がFirefoxを改善するために生まれた言語
599デフォルトの名無しさん
垢版 |
2026/07/20(月) 22:35:09.28ID:UJSv85dV
>>592
>>594
複おじまだいたのか
2026/07/20(月) 22:43:17.19ID:kp6lL+TA
>>597
FirefoxにもChromiumにも入ってるよｗ
FirefoxなんかもろCSSのレンダリングに使ってる
2026/07/20(月) 23:12:17.26ID:61nUbP3Q
アンチはやたら「100%RustじゃなかったらRustの意味はない」ってゼロヒャクを言いたがるよな
2026/07/20(月) 23:12:50.06ID:LQZCFRGP
>>594
Rustの言語仕様として受け取った参照を返すことができるのはもちろん正しい
一方で論争になっていたのはこちら
「なぜ関数が受け取る引数には型やライフタイムに制約があるものが存在するのか？」
結局これは関数が提供したい機能に依って受け取れる型やライフタイムに制約が生じる
こちらはRustの言語仕様とは関係ない
2026/07/20(月) 23:19:43.37ID:H8/wSbOi
>>594
これで何かを証明したつもりになっているらしい草
2026/07/20(月) 23:52:47.51ID:whsYlLNP
>>602みたいな主語抜けアスペ文で誰かに何かが伝わると思ってるほうが草だよ
605デフォルトの名無しさん
垢版 |
2026/07/20(月) 23:57:17.47ID:IJFMdDIv
>>602
まあそうなんだけど
'staticしか受け取らない関数なんて無数にあるのにspawnに固執してた人いたな
606デフォルトの名無しさん
垢版 |
2026/07/21(火) 00:58:47.10ID:QTPwz4XE
もうみんなclone()して幸せになろう
607デフォルトの名無しさん
垢版 |
2026/07/21(火) 01:02:17.70ID:llmZLZOr
Linux全面AI推進へ

リーナス・トーバルズが「LinuxはアンチAIではない」「気に入らないならフォークすればいい」などLinuxカーネル開発におけるAI利用について意見を述べる
https://gigazine.net/news/20260717-linux-linus-torvalds-ai/
608デフォルトの名無しさん
垢版 |
2026/07/21(火) 01:38:33.62ID:QTPwz4XE
貼る場所ちがくね
2026/07/21(火) 02:34:33.11ID:skCMy8IN
>>605
まだやってんのか
「ライフタイムの制約はない」とかほざいてる奴がいただけだろ
2026/07/21(火) 02:35:01.04ID:skCMy8IN
>>607
AI全面推進なんて書いてないしRustの話でもないし無茶苦茶
2026/07/21(火) 02:36:30.43ID:skCMy8IN
>>602
提供したい機能によってライフタイムの制約が生じるというのは間違ってないけど、言語仕様と関係ないというのは間違いだね
提供したい機能を言語仕様の制限の中で提供するにあたって、ライフタイムの制約を受けているので
2026/07/21(火) 02:50:42.06ID:x5O9ScDZ
>>611
それは言語機能による制約ではない
特殊な機能を提供するための各関数の固有の制約
2026/07/21(火) 02:54:10.33ID:G3LfMY0d
>>612
じゃあ言語仕様の制約はどの言語にも一切ないって主張になるな
そんな前提をぶち壊すラディカルな話をしろって言ってるわけじゃない
2026/07/21(火) 02:55:15.55ID:IG70nYUK
> 各関数の固有の制約

Rustにライフタイムの制約がないのに各関数が勝手にそれをつけてるって、流石にそんな嫌がらせはしないと思うが
2026/07/21(火) 03:01:24.29ID:pperHCQY
>>611
これよな
2026/07/21(火) 03:05:18.55ID:6mJa4phR
>>612の理屈をC言語の標準ライブラリで考えるとおかしさがわかりやすくて、malloc() で確保した領域を free() で解放しなきゃいけないのは標準ライブラリの仕様ではなくそれを使うコードのせい、みたいな話になってるんだよな
当然そんなわけはなくて、malloc() を使うことまではそのコードの問題だけど、free() を使う必要があるのは標準ライブラリの仕様に縛られているから
2026/07/21(火) 03:06:50.82ID:8oAusgWd
同じように、'static しか受け取れない機能を作ることまではその関数の問題であったとして、'static しか受け取れないという仕様の原因になっているのはライフタイムの制約を言語側が仕様として定めているからに他ならない
2026/07/21(火) 03:08:49.84ID:tAZ83IIh
こういう区別のつく人間って希少なんだよな……
619デフォルトの名無しさん
垢版 |
2026/07/21(火) 03:16:38.78ID:dnpNhuMb
>>612
その区別が重要だな
620デフォルトの名無しさん
垢版 |
2026/07/21(火) 04:02:54.66ID:llmZLZOr
###なぜ 'static やライフタイムの制約が存在するのか？

​Rustには**「ガベージコレクタ（GC）を持たずに、メモリ安全性と高いパフォーマンスを両立する」**という根本的な設計思想があります。これをコンパイル時の静的解析だけで実現するために編み出されたのが、ライフタイムのシステムです。
2026/07/21(火) 04:39:09.20ID:uj8HJQGP
>>620
GC言語でGC対象はヒープ領域に格納されるのに対して
Rustはスタック領域にある関数ローカル変数に値を置いたままそこへの参照を安全に使うことができる点が大きい
取り扱う参照がスタック領域を指しているかヒープ領域を指しているか区別することなく全く同様に扱えるようになった
つまりGC言語と比べてRustは自由を得た
2026/07/21(火) 14:15:41.69ID:lcbPHFy/
>>619
区別ついてない側なの笑う
2026/07/21(火) 14:18:04.24ID:lcbPHFy/
>>621
×取り扱う参照がスタック領域を指しているかヒープ領域を指しているか区別することなく全く同様に扱えるようになった
別に参照はこれまでの言語でもどちらの領域を指すか区別して用いるものではない
また、変数自体はスタック領域を指しているかヒープ領域を指しているか区別して扱う必要がある
2026/07/21(火) 14:18:31.22ID:lcbPHFy/
>>620
まあ、せやな
2026/07/21(火) 14:28:07.20ID:VQBl6cxm
Goで書き直されたTypeScript 7.0が正式リリースされてるね
自由度高くて安全で高速なGo実装を簡単にRustに移植出来たら良いのに
2026/07/21(火) 14:29:27.36ID:CzSf/WLm
>>623
嘘つくな
区別して扱う必要ない
627デフォルトの名無しさん
垢版 |
2026/07/21(火) 14:35:44.45ID:snwCrAuS
###なぜGoなのか
Rustの厳格な所有権や借用規則の世界へいきなりジャンプしようとすると、その「TS寄りの複雑な構造」そのものを根本から完全再設計しなければならず、難易度が跳ね上がってしまいます。
​つまり、移行元のコードベースの性質や、プロジェクトを現実的な期間でゴールさせるための「距離感」として、Goがちょうどよかったということですね。
2026/07/21(火) 14:36:57.76ID:+g9vCx9h
>>626
じゃあスタックに巨大構造体置きまくっても安心だな！
2026/07/21(火) 14:38:08.63ID:Y7iYabno
>>625
常に動き続けるホットパスでもないし、Rustである意味がないからなあ
2026/07/21(火) 14:42:04.63ID:dOwNZd0l
>>628
草
2026/07/21(火) 14:43:29.36ID:Q4NAg/vC
>>626はVecと配列の使い分けとかわかってなさそう
「どうしてサイズが決まってるのにVec使うんだ！」とか怒るのかなｗ
632デフォルトの名無しさん
垢版 |
2026/07/21(火) 14:46:23.20ID:zAGEz4m7
wasmあるのにうんこスクリプトとかどうでもよくね
633デフォルトの名無しさん
垢版 |
2026/07/21(火) 14:47:38.87ID:WrqAi9Ss
>>623
逆だよ
スタック領域を指しているかヒープ領域を指しているか区別して扱わなくても安全になったのがRust
2026/07/21(火) 14:48:11.17ID:tGu6saZ+
>>633
スタックとヒープの区別を free() するかどうかだけだと思ってそう
2026/07/21(火) 14:48:44.88ID:N6cPltdK
えっ、違うんですか！？
636デフォルトの名無しさん
垢版 |
2026/07/21(火) 14:54:33.42ID:llmZLZOr
>>632
うーむ...🤔
2026/07/21(火) 15:01:54.68ID:WbXqAfwq
Rustではスタック領域/ヒープ領域に正式な名称がないはずだから、Cの自動記憶域/割り当て記憶域って言葉を使うけど、自動記憶域は関数に入る時に関数の戻り先アドレス、引数、ローカル変数などをスタックフレームに積むプログラム自身の管理のための機能になってる
だから変数を置く領域の広さはそこまでなくて、OSによって違うけどデスクトップやモバイルなら1MiB〜8MiBくらいしかない
したがって、大きなデータは割り当て記憶域に置く必要があるので、たとえばさっきの配列とVecの例なら、大きな配列はサイズが固定されていても割り当て記憶域を確保するVecで作りましょう、という使い分けが必要になる
2026/07/21(火) 15:02:14.97ID:2WiNYKUy
最後のここはおかしい

>>623
>>また、変数自体はスタック領域を指しているかヒープ領域を指しているか区別して扱う必要がある
2026/07/21(火) 15:03:33.41ID:yMrwq5y3
>>638
この書き方あの荒らしじゃん
めちゃくちゃなこと言って反論が来たら大喜びで荒らすだけの奴だからスルーでいい
2026/07/21(火) 15:04:07.09ID:2WiNYKUy
>>637
それはスタックに置くかヒープに置くかの使い分け
そちらは使い分けすること
2026/07/21(火) 15:04:36.57ID:SlBA2UO5
>>637
なるほどー
2026/07/21(火) 15:05:15.27ID:pv54lT0d
>>640
区別せずに使い分けるのか
面白いこと言うねｗ
2026/07/21(火) 15:05:27.99ID:2WiNYKUy
>>639
どこが荒らしだよ

>>623は間違っている
>>637は正しい
2026/07/21(火) 15:05:33.13ID:/9FNoXDk
荒らしはスルー、これ基本
2026/07/21(火) 15:06:57.63ID:2WiNYKUy
間違えたことを書いた>>637が俺を荒らし扱いかよ
646デフォルトの名無しさん
垢版 |
2026/07/21(火) 15:07:05.45ID:llmZLZOr
そもそもチェリーピックの連鎖だから読んでない😅
2026/07/21(火) 15:07:16.18ID:MmhJ1S97
>>637
話の本筋からはそれるけど、Cでは自動記憶域がスタックじゃない可能性ってあるけど、Rustだとどうなんだろう
どっちみちスタック領域って言葉だと混同するから自動記憶域でいいとは思うんだけど
2026/07/21(火) 15:07:57.43ID:2WiNYKUy
ごめん
>>645はミス
間違えたことを書いてるのは>>623
2026/07/21(火) 15:10:33.04ID:4b7drwod
どうやったらケチつけられるかだけ考えてる荒らしもいるってだけ
相手にしなければ消える
650デフォルトの名無しさん
垢版 |
2026/07/21(火) 15:11:20.02ID:XlCg0k5h
###まとめてみると
「意識する必要がない」というのは**
「メモリリークや解放漏れ、ポインターの不正参照の心配をコンパイラが肩代わりしてくれるため、安全かつ自動で処理される」**という意味において非常に正確です。

​ただし、パフォーマンスの観点からは、**「データのコピーコスト（スタック）」と「ヒープアロケーションのコスト（動的確保のオーバーヘッド）」**の違いを理解しておくことが、高速なコードを書く上で重要になる場面もあります。
2026/07/21(火) 15:12:44.46ID:2WiNYKUy
>>647
Rustではローカル変数(local variable)と呼ぶ
2026/07/21(火) 15:13:35.13ID:kXoc5vQo
>>651
ローカル変数のある領域の話をしているのでは？
2026/07/21(火) 15:14:32.40ID:bNNm5rfo
>>647はどう呼ぶか聞いてるんじゃなくて、スタックで実装されてるかどうかを聞いてるんだと思うが、>>651は何が言いたいんだ
2026/07/21(火) 15:16:03.38ID:2WiNYKUy
>>652
変数はローカルつまりスタックか
あるいはstaticのどちらかにしかないためそこを区別する必要はない
変数はヒープに置くことができないため
2026/07/21(火) 15:16:14.13ID:tubUJsTp
>>647
Cと同じく意味論として挙動が決まっているだけだから、実装がスタックを使う保証はない
実際にはほぼ確実にスタックが使われるところまで、Cと同じだよ
2026/07/21(火) 15:17:04.09ID:2WiNYKUy
>>653
スタックで実装されているかどうかは機種アーキテクチャに依る
2026/07/21(火) 15:17:45.78ID:tubUJsTp
>>654はちゃんとした話はする気ないからやっぱりスルーでいいんだよ
荒らしは放置安定
2026/07/21(火) 15:19:02.28ID:FH4yxgtk
何聞かれてるか回答見るまで理解できてなかったのか
2026/07/21(火) 15:19:18.93ID:2WiNYKUy
>>657
正しいことしか言ってないが何が気に入らない？
>>623が間違っていると指摘したことを逆恨みかね？
2026/07/21(火) 15:20:47.40ID:FH4yxgtk
もうこの荒らしについて言及するの禁止な
ID:2WiNYKUyにレスすんな
2026/07/21(火) 15:22:04.19ID:J9RlHKjx
>>637
Windowsが1MiB、Unix系が8MiBなんだっけ？
2026/07/21(火) 15:22:57.37ID:2WiNYKUy
>>660
意味のないことを一つも書いていないおまえが荒らしだろ
663デフォルトの名無しさん
垢版 |
2026/07/21(火) 15:23:24.83ID:jQxUHqaw
Windowsはそうだけど、Unix系と言っても広いからなあ
まあ、デスクトップとモバイルだけならmacOSとLinuxだけ考えればいいんだろうけど
macOSとLinuxだけなら8MiBであってたはず
2026/07/21(火) 15:25:12.62ID:t00ocqsc
Linuxでも組み込みだと違いそうだよな
2026/07/21(火) 15:27:20.73ID:40SuJKkv
> スタック領域を指しているかヒープ領域を指しているか区別して扱わなくても安全
そんなことはみんなわかってる

> 取り扱う参照がスタック領域を指しているかヒープ領域を指しているか区別することなく全く同様に扱える
それは全く別の話だぞおい

ってだけなんだよな
2026/07/21(火) 15:30:15.43ID:DT06qJlN
>>665
厳密に言えば区別せずにスタックに大きな構造体なり配列なりを置きまくってたらスタックオーバーフローすることはあるから、メモリ安全なだけで他の安全は保障されてないんだけどな
2026/07/21(火) 15:35:58.30ID:2WiNYKUy
>>661
基本はそうだけど
特にRustの場合はメインスレッドと新規スレッドで異なる点が重要
メインスレッドはOSレベルで指定でLinuxなら8MBがデフォルトだがulimit -sで自由に変更できる
新規スレッドはRustの中で指定でデフォルトは2MBだがスレッドのビルダーで自由に指定できる
だからRustではサイズの大きなものをスタック上に置ける
2026/07/21(火) 15:46:56.23ID:I5lpyWej
>>667
まあ大きくしすぎてもでメリットがあるからあんまやらないし、新規スレッドだけの話だからどこでも自由なわけでもないし、使い分けを意識してない奴ができることでもないんだけどな
2026/07/21(火) 15:47:46.31ID:XIv+O+su
そいつは放置しろって言ってるだろ
2026/07/21(火) 15:54:29.22ID:2WiNYKUy
>>668
スタック領域を大きくして使うことは
ヒープを使うことと比べて不利にならない
新規スレッドだけの話ではなくメインスレッドもスタックを大きくして使われている
ulimit -sで誰でも変更可能でその後に起動すればメインスレッドのスタックを大きく使えるため
2026/07/21(火) 16:03:56.55ID:8y3GD3Tf
>>670
スタック領域に大きなデータを置くと関数の壁を跨ぐ度にディープコピーになる
これは当然動作速度に悪影響を与える
ヒープ領域なら .clone() しない限りムーブになるので、シャローコピーして所有権を渡すだけなのでこの悪影響を回避できる
2026/07/21(火) 16:04:57.47ID:xd5iI70P
>>670
ulimitが必要な時点でデメリットあるやんけ
2026/07/21(火) 16:05:38.98ID:2WiNYKUy
>>671
Rust初心者でもそんな間違いしないぞ
2026/07/21(火) 16:06:00.04ID:AeCBf1sw
>>671
そっか、moveが標準だからヒープをわざわざコピーするわけないのか
2026/07/21(火) 16:06:45.90ID:AeCBf1sw
また何が間違いなのかも言わずに間違いだと主張する荒らし仕草が出たな
676デフォルトの名無しさん
垢版 |
2026/07/21(火) 16:09:01.68ID:HmEIVqbd
>>675
自閉症スペクトラム総合スレ86【ASD】発達障害
https://mevius.5ch.io/test/read.cgi/utu/1782020264/
2026/07/21(火) 16:10:12.70ID:O12s/9BG
可変借用は元のところに返すわけじゃないならデメリットが大きいからなあ
わざわざ大きなデータを置いて寿命を気にして可変借用を引き回すより、ヒープに置いてムーブした方が素直な実装になって楽なんだよな
2026/07/21(火) 16:10:44.00ID:TYtR9CLl
>>676
アンカー間違ってますよ
2026/07/21(火) 16:11:10.33ID:S3O97n0J
>>673
自閉症スペクトラム総合スレ86【ASD】発達障害
https://mevius.5ch.io/test/read.cgi/utu/1782020264/
680デフォルトの名無しさん
垢版 |
2026/07/21(火) 16:12:22.16ID:q4wR5dpo
自閉症はC#みたいなのを好む
馬鹿だから😂
2026/07/21(火) 16:13:11.43ID:fB1yulXn
大きなデータをスタックに置くと他所で書き換える用途が1つあるだけで可変借用が面倒なことになるよな
ムーブできないのはめんどくさい
682デフォルトの名無しさん
垢版 |
2026/07/21(火) 16:13:12.93ID:FfUaKNHi
😭
https://i.imgur.com/QdnVOt2.png
2026/07/21(火) 16:13:49.10ID:fB1yulXn
何も考えず上げるアホのせいで荒らしが増えたな
2026/07/21(火) 16:15:20.14ID:ahw91GYg
荒らしが仲間読んで増えちゃってるじゃん
だから話しかけんなって言ってんのに
2026/07/21(火) 16:15:27.18ID:2WiNYKUy
>>677
本気か？
関数を呼び出すたびにその関数へムーブしていってを深く繰り返し戻る時は返り値で何度もムーブして返すのかね？
爆笑すぎて笑ってしまった
686sage
垢版 |
2026/07/21(火) 16:18:58.43ID:Hil5y1j1
ageで荒らしが来るって5chをPCで操作してるのかな？いろいろ時代遅れ極まりない

【専ブラ】5ちゃんねるブラウザ「ChMate」part269
https://egg.5ch.io/test/read.cgi/android/1784035194/
2026/07/21(火) 16:19:37.34ID:hTZmyRpd
>>685
無意味に可変借用し続けてライフタイム注釈書きまくる奴の方がアホなんだよなあ
C++とRustは違う言語だと理解した方がいい
2026/07/21(火) 16:20:05.98ID:hTZmyRpd
ほら荒らしが来た
2026/07/21(火) 16:23:46.80ID:2WiNYKUy
>>687
ギャグではなく本気かよ
関数の引数でムーブで渡して返り値でムーブして戻すなんて爆笑行為だろ
2026/07/21(火) 16:24:18.10ID:jitdnUFF
>>689
moveの意味知らなそう
2026/07/21(火) 16:26:07.39ID:ahw91GYg
ムーブとコピーの区別がついてるかも怪しい
こいつ言ってることがいちいちRust知識皆無なんだよな
2026/07/21(火) 16:31:09.85ID:yw9QsJ6s
mut self なんか日常的に取るだろ
ムーブしない設計に固執するのはバカ
2026/07/21(火) 16:36:21.16ID:tqPKLH4t
>>677は
> 可変借用は元のところに返すわけじゃないならデメリットが大きいからなあ
って言ってるのに
>>689は
> 返り値でムーブして戻すなんて爆笑行為
とイチャモンをつけてる
2026/07/21(火) 16:36:36.50ID:hFTJcci7
荒らしは放置
2026/07/21(火) 16:40:15.47ID:DT9zLzL2
ビルダーパターンもイテレータアダプタもムーブなんだが、知らないのかな？
2026/07/21(火) 16:50:13.47ID:2WiNYKUy
>>695
それらは一階層のみ
しかもヒープを使わずにselfはスタック上で問題ないパターンなので今回の話とは全く関係がない
2026/07/21(火) 16:58:30.31ID:aLius24S
>>696
関係あるんだよなあ
それに実装のやり方次第だから1階層なんて保証も全くないし
2026/07/21(火) 17:00:42.33ID:cV1W7TCj
スタック領域でもムーブを書けることと、ディープコピーがないことは別なんだよな
引数ならまだしも、戻り値にする場合その関数のスタックは破棄されるのでディープコピーは発生する
2026/07/21(火) 17:01:51.78ID:2WiNYKUy
>>697
ビルダーもイテレータも通常スタック上に置く
そして支障はない
ヒープを使わなければいけない例になっていない
2026/07/21(火) 17:02:45.16ID:OLRGAddi
どうせこいつまともな知識ないくせにイキってるだけだから何言っても無駄だぞ
荒らしはスルーが安定
2026/07/21(火) 17:03:54.13ID:OLRGAddi
>>699
大きなデータをスタック領域においても何のデメリットもないと主張してたのはお前だぞ
小さいから支障がないって主張はそれと矛盾してるよなあ
2026/07/21(火) 17:04:33.67ID:AUT4IY/C
まあこの程度の話がわからない奴なんだから相手しても無駄
2026/07/21(火) 17:04:56.19ID:HO4SZ0K4
>>701
お前が反応してどうする
2026/07/21(火) 17:07:21.81ID:aA5nG03I
ID:2WiNYKUyはID:GVCMKu1f
大した知識もないくせにチェリーピックと無茶苦茶な主張で何百書き込みも荒らしたやつだから相手しちゃダメ
2026/07/21(火) 17:10:25.68ID:QMF0m492
荒らしなんかやるレベルのバカにはRustは難しいんだよ
2026/07/21(火) 17:12:38.20ID:Dk5sqQuX
結局>>671が結論でそこから先荒らしが喚いてただけ
2026/07/21(火) 17:19:23.86ID:n2iwmqGn
>>698
スタックじゃない実装の場合は変わるのかね
2026/07/21(火) 17:32:08.98ID:2WiNYKUy
>>701
その「小さいから支障がない」を主張したことがない
そのビルダーやイテレータのパターンならスタック上に大きなデータでも問題ない
「ヒープを使わなければいけない例になっていない」と主張している
早くヒープを使わなければいけない例を示してくれ
2026/07/21(火) 18:30:11.05ID:2WiNYKUy
>>706
>>671に現実味がないため議論になっている
既に話がでているパターンのあちこちの例はスタック上に置いて使われているがコピーは発生せず問題になっていない
他のパターンだと例えば関数奥深くで大きなデータを作って一番上の関数まで返していくパターン
これはRustでもRVOになる
つまり関数奥深くから一番上の関数のスタックフレームへ直接代入してしまうため大きなデータのコピーは発生しない
2026/07/21(火) 18:42:19.18ID:HHuPuFDF
>>671>>698
ディープコピーの意味を勘違いしてる
昔の複オジと同じ勘違い
2026/07/21(火) 19:22:01.43ID:2WiNYKUy
>>710
その人の書き込みは意味の勘違いに用語の間違いもあって突っ込みどころ満載だよね
それなのになぜかその書き込みを支持してる人がいるから同一人物による自演支持なのかも
あと同じ間違いをしてるからその二つの書き込みも同一人物かも

>>698
戻り値にする場合は先ほど書いたようにRVOでコピーされない
2026/07/21(火) 19:38:35.29ID:28j0dMrv
>>708-711
どう見ても自演なのはそっち

>>708
先日に続いてまた同じ荒らし方
根拠なく「そんな事実はない」「例を示せ」と言うだけ言って何も聞かないやつ

>>709
> コピーは発生せず問題になっていない
根拠がないし、スタックで戻り値ならコピーは発生する

> RustでもRVOになる
単純なケースでコンパイラが最適化することと、言語仕様を混同することはできない
2026/07/21(火) 19:38:44.43ID:28j0dMrv
>>710
ディープコピーとは実体をコピーすることで>>671 >>698の使い方に間違いはない
勝手な思い込み定義をしているのか知らないが

>>711
> 意味の勘違いに用語の間違いもあって突っ込みどころ満載
どこがかは言えないいつもの荒らし仕草
2026/07/21(火) 19:47:57.74ID:y21dV+Vh
こう訊いたら
> is RVO always applied in Rust?

こう即答されて、その後、RVOになる可能性の低い場合を挙げてくれる
> No, Return Value Optimization (RVO) is not guaranteed by the Rust
> language specification.
2026/07/21(火) 21:50:22.11ID:zMkCdy3E
初出のIDが「どう見ても自演なのはそっち」とは面白い冗談ですね
2026/07/21(火) 21:54:04.61ID:BzW/oQJ/
>>715
何言ってんだこいつ
2026/07/21(火) 21:54:44.07ID:PsDVu0+l
>>714
最適化はコンパイラの実装の問題でしかないからねえ
2026/07/21(火) 22:18:44.95ID:2WiNYKUy
>>712
自演してません
>>710は別人です
あなたの自演の可能性を疑った理由はあなたの書き込みが突っ込みどころ満載なのに突っ込まれずになぜか支持する人がいて更に同じ間違いをしてる書き込みがあったためです
2026/07/21(火) 22:19:07.57ID:DbCuiygU
ID:2WiNYKUy（ID:GVCMKu1f）ってずっと「ほんの少しのケースにだけ当てはまること」を「全部必ずこうなる！」って主張して、「これならないんですけど」と言われたら条件を増やし始めるという論法ばっかりだよな
2026/07/21(火) 22:20:42.35ID:Y2iieiR6
>>718
自分の主張を否定してるから突っ込みどころ満載なんだ！と言いたいわけですな
2026/07/21(火) 22:23:20.52ID:2WiNYKUy
>>713
ディープコピーは分野によって微妙に指すものが異なることもある言葉ですが
Rustでは公式に使われ方が一定しています
あなたの使い方はそれとは異なり間違っています
Rustのbookなどで使われる時は常にヒープ領域まで含めてコピーすることをディープコピーと呼んでいます
>>671も>>698もスタック領域について言及していますからディープコピーではありません
2026/07/21(火) 22:31:09.33ID:ElegamEg
>>721
「The Bookではスタック上のコピーをCopyトレイトでしか語らない」ということと「スタック領域について言及していますからディープコピーではありません」というのとは結び付いてないんだよな
論理が2段階くらい飛躍してる
2026/07/21(火) 22:33:33.85ID:JUKJhZF2
それに、実体をコピーすることをディープコピーと言うのはプログラミングにおいて一般的な用法なので、これを間違いだと断言するのは法律家に「変数に人格はないから所有権は認められない」って言わせるのに近くてあまり意味がない
2026/07/21(火) 22:35:27.54ID:YS4VSVPg
https://mevius.5ch.io/test/read.cgi/tech/1652347700/52

ディープコピーこれか
今はこれくらい吹っ切れたこと言わないで言葉濁してばっかりでつまらんわ
2026/07/21(火) 22:36:11.69ID:9K5Ee26J
要するに「今そんな話してない」って話よな
アスペはすぐ「こうも解釈できるから違う」って言いたがるけど、人と話してるんだからこういう複数定義が見つかるものであれば、まず何を伝えようとしてるかから類推する必要がある
2026/07/21(火) 22:37:02.36ID:9K5Ee26J
>>723
そのアスペ法律家ちょっとおもろい
2026/07/21(火) 22:44:14.93ID:2WiNYKUy
>>722
the bookで明記していますよ
スタック領域のムーブは2つのうちのどちらかで強いて言えばシャローコピー

If you’ve heard the terms shallow copy and deep copy while working with other languages, the concept of copying the pointer, length, and capacity without copying the data probably sounds like making a shallow copy. But because Rust also invalidates the first variable, instead of being called a shallow copy, it’s known as a move.

通常は二つの対比が必要ないならばCopyトレイトに明記されてるようにビットコピーと呼ぶのが良いでしょう
2026/07/21(火) 22:47:38.39ID:2WiNYKUy
これがRust界での常識です
学習してください
ではおやすみなさい
2026/07/21(火) 22:50:37.62ID:pIdf2Ljv
>>723
>それに、実体をコピーすることをディープコピーと言うのはプログラミングにおいて一般的な用法なので
全く一般的ではありません。完全にあなたの勘違いです。
早めにそれも匿名掲示板で恥をかいてよかったですね。
2026/07/21(火) 22:53:57.77ID:eFLxnQVM
>>727-729
どう見ても自演
2026/07/21(火) 22:57:05.01ID:3DpZBFH1
>>727
自分で貼った文章を読んでいないみたいだが全く違う意味の話をしてるぞ
雑に要約すると「一般的な言語で言うシャロ―コピーをムーブと呼んでいます」と言っているのであって、スタック領域に確保したオブジェクトをコピー/ムーブすることをどう表現するかには言及していない
いつもそうですが、あなたは自分が言いたいことを言うのに都合のいい記述を探しているだけで、ちゃんと文章を読んでいないからそういう間違いをするんです
2026/07/21(火) 22:58:34.14ID:5eyHU167
>>728 >>729でせっかく人バカにして散々イキったのに、>>731にしっかり訂正されて恥かいてて草
2026/07/21(火) 23:01:52.27ID:B+Y3bEuK
>>729
ディープコピー（深いコピー）とは - IT用語辞典 e-Words
https://e-words.jp/w/%E3%83%87%E3%82%A3%E3%83%BC%E3%83%97%E3%82%B3%E3%83%94%E3%83%BC.html

> ディープコピーとは、配列やオブジェクトなどのデータ構造を複製する際、同じ構造の実体を新たに作成して対応するデータを写し取る方式。

これは全く一般的ではなかったのかー
お前の記憶の方がこっちより正しかったんだなｗ
2026/07/21(火) 23:03:22.98ID:sxvJfiz9
Deep copy (ディープコピー) - 用語集 | MDN
https://developer.mozilla.org/ja/docs/Glossary/Deep_copy

> オブジェクトの ディープコピー とは、コピー先のオブジェクトのプロパティがコピー元のオブジェクトのプロパティと同一の参照（同じ値を指す）で共有しないコピー方法のことです。結果として、コピー元かコピー先のどちらかを変更しても、もう一方オブジェクトにも変更を及ぼしていないことを保証できます。すなわち、コピー元かコピー先に意図せずに予期しない変更が加えられるこはありません。この振る舞いはシャローコピーとは対照的です。シャローコピーでは、コピー元かコピー先のどちらかを変更するともう一方のオブジェクトも変更される可能性があります。

これも一般的ではなかったんだなあｗ
2026/07/21(火) 23:05:44.19ID:6e3KrnZd
>>729
アホほど浅い知識ですぐに断言して他人を煽りたがるよな
2026/07/21(火) 23:08:27.17ID:fQZ8gbX2
>>727
> the bookで明記していますよ
嘘はやめましょう
あなたの引用した範囲には「一般的にシャロ―コピーと呼ばれる操作と、元の変数を使えなくする挙動を合わせて、ムーブと呼称する」という内容しか書かれていません
あなたの主張するようなことは一切書いてないですね

>>728
> これがRust界での常識です
> 学習してください
あなたがまず自分で貼った文章くらい読めるようになってください
2026/07/21(火) 23:11:23.23ID:YS4VSVPg
この複製おじさんのID変えない版みたいなやつこの前の週末からか？
面白くなってきた
2026/07/21(火) 23:11:55.24ID:enjQvq/8
> スタック領域のムーブは2つのうちのどちらかで強いて言えばシャローコピー
流石に無理がある

> copying the pointer, length, and capacity without copying the data probably sounds like making a shallow copy
日本語訳: データをコピーせずにポインタ、長さ、容量をコピーすることは、おそらく浅いコピーを行うことのように聞こえるでしょう

"without copying the data" 「データをコピーせずに」と断言されている
スタックの仕組みを知っていれば戻り値では論理的にコピーが生じる（実装での最適化の話はしていないことに注意）ので、ここで言われているのはヒープ領域のムーブの話に過ぎない
2026/07/21(火) 23:13:44.57ID:ADBZCODt
> これがRust界での常識です
> 学習してください

ｗ
2026/07/21(火) 23:17:24.46ID:i+g+TbZ6
> 関数の引数でムーブで渡して返り値でムーブして戻すなんて爆笑行為だろ
そもそもこんなこと言ってたくらいにはRust知識ないからね
一生懸命The Book読んで反論材料探してるだけで、何の知識も持ってないよこいつ
2026/07/21(火) 23:18:33.64ID:prLGQ+o1
英語読めないなら日本語翻訳版のThe Book開けばいいのに……ｗ
英語の成績悪かった俺でもおかしなこと言ってるなって気づく程度には読めてないぞ
2026/07/21(火) 23:23:57.63ID:2WiNYKUy
>>730
自演してません
>>729は別人です
2026/07/21(火) 23:25:05.17ID:2WiNYKUy
>>731 >>736
一部引用してあげただけなのに
その部分しか読んでないのですか？
Rust Bookでは一貫してます
clone()によってヒープ領域までコピーすることをディープコピーと呼んでいます
ムーブによってスタック領域のみをビットコピーすることをシャローコピーと呼んでいます
2026/07/21(火) 23:26:36.15ID:2WiNYKUy
>>734
そこに書かれてるように二段階の領域のうち二段階目(Rust Bookではヒープ領域)もコピーすればディープコピーとRust Bookで述べています
一段階目(Rust Bookではスタック領域)のみビットコピーのムーブならシャローコピーとして区別しています
したがって>>671と>>698は明確に間違いです
2026/07/21(火) 23:28:03.12ID:XdrfV7kF
>>731
>> いつもそうですが、あなたは自分が言いたいことを言うのに都合のいい記述を探しているだけで、ちゃんと文章を読んでいないからそういう間違いをするんです
かなりキツくて草
2026/07/21(火) 23:28:53.51ID:XdrfV7kF
>>743
「わざと関係ない場所を引用しただけです！」ってか？
流石に主張に無理があるわｗ
2026/07/21(火) 23:30:12.16ID:7bDfgG31
>>744また都合のいい幻視が始まってるぞ
2026/07/21(火) 23:32:01.86ID:mion99Qn
>>744
唐突に二段階とか言い出して話をややこしくしてるが、結局お前が言ってるようなことはどこにも書いてないな
2026/07/21(火) 23:32:05.13ID:poCaFg3z
ヒープかスタックか、みたいな話で終われないんじゃないの？
（一人を除いて（？）みんなが思ってるディープコピーは同じのような気もするけど）
ディープコピーは文字通り深く、根元まで全部コピーしてくれる

a = [[1, 2], 3]
b = a.clone # shallow copy
c = Marshal.load(Marshal.dump(a)) # deep copy
a[0][0] = 11
a[1] = 33
p a # [[11, 2], 33]
p b # [[11, 2], 3]
p c # [[1, 2], 3]

b[1]は3のままだけど、b[0][0]は11になっちゃってるのがシャロ―コピー
全てを複製しきってるのがディープコピー

Rustでも同じようなことにならない？
Rustにディープコピーあるのかどうか知らんけど
2026/07/21(火) 23:32:58.06ID:iK9zpUBS
こいつスタック領域とプリミティブ型の区別ついてないんじゃね
配列とか構造体とかちゃんと触ったことないんだろ
2026/07/21(火) 23:34:37.27ID:pIdf2Ljv
>>733の定義は「新たに作成する同じ構造の実体」がコピー対象の配列やオブジェクト自体のように読める文章になっちゃってるから間違ってると言っていいね

>>734のMDNのは間違ってないけど君の言ってる内容とは全然違うよね

wikitionaryの定義がわかりやすい
A copy of a data structure duplicating not only the structure itself, but all structures to which it is linked.

例えば[Vec<i32>; 5]という配列をディープコピーするというのは
Vecというfat pointerを5個含む配列というデータ構造をコピーするだけでなく
そのfat pointerらが指し示す先のデータ構造であるi32たちもすべて含めてコピーすること
2026/07/21(火) 23:34:59.05ID:COhktLyH
>>750
たしかにそれっぽいな
それなら>>744の説明はつく
まあ、そうだとしてプリミティブ型ならディープコピーとシャロ―コピーが一致するなんてわかりきった話をしてるわけではないんだが
2026/07/21(火) 23:36:08.82ID:2WiNYKUy
明確に間違っている>>671と>>698を擁護してる人は信頼されません

アドレスやインデックスなどの値を変数に持っている時に
そのアドレスやインデックスなどによって指されている先のデータまでコピーすることがディープコピーです
スタック領域のムーブによるビットコピーをディープコピーと呼ぶのは頭悪いです
2026/07/21(火) 23:36:34.25ID:69RgfUCQ
>>751
> 「新たに作成する同じ構造の実体」がコピー対象の配列やオブジェクト自体のように読める文章になっちゃってるから間違ってると言っていい
いや、「新たに作成する同じ構造の実体」が元の実体と同じって「新たに作成する」って部分を完全に無視してるよね
あんたが日本語出来ないだけだよ
2026/07/21(火) 23:37:20.17ID:Zg2X1Ixv
>>753
間違っている根拠を出さずに間違っているって喚くいつものパターン
また同じ荒らし方か
2026/07/21(火) 23:38:27.87ID:H27nQAne
>>753
その「間違ってるから間違ってるんだ！俺の言うことは正しい！こいつの言うことは間違ってる！こんなのは信頼できない！」って論法聞き飽きたからやるなら他のやってくれ
それしか出来ないなら出て行って、どうぞ
2026/07/21(火) 23:39:36.73ID:an7CxeVk
おじは全体的に過疎ってる5chの中でも過疎ってるマ板の
さらにニッチなRustのスレで、さらにおじの面白くもない話題に律儀に付き合ってる人間が
おじが来るたびに毎度毎度何十人と湧いてくる状況が、いかに他人からおかしく見えるか客観視したほうがいい
もはやAIでも状況から推測ができるんだし
2026/07/21(火) 23:39:41.62ID:2WiNYKUy
>>750
The Bookを読みなさい
スタック領域に置かれたVec構造体をムーブによりビットコピーすることはディープコピーではありません
clone()によってヒープ領域までコピーする時のみディープコピーとRustでは呼んでいます
2026/07/21(火) 23:40:22.59ID:2Xpxs7rc
>>749
> 一人を除いて（？）みんなが思ってるディープコピーは同じのような気もするけど
> ディープコピーは文字通り深く、根元まで全部コピーしてくれる
そっすね
なぜか若干一名自分の貼った文章すら読めない奴が違うって言ってるけど
2026/07/21(火) 23:41:02.85ID:WzqHMHOy
>>758
> スタック領域に置かれたVec構造体
はい解散
こいつやっぱ何も知らないのにイキってるだけだわ
2026/07/21(火) 23:42:18.13ID:2WiNYKUy
一方で>>671と>>698はヒープ領域をコピーしないのにディープコピーと書いていますから間違ってます
2026/07/21(火) 23:43:08.42ID:zTzlaZU1
スタックに置かれる配列の話をしてるのに、Vecの管理構造体がどうとか言い出しちゃう時点で、Rust知識がまともにないってのはわかる
2026/07/21(火) 23:43:53.44ID:zTzlaZU1
ID:2WiNYKUyは配列すらわからないということが判明しました
これでよくイキってられるよな
2026/07/21(火) 23:44:40.86ID:DT06qJlN
>>761
お前の妄想の中ではそうなんだな
Rustの仕様やThe Bookにそんなことは書いてないが
2026/07/21(火) 23:45:15.06ID:2WiNYKUy
>>760
普通にlet v = Vec::new();するとVec構造体はスタック領域に置かれることを知らなかったのですね
勉強しなさい
2026/07/21(火) 23:45:50.45ID:Q0snuN7U
The Bookでディープコピーという言葉をどう使っているかという話と、ディープコピーという言葉が一般に何を指しているかという話の区別がつかない時点でね
2026/07/21(火) 23:46:24.75ID:9gOpu4wN
>>765
実はVecって配列じゃないんですよ
今してるのは配列の話です
2026/07/21(火) 23:46:33.58ID:2WiNYKUy
>>762
配列に特有の話は一切していませんが
どこから唐突に配列？？
2026/07/21(火) 23:47:35.41ID:rMUsxY/a
>>765
誰もVecの管理構造体がスタックに置かれる話を否定してないよｗ
お前が勝手に妄想してるだけ
2026/07/21(火) 23:47:38.85ID:2WiNYKUy
>>767
配列の話をしている人はいません
あなたの妄想ですか？
2026/07/21(火) 23:47:41.98ID:pIdf2Ljv
>>754
君の中で「実体」の定義が定まってないようだね
>>751の定義では「実体」と「データ」は別

その定義に沿わずにもう少しわかりやすく書くと
>>751の定義では「新たに作成する同じ構造」がコピー対象の配列やオブジェクト自体の構造のように読める文章になっちゃってるから間違ってるという話
2026/07/21(火) 23:48:33.25ID:YeuD6aXY
>>768
スタック領域に構造体や配列などの大きなデータを置く場合の話をずっとしてたよね？
なぜかお前がヒープ領域にデータを置くVecの話を始めたわけだけどｗｗ
2026/07/21(火) 23:49:22.24ID:YeuD6aXY
>>771
そういえばこいつもVecと配列の区別ついてなくて草
わかりやすい自演だなあｗｗ
2026/07/21(火) 23:49:50.32ID:2WiNYKUy
元の書き込み>>671と>>698にも配列なんて出て来ませんし
わたくしも配列なんて一度も書き込んだことはありません
なぜ唐突に配列と叫びだしたのですか？
2026/07/21(火) 23:50:37.04ID:2wZTIRF6
>>771
お前が勝手に始めた定義なんぞ知らんわｗ
普通は「実体」と言って「管理構造体だけ」を指すなんて考えねえよｗｗ
データごとに決まってるだろｗｗｗｗｗ
2026/07/21(火) 23:51:04.61ID:zxSrFRZk
>>774
バカにはわからないと思うが、プリミティブ型は巨大じゃないんだぜｗ
2026/07/21(火) 23:51:37.24ID:sU29O3wY
>>776
それ以前の問題
この人さっきまでプリミティブ型自体を知らなかったから
2026/07/21(火) 23:51:49.21ID:pIdf2Ljv
>>771
アンカ間違えてたわ
↓修正版

>>754
君の中で「実体」の定義が定まってないようだね
>>733の定義では「実体」と「データ」は別

その定義に沿わずにもう少しわかりやすく書くと
>>733の定義では「新たに作成する同じ構造」がコピー対象の配列やオブジェクト自体の構造のように読める文章になっちゃってるから間違ってるという話
2026/07/21(火) 23:52:36.08ID:auYTZTx+
>>671が結論でそこから先無知な荒らしが喚いてただけ
2026/07/21(火) 23:52:45.54ID:2WiNYKUy
>>772
配列でも構造体でも数値でもローカル変数としてスタック領域に置かれるものはすべて同じ対象です
それらの複合型まであるのですから
Rustにおいて配列の場合だけ特殊に何か変わることはありません
2026/07/21(火) 23:53:11.94ID:iTFVdb9H
> >>733の定義では「実体」と「データ」は別
↑根拠なし
2026/07/21(火) 23:53:52.50ID:e1pVD1JT
>>780
そうだね
ちなみに特殊に変わるってお前以外は誰も言ってないよ
2026/07/21(火) 23:54:11.35ID:2WiNYKUy
>>779
間違ってる>>671を批判せずにそうやって結論にするのはいかがなものかと
2026/07/21(火) 23:54:42.12ID:NgcGGC/+
文章は読めないし知識はないしバカなんだからそれこそ半年ROMってろよ
2026/07/21(火) 23:55:39.64ID:KsT9HPFN
>>783
間違ってるのはお前じゃいｗ
スタックに巨大なデータを置いても問題ないなんてRustで定められている事実はない
2026/07/21(火) 23:56:52.90ID:6AILaI3O
>>784
それな
ID:2WiNYKUyは自分の妄想じゃなくてちゃんとThe Bookを読んで来いって話
読んでないから>>738で指摘されてるようなバカげた間違いをする
2026/07/21(火) 23:56:56.16ID:2WiNYKUy
>>782
配列でも構造体でも数値でも扱いは同じです
それらがスタック上にあるのかヒープ上にあるのかの違いのみあります
配列であろうとスタック上にあるならディープコピーになりません
2026/07/21(火) 23:57:46.86ID:2WiNYKUy
>>785
スタックサイズは大きくできますよ
スタック上にデータを置いても安全にRustでは扱えます
2026/07/21(火) 23:57:52.88ID:6AILaI3O
読んでないのに読んだふりをしてイキる、知らないのに知ったかぶりをする、まずは勉強してくるべきだね
2026/07/21(火) 23:58:13.27ID:6AILaI3O
>>788
誰も扱えないなんて言ってないよ
それもお前の妄想
2026/07/21(火) 23:58:44.49ID:2WiNYKUy
>>786
Bookにあるディープコピーの例はすべてヒープコピーです
2026/07/21(火) 23:59:04.75ID:1wvc5539
>>671には動作速度に悪影響を与えるって書いてるんだよな
動かないなんてどこにも書いてないし、動作速度に悪影響を与えるってことは確実に動いてる
2026/07/21(火) 23:59:27.19ID:2WiNYKUy
>>671と>>698が間違ってるとわかればいい
2026/07/21(火) 23:59:40.21ID:1wvc5539
>>791
だから？
The BookにないものはRustに一切ない、と言いたいのかな
入門書って言葉の意味がわかってないのかな
2026/07/21(火) 23:59:55.76ID:YS4VSVPg
ヒートアップしすぎてもう飛行機飛ばしても何の意味もないやないかｗｗｗ
2026/07/22(水) 00:00:14.90ID:tGok+TtY
>>793
間違ってるのはずっとお前
お前が勝手な妄想と決めつけと無知と知ったかぶりでここまで荒らしてきただけ
2026/07/22(水) 00:01:05.24ID:MCYwDp1k
今日も逃げるチャンスですね、ID:2WiNYKUyさん
2026/07/22(水) 00:01:58.91ID:bNcZ+xby
結局>>671と>>698が正しかったな
2026/07/22(水) 00:03:54.54ID:l09dx9EB
Rustにおける配列は基本スタック領域に置かれるし、Vecはヒープ領域に確保される
これは常識中の常識なんだが、あそこまでイキってる奴が知らんのかｗ
2026/07/22(水) 00:04:02.26ID:Ka9c4UTc
寝るにゃん
こうひとこと言っておけば大丈夫
2026/07/22(水) 00:05:23.64ID:cO1obK37
自分で引用した文章も読めないのは流石に笑った
802デフォルトの名無しさん
垢版 |
2026/07/22(水) 00:05:42.41ID:/BWr+zSa
>>798
ヒープ領域をコピーしていないのにディープコピーと書いてるから違和感ある
2026/07/22(水) 00:08:11.55ID:hBWpKZVl
>>802
勝手に違和感持ってろ
そんな定義は一切ないし、普通に巨大なデータを引き回さないで参照を使う理由にディープコピーを避けるというのはあるってだけ
お前の知識がないことと事実がないことは異なるだけ
2026/07/22(水) 00:08:37.24ID:YKpwIP/3
自分の知らないことはないと思ってるのはバカの特徴だよね
2026/07/22(水) 00:09:22.30ID:Jx50pW2v
ポインタで指してる先がコピーされるとディープコピーだよね
>>671はディープコピーとは違うよ
2026/07/22(水) 00:14:10.47ID:0PjCe+i4
>>805
だったらRustにはディープコピーはほとんどないじゃん
ポインタなんてほとんど使わないんだから
そんな我流定義を持ち出してきてあーだこーだ言っても事実が変わるわけじゃないよ
2026/07/22(水) 00:15:13.30ID:0PjCe+i4
データごと丸ごとコピーして実体を複製する行いはディープコピーです
これが一番一般的な定義です
プリミティブ型ならシャロ―コピーとディープコピーは一致します
2026/07/22(水) 00:16:59.55ID:VYV3iZui
>>671が言ってるのはスタック領域の巨大データの話なので、データごと丸ごとコピーして実体を複製する行いなのでディープコピーだし、プリミティブ型でもなければポインタを渡すことでも解決できないのでシャローコピーでもない、ヒープで .clone() を使うよりはOSのコールがない分速いだけのディープコピーです
2026/07/22(水) 00:18:33.47ID:yr5TLezq
>>806
ヒープ領域を持つ任意の型でclone()できるとそれがRustにおけるディープコピー
2026/07/22(水) 00:19:37.59ID:oj722HcK
そもそもディープコピーはヒープだけとかどこのアホが言い出したんだろうな
Rustでは巨大なデータをスタックに置く文化がほとんどないから普段スタックでディープコピーを問題にすることはないけど、巨大なデータをスタックに置けばディープコピーは普通に問題になる
CやC++ではヒープの確保が重いのは知られてるけど、意外とスタック上の構造体のディープコピーが安易に使われてる、と定期的に話題にもなるし
2026/07/22(水) 00:20:21.35ID:oj722HcK
>>809
そんな定義はお前の頭の中にしかないけど勝手にそう思ってればｗ
2026/07/22(水) 00:21:21.41ID:yr5TLezq
>>808
それはちょっとおかしいよ
例えばstruct Hage(i32, i32)型
スタック上のこの型をコピーするとディープコピーですか？
2026/07/22(水) 00:22:43.54ID:yLaC1azO
そもそもスタック領域の値を戻す時にコピーは発生し得ないと力説してた奴だからなあ
スタック上の構造体のディープコピーを安易に使う側なんだろ
2026/07/22(水) 00:23:15.66ID:4HblP/Gz
>>812
そうだが……
2026/07/22(水) 00:23:55.18ID:L1sn8Brj
なんでこのスレの単発異様に殺気立ってるの？
2026/07/22(水) 00:24:20.54ID:4HblP/Gz
Deep copy (ディープコピー) - 用語集 | MDN
https://developer.mozilla.org/ja/docs/Glossary/Deep_copy

> プロパティがすべてプリミティブ値であるオブジェクトのコピーは、ディープコピーとシャローコピーの両方の定義に当てはまります。しかし、このようなコピーの深さについて話すのはやや無意味です。というのも、このコピーには入れ子プロパティがなく、ディープコピーについては通常、入れ子プロパティを変更するコンテキストで話すからです。

はっきり書いてますね
2026/07/22(水) 00:25:03.62ID:4HblP/Gz
>>815
そこの無茶苦茶な主張してる奴がもうこのスレで300以上は確実に書きこんでる荒らしだからだぞ
818デフォルトの名無しさん
垢版 |
2026/07/22(水) 00:25:16.50ID:xdLXSwNC
[i32; 2]がディープコピーではないのはわかるけど
[i32; 20]だとディープコピーなのかな？
サイズで変わるのはやっぱなんか変だよね
サイズが大きいとディープコピーは変
2026/07/22(水) 00:25:38.81ID:L1sn8Brj
>>817
なんでそれで単発が殺気立つの？
2026/07/22(水) 00:26:17.20ID:LylUcC8d
>>818
そうだね
サイズが大きいとディープコピーだって言ってるの君だけだからね
2026/07/22(水) 00:26:54.66ID:PntR9YqK
>>819
延々話がループする荒らしの相手させられてるからだろ
スルーしても構わず書きこみ続けるからなこいつ
2026/07/22(水) 00:28:20.94ID:xdLXSwNC
i32とラッパー型X(i32)はどうなの
derive Copyしてもラッパー型はディープコピー？？
2026/07/22(水) 00:28:46.52ID:PntR9YqK
>>818
Deep copy (ディープコピー) - 用語集 | MDN
https://developer.mozilla.org/ja/docs/Glossary/Deep_copy

> プロパティがすべてプリミティブ値であるオブジェクトのコピーは、ディープコピーとシャローコピーの両方の定義に当てはまります。しかし、このようなコピーの深さについて話すのはやや無意味です。というのも、このコピーには入れ子プロパティがなく、ディープコピーについては通常、入れ子プロパティを変更するコンテキストで話すからです。

ここにも書いてるけど、どれだけ小さくてもデータごと丸ごとコピーして実体を複製する行いはディープコピー
ただ、それが問題になるのは大きなデータの時だけですよって話だ
2026/07/22(水) 00:29:33.48ID:PntR9YqK
>>822
ラッパーがあってもなくてもディープコピーだね
小さいから問題にはならないけど
2026/07/22(水) 00:31:06.33ID:xdLXSwNC
スタックにあるi32をコピーするとディープコピーはちょっと違和感あるかな～
2026/07/22(水) 00:31:45.29ID:PntR9YqK
>>825
普段はそれをディープコピーとは呼ばないからね
でもディープコピーの定義には当てはまる
827sage
垢版 |
2026/07/22(水) 00:32:26.03ID:cmrJLzza
###まとめ
「ヒープ＝ディープコピー、スタック＝シャローコピー（または単なる代入）」という誤解は、「スタックにある変数はプリミティブか、ポインタサイズのものばかり」という暗黙の前提（あるいは特定の高水準言語の仕様）に囚われているからこそ生まれるものですね。メモリがスタックであろうとヒープであろうと、実体を伴う構造の複製を行えば、それは立派なディープコピーであり、コストの議論の対象になります。
2026/07/22(水) 00:32:43.32ID:xdLXSwNC
ひっかけなぞなぞみたい
2026/07/22(水) 00:32:52.81ID:L1sn8Brj
#[derive(Clone, Copy)]
struct X<'a, T>(&'a T);

がスタックにあったとして、スタックにあるものをコピーすればディープコピーなんだ

へえ〜
2026/07/22(水) 00:33:02.34ID:PntR9YqK
その上で大きなデータのディープコピーが問題になるのは、単純にそれを全部移し替えないといけないから遅いしメモリの無駄って話だね
RustはC/C++同様低レイヤの言語だから、一般にプログラマはそのあたりのことを考えることが多い
2026/07/22(水) 00:35:11.20ID:xdLXSwNC
>>829
たしかにディープコピーとは言い難いかも
2026/07/22(水) 00:35:22.70ID:d6JHHVBS
スタック領域においてしまうと、戻り値でムーブする時にもこのディープコピーが発生してしまう（単純なケースであればコンパイラによる最適化で解消可能）
なぜなら、関数やスコープは開始時にスタックを積み上げて終了時にスタックを戻すからで、この中から外にムーブさせるとなるとアドレスを渡して済む問題ではなくなってしまう
これはスタックで実装されている場合に限った話だけど、基本的にはスタックで実装されているからね
2026/07/22(水) 00:36:20.23ID:d6JHHVBS
>>829
「スタックにあるもの」によるなあ
データ自体がスタックに乗ってて丸ごとコピーすることを指してるならディープコピー
2026/07/22(水) 00:36:59.37ID:xdLXSwNC
>>829
イメージとしてはTをコピーするとディープコピーかな
2026/07/22(水) 00:37:32.30ID:d6JHHVBS
>>832の続き
これに対して、ヒープ領域においておけばスタックに置かれているのはその領域の管理構造体だけなので、ムーブする時は無条件にこれだけコピーすればいい
これはシャローコピーではあるけどディープコピーではない
2026/07/22(水) 00:38:56.38ID:d6JHHVBS
なので同じ大きなデータをスタックとヒープに置いた時、ムーブで戻り値として返す場合はヒープに置く方がコピーするものが少なく、動作が高速になる
2026/07/22(水) 00:42:33.61ID:blalnmjp
>>835
しっくりこない点を言ってもいい？
サイズある実体をヒープでなくスタックに置いて
管理構造体もスタックに置けば更に改善されてる気がする
2026/07/22(水) 00:43:45.85ID:blalnmjp
>>836
つまり実体をヒープに置くことが良いのではなくて
別途、管理構造体をスタックに持つことが本質ではないかい？
2026/07/22(水) 00:48:25.38ID:iwo7j10o
>>823-824, >>826-827,
>>830, >>832,
あとは>>835-836あたりに散ってしまっているからわかりにくいけど、要するに

* ディープコピーはデータ自体を含めて丸ごとコピーして実体を複製する行い
* どれだけ小さくてもスタック領域でも関係なくディープコピーになる
* ただし大きいデータの場合しか問題にはならないので、小さいデータに使うことはない
* 大きいデータの場合、借用（参照）やヒープ領域上のデータのムーブ、スタックを積み上げる時（スコープに入る時）のスタック領域上のデータのムーブは速いが、スタック領域上のデータの.clone()やスタックを戻す時のスタック領域上のデータのムーブはディープコピーになるので遅く（最適化で改善される場合アリ）、ヒープ領域上のデータの.clone()はシステムコールがあるのでそれよりはるかに遅い

こんな感じか
2026/07/22(水) 00:48:38.10ID:blalnmjp
つまり、実体をヒープ領域に置いたほうが優れている、は間違いというか錯覚
2026/07/22(水) 00:49:52.70ID:MXbcRWOz
>>837
スタックだとスコープを抜ける時に巻き戻しが入るからスタック上の実体をムーブするにもディープコピーが必要になる
単純なコードであればコンパイラが最適化でディープコピーを消すことはある
2026/07/22(水) 00:50:38.19ID:OQXWNcQK
>>840
そう思ってたいなら勝手にそう思ってたら
事実とは違うけどね
2026/07/22(水) 00:51:42.02ID:bjO+R+mh
>>838
違う
実体をヒープに置いていないのでスタックで巻き戻されない、という部分が本質
これはスタックというデータ構造を理解していればわかる
2026/07/22(水) 00:52:32.07ID:blalnmjp
>>841
下の関数に引数で渡していく時は影響なくて
上の関数に戻値で渡していく時は影響あるけど単純に最適化できそう、かな
2026/07/22(水) 00:55:39.54ID:bjO+R+mh
スタックはデータを後入れ先出しで保持するデータ構造で、スタック領域では通常これをスコープ（関数を含む）に入る時にプッシュし、スコープを抜ける時にポップする
つまりスコープに入る時にそのスタック領域で必要なメモリを確保して、スコープを抜ける時にそれをそのまま巻き戻すことで解放を行っている
なので、内側のスコープで生成したデータを外側のスコープに与える時にはコピーしなくてはならなくなる
2026/07/22(水) 00:58:01.43ID:blalnmjp
>>845
そこは静的に判っているからReturn Value Optimizationできそう
2026/07/22(水) 00:59:07.03ID:DeO+WrPt
>>844
まあ単純に戻す場合は最適化できるだろうけど、複雑なデータのやり取りがある場合は必ずしも既存のパターンだけで最適化できないことはある
最初からヒープ領域にデータを置いて管理構造体だけを移すムーブにすると、確実にシャロ―コピーとなることが保障されるので最適化頼みの賭けにならずに済む
2026/07/22(水) 01:06:02.68ID:L1sn8Brj
スタック巻き戻しってそういうことじゃないです
2026/07/22(水) 01:08:33.80ID:iL1PKXjH
また根拠のない否定か
もうみんな飽きてるよそれ
2026/07/22(水) 01:10:07.59ID:blalnmjp
>>847
そこの最適化はRustなら大丈夫だと思う
戻値が16バイトまでならレジスタ2つで返すけど
それを超えると関数呼び出し元のスタックフレームに戻値の領域を確保してそのアドレスをレジスタリストの第一引数として渡すABIになってる
呼ばれた下の関数はその渡されたアドレスに戻値を書き込むRust ABI
2026/07/22(水) 01:15:29.52ID:o2cM4ZXa
必ずそうなるってわけではないからねえ
それだと不都合なこともあり得るし、アーキテクチャによっても最終的には変わってくるだろう
2026/07/22(水) 01:19:39.84ID:blalnmjp
>>851
むしろ必ずなってくれないと動的ライブラリの仕様で困っちゃう
少なくとも同じバージョンコンパイラならABI安定してるよ
2026/07/22(水) 01:24:30.85ID:oB+DESr1
>>852
ライブラリは無駄があっても互換性優先だけど、全関数がそうかは別の問題
2026/07/22(水) 01:27:55.98ID:blalnmjp
>>853
動的リンクライブラリ以外の関数は静的にリンクだからもっと安心だと思うよ
2026/07/22(水) 01:38:42.52ID:hheEkfdk
>>854
また動くかどうかの話になってるけど、そんな話はしてないという
856デフォルトの名無しさん
垢版 |
2026/07/22(水) 04:57:35.83ID:XaGJSnmH
こんなにスレ伸ばしたって読まねぇぞ
2026/07/22(水) 05:12:55.66ID:H8x9U9EL
deep copyとshallow copyは2種類の異なるcopy方法が考えられる時にのみ
その使い分けに用いられる用語
1種類しかない時に用いたら失格
858デフォルトの名無しさん
垢版 |
2026/07/22(水) 07:28:52.11ID:bm8B9/Z+
夏休みは海とか山とか友達なんかと遊びに行きなよ
人付き合いはできて困る事はないぞ多分
2026/07/22(水) 10:18:10.68ID:qLhff68A
仮に111レスしてるおじが本人の言う通り自演してないとしても
もう一人の無限湧きの単発のおじが自演ってだけだから、結局二人でずっとまったく成立してない会話してるんだよね
OpenClawでやってるにしろ人力にしろ、本当に海か山でも行ったほうがいいと思う
860デフォルトの名無しさん
垢版 |
2026/07/22(水) 12:08:53.98ID:d19KA9Tj
音大出身の女性がITディレクターやってたらしいんだが、あり得るの？
年収は600万

https://lavender.5ch.io/test/read.cgi/karaok/1784604629/625
861デフォルトの名無しさん
垢版 |
2026/07/22(水) 12:10:09.72ID:d19KA9Tj
625 選曲してください sage 2026/07/22(水) 00:11:47.96 ID:5DADgvY5
>>608
その会社は入社1年目
そのままクライアント会社(上場)に新設されたWEB事業部に出向→移籍、社長プレゼン

我ながら特殊な経験をしてると思うよ
まだWEB専門卒の人とかも少ないし素人が現場で仕事を覚えていける時代だったから、今ではあり得ないやろね
紙媒体からWEBに移行した人も多くて、得体の知れない業界人がウヨウヨいた
2026/07/22(水) 13:14:32.22ID:5C0qO59L
普通によくある構造体struct Xxx { ... }を生成する関数
impl Xxx {
fn new( ... ) -> Self {
...
}
}
fn foo {
let x = Xxx::new( ... );
}
これはもちろんこの関数new()の中で生成したXxx型の値が呼び出し元の関数foo()にある変数xへムーブされる
Rustの抽象概念としてはここまで
ムーブが現実にはどのように実現されているかを知ることなくRustのプログラミングができる
2026/07/22(水) 13:18:55.70ID:5C0qO59L
Rustの抽象概念ムーブがどのように機械語で実装されるのか？
それがRustの高速性を決めている
普通によくあるx86-64bitのLinux環境で関数が値を返すときのムーブの実装について見てみよう
64bit二つ分までのサイズのデータを関数が返す時は64bitレジスタraxとrdxに入れて返す
しかし>>862の構造体Xxxのサイズがその128bit (=16byte)を超えていてレジスタ返しができない場合はどうなるだろう？
Rustでは関数f()でのデータ受け取り変数xのアドレスを隠れた引数として関数new()へレジスタ渡しする
new()ではそのアドレスへ直接データを書き込んでXxx構造体を作っていく

関数が多段で孫関数からXxxを返す場合でも子関数から孫関数へ隠れた引数としてアドレスが同様に渡される
孫関数は祖父関数のスタックフレームへ直接データを書き込むことになる

ムーブは抽象概念に過ぎないため実際にデータを移動(コピー)させる必要はない
最初から最終移動先へデータを書き込むことでRustは無駄なコピーを排除している
2026/07/22(水) 13:20:20.48ID:IHEroBD/
仮に額面通りmoveするんだったらコピーが入るから、効率重視のコードなら回避しないといけないでしょ
つまり最適化を理解する必要があるわけで、
> ムーブが現実にはどのように実現されているかを知ることなくRustのプログラミングができる
は誤りということになる
2026/07/22(水) 14:07:07.48ID:P03AutQj
ムーブという魔法でRustは上手いことやってくれるという抽象レベルの理解も重要
そのムーブ魔法がどう実現されているか知っておくことも重要
2026/07/22(水) 14:35:10.94ID:YIjqgtY0
魔法を信じてプログラミングしても大丈夫だよ
もし遅いと感じたら測定する
ムーブの最適化が何らかの事情でできてなければ判明してそこで初めて対処すればいいんだよ
万が一に備えて最初からヒープ領域にデータを置くことは間違った早すぎる最適化であり愚かな行為
2026/07/22(水) 15:37:11.70ID:9kaHeq4d
>>857
両方あるが
何を言ってるんだこいつは……
2026/07/22(水) 15:38:48.11ID:6Gra50HL
>>866
いや、予想できることだし最初から大きなデータをヒープに置くのはRustでも普遍的なシステムプログラミングの慣習でもあるんだわ
君が書いたことないからっててきとうなことを言ってはいけない
2026/07/22(水) 15:41:08.01ID:8n0waISf
>>863
値を返す時に必ずそうなるという主張はコンパイラを単純に考えすぎているし、そもそも出力されるアセンブリ言語や機械語はそのバージョンのコンパイラの解析能力で扱える範囲で最適化されるにすぎないことは知っておく必要がある
2026/07/22(水) 15:42:53.59ID:9kaHeq4d
>>864

>>862の
> ムーブが現実にはどのように実現されているかを知ることなくRustのプログラミングができる
は
> ループとif文があれば全てのプログラムが書ける
みたいな理論上の話と捉えれば筋は通る
ただ、現実問題として「できる」と「やるべき」の間にはかなり深い溝がある
2026/07/22(水) 15:44:31.94ID:JycBCTuD
>>866
そもそもスタックに巨大データを置くことが誤った設計なんですけど
2026/07/22(水) 15:49:37.99ID:n22ahHSU
旧来からの発想の転換で有利なスタック領域を活用することがRustの高速化に繋がった
2026/07/22(水) 15:50:52.67ID:fqsfiDCR
流石に嘘すぎる
何のためにRustがヒープを安全に扱える仕組みを導入したのか完全に無視している
2026/07/22(水) 15:53:09.53ID:fqsfiDCR
スタック領域が有利なのは特定の条件下（確保/解放が多い、扱うデータが小さくコピーが起きても支障がない、決定論的な動作が必要でシステムコールが待てない）だけで、大きなデータを扱う場合には普通にヒープに置いた方が使い勝手はいい
2026/07/22(水) 15:57:07.11ID:O01J+ZaE
>>872
Rustが高速な理由は無駄な処理をしない、遅い処理を排除することに注力し、かつ言語仕様を厳格化することで最適化しやすいヒントを多く含むIRを生成して、LLVMに渡せるようにすることで実現されている
ヒープ領域はむしろ積極的に活用されている（たとえば、VecやStringはヒープの確保を伴う）し、スタックに大きなデータを置かないことを推奨してもいる
2026/07/22(水) 16:01:13.48ID:nRzhKxoM
Rc/Arcはヒープ領域を管轄するからこそ実現できる例のようにヒープ領域の利用は意味があるよ
基本はスタック領域を活用
必要に応じてヒープ領域
2026/07/22(水) 16:04:22.62ID:JKcxJ34H
>>876
> 基本はスタック領域を活用
この時点で嘘なんだよな
Rustはプリミティブ値以外ほとんどヒープに置く
配列よりもVecを使う言語だぞ
2026/07/22(水) 16:10:10.68ID:Of/BcPgB
>>875
スタックに大きなデータを置いても構わない
推奨なんてものはない
例えば全てのデータをスタックに置いてL2キャッシュの恩恵により高速に動かすことなど普通に行われている
2026/07/22(水) 16:25:45.26ID:XYz54jbC
>>878
ダウト
スタックに置くこととL2キャッシュに載ることに関連性はない
2026/07/22(水) 16:31:09.68ID:c7srhqru
>>877
初心者なのかもしれんがRustではスタック上で配列を使うクレートも盛んに使われているぞ
適材適所で使い分けが肝心
2026/07/22(水) 16:59:58.86ID:Z37YkZf/
言い争ってる内容のレベルが日々下がってくね
2026/07/22(水) 17:15:11.12ID:XYz54jbC
>>880
そりゃ機能があるのに全く使われてないと仮定するのは無理があるし、そんなことは言ってないでしょ
「よりも」はゼロヒャクじゃないよ
2026/07/22(水) 17:16:51.37ID:XYz54jbC
>>881
Rustろくに書いたことないのにゼロヒャクで断言したがる奴が多すぎるんだよな
2026/07/22(水) 17:22:27.60ID:XYz54jbC
>>879の補足
CPUのキャッシュはヒープ領域のデータでも使用頻度が高ければキャッシュするので、スタック領域かヒープ領域かは関係がない
そのためにキャッシュラインに合わせてアラインメントしてヒープ領域を使うということも行われる
また、スタック領域に置かれていてもアラインメントがされていなければキャッシュ効率が悪くなることも普通にある
2026/07/22(水) 22:43:51.19ID:o2Jdm9L+
メモリ空間をOSが管理してると、ヒープ領域を使うのにいちいちシステムコールが必要になるから、欠点が目立つんだよな
でもスタック領域に欠点がないかと言えば、別にそんなこともないから使い分けが必要
2026/07/22(水) 23:14:46.59ID:WzrqCFod
>>879
スタック上で処理したほうが圧倒的に有利になっている理由は、他のローカル変数はスタック上にあり、関数呼び出し時もスタックを用いるため
メモリの使用範囲がスタック上のみに限定され、メモリキャッシュ効果が最大限に発揮されます
2026/07/23(木) 02:50:21.49ID:luqj8bdN
>>886
そもそもスタック領域を大きくしたらスタック全体がキャッシュに乗らなくなるし、ヒープでも確保を工夫すればキャッシュに乗せられるので、ほとんど関係がない
888デフォルトの名無しさん
垢版 |
2026/07/23(木) 03:28:47.44ID:0/IAmlr6
>>887
大きさ問題はその両者で中立。
ヒープだけを使うことは不可能だがスタックだけを使うことは可能だから必ずスタックが有利になる。
2026/07/23(木) 07:58:46.98ID:rkdmRmzF
仮に (あくまでも仮に) スタックの多用が全面的にメリットばかりだとしてもたとえば Linux のデフォルトだとスタックの上限はたった 8MB だぞ。
上限を引き上げる設定をやったことなんてほとんどないだろ。みんなスタック 8MB でやりくりしてるんだよ。
2026/07/23(木) 08:13:33.16ID:AUDDS2Ak
> スタックの多用が全面的にメリットばかり
正にこれが間違い

ヒープ領域に確保する方が関係データを含めてアクセスローカリティを考慮したデータレイアウト設計が出来る
2026/07/23(木) 08:19:49.70ID:z4+uszs5
組み込みだとスタックが浅いからって
関数呼び出しはするな
引数も使うな
全部グローバルでやりとりしろ
みたいな流儀があったらしいと聞くが
なんでそういう絶対的な制約があるわけでもないのに似たような縛りプレイやろうとしてるんだろう
892デフォルトの名無しさん
垢版 |
2026/07/23(木) 11:19:45.15ID:FxkCx1gi
>>889
8MBはデフォルト値にすぎないから
起動プロセスのための環境変数を設定するタイミングと同じように
起動直前で例えばulimit -s 65536すれば子プロセスのみスタック領域を64MBに変えることができるよ
2026/07/23(木) 11:33:58.96ID:rkdmRmzF
>>892
デフォルトなのは知ってるからデフォルトって書いてるだろ。
変更できるのは知ってるから、でも変更したことないだろ (それが普通) って話をしてる。
2026/07/23(木) 11:43:37.14ID:ZelaGfP0
スタック領域サイズだけに限らず諸々のリソースのパラメータは各用途に応じて設定して運用が行われている
2026/07/23(木) 11:46:07.77ID:1wG4VbX9
Rustってすごい言語なんですね
2026/07/23(木) 11:47:21.36ID:SaQIv/sp
>各用途に応じて設定して運用が行われている
(つまり、各用途に応じた設定をして運用を行ったことはない)
897デフォルトの名無しさん
垢版 |
2026/07/23(木) 11:55:01.09ID:RmZ5xdy6
>>895
リソースパラメタ変更して運用はRust登場以前から普通に行われている
2026/07/23(木) 13:12:35.86ID:cxrYFfJU
>>890
そもそもスタックが全てキャッシュに乗るわけでも、データが全てキャッシュに乗るわけでもなく、使ったものがキャッシュに乗る
なのでスタックにあるかどうかは関係ないし、そこに固執してるのは知識がないから
2026/07/23(木) 13:13:10.18ID:cxrYFfJU
ごめん、>>888だった
2026/07/23(木) 13:13:53.08ID:cxrYFfJU
複おじの妄想は相手しなくていいよ
2026/07/23(木) 13:16:21.80ID:VXCn4TUk
>>898
スタックは必ず使われるからキャッシュに必ず乗り必ず有利になることは常識
2026/07/23(木) 13:22:40.15ID:cxrYFfJU
>>901
キャッシュはキャッシュラインの単位ごとにしか乗らないので、巨大データをスタックに置いたところで他の変数と一緒にキャッシュに乗ることは保証されない
一方でヒープに置いた場合でも、一度使えばキャッシュに乗るため繰り返し使う時に高速で扱える
2026/07/23(木) 13:23:01.90ID:m8CXPFD8
> 必ず乗り
そんなわけない
2026/07/23(木) 13:25:12.89ID:cxrYFfJU
キャッシュが無限に容量があって無限に高速なメモリだとでも仮定しないと、必ず乗るなんて主張は成立させられないはずなのだが
それにヒープ領域はキャッシュに乗らないと頑なに信じているらしいが、CPU設計者をそこまでバカにする理由もよくわからない
わざわざ大量の計算をしてスタック領域だけを見分けてキャッシュに乗せる、そんな無意味なことをするとなぜ信じられるのだろうか
2026/07/23(木) 13:29:30.30ID:neKzl6rg
レジスタ退避でいつもL1に乗るからスタック上にあるローカル変数は速いよね
2026/07/23(木) 13:30:40.71ID:cxrYFfJU
>>905
いつでもL1に乗るなんてありえない妄想
そもそもL1は8MiBもねえじゃん
2026/07/23(木) 13:57:52.08ID:qk0tjYWL
>>905
レジスタ退避について勘違いしてるよ
2026/07/23(木) 19:14:51.69ID:OLcLF/i1
>>905
シンプルに教えてほしいんだけど、レジスタやL1が8MiBもあるCPUってどこにあるんだい？
909デフォルトの名無しさん
垢版 |
2026/07/23(木) 21:46:09.46ID:vX/zh6w3
topcoatてこれwasmじゃなくてjsに変換するらしいけど普通にjs書いたほうがよくね？
2026/07/23(木) 22:01:21.86ID:1wG4VbX9
人類はいつまでJavaScriptに苦しめられるのでしょうか？
WASMを作った連中に覚悟があれば、今頃はC++でWebアプリを作れたでしょうに
911sage
垢版 |
2026/07/23(木) 22:10:09.90ID:xivhFue3
Rustってハードパワーのゴリ押しみたいな側面もあるんで
そういうこと
912デフォルトの名無しさん
垢版 |
2026/07/23(木) 22:48:38.91ID:oRBJ/Nhk
来年WASMでDOM操作とfetchできるようになるから待ってて
2026/07/23(木) 22:52:01.41ID:IHVi+hDe
フロントエンドはJavaScript側のエコシステムで対応しないと
思ってる以上に早く負債になって失敗、後悔するというのは
これまでもRubyのほうのRailsが散々証明してくれてるからな
914デフォルトの名無しさん
垢版 |
2026/07/23(木) 22:54:25.22ID:vX/zh6w3
てか10日間で設計されたうんこスクリプトをWEBのデファクトにするて人類ガイジすぎやろ
915デフォルトの名無しさん
垢版 |
2026/07/23(木) 23:07:32.79ID:bEDi3eQt
さすがにここまで来たら10日間で作った部分は消え去ってるんじゃねーの
2026/07/23(木) 23:12:44.53ID:T3AzUbLt
>>907
レジスタは明示的にpushしなくてもripなどの命令ポインタはcallすると自動的にスタックに退避されるよ
2026/07/23(木) 23:29:45.68ID:sSI22omN
>>911
そんなわけなくて草
それでCと同じ速度が出るわけねえだろ
2026/07/23(木) 23:36:14.54ID:u5UkAy+5
>>916
関数を呼び出す時にスタックにレジスタの値を退避するというのは、スタックで現在処理中の値やプログラムの実行位置を管理してるからで、呼び出した関数から戻ってくるまでそれらの値をスタックに置いておくということでしかない
呼び出した関数から戻ってきた時にこれらの値をレジスタに戻すことで、同じ位置から処理を再開するというのがこの機能の目的であって、キャッシュとは何も関係がない

また、スタック領域に置かれた変数が全てレジスタに書きこまれているわけではない（それどころか、レジスタは全部合わせても大した数がなく、データ置き場としては使えない）し、スタック領域に置かれた変数が全てキャッシュに乗るといった事実もない（当然ながら、あまり使われなければキャッシュには置かない）
919デフォルトの名無しさん
垢版 |
2026/07/23(木) 23:44:02.18ID:CqZb6B5+
>>918
キャッシュとは何も関係がない？ってアホやな
スタックに退避されるとスタックのその前後はキャッシュに載る
その前後にはローカル変数がいる
だから速さの恩恵を受ける
2026/07/23(木) 23:51:27.31ID:oVCWnmQT
キャッシュに載ってなかったら、キャッシュレス？
2026/07/24(金) 00:05:19.44ID:YdTFtdBW
>>919
> スタックに退避されるとスタックのその前後はキャッシュに載る
> その前後にはローカル変数がいる
> だから速さの恩恵を受ける

複数の誤謬が含まれている

まず第一に、レジスタがスタックに退避される時のキャッシュへの読み込みはキャッシュライン単位でしか行われないので、64バイトを超えた分はキャッシュに読み込まれない
そのため、巨大データをスタックに置くことでキャッシュ上有利に扱えるということは、この時点でなくなっている

次に、実際にはローカル変数だけでなく、戻りアドレスや呼び出し元のフレームポインタ、レジスタが不足した時の退避先などもスタックに置かれるため、実際には64バイトから8バイトのレジスタ分を引いて残りが全てローカル変数、ということにもならない
そのため、そこまで大きくないデータであってもスタックへのレジスタ退避でキャッシュに乗るとは限らない

更に、キャッシュはスタックへのレジスタ退避の時しか行われないわけではない
既に散々書かれているようにしか見えないのだが、スタックだろうがヒープだろうが読み書きすればキャッシュに乗り、使われ続ければ保持されるためスタックへのレジスタ退避とは無関係に、キャッシュの挙動に合わせたデータが有利に速さの恩恵を受ける
そして、スタックとローカル変数はこれに最適化されていない
2026/07/24(金) 00:07:11.57ID:YdTFtdBW
説明もなく64バイトと書いてしまったが、これは一般的なCPUのL1キャッシュで比較的多く採用されている、キャッシュラインの大きさである
2026/07/24(金) 00:51:48.87ID:8ekr92pQ
> キャッシュはスタックへのレジスタ退避の時しか行われないわけではない
結局これよな
ずっと変なこと言ってる奴いるけど、レジスタ退避もスタック/ヒープも関係なく使っていればキャッシュはされる
2026/07/24(金) 00:59:27.67ID:SqDgs0gR
スタックじゃないとキャッシュに乗らないとか、レジスタ退避の時にしかキャッシュに乗らないとか、とにかくCPUの設計者をバカだと思いすぎだよな
そんなバカな設計になってるわけないのに、頭を使ってない奴はこれだから
2026/07/24(金) 01:12:00.30ID:9TfMzF0I
自演連投と論点ずらしの傾向がだんだんわかってきた
>>924はついに「スタックじゃないとキャッシュに乗らないとか、レジスタ退避の時にしかキャッシュに乗らないとか、」など
誰の書き込みにも存在していない方向へ話をずらしている
2026/07/24(金) 01:48:18.05ID:c1YiTQq7
ディープコピー: 大きなサイズのメモリをコピーすること
スタック巻き戻し: ベースポインタの値をスタックからpopすること
レジスタ退避: リターンアドレスをスタックにpushすること

こりゃ大変だ
927デフォルトの名無しさん
垢版 |
2026/07/24(金) 01:52:59.95ID:qgjP8TGu
もういちいち追ってないけどなんか新情報出てたら教えてくれ
928デフォルトの名無しさん
垢版 |
2026/07/24(金) 01:57:07.03ID:QEapMI1v
相変わらずUIはGUIよりratatuiが圧倒的
2026/07/24(金) 02:25:14.39ID:H84B0AqN
>>926
おじいちゃん、大昔はスタックフレームの管理にベースポインタ(bp/ebp/rbpなど)を使ったけれど
現在はどこのABIでもベースポインタなんて使わないんだよ
無駄だからね
2026/07/24(金) 04:11:45.27ID:nkS/xplE
>>925-926
都合が悪くなると攻撃的なことを言ったりバカにしたりして話をそらしてるのはいつもお前だよｗ
複おじらしい嘘つきっぷり
2026/07/24(金) 04:12:52.19ID:nkS/xplE
>>926
たしかにお前の頭が大変だな、何一つ読めていないせいで全部間違ってるｗ
932デフォルトの名無しさん
垢版 |
2026/07/24(金) 04:15:38.70ID:rWosD9Xv
>>925
ずっと言ってる奴いただろ
いくら勝てなくなったからって嘘はよくない
2026/07/24(金) 04:19:18.33ID:lb0jFh4G
少なくともヒープだとキャッシュには乗らない、レジスタ退避がキャッシュ性能に大きな影響を与えるとは確実に言ってたな

> スタックじゃないとキャッシュに乗らないとか、レジスタ退避の時にしかキャッシュに乗らないとか

も曲解ではなく言い換えでしかない
2026/07/24(金) 04:40:12.87ID:apVU3Uz6
>>929
そりゃそうよな

>>925-926
相変わらず書いてあることは読めないし、妄想力は豊かだよね
まあどうせ否定するだろうけど、https://mevius.5ch.io/test/read.cgi/tech/1774264073/679-683 でも散々言われてたように国語ができてなさすぎるよ君
すぐに自演バレするのは、毎回同じ誤読の仕方をするからなんだよ
2026/07/24(金) 04:43:04.89ID:Wi2Ws13b
>>要するに、文脈や構造を見ず文中の単語だけをつまみ食いして、「〜って言ってる！」と脳内変換してしまう、いわゆる**機能的文脈文盲**（単語は読めても構造が理解できない状態）ですね。

これAIの回答っぽいだけに辛辣すぎて笑った
2026/07/24(金) 04:48:34.54ID:CfttdDzL
決定的な認知のゆがみがある奴おるよな
某スレだと「〇おじ」とか
この板に限らずだと古くは「〇の壁」とか
思い込みの世界から一歩も外に出てこないのと
意固地になってるのか
もともと粘着質なのか知らんけど
いつでもどこでもいつまでも聖戦を繰り広げてる
2026/07/24(金) 04:50:17.57ID:CfttdDzL
バカはまともに文章を読めないくせに、そこに書いてる単語から自分にとって都合のいい物語を作ることには熱心だからな
2026/07/24(金) 05:09:59.03ID:LN2X/GDi
また複オジ4連投キタ
2026/07/24(金) 05:24:36.34ID:FvT5yST4
>>938
お前やｗ
2026/07/24(金) 05:25:10.34ID:gO/X+gvB
複おじはやたら何連投って言いたがるけど、自分はID変えるからバレないと思ってるんだろうな
2026/07/24(金) 05:31:13.14ID:CGZNp1qG
どうぜ図星だったんだろｗ
2026/07/24(金) 06:06:30.85ID:vznzDL0o
どっちが複おじでどっちが複オジかしらんがまた真夜中ずっと争ってたのか
2026/07/24(金) 07:20:47.88ID:c1YiTQq7
自演じゃないよ〜ん

伝えたいことはもともとびっくりするくらいシンプルなんだけど（大きいデータをコピーするとコストがかかるから気をつけよう！とか）
よく知らない専門用語を雑に当てはめてしまうから、本人以外はその専門用語が正確な意味で使われていると思って誤読してしまう、ということが発生しているんだろうなあと推測しました
2026/07/24(金) 07:44:04.06ID:c1YiTQq7
>>929
これは単純に知らなかったからありがとうね
2026/07/24(金) 08:13:30.89ID:TlV0Uwzc
IDコロコロの誰かさんも自演を訴え始めた今こそ満場一致でワッチョイに移行する好機なのでは？
2026/07/24(金) 08:33:04.60ID:2FjN0coi
>>945
どうぞ
プログラミング言語 Rust 4【ﾜｯﾁｮｲ】
https://mevius.5ch.io/test/read.cgi/tech/1514107621/
2026/07/24(金) 08:43:17.13ID:TA527/vs
sp を bp (ebp, rbp) に退避するのは元から ABI の要求に含まれてない。
ABI はインターフェイスの規定なので呼び出し側にとって sp のつじつまが合っていればどんなやり方で実現してもどうでもいいから退避のやり方までは規定する必要がない。
bp を使っていたのは単なる慣例。

スタックトレースのやりやすさとかの都合で今でもデバッグモードではごく普通に bp を使うし、無用になったというわけでもない。
2026/07/24(金) 10:22:56.20ID:OkaVr+Mc
>>947
RustでもC++でもDWARF情報でデバッグできるから今はbp不要
2026/07/24(金) 15:06:00.00ID:WIK69ucb
>>943
> よく知らない専門用語を雑に当てはめてしまうから、本人以外はその専門用語が正確な意味で使われていると思って誤読してしまう
逆では
毎回「そんな定義はない、こうだ！」って主張してる側が定義を間違えてる
2026/07/24(金) 15:11:25.65ID:CXHgHqXT
>>要するに、文脈や構造を見ず文中の単語だけをつまみ食いして、「〜って言ってる！」と脳内変換してしまう、いわゆる**機能的文脈文盲**（単語は読めても構造が理解できない状態）ですね。
2026/07/24(金) 15:54:25.25ID:QEfncnYQ
ローカル変数のムーブをディープコピーだと言い張ったりな
2026/07/24(金) 17:21:57.30ID:Baz7gtD0
参照を含むデータならば
moveやcopyはシャローコピー
参照先も処理するcloneならばディープコピー

参照を含まないデータならば
moveやcopyは単なるコピー
区別する2種類がないためシャローやディープは使われない

いずれにせよmoveをディープコピーと呼ぶことはない
2026/07/24(金) 18:47:46.92ID:24e2kQId
>>951-952
また複おじが妄想を垂れ流し始めたな
散々言われてたことは全部無視して仕切りなおせると思っているらしい
2026/07/24(金) 18:49:07.49ID:o7aCA+Y6
>>952
コピーは発生しないって自信満々に言ってたのに……ｗ
2026/07/24(金) 18:50:40.84ID:24e2kQId
>>952
それ>>827あたりではっきり否定されてた話を書き直しただけな
2026/07/24(金) 18:53:17.62ID:ZfJkjuoc
そもそも複オジはまともなプログラミング知識がないから、言われたことを覚えておけないのも仕方ない
こいつ間違ったことしか言わないし、誤読しかしない
2026/07/24(金) 18:55:21.78ID:LwZ5WlVx
複おじの行動原理はAIに「自分の理解不足を相手の説明能力・理解力のせいにする方が楽だから」と言われてたよなｗ
958デフォルトの名無しさん
垢版 |
2026/07/24(金) 19:09:20.11ID:0PvzCVIX
>>827は間違ってる
まずスタックやヒープなんて無関係でどこにあってもいい
そのデータをアドレス/ポインタ/参照などで指すデータがある時に、指す先のデータもコピーすればディープコピー
指す先がなければディープは存在しないためディープコピーと言わない
2026/07/24(金) 19:10:16.36ID:Le5u61/j
>>952
「複製する」というアクションを区別する話と
「複製物」という複製した結果として生じるオブジェクトを区別する話を混同してる

moveやcopyは対象が参照を含もうが含むまいが分岐はなくやることは同じ
つまり「複製する」というアクションの区別で言えばシャローコピー

複製された結果の「複製物」の区別で言えば
参照を含まないのであれば複製物がシャローかディープかを論じる意味はない
(これはMDNの定義に書いてある通り)
2026/07/24(金) 19:11:18.43ID:3oZV/qUu
>>958
それも>>733-734で否定されたことをもう一回言ってるだけね
普通にわかってないんだからROMってた方がいいよ君
2026/07/24(金) 19:16:02.26ID:ziGmj28M
元々はこれだろ

>>671
>>スタック領域に大きなデータを置くと関数の壁を跨ぐ度にディープコピーになる

671がディープコピーを誤用したから荒れた
2026/07/24(金) 19:21:21.20ID:EbAMsdeM
>>959
最後の段落はMDNの定義に書いてないし、むしろ矛盾してる
MDNではプリミティブ値についてはシャローコピーとディープコピーは同時に成立するため、通常この区別を論じる必要はないとしている
参照を含むかどうかといった話はされておらず、配列や構造体などプリミティブでないオブジェクトにおいて、この区別が論じられるものということになる

また、中段についてはcopyとmoveに対する誤解がある
copyの場合は値、つまり実体が複製されることになるためMDNの定義によるとディープコピー
一方でmoveは通常（ここは重要）管理構造体しかコピーしないのでシャローコピーとなる

moveにおいて「通常」と強調したのは、スタック領域に実体が置かれている場合、戻り値に指定するとmoveでも実体のコピーが発生する（仕様上の話。最適化の話はまた別）ため、ディープコピーの条件を満たすため
2026/07/24(金) 19:22:08.99ID:EbAMsdeM
>>961
それも>>733-734で否定されたことをもう一回言ってるだけだね、それは誤用じゃなくて正しい用法だよ
普通にわかってないんだからROMってた方がいいよ君
2026/07/24(金) 19:23:51.76ID:ubGLSJxU
ディープコピー（深いコピー）とは - IT用語辞典 e-Words
https://e-words.jp/w/%E3%83%87%E3%82%A3%E3%83%BC%E3%83%97%E3%82%B3%E3%83%94%E3%83%BC.html

> ディープコピーとは、配列やオブジェクトなどのデータ構造を複製する際、同じ構造の実体を新たに作成して対応するデータを写し取る方式。


Deep copy (ディープコピー) - 用語集 | MDN
https://developer.mozilla.org/ja/docs/Glossary/Deep_copy

> オブジェクトの ディープコピー とは、コピー先のオブジェクトのプロパティがコピー元のオブジェクトのプロパティと同一の参照（同じ値を指す）で共有しないコピー方法のことです。結果として、コピー元かコピー先のどちらかを変更しても、もう一方オブジェクトにも変更を及ぼしていないことを保証できます。すなわち、コピー元かコピー先に意図せずに予期しない変更が加えられるこはありません。この振る舞いはシャローコピーとは対照的です。シャローコピーでは、コピー元かコピー先のどちらかを変更するともう一方のオブジェクトも変更される可能性があります。

> プロパティがすべてプリミティブ値であるオブジェクトのコピーは、ディープコピーとシャローコピーの両方の定義に当てはまります。しかし、このようなコピーの深さについて話すのはやや無意味です。というのも、このコピーには入れ子プロパティがなく、ディープコピーについては通常、入れ子プロパティを変更するコンテキストで話すからです。
2026/07/24(金) 19:26:06.72ID:ubGLSJxU
>>961
>>671じゃなくてお前が誤用してるだけな
2026/07/24(金) 19:26:37.26ID:ClG+7gyM
>>962
関数が構造体を返すのは単なるコピー
参照先を持つならシャローコピーと呼んでもよいがディープコピーではない
2026/07/24(金) 19:27:56.84ID:U8nohlki
>>966
お前の独自定義ではそうなんだな
でも俺は今そんな話はしてないんだ
2026/07/24(金) 19:30:12.36ID:B1bgDAdW
Rustなら話は非常に簡単だよね
関数がVecなど構造体を返すのはシャローコピー
clone()して返すとディープコピー
2026/07/24(金) 19:33:33.78ID:Ut9H4FRI
>>968
構造体にもいろいろあるからややこしい
データの実体をどう考えるかという話で、Vecはスタックに置かれる管理構造体は実体ではなくて、データの実体はヒープに置かれた可変長の配列データなので、シャローコピーになる
でも構造体自体がデータの実体なら、そのコピーはディープコピーとなる
970デフォルトの名無しさん
垢版 |
2026/07/24(金) 19:33:57.79ID:1w4K/jCF
>>968
Rustはディープコピーが必ずcloneになるから分かりやすいよな
2026/07/24(金) 19:36:41.47ID:ElAURJKT
.clone() は管理構造体だけでなくヒープに置かれた可変長の配列データという実体をコピーするので、当然ディープコピー
ただ、.clone() 以外の方法で実体をコピーすることもできて、それがCopyトレイトと呼ばれるもの
Rustの場合はこのCopyトレイトがあれば、.clone() でなく代入によってディープコピーを行うことができる
2026/07/24(金) 19:38:29.79ID:ElAURJKT
Rustではあくまで標準状態がmoveなだけで、copyが利用できないわけではないので、プリミティブ値にはこのCopyトレイトが用意されている
この場合必ずディープコピーが発生する（MDNの記述通り、プリミティブ値についてはシャローコピーとディープコピーは同時に成立するため、通常この区別を論じる必要はない）
2026/07/24(金) 19:41:06.80ID:ElAURJKT
ただし、Copyトレイトはプログラマが定義した型に用意することもできるため、プリミティブ値でない値が必ずmoveすることは保証されない
この場合はシャローコピー（一部除くmove）とディープコピー（.clone() または Copyトレイト）が区別される必要がある
2026/07/24(金) 19:43:46.18ID:vUmL0DQY
あれだよね、複オジが「そんなことするのはバカ」って言ってたけど実際はよくされている、moveで受け取ったデータを戻り値で返すを繰り返すパターンは、これがシャローコピーだから成り立っていると
2026/07/24(金) 19:44:41.04ID:Tmh4AYKj
せやな
2026/07/24(金) 19:46:47.08ID:cRa7vLpB
一部、『構造体』と言った時にヒープの管理構造体しか思い浮かばない人が（複おじ以外にも）いるっぽいけど、Rustでは構造体は非常によく使われるので、データの実体を持っていることも普通にある
なので構造体がコピーされる = シャローコピーとは決まっていない
2026/07/24(金) 19:53:33.69ID:24e2kQId
>>962
> スタック領域に実体が置かれている場合、戻り値に指定するとmoveでも実体のコピーが発生する（仕様上の話。最適化の話はまた別）ため、ディープコピーの条件を満たす
ややこしいのはこれよな
ディープコピーというのはあくまで、実体を新たに作成して対応するデータを写し取る複製のことだから、スタックがpopされて実体の置き場所を変更する必要が生まれた時は、当然ディープコピーせざるを得ない
実際は先に、受け取る側のスタックに確保しておいてこのアドレスを使わせるという最適化が走るので、仕様上発生するはずのディープコピーは発生しないけど、これは最適化なのでできるパターンとできないパターンがある
978デフォルトの名無しさん
垢版 |
2026/07/24(金) 19:55:44.17ID:t7R+hAOc
複おじって荒らしたいマウント取りたいだけで責任は負いたくないタイプだから、どのスレでも980が近づいてくると静かになって、その後けたたましく喚き始めるよな
2026/07/24(金) 19:56:54.14ID:24e2kQId
>>978
それな
だから主張が対立してる時に980が近づいてくると、片方がピタッと止まって複オジだとバレることが多い
2026/07/24(金) 19:59:07.85ID:24e2kQId
>>977なので、この話の発端になった複オジの「スタックにどれだけ大きいデータを置いても拡張すれば欠点皆無で使える」は正しくない
2026/07/24(金) 19:59:42.01ID:24e2kQId
ここから複おじの時間かな
2026/07/24(金) 20:05:59.07ID:24e2kQId
立てた

Rust part38
https://mevius.5ch.io/test/read.cgi/tech/1784891065/
983デフォルトの名無しさん
垢版 |
2026/07/24(金) 20:08:56.96ID:TwOMBitv
ホントに970超えてから急に、あれだけ「ディープコピーは参照を含む場合だけ！」と騒いでた複数のIDが無言になったな
984デフォルトの名無しさん
垢版 |
2026/07/24(金) 20:15:26.16ID:/OO5Vvu4
流石に露骨すぎてわかりやすいよな
前スレでも970あたりから黙ってたしｗ
985デフォルトの名無しさん
垢版 |
2026/07/24(金) 20:19:11.95ID:wbLRAqNe
>>要するに、文脈や構造を見ず文中の単語だけをつまみ食いして、「〜って言ってる！」と脳内変換してしまう、いわゆる**機能的文脈文盲**（単語は読めても構造が理解できない状態）ですね。

これAIの回答っぽいだけに辛辣すぎて笑った
986デフォルトの名無しさん
垢版 |
2026/07/24(金) 20:32:01.52ID:I7AzWuQz
複おじはこっちだと答え出すぎてるから新スレで暴れることにしたらしい
987デフォルトの名無しさん
垢版 |
2026/07/24(金) 20:36:14.40ID:I7AzWuQz
英語で書いてあったら国際的な定義、日本語で書いてあったら間違ってるらしいｗ
988デフォルトの名無しさん
垢版 |
2026/07/24(金) 20:38:23.89ID:KYRlA4KA
複オジ理論はよくわからん
989デフォルトの名無しさん
垢版 |
2026/07/24(金) 20:44:57.79ID:W/d7Mv2N
あいつ変なことしか言わねえな
2026/07/24(金) 20:46:06.35ID:e9l5scLb
Rustを勉強したら儲かりますか？
2026/07/24(金) 20:58:27.92ID:GMVtSP0X
君たちが正論で追い詰めるから複おじは黙ってしまいました
あーあ
992デフォルトの名無しさん
垢版 |
2026/07/24(金) 20:58:44.31ID:WVcSNKWA
黙ってくれた方がうれしい定期
2026/07/24(金) 21:08:21.43ID:c1YiTQq7
黙ったところで住民が残ってるわけじゃないし冷やかしで見に来てるだけなのでどっちでもいいです
994デフォルトの名無しさん
垢版 |
2026/07/24(金) 21:11:16.94ID:JtKQuH3B
何言ってんだこいつ
995デフォルトの名無しさん
垢版 |
2026/07/24(金) 21:16:08.14ID:8YZRBJlW
今度はプリミティブ値の入った構造体を丸ごとコピーしてもディープコピーじゃないと主張することで、相手を言い負かしたがってる模様
996デフォルトの名無しさん
垢版 |
2026/07/24(金) 21:19:53.12ID:WKAMhSVT
もうめちゃくちゃで草
997デフォルトの名無しさん
垢版 |
2026/07/24(金) 21:34:41.28ID:/w/RcGUU
コロコロ変わるなあ
2026/07/24(金) 23:34:02.51ID:vZeGyDIK
Rustのムーブがディープコピーになることはありません
2026/07/25(土) 00:05:40.49ID:o/HmqDU4
そりゃ当たり前
1000デフォルトの名無しさん
垢版 |
2026/07/25(土) 00:06:50.44ID:kvAB/Upo
こいつバカ？

>>671 デフォルトの名無しさん sage 2026/07/21(火) 16:03:56.55 ID:8y3GD3Tf
スタック領域に大きなデータを置くと関数の壁を跨ぐ度にディープコピーになる
10011001
垢版 |
Over 1000Thread
このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 7日 4時間 54分 20秒
10021002
垢版 |
Over 1000Thread
5ちゃんねるの運営はUPLIFT会員の皆さまに支えられています。
運営にご協力お願いいたします。


───────────────────
《UPLIFT会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────

会員登録には個人情報は一切必要ありません。
4 USD/mon. から匿名でご購入いただけます。

▼ UPLIFT会員登録はこちら ▼
https://uplift.5ch.io/

▼ UPLIFTログインはこちら ▼
https://uplift.5ch.io/login
レス数が1000を超えています。これ以上書き込みはできません。
ニューススポーツなんでも実況