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/

>>647
Cと同じく意味論として挙動が決まっているだけだから、実装がスタックを使う保証はない
実際にはほぼ確実にスタックが使われるところまで、Cと同じだよ

>>653
スタックで実装されているかどうかは機種アーキテクチャに依る

>>654はちゃんとした話はする気ないからやっぱりスルーでいいんだよ
荒らしは放置安定

何聞かれてるか回答見るまで理解できてなかったのか

>>657
正しいことしか言ってないが何が気に入らない？
>>623が間違っていると指摘したことを逆恨みかね？

もうこの荒らしについて言及するの禁止な
ID:2WiNYKUyにレスすんな

>>637
Windowsが1MiB、Unix系が8MiBなんだっけ？

>>660
意味のないことを一つも書いていないおまえが荒らしだろ

Windowsはそうだけど、Unix系と言っても広いからなあ
まあ、デスクトップとモバイルだけならmacOSとLinuxだけ考えればいいんだろうけど
macOSとLinuxだけなら8MiBであってたはず

Linuxでも組み込みだと違いそうだよな

> スタック領域を指しているかヒープ領域を指しているか区別して扱わなくても安全
そんなことはみんなわかってる

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

ってだけなんだよな

>>665
厳密に言えば区別せずにスタックに大きな構造体なり配列なりを置きまくってたらスタックオーバーフローすることはあるから、メモリ安全なだけで他の安全は保障されてないんだけどな

>>661
基本はそうだけど
特にRustの場合はメインスレッドと新規スレッドで異なる点が重要
メインスレッドはOSレベルで指定でLinuxなら8MBがデフォルトだがulimit -sで自由に変更できる
新規スレッドはRustの中で指定でデフォルトは2MBだがスレッドのビルダーで自由に指定できる
だからRustではサイズの大きなものをスタック上に置ける

>>667
まあ大きくしすぎてもでメリットがあるからあんまやらないし、新規スレッドだけの話だからどこでも自由なわけでもないし、使い分けを意識してない奴ができることでもないんだけどな

そいつは放置しろって言ってるだろ

>>668
スタック領域を大きくして使うことは
ヒープを使うことと比べて不利にならない
新規スレッドだけの話ではなくメインスレッドもスタックを大きくして使われている
ulimit -sで誰でも変更可能でその後に起動すればメインスレッドのスタックを大きく使えるため

>>670
スタック領域に大きなデータを置くと関数の壁を跨ぐ度にディープコピーになる
これは当然動作速度に悪影響を与える
ヒープ領域なら .clone() しない限りムーブになるので、シャローコピーして所有権を渡すだけなのでこの悪影響を回避できる

>>670
ulimitが必要な時点でデメリットあるやんけ

>>671
Rust初心者でもそんな間違いしないぞ

>>671
そっか、moveが標準だからヒープをわざわざコピーするわけないのか

また何が間違いなのかも言わずに間違いだと主張する荒らし仕草が出たな

>>675
自閉症スペクトラム総合スレ86【ASD】発達障害
https://mevius.5ch.io/test/read.cgi/utu/1782020264/

可変借用は元のところに返すわけじゃないならデメリットが大きいからなあ
わざわざ大きなデータを置いて寿命を気にして可変借用を引き回すより、ヒープに置いてムーブした方が素直な実装になって楽なんだよな

>>676
アンカー間違ってますよ

>>673
自閉症スペクトラム総合スレ86【ASD】発達障害
https://mevius.5ch.io/test/read.cgi/utu/1782020264/

自閉症はC#みたいなのを好む
馬鹿だから😂

大きなデータをスタックに置くと他所で書き換える用途が1つあるだけで可変借用が面倒なことになるよな
ムーブできないのはめんどくさい

😭
https://i.imgur.com/QdnVOt2.png

何も考えず上げるアホのせいで荒らしが増えたな

荒らしが仲間読んで増えちゃってるじゃん
だから話しかけんなって言ってんのに

>>677
本気か？
関数を呼び出すたびにその関数へムーブしていってを深く繰り返し戻る時は返り値で何度もムーブして返すのかね？
爆笑すぎて笑ってしまった

ageで荒らしが来るって5chをPCで操作してるのかな？いろいろ時代遅れ極まりない

【専ブラ】5ちゃんねるブラウザ「ChMate」part269
https://egg.5ch.io/test/read.cgi/android/1784035194/

>>685
無意味に可変借用し続けてライフタイム注釈書きまくる奴の方がアホなんだよなあ
C++とRustは違う言語だと理解した方がいい

ほら荒らしが来た

>>687
ギャグではなく本気かよ
関数の引数でムーブで渡して返り値でムーブして戻すなんて爆笑行為だろ

>>689
moveの意味知らなそう

ムーブとコピーの区別がついてるかも怪しい
こいつ言ってることがいちいちRust知識皆無なんだよな

mut self なんか日常的に取るだろ
ムーブしない設計に固執するのはバカ

>>677は
> 可変借用は元のところに返すわけじゃないならデメリットが大きいからなあ
って言ってるのに
>>689は
> 返り値でムーブして戻すなんて爆笑行為
とイチャモンをつけてる

荒らしは放置

ビルダーパターンもイテレータアダプタもムーブなんだが、知らないのかな？

>>695
それらは一階層のみ
しかもヒープを使わずにselfはスタック上で問題ないパターンなので今回の話とは全く関係がない

>>696
関係あるんだよなあ
それに実装のやり方次第だから1階層なんて保証も全くないし

スタック領域でもムーブを書けることと、ディープコピーがないことは別なんだよな
引数ならまだしも、戻り値にする場合その関数のスタックは破棄されるのでディープコピーは発生する

>>697
ビルダーもイテレータも通常スタック上に置く
そして支障はない
ヒープを使わなければいけない例になっていない

どうせこいつまともな知識ないくせにイキってるだけだから何言っても無駄だぞ
荒らしはスルーが安定

>>699
大きなデータをスタック領域においても何のデメリットもないと主張してたのはお前だぞ
小さいから支障がないって主張はそれと矛盾してるよなあ

まあこの程度の話がわからない奴なんだから相手しても無駄

>>701
お前が反応してどうする

ID:2WiNYKUyはID:GVCMKu1f
大した知識もないくせにチェリーピックと無茶苦茶な主張で何百書き込みも荒らしたやつだから相手しちゃダメ

荒らしなんかやるレベルのバカにはRustは難しいんだよ

結局>>671が結論でそこから先荒らしが喚いてただけ

>>698
スタックじゃない実装の場合は変わるのかね

>>701
その「小さいから支障がない」を主張したことがない
そのビルダーやイテレータのパターンならスタック上に大きなデータでも問題ない
「ヒープを使わなければいけない例になっていない」と主張している
早くヒープを使わなければいけない例を示してくれ

>>706
>>671に現実味がないため議論になっている
既に話がでているパターンのあちこちの例はスタック上に置いて使われているがコピーは発生せず問題になっていない
他のパターンだと例えば関数奥深くで大きなデータを作って一番上の関数まで返していくパターン
これはRustでもRVOになる
つまり関数奥深くから一番上の関数のスタックフレームへ直接代入してしまうため大きなデータのコピーは発生しない

>>671>>698
ディープコピーの意味を勘違いしてる
昔の複オジと同じ勘違い

>>710
その人の書き込みは意味の勘違いに用語の間違いもあって突っ込みどころ満載だよね
それなのになぜかその書き込みを支持してる人がいるから同一人物による自演支持なのかも
あと同じ間違いをしてるからその二つの書き込みも同一人物かも

>>698
戻り値にする場合は先ほど書いたようにRVOでコピーされない

>>708-711
どう見ても自演なのはそっち

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

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

> RustでもRVOになる
単純なケースでコンパイラが最適化することと、言語仕様を混同することはできない

>>710
ディープコピーとは実体をコピーすることで>>671 >>698の使い方に間違いはない
勝手な思い込み定義をしているのか知らないが

>>711
> 意味の勘違いに用語の間違いもあって突っ込みどころ満載
どこがかは言えないいつもの荒らし仕草

こう訊いたら
> is RVO always applied in Rust?

こう即答されて、その後、RVOになる可能性の低い場合を挙げてくれる
> No, Return Value Optimization (RVO) is not guaranteed by the Rust
> language specification.

初出のIDが「どう見ても自演なのはそっち」とは面白い冗談ですね

>>715
何言ってんだこいつ

>>714
最適化はコンパイラの実装の問題でしかないからねえ

>>712
自演してません
>>710は別人です
あなたの自演の可能性を疑った理由はあなたの書き込みが突っ込みどころ満載なのに突っ込まれずになぜか支持する人がいて更に同じ間違いをしてる書き込みがあったためです

ID:2WiNYKUy（ID:GVCMKu1f）ってずっと「ほんの少しのケースにだけ当てはまること」を「全部必ずこうなる！」って主張して、「これならないんですけど」と言われたら条件を増やし始めるという論法ばっかりだよな

>>718
自分の主張を否定してるから突っ込みどころ満載なんだ！と言いたいわけですな

>>713
ディープコピーは分野によって微妙に指すものが異なることもある言葉ですが
Rustでは公式に使われ方が一定しています
あなたの使い方はそれとは異なり間違っています
Rustのbookなどで使われる時は常にヒープ領域まで含めてコピーすることをディープコピーと呼んでいます
>>671も>>698もスタック領域について言及していますからディープコピーではありません

>>721
「The Bookではスタック上のコピーをCopyトレイトでしか語らない」ということと「スタック領域について言及していますからディープコピーではありません」というのとは結び付いてないんだよな
論理が2段階くらい飛躍してる

それに、実体をコピーすることをディープコピーと言うのはプログラミングにおいて一般的な用法なので、これを間違いだと断言するのは法律家に「変数に人格はないから所有権は認められない」って言わせるのに近くてあまり意味がない

https://mevius.5ch.io/test/read.cgi/tech/1652347700/52

ディープコピーこれか
今はこれくらい吹っ切れたこと言わないで言葉濁してばっかりでつまらんわ

要するに「今そんな話してない」って話よな
アスペはすぐ「こうも解釈できるから違う」って言いたがるけど、人と話してるんだからこういう複数定義が見つかるものであれば、まず何を伝えようとしてるかから類推する必要がある

>>723
そのアスペ法律家ちょっとおもろい

>>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トレイトに明記されてるようにビットコピーと呼ぶのが良いでしょう

これがRust界での常識です
学習してください
ではおやすみなさい

>>723
>それに、実体をコピーすることをディープコピーと言うのはプログラミングにおいて一般的な用法なので
全く一般的ではありません。完全にあなたの勘違いです。
早めにそれも匿名掲示板で恥をかいてよかったですね。

>>727-729
どう見ても自演

>>727
自分で貼った文章を読んでいないみたいだが全く違う意味の話をしてるぞ
雑に要約すると「一般的な言語で言うシャロ―コピーをムーブと呼んでいます」と言っているのであって、スタック領域に確保したオブジェクトをコピー/ムーブすることをどう表現するかには言及していない
いつもそうですが、あなたは自分が言いたいことを言うのに都合のいい記述を探しているだけで、ちゃんと文章を読んでいないからそういう間違いをするんです

>>728 >>729でせっかく人バカにして散々イキったのに、>>731にしっかり訂正されて恥かいてて草

>>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

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

これは全く一般的ではなかったのかー
お前の記憶の方がこっちより正しかったんだなｗ

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

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

これも一般的ではなかったんだなあｗ

>>729
アホほど浅い知識ですぐに断言して他人を煽りたがるよな

>>727
> the bookで明記していますよ
嘘はやめましょう
あなたの引用した範囲には「一般的にシャロ―コピーと呼ばれる操作と、元の変数を使えなくする挙動を合わせて、ムーブと呼称する」という内容しか書かれていません
あなたの主張するようなことは一切書いてないですね

>>728
> これがRust界での常識です
> 学習してください
あなたがまず自分で貼った文章くらい読めるようになってください

この複製おじさんのID変えない版みたいなやつこの前の週末からか？
面白くなってきた

> スタック領域のムーブは2つのうちのどちらかで強いて言えばシャローコピー
流石に無理がある

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

"without copying the data" 「データをコピーせずに」と断言されている
スタックの仕組みを知っていれば戻り値では論理的にコピーが生じる（実装での最適化の話はしていないことに注意）ので、ここで言われているのはヒープ領域のムーブの話に過ぎない

> これがRust界での常識です
> 学習してください

ｗ

> 関数の引数でムーブで渡して返り値でムーブして戻すなんて爆笑行為だろ
そもそもこんなこと言ってたくらいにはRust知識ないからね
一生懸命The Book読んで反論材料探してるだけで、何の知識も持ってないよこいつ

英語読めないなら日本語翻訳版のThe Book開けばいいのに……ｗ
英語の成績悪かった俺でもおかしなこと言ってるなって気づく程度には読めてないぞ

>>730
自演してません
>>729は別人です

>>731 >>736
一部引用してあげただけなのに
その部分しか読んでないのですか？
Rust Bookでは一貫してます
clone()によってヒープ領域までコピーすることをディープコピーと呼んでいます
ムーブによってスタック領域のみをビットコピーすることをシャローコピーと呼んでいます

>>734
そこに書かれてるように二段階の領域のうち二段階目(Rust Bookではヒープ領域)もコピーすればディープコピーとRust Bookで述べています
一段階目(Rust Bookではスタック領域)のみビットコピーのムーブならシャローコピーとして区別しています
したがって>>671と>>698は明確に間違いです

>>731
>> いつもそうですが、あなたは自分が言いたいことを言うのに都合のいい記述を探しているだけで、ちゃんと文章を読んでいないからそういう間違いをするんです
かなりキツくて草

>>743
「わざと関係ない場所を引用しただけです！」ってか？
流石に主張に無理があるわｗ

>>744また都合のいい幻視が始まってるぞ

>>744
唐突に二段階とか言い出して話をややこしくしてるが、結局お前が言ってるようなことはどこにも書いてないな

ヒープかスタックか、みたいな話で終われないんじゃないの？
（一人を除いて（？）みんなが思ってるディープコピーは同じのような気もするけど）
ディープコピーは文字通り深く、根元まで全部コピーしてくれる

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にディープコピーあるのかどうか知らんけど

こいつスタック領域とプリミティブ型の区別ついてないんじゃね
配列とか構造体とかちゃんと触ったことないんだろ

>>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たちもすべて含めてコピーすること

>>750
たしかにそれっぽいな
それなら>>744の説明はつく
まあ、そうだとしてプリミティブ型ならディープコピーとシャロ―コピーが一致するなんてわかりきった話をしてるわけではないんだが

明確に間違っている>>671と>>698を擁護してる人は信頼されません

アドレスやインデックスなどの値を変数に持っている時に
そのアドレスやインデックスなどによって指されている先のデータまでコピーすることがディープコピーです
スタック領域のムーブによるビットコピーをディープコピーと呼ぶのは頭悪いです

>>751
> 「新たに作成する同じ構造の実体」がコピー対象の配列やオブジェクト自体のように読める文章になっちゃってるから間違ってると言っていい
いや、「新たに作成する同じ構造の実体」が元の実体と同じって「新たに作成する」って部分を完全に無視してるよね
あんたが日本語出来ないだけだよ