Rust part37

公式
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/

>>806
ヒープ領域を持つ任意の型でclone()できるとそれがRustにおけるディープコピー

そもそもディープコピーはヒープだけとかどこのアホが言い出したんだろうな
Rustでは巨大なデータをスタックに置く文化がほとんどないから普段スタックでディープコピーを問題にすることはないけど、巨大なデータをスタックに置けばディープコピーは普通に問題になる
CやC++ではヒープの確保が重いのは知られてるけど、意外とスタック上の構造体のディープコピーが安易に使われてる、と定期的に話題にもなるし

>>809
そんな定義はお前の頭の中にしかないけど勝手にそう思ってればｗ

>>808
それはちょっとおかしいよ
例えばstruct Hage(i32, i32)型
スタック上のこの型をコピーするとディープコピーですか？

そもそもスタック領域の値を戻す時にコピーは発生し得ないと力説してた奴だからなあ
スタック上の構造体のディープコピーを安易に使う側なんだろ

>>812
そうだが……

なんでこのスレの単発異様に殺気立ってるの？

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

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

はっきり書いてますね

>>815
そこの無茶苦茶な主張してる奴がもうこのスレで300以上は確実に書きこんでる荒らしだからだぞ

[i32; 2]がディープコピーではないのはわかるけど
[i32; 20]だとディープコピーなのかな？
サイズで変わるのはやっぱなんか変だよね
サイズが大きいとディープコピーは変

>>817
なんでそれで単発が殺気立つの？

>>818
そうだね
サイズが大きいとディープコピーだって言ってるの君だけだからね

>>819
延々話がループする荒らしの相手させられてるからだろ
スルーしても構わず書きこみ続けるからなこいつ

i32とラッパー型X(i32)はどうなの
derive Copyしてもラッパー型はディープコピー？？

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

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

ここにも書いてるけど、どれだけ小さくてもデータごと丸ごとコピーして実体を複製する行いはディープコピー
ただ、それが問題になるのは大きなデータの時だけですよって話だ

>>822
ラッパーがあってもなくてもディープコピーだね
小さいから問題にはならないけど

スタックにあるi32をコピーするとディープコピーはちょっと違和感あるかな～

>>825
普段はそれをディープコピーとは呼ばないからね
でもディープコピーの定義には当てはまる

###まとめ
「ヒープ＝ディープコピー、スタック＝シャローコピー（または単なる代入）」という誤解は、「スタックにある変数はプリミティブか、ポインタサイズのものばかり」という暗黙の前提（あるいは特定の高水準言語の仕様）に囚われているからこそ生まれるものですね。メモリがスタックであろうとヒープであろうと、実体を伴う構造の複製を行えば、それは立派なディープコピーであり、コストの議論の対象になります。

ひっかけなぞなぞみたい

#[derive(Clone, Copy)]
struct X<'a, T>(&'a T);

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

へえ〜

その上で大きなデータのディープコピーが問題になるのは、単純にそれを全部移し替えないといけないから遅いしメモリの無駄って話だね
RustはC/C++同様低レイヤの言語だから、一般にプログラマはそのあたりのことを考えることが多い

>>829
たしかにディープコピーとは言い難いかも

スタック領域においてしまうと、戻り値でムーブする時にもこのディープコピーが発生してしまう（単純なケースであればコンパイラによる最適化で解消可能）
なぜなら、関数やスコープは開始時にスタックを積み上げて終了時にスタックを戻すからで、この中から外にムーブさせるとなるとアドレスを渡して済む問題ではなくなってしまう
これはスタックで実装されている場合に限った話だけど、基本的にはスタックで実装されているからね

>>829
「スタックにあるもの」によるなあ
データ自体がスタックに乗ってて丸ごとコピーすることを指してるならディープコピー

>>829
イメージとしてはTをコピーするとディープコピーかな

>>832の続き
これに対して、ヒープ領域においておけばスタックに置かれているのはその領域の管理構造体だけなので、ムーブする時は無条件にこれだけコピーすればいい
これはシャローコピーではあるけどディープコピーではない

なので同じ大きなデータをスタックとヒープに置いた時、ムーブで戻り値として返す場合はヒープに置く方がコピーするものが少なく、動作が高速になる

>>835
しっくりこない点を言ってもいい？
サイズある実体をヒープでなくスタックに置いて
管理構造体もスタックに置けば更に改善されてる気がする

>>836
つまり実体をヒープに置くことが良いのではなくて
別途、管理構造体をスタックに持つことが本質ではないかい？

>>823-824, >>826-827,
>>830, >>832,
あとは>>835-836あたりに散ってしまっているからわかりにくいけど、要するに

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

こんな感じか

つまり、実体をヒープ領域に置いたほうが優れている、は間違いというか錯覚

>>837
スタックだとスコープを抜ける時に巻き戻しが入るからスタック上の実体をムーブするにもディープコピーが必要になる
単純なコードであればコンパイラが最適化でディープコピーを消すことはある

>>840
そう思ってたいなら勝手にそう思ってたら
事実とは違うけどね

>>838
違う
実体をヒープに置いていないのでスタックで巻き戻されない、という部分が本質
これはスタックというデータ構造を理解していればわかる

>>841
下の関数に引数で渡していく時は影響なくて
上の関数に戻値で渡していく時は影響あるけど単純に最適化できそう、かな

スタックはデータを後入れ先出しで保持するデータ構造で、スタック領域では通常これをスコープ（関数を含む）に入る時にプッシュし、スコープを抜ける時にポップする
つまりスコープに入る時にそのスタック領域で必要なメモリを確保して、スコープを抜ける時にそれをそのまま巻き戻すことで解放を行っている
なので、内側のスコープで生成したデータを外側のスコープに与える時にはコピーしなくてはならなくなる

>>845
そこは静的に判っているからReturn Value Optimizationできそう

>>844
まあ単純に戻す場合は最適化できるだろうけど、複雑なデータのやり取りがある場合は必ずしも既存のパターンだけで最適化できないことはある
最初からヒープ領域にデータを置いて管理構造体だけを移すムーブにすると、確実にシャロ―コピーとなることが保障されるので最適化頼みの賭けにならずに済む

スタック巻き戻しってそういうことじゃないです

また根拠のない否定か
もうみんな飽きてるよそれ

>>847
そこの最適化はRustなら大丈夫だと思う
戻値が16バイトまでならレジスタ2つで返すけど
それを超えると関数呼び出し元のスタックフレームに戻値の領域を確保してそのアドレスをレジスタリストの第一引数として渡すABIになってる
呼ばれた下の関数はその渡されたアドレスに戻値を書き込むRust ABI

必ずそうなるってわけではないからねえ
それだと不都合なこともあり得るし、アーキテクチャによっても最終的には変わってくるだろう

>>851
むしろ必ずなってくれないと動的ライブラリの仕様で困っちゃう
少なくとも同じバージョンコンパイラならABI安定してるよ

>>852
ライブラリは無駄があっても互換性優先だけど、全関数がそうかは別の問題

>>853
動的リンクライブラリ以外の関数は静的にリンクだからもっと安心だと思うよ

>>854
また動くかどうかの話になってるけど、そんな話はしてないという

こんなにスレ伸ばしたって読まねぇぞ

deep copyとshallow copyは2種類の異なるcopy方法が考えられる時にのみ
その使い分けに用いられる用語
1種類しかない時に用いたら失格

夏休みは海とか山とか友達なんかと遊びに行きなよ
人付き合いはできて困る事はないぞ多分

仮に111レスしてるおじが本人の言う通り自演してないとしても
もう一人の無限湧きの単発のおじが自演ってだけだから、結局二人でずっとまったく成立してない会話してるんだよね
OpenClawでやってるにしろ人力にしろ、本当に海か山でも行ったほうがいいと思う

音大出身の女性がITディレクターやってたらしいんだが、あり得るの？
年収は600万

https://lavender.5ch.io/test/read.cgi/karaok/1784604629/625

625 選曲してください sage 2026/07/22(水) 00:11:47.96 ID:5DADgvY5
>>608
その会社は入社1年目
そのままクライアント会社(上場)に新設されたWEB事業部に出向→移籍、社長プレゼン

我ながら特殊な経験をしてると思うよ
まだWEB専門卒の人とかも少ないし素人が現場で仕事を覚えていける時代だったから、今ではあり得ないやろね
紙媒体からWEBに移行した人も多くて、得体の知れない業界人がウヨウヨいた

普通によくある構造体struct Xxx { ... }を生成する関数
impl Xxx {
fn new( ... ) -> Self {
...
}
}
fn foo {
let x = Xxx::new( ... );
}
これはもちろんこの関数new()の中で生成したXxx型の値が呼び出し元の関数foo()にある変数xへムーブされる
Rustの抽象概念としてはここまで
ムーブが現実にはどのように実現されているかを知ることなくRustのプログラミングができる

Rustの抽象概念ムーブがどのように機械語で実装されるのか？
それがRustの高速性を決めている
普通によくあるx86-64bitのLinux環境で関数が値を返すときのムーブの実装について見てみよう
64bit二つ分までのサイズのデータを関数が返す時は64bitレジスタraxとrdxに入れて返す
しかし>>862の構造体Xxxのサイズがその128bit (=16byte)を超えていてレジスタ返しができない場合はどうなるだろう？
Rustでは関数f()でのデータ受け取り変数xのアドレスを隠れた引数として関数new()へレジスタ渡しする
new()ではそのアドレスへ直接データを書き込んでXxx構造体を作っていく

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

ムーブは抽象概念に過ぎないため実際にデータを移動(コピー)させる必要はない
最初から最終移動先へデータを書き込むことでRustは無駄なコピーを排除している

仮に額面通りmoveするんだったらコピーが入るから、効率重視のコードなら回避しないといけないでしょ
つまり最適化を理解する必要があるわけで、
> ムーブが現実にはどのように実現されているかを知ることなくRustのプログラミングができる
は誤りということになる

ムーブという魔法でRustは上手いことやってくれるという抽象レベルの理解も重要
そのムーブ魔法がどう実現されているか知っておくことも重要

魔法を信じてプログラミングしても大丈夫だよ
もし遅いと感じたら測定する
ムーブの最適化が何らかの事情でできてなければ判明してそこで初めて対処すればいいんだよ
万が一に備えて最初からヒープ領域にデータを置くことは間違った早すぎる最適化であり愚かな行為

>>857
両方あるが
何を言ってるんだこいつは……

>>866
いや、予想できることだし最初から大きなデータをヒープに置くのはRustでも普遍的なシステムプログラミングの慣習でもあるんだわ
君が書いたことないからっててきとうなことを言ってはいけない

>>863
値を返す時に必ずそうなるという主張はコンパイラを単純に考えすぎているし、そもそも出力されるアセンブリ言語や機械語はそのバージョンのコンパイラの解析能力で扱える範囲で最適化されるにすぎないことは知っておく必要がある

>>864

>>862の
> ムーブが現実にはどのように実現されているかを知ることなくRustのプログラミングができる
は
> ループとif文があれば全てのプログラムが書ける
みたいな理論上の話と捉えれば筋は通る
ただ、現実問題として「できる」と「やるべき」の間にはかなり深い溝がある

>>866
そもそもスタックに巨大データを置くことが誤った設計なんですけど

旧来からの発想の転換で有利なスタック領域を活用することがRustの高速化に繋がった

流石に嘘すぎる
何のためにRustがヒープを安全に扱える仕組みを導入したのか完全に無視している

スタック領域が有利なのは特定の条件下（確保/解放が多い、扱うデータが小さくコピーが起きても支障がない、決定論的な動作が必要でシステムコールが待てない）だけで、大きなデータを扱う場合には普通にヒープに置いた方が使い勝手はいい

>>872
Rustが高速な理由は無駄な処理をしない、遅い処理を排除することに注力し、かつ言語仕様を厳格化することで最適化しやすいヒントを多く含むIRを生成して、LLVMに渡せるようにすることで実現されている
ヒープ領域はむしろ積極的に活用されている（たとえば、VecやStringはヒープの確保を伴う）し、スタックに大きなデータを置かないことを推奨してもいる

Rc/Arcはヒープ領域を管轄するからこそ実現できる例のようにヒープ領域の利用は意味があるよ
基本はスタック領域を活用
必要に応じてヒープ領域

>>876
> 基本はスタック領域を活用
この時点で嘘なんだよな
Rustはプリミティブ値以外ほとんどヒープに置く
配列よりもVecを使う言語だぞ

>>875
スタックに大きなデータを置いても構わない
推奨なんてものはない
例えば全てのデータをスタックに置いてL2キャッシュの恩恵により高速に動かすことなど普通に行われている

>>878
ダウト
スタックに置くこととL2キャッシュに載ることに関連性はない

>>877
初心者なのかもしれんがRustではスタック上で配列を使うクレートも盛んに使われているぞ
適材適所で使い分けが肝心

言い争ってる内容のレベルが日々下がってくね

>>880
そりゃ機能があるのに全く使われてないと仮定するのは無理があるし、そんなことは言ってないでしょ
「よりも」はゼロヒャクじゃないよ

>>881
Rustろくに書いたことないのにゼロヒャクで断言したがる奴が多すぎるんだよな

>>879の補足
CPUのキャッシュはヒープ領域のデータでも使用頻度が高ければキャッシュするので、スタック領域かヒープ領域かは関係がない
そのためにキャッシュラインに合わせてアラインメントしてヒープ領域を使うということも行われる
また、スタック領域に置かれていてもアラインメントがされていなければキャッシュ効率が悪くなることも普通にある

メモリ空間をOSが管理してると、ヒープ領域を使うのにいちいちシステムコールが必要になるから、欠点が目立つんだよな
でもスタック領域に欠点がないかと言えば、別にそんなこともないから使い分けが必要

>>879
スタック上で処理したほうが圧倒的に有利になっている理由は、他のローカル変数はスタック上にあり、関数呼び出し時もスタックを用いるため
メモリの使用範囲がスタック上のみに限定され、メモリキャッシュ効果が最大限に発揮されます

>>886
そもそもスタック領域を大きくしたらスタック全体がキャッシュに乗らなくなるし、ヒープでも確保を工夫すればキャッシュに乗せられるので、ほとんど関係がない

>>887
大きさ問題はその両者で中立。
ヒープだけを使うことは不可能だがスタックだけを使うことは可能だから必ずスタックが有利になる。

仮に (あくまでも仮に) スタックの多用が全面的にメリットばかりだとしてもたとえば Linux のデフォルトだとスタックの上限はたった 8MB だぞ。
上限を引き上げる設定をやったことなんてほとんどないだろ。みんなスタック 8MB でやりくりしてるんだよ。

> スタックの多用が全面的にメリットばかり
正にこれが間違い

ヒープ領域に確保する方が関係データを含めてアクセスローカリティを考慮したデータレイアウト設計が出来る

組み込みだとスタックが浅いからって
関数呼び出しはするな
引数も使うな
全部グローバルでやりとりしろ
みたいな流儀があったらしいと聞くが
なんでそういう絶対的な制約があるわけでもないのに似たような縛りプレイやろうとしてるんだろう

>>889
8MBはデフォルト値にすぎないから
起動プロセスのための環境変数を設定するタイミングと同じように
起動直前で例えばulimit -s 65536すれば子プロセスのみスタック領域を64MBに変えることができるよ

>>892
デフォルトなのは知ってるからデフォルトって書いてるだろ。
変更できるのは知ってるから、でも変更したことないだろ (それが普通) って話をしてる。

スタック領域サイズだけに限らず諸々のリソースのパラメータは各用途に応じて設定して運用が行われている

Rustってすごい言語なんですね

>各用途に応じて設定して運用が行われている
(つまり、各用途に応じた設定をして運用を行ったことはない)

>>895
リソースパラメタ変更して運用はRust登場以前から普通に行われている

>>890
そもそもスタックが全てキャッシュに乗るわけでも、データが全てキャッシュに乗るわけでもなく、使ったものがキャッシュに乗る
なのでスタックにあるかどうかは関係ないし、そこに固執してるのは知識がないから

ごめん、>>888だった

複おじの妄想は相手しなくていいよ

>>898
スタックは必ず使われるからキャッシュに必ず乗り必ず有利になることは常識

>>901
キャッシュはキャッシュラインの単位ごとにしか乗らないので、巨大データをスタックに置いたところで他の変数と一緒にキャッシュに乗ることは保証されない
一方でヒープに置いた場合でも、一度使えばキャッシュに乗るため繰り返し使う時に高速で扱える

> 必ず乗り
そんなわけない

キャッシュが無限に容量があって無限に高速なメモリだとでも仮定しないと、必ず乗るなんて主張は成立させられないはずなのだが
それにヒープ領域はキャッシュに乗らないと頑なに信じているらしいが、CPU設計者をそこまでバカにする理由もよくわからない
わざわざ大量の計算をしてスタック領域だけを見分けてキャッシュに乗せる、そんな無意味なことをするとなぜ信じられるのだろうか

レジスタ退避でいつもL1に乗るからスタック上にあるローカル変数は速いよね

>>905
いつでもL1に乗るなんてありえない妄想
そもそもL1は8MiBもねえじゃん

>>905
レジスタ退避について勘違いしてるよ

>>905
シンプルに教えてほしいんだけど、レジスタやL1が8MiBもあるCPUってどこにあるんだい？