Rust part13

**デフォルトの名無しさん** · 2021/11/07(日) 10:04:59.35

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

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

日本語の情報
https://rust-jp.rs/

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

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

※C++との比較は専用スレへ
C++ vs Rust
https://mevius.5ch.net/test/read.cgi/tech/1619219089/

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

前スレ
Rust part12
https://mevius.5ch.net/test/read.cgi/tech/1629813327/

**デフォルトの名無しさん** · 2022/02/11(金) 17:45:40.46

決まっていないなら

**デフォルトの名無しさん** · 2022/02/11(金) 17:56:17.41

>>945
なんでもいいの？
書かれているコードが>>926だとして、
iの値が0x5617ae143260で
aの値が0x5617ae143260でもあなた的には問題ないってこと？

**デフォルトの名無しさん** · 2022/02/11(金) 18:02:50.44

>>947
新しいアドレスにはすでに使われているアドレスの値を使ってはいけないという制約は操作的意味論でも目にするでしょう
あなたが熱心に勉強するタイプの人であったなら私のレスを待たずにして自分で調べて自分で疑問を解決していただろうに残念ながらあなたは受動的にしか学習せず一生初心者のままに留まる人間なんでしょうね

**デフォルトの名無しさん** · 2022/02/11(金) 18:14:14.82

>>942
その通りで、単なる識別子としての「値」で解放しているだけだね
そしてアロケーションライブラリによってはその「値」がアドレス自体でないかもしれない、と
C言語では抽象レベルと具体化レベルがほぼ一致のためアドレスが使われアドレスで考えてもいいけど
多くのプログラミング言語ではその部分は実装レベルに隠蔽されているからアドレスで考えてはよくないね

で、話を戻すと、大元の話ではその「『値で』解放している」かどうかではなくて
「『値を』解放している」のか、「なんらか抽象的な『空間を』解放しているのか」の話だったと認識してる

**デフォルトの名無しさん** · 2022/02/11(金) 18:27:09.56

>>948
ごめん、プログラミング歴20年超えてるんだわ

まあ>>947は意地悪だったけど、何が言いたいかっていうと、
有効なアドレスってのは実行時するかコンパイルしないことには定まらないでしょって話
でも言語仕様っていうのは、コンパイラが存在しなかったとしても存在し得るんだわ

で、他の人は言語仕様の話をしてるけど、一人だけ変数じゃなくてアドレスという値だって言い張るから、
マシンが存在しない状態だとどういう値なのよ？って思ったのね
意地悪なこと書いてごめんよ

**デフォルトの名無しさん** · 2022/02/11(金) 18:35:25.52

おまえらって基本マジメなんやろな何か
意見の違いはあれどそんなに嫌いじゃないわ
（ただし複製おじは除く）

**デフォルトの名無しさん** · 2022/02/11(金) 18:36:53.23

最適化で消えるようなもんが言語仕様なわけ無いですもんなー

**デフォルトの名無しさん** · 2022/02/11(金) 18:39:18.92

>>949
closeシステムコールはfile descriptorをcloseする
file descriptorでcloseするとは誰も言わない
file descriptorはファイルを参照する値であるがファイル自体ではない
それと同様freeはアドレスという値を解放しているのであってアドレスという値で解放してるとは誰も言わない
「値で解放するの表現が正しい」(笑)って言う意見に耳を傾けるのはまだあなたが初心者を脱することができていない証拠

https://linuxjm.osdn.jp/html/LDP_man-pages/man2/close.2.html
こういうサイトにも「close() は、ファイルディスクリプターをクローズする。」とある

**デフォルトの名無しさん** · 2022/02/11(金) 18:51:10.18

>>951
真面目すぎてひねくれたパターンだろうな
出世もしないで片隅でコード書いてる人よくいるし

**デフォルトの名無しさん** · 2022/02/11(金) 18:51:59.28

>>952
その最適化で消えるようなもんが言語仕様
例えばRustでは言語仕様で通常の参照ポインタはnullにならない
nullを言語仕様として扱わずNone値を持つOptionを導入にしている
そしてヌルポの先へアクセスすることを完全に封じている、というのが言語仕様

ところがその抽象レベルを離れて実装レベルになると話が違う
愚直にOptionを実装すると参照ポインタ以外にメモリを余分に使う
そこで最適化によってNone時は参照ポインタの実体アドレスを0すなわちnullポインタとしている
これでOption分の余分なメモリを使わずに済ませている

つまり言語仕様としての抽象化されたレベルと
実際にアドレスがどうなるかという具体化されたレベルは常に区別しないといけない
Rustプログラマーとしては実装でどうなるかは知らなくてもプログラミングできる
そしてまずはその抽象的なレベルのみ意識して学習すべき

**デフォルトの名無しさん** · 2022/02/11(金) 18:58:14.24

>>955
こりゃ失敬。なるほど確かにそうだわ。適当な事言いましたわ

**デフォルトの名無しさん** · 2022/02/11(金) 21:48:20.48

>>925
まーたオジさんいい加減なこと書いてるねw
操作的意味論ではvariableとlocationとvalueを明確に区別するのが一般的
メモリ領域のことを値だと表現するのはRust的にも操作意味論的にも間違い

**デフォルトの名無しさん** · 2022/02/11(金) 21:52:44.45

>>941
>Rustを含めアドレスという言語機能を持っている手続き型言語で変数と呼ばれているものはただのアドレスです

全く違うんですけどwww
都合悪くなってスレ流したいのかもしれないが
とりあえず嘘八百でスレ埋め立てるの辞めてくれ

**デフォルトの名無しさん** · 2022/02/11(金) 22:35:25.65

>>957
操作的意味論ではそれ以上簡約できない項を値と呼びます
varもlocもどちらもそれ以上簡約できないので値です
試しにTaPLで値ががどのようにBNFで帰納的定義されている集合なのか確認してみたら？
あなたが理解していないだけでは？

**デフォルトの名無しさん** · 2022/02/11(金) 22:39:32.55

>>958
スレ埋めてるのはどちらかというとこのような無意味なレスをするあなたでは？
私は自分のレスが正しいと知っておりますのでどうぞ余計なレスを書き込まないでこのスレを延命してくださいませ

**デフォルトの名無しさん** · 2022/02/11(金) 22:48:24.70

6AYXkq/Gを相手にしても無駄だから元の話に戻りましょう
>>808について自分の意見は
○「型のインスタンスに所有権がある」
×「値に所有権がある」　←値は途中で完全に置き変わっても構わないため×
×「変数に所有権がある」　←変数はどんどん移動できて一時的な束縛にすぎないため×
×「アドレスに所有権がある」　←アドレスは関数へ渡したり返したり途中で変わるため×

**デフォルトの名無しさん** · 2022/02/11(金) 23:10:21.43

>>961
「所有権がある」という意味が「所有権を持つ」という意味であれば
「値の所有者は変数」だから「所有権を持つのは変数」だよ
スコープを抜ける時に所有リソースを解放する責任というのかownershipを持つということ

型のインスタンス？
説明してもらわないと意味分からないな

**デフォルトの名無しさん** · 2022/02/11(金) 23:19:43.49

>>961
> 値は途中で完全に置き変わっても構わないため

所有権というのは「後始末する責任」のこと。
内容が書き換えられることを許すのは所有権を手放しているわけではない。

**デフォルトの名無しさん** · 2022/02/11(金) 23:22:41.86

>>961
> 「変数に所有権がある」　←変数はどんどん移動できて一時的な束縛にすぎないため×
変数は移動できなくない？何か別のことを言いたかったんかな？

変数が所有権を持つ、で良いんじゃないかな
値を変数に束縛するときに、変数が値を所有することになる
そして変数が値を所有したままスコープアウトすると、値をdrop(解放)する

**デフォルトの名無しさん** · 2022/02/11(金) 23:25:49.74

「変数が所有権を持つ」よりも、「変数が値を所有する」のほうがいいか

**デフォルトの名無しさん** · 2022/02/11(金) 23:27:09.03

主語と目的語を逆に違う意味に誤解されるとわかったので補足します
○「型のインスタンスに対して所有権があるor生じる」
×「値に対して所有権があるor生じる」　←値は途中で完全に置き変わっても構わないため×
×「変数に対して所有権があるor生じる」　←変数はどんどん移動できて一時的な束縛にすぎないため×
×「アドレスに対して所有権があるor生じる」　←アドレスは関数へ渡したり返したり途中で変わるため×

>>962
プログラミング言語の分野で一般的に用いられるインスタンスです
型とインスタンスは一般的に1対多の関係になります (シングルトンでは1対1ですが)
言語によっては型をクラスと表現する場合もあるようですがRustではそんな狭い範囲ではなく全ての型が対象です

>>963
そのように値は変わっていくものだから
値に対して所有権といっても曖昧さが残るでしょう
だから不変でない値に対して所有権があるとの考えはよろしくない
まだ>>964の言う変数を持ち出したほうがマシ

しかし変数との関係は一時的にすぎず所有権は別の変数へ移動していきます
所有権と常に1対1の関係にあるのは(型の)インスタンスです

**デフォルトの名無しさん** · 2022/02/11(金) 23:32:51.77

>>964
変数が所有権を持つというのは変な解釈。
結果的にはそういう挙動ではあるんだが
値が変数に捉えられている間は寿命が継続されるというルールによって
変数のスコープと連動してるだけ。
所有権を持っているのはあくまで値。

**デフォルトの名無しさん** · 2022/02/11(金) 23:37:03.65

>>967
所有権を持っているのはインスタンスであって
値はそのときどきで変化するだけにすぎない存在だと思います

**デフォルトの名無しさん** · 2022/02/11(金) 23:39:32.68

>>968
いいえ。そんな定義はないです。

**デフォルトの名無しさん** · 2022/02/11(金) 23:45:01.94

俺が入れ物に対して所有権があると>>900で書いたのも実質その型のインスタンスだ
インスタンスという言葉を使うと面倒になりそうなので抽象的に型の入れ物とした
いずれにせよ所有権の対象は値ではなく値が収容される入れ物orインスタンスだ

**デフォルトの名無しさん** · 2022/02/11(金) 23:45:21.67

実際のところ「値」と「インスタンス」の間にそんなに意味の差はないです。
特的の型を元に作られたということを強調するときにインスタンスと言うことはありますが、
どの値も型を持つのでインスタンスではない値などありはしません。

**デフォルトの名無しさん** · 2022/02/11(金) 23:47:31.44

>>971
インスタンスはその型の形をした器(うつわ)であり解放されるまで不変
値はその器(うつわ)に入った内容にすぎず可変

**デフォルトの名無しさん** · 2022/02/11(金) 23:48:11.08

>>972
いいえ。繰り返しますがそんな定義はないです。

**デフォルトの名無しさん** · 2022/02/11(金) 23:49:47.15

>>967
＞所有権を持っているのはあくまで値。

で、その値は何の所有権を持ってるのさ？

**964** · 2022/02/11(金) 23:51:18.52

そもそも「所有権を持つ」ってのが苦しい
英訳すると "own the ownership" になってしまうが、そんな表現は公式ドキュメントでも避けられてるように思う

値が変数に束縛されるとき、その値を変数が所有することになる
変数をreturnしたり、変数を他の変数に代入するときには、所有権がtransferされることになる

ここまでは良いでしょ
例えば、公式ドキュメントにもこう書かれてる
https://doc.rust-lang.org/book/ch04-01-what-is-ownership.html
> Returning values can also transfer ownership.

なので、強いて >>961 の中から選ぶなら変数が所有権を持つだけど、最初に書いたようにそもそも「所有権を持つ」が苦しいので、
「変数が値を所有する」とすれば良いと思う

**デフォルトの名無しさん** · 2022/02/11(金) 23:51:21.22

>>965
＞「変数が値を所有する」

これが正解。

**デフォルトの名無しさん** · 2022/02/11(金) 23:51:57.38

>>973
皆がその点については定義がはっきりしないからこれだけ揉めてるんだろ
「そんな定義はないです」は反論にすらなっていない

**964** · 2022/02/11(金) 23:53:29.17

ああ、別に「持つ」を必ずしも "own" で訳す必要もないね
さっきから変なことばかり書いててすまんね、今日は冷静になっていったんもう寝る

**デフォルトの名無しさん** · 2022/02/11(金) 23:54:02.65

>>974
値自身を後始末する責任をもってる。
所有権という訳語がよくないというのはよく指摘されることだが、
何者かが値を所有しているという誤解のもとになるからだ。

変数が所有権を持っていることにしたら
一時オブジェクトの所有権はどうなってんだって話になるだろ。

**デフォルトの名無しさん** · 2022/02/11(金) 23:57:48.33

>>975 >>976
そんな話は誰もしていないと思う
所有権は何に対して付随するのか生じているのかが論点
そして所有権が消滅するのは型のインスタンスが最後に解放される時
だから所有権と1対1の関係にあるのは(型の)インスタンスだと主張しています

**デフォルトの名無しさん** · 2022/02/12(土) 00:03:26.33

>>972
> インスタンスはその型の形をした器(うつわ)であり解放されるまで不変

いいえ。
代入で内容が書き換えられる場合もあり、
そのときに drop が呼ばれます。
寿命の管理は値に付随します。

**デフォルトの名無しさん** · 2022/02/12(土) 00:19:59.58

とりあえずbookの
4.1. What is ownership?
（ttps://doc.rust-lang.org/book/ch04-01-what-is-ownership.html）
からOwnership Rulesの節を丸ごと抜いてきた（訳は適当）

Ownership Rules

First, let’s take a look at the ownership rules.
Keep these rules in mind as we work through the examples that illustrate them:

* Each value in Rust has a variable that’s called its owner.
* There can only be one owner at a time.
* When the owner goes out of scope, the value will be dropped.

まずは所有権（ownership）に関するルールを見てみよう
このルールを記憶に留めて以下の例示を読み進めてほしい

・Rustの各々の値（value）は所有者（owner）と呼ばれる１つの変数（variable）をもつ
・所有者は同時に１つしか存在しない
・その所有者がスコープからいなくなる時、その値は破棄される

**デフォルトの名無しさん** · 2022/02/12(土) 00:26:03.97

>>982
これが正解

**デフォルトの名無しさん** · 2022/02/12(土) 00:26:42.42

>>981
内容が書き換えられてdropすることはない
所有権と値は関係ない
値に付随するものではない

>>982に明記されているように所有権を持つ所有者は変数
所有者である変数がスコープから外れるとdrop

**デフォルトの名無しさん** · 2022/02/12(土) 00:31:23.69

>>982
だよなぁ。「入れ物」とか妙ちきりんな説明する人はなんなんだろう？

**デフォルトの名無しさん** · 2022/02/12(土) 00:37:10.88

インスタンスというのも一理ある
その型のインスタンスが作られてから解放されるまで一貫して一つの存在なのに対して
変数は次々と移り変わって行く乗り物と捉えることができる
そしてインスタンスがたまたま束縛されている変数がスコープから消えると乗っていたインスタンスも巻き添えで消えると考えられないこともない

**デフォルトの名無しさん** · 2022/02/12(土) 01:06:37.82

>>980
スレ立てヨロ

**デフォルトの名無しさん** · 2022/02/12(土) 01:26:58.40

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

**デフォルトの名無しさん** · 2022/02/12(土) 01:32:16.48

>>988
GJ

**デフォルトの名無しさん** · 2022/02/12(土) 01:58:18.50

横からすまんが、実際のメモリ上だと所有権ってどうなってるもんなの？
>>982にある仕組みからしたら・・・・メモリが確保されるのと同時に、併せて所有権情報（スタックへの参照か何か？）がメモリのどっか確保されるわけ？
俺、てっきりコンパイラへのただの指示だとばっか思ってたぜ

**デフォルトの名無しさん** · 2022/02/12(土) 02:19:56.25

横からキターーー

コンパイラの課すルールの話なので
所有権情報が実行時にメモリに確保されたりしないよ

**デフォルトの名無しさん** · 2022/02/12(土) 04:01:34.21

まじか、そうなんだ

**デフォルトの名無しさん** · 2022/02/12(土) 06:46:04.75

ワッチョイ無しか、次スレも荒れそう

**デフォルトの名無しさん** · 2022/02/12(土) 07:47:32.16

struct S;
impl Drop for S {
fn drop(&mut self) {
println!("drop");
}
}
fn main() {
S;
}
↑じゃあこれは何が所有権をもってて何がdropさせてんの？
インスタンス説のほうがまだシックリくる？
変数も所有権を持てるしスコープ終了で手放せる？

**デフォルトの名無しさん** · 2022/02/12(土) 08:42:47.12

>>961
お前が突っかかって来たんだろうが
ガイジｗｗｗｗ

**デフォルトの名無しさん** · 2022/02/12(土) 08:42:55.77

うんこ

**デフォルトの名無しさん** · 2022/02/12(土) 08:43:01.75

まんげ

**デフォルトの名無しさん** · 2022/02/12(土) 08:43:06.69

ちんげ

**デフォルトの名無しさん** · 2022/02/12(土) 08:43:39.79

>>957
お前の負けやでｗｗｗｗｗｗｗｗ

**デフォルトの名無しさん** · 2022/02/12(土) 08:44:18.55

無教養のガイジども阿鼻叫喚していて草ｗっｗｒ
ンゴｗｗｗｗｗｗｗ

**1001** · Over 1000

このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 96日 22時間 39分 19秒