22/02/10 04:10:06.01 ZV1iYxPB.net
>>868 が言ってる通り公式ドキュメントと矛盾がないように書くべきでしょ
そうすると、copyするのはvalueであって、ownershipはcopyしない
ownershipはtakeしたりtransferするもの
>>866 の最初に書かれてることは良いけど、そのあとは意味不明
887:デフォルトの名無しさん
22/02/10 05:39:51.83 LZ4lXgTU.net
この自演おじさん、そこらじゅうで同じ芸風で荒らし回ってるから本当にタチ悪い。
888:デフォルトの名無しさん
22/02/10 07:56:52.23 B7Nnq//K.net
結論：
｢所有権の複製｣は根拠の無いオレオレ用語であり
rust公式による定義は今回も一切示されなかった
でオシマイの話
889:デフォルトの名無しさん
22/02/10 08:16:17.16 lkU+MWHi.net
このおじさん普通に統失だと思う
890:デフォルトの名無しさん
22/02/10 09:03:54.77 o2ECnsWv.net
>>870
これが正しい
891:デフォルトの名無しさん
22/02/10 10:20:54.50 E3cwpb32.net
>>868
take ownershipのownershipは”もの”じゃないよ
もうちょっと英語勉強したほうがいいんでは？
892:デフォルトの名無しさん
22/02/10 12:39:37.06 JVrcL5p7.net
>>875
理由を言わず間違ってるとだけ指摘して勉強した方が良いとマウントとってくるいつもの人だ
反論できないから空っぽの指摘しかできないのかな
893:デフォルトの名無しさん
22/02/10 12:43:51.26 tTxcUdMu.net
unixのファイルシステムの権限周りの継承とかその辺とごっちゃになってんのかね？
どうして所有権をコピーみたいな話が出てきたのかわりと謎
894:デフォルトの名無しさん
22/02/10 14:41:33.57 3wQKSQe5.net
謎だよな
C++から来てるわけでもないし
どこから来た発想なんだろう？
895:デフォルトの名無しさん
22/02/10 16:06:58.32 mDz1Cqyx.net
>>876
説明してもらっても聞く耳持たないから
もう理由は教えないみたいなことを言われてなかったか？
896:デフォルトの名無しさん
22/02/10 16:38:55.18 rtSKPHyc.net
>>879
その説明へのレス番号貼るだけでもいいよ
897:デフォルトの名無しさん
22/02/10 17:36:51.53 jQfqixkL.net
所有権ルールと参照ルールを混同してたり
所有権が複製される構造はBox<T>のcloneと同じと言ってるところに
勘違いのヒントがありそうだか皆目検討がつかない
誰か解読してくれ
898:デフォルトの名無しさん
22/02/10 18:29:19.19 1jbJS/Bn.net
人格複製ニキの目的って何なんだろな
899:デフォルトの名無しさん
22/02/10 21:15:53.35 HYxEyueN.net
所有権の複製wwwww
900:デフォルトの名無しさん
22/02/10 21:16:13.39 lQNRE6Xh.net
はちみつさんに直接聞いてみたら？
901:デフォルトの名無しさん
22/02/10 21:17:20.02 lQNRE6Xh.net
>>882
>>884
902:デフォルトの名無しさん
22/02/10 23:25:06.23 3aizDYBf.net
ここまで見てる限りどっちでもOKな話だな
値と所有権が「!Copy型は移動」「Copy型は複製」との説明でもRustの理解に支障がないのも事実
一方で現世界にない「所有権の複製」という表現に違和感を持つ人が存在することも理解できる
ただし後者はあくまでも心の内なる話だから前者を崩せない限り不利っぽい
903:デフォルトの名無しさん
22/02/10 23:34:31.44 o2ECnsWv.net
>>886
いや、>>870 で正しいの書いてくれてるのに、公式でもそうなってるのに何故に頑なに所有権の複製を広めようとしてるのよ笑食べて
904:デフォルトの名無しさん
22/02/11 00:20:49.53 05KWrNRV
905:.net
906:デフォルトの名無しさん
22/02/11 00:26:11.55 jgApYu5Z.net
Rustの公式ドキュメントを調べると "copy of the value" という表現はたくさん出てくるが、 "copy of the ownership" のような表現は見つけられない
おそらく公式ドキュメントでも "copy of the ownership" みたいな言葉が使われそうになったときは意図的に排除されてるんだろう
もし "copy of the ownership" みたいに変更しても問題ないと思うなら、公式ドキュメントのリポジトリでそういうふうに提案してみてくれよ
Contributionのガイドを参考にコミュニティに書いたり、GithubでPull Requestするだけだからさ
URLﾘﾝｸ(rustc-dev-guide.rust-lang.org)
907:デフォルトの名無しさん
22/02/11 01:40:58.50 3Ka4+NQm.net
ownership の take や transfer という言葉が出てくるのは !Copy な値についての説明で、
Copy な値については ownership 絡めて説明されてないよね
ownership rule 自体は全ての値に適用されるから本来は Copy な値の ownership についてとうルールが適用されるかという説明はあった方が良いかもね
元々の初学者向け記事ではTRPL英語版にない部分の説明をするにあたって所有権の複製という用語を発明したわけだけど
どう説明するとわかりやすいんだろうか
908:デフォルトの名無しさん
22/02/11 01:48:31.89 +uMSd1hh.net
>>886
>Rustの理解に支障がないのも事実
めちゃくちゃ支障が出てますやんw
所有権が複製されると思ってるからRustの基本ルールが理解できない >>836
所有権が複製されると思ってるからThe Bookの意味が取れない >>868
909:デフォルトの名無しさん
22/02/11 01:57:15.41 Bozzm6u4.net
>>888
Rust的には「変数（値）の所有権がある」という表現が既におかしいぞ
910:デフォルトの名無しさん
22/02/11 08:08:57.43 pt0GtJjK.net
>>890
> 元々の初学者向け記事では(中略)所有権の複製という用語を発明したわけだけど
オレオレ用語を初学者に平気で刷り込んで平気ならば
> どう説明するとわかりやすいんだろうか
今後一切あらゆる場所で説明などしないでほしい
911:デフォルトの名無しさん
22/02/11 08:18:36.04 pt0GtJjK.net
平気すぎた(ノ∀｀)アチャー
912:デフォルトの名無しさん
22/02/11 08:49:57.52 IHS0l4KB.net
個人が複製を分かりやすいと思うのは自由だけど
初心者に広めるのはダメだと思うがな
もっと明らかに初心者向けの例え話とわかるような用語ならともかく
いかにも公式の技術用語っぽい見た目をしてるわけで
これを知った初心者がもっと深く知りたいと思ったときに
ググっても全く情報は出てこないし、誰かに質問しても「なにそれ？」ってなる
少なくとも公式の説明に沿った言い方なら、それで理解してる人が
大勢いるから、そういった問題は生じない
913:デフォルトの名無しさん
22/02/11 08:58:58.08 WRuOVQdn.net
自分の理解不足を何で公式の落ち度みたいにすり替えてるんだ。間違いを認めたら死んじゃう病なの？
914:デフォルトの名無しさん
22/02/11 10:27:57.19 2FzZhGyg.net
>>881
Box<T>が出てくるあたり所有権を値へのポインタ的なものとして考えてるのかもな
まあそれでも複製はされないからイミフには変わりないんだが
915:デフォルトの名無しさん
22/02/11 11:14:45.52 zZVxGVeC.net
勘違い勘違い言うけど>>808以上の話じゃないように思うんだが。
916:デフォルトの名無しさん
22/02/11 11:24:34.62 3Ka4+NQm.net
自分も>>808で良いと思うけど公式の説明と表現が同じになってるかは気になる
917:デフォルトの名無しさん
22/02/11 11:38:14.49 MSfgatap.net
>>808
>>「値が複製されるとき、複製された値には新しい所有権が生まれる」と表現すべき
だからそれが間違っている
値には所有権は無い
入れ物に対して所有権がある
例えば&mutはその入れ物に対する書き換え可能な参照つまり所有権の借用
>>808を肯定する連中はRustをわかっていない
918:デフォルトの名無しさん
22/02/11 11:42:56.32 UuEYjDqs.net
複製オジが遂に撤退戦をはじめたかw
なんで所有権が複製可能だと思い込んだのか説明してくれれば
他の人の役に立つのにな
919:デフォルトの名無しさん
22/02/11 12:01:57.67 3Ka4+NQm.net
>>900
｢入れ物に対して所有権がある｣も微妙な表現で
｢入れ物となる変数が複製された値の所有権を持つ｣の方が適当だと思うけど、どう思う？
920:デフォルトの名無しさん
22/02/11 12:06:36.51 IlhJUkFw.net
流れぶった切ってすまんけど質問
｢借用｣と｢参照｣の違いってなんなん？
921:デフォルトの名無しさん
22/02/11 12:07:10.38 MSfgatap.net
>>902
値は書き換わる物
だから値に所有権はない
入れ物に対して所有権がある
解放する対象も入れ物であってその値ではない
922:デフォルトの名無しさん
22/02/11 12:14:00.85 6AYXkq/G.net
>>904
c言語のfreeって明らかに値を解放してるように思えるんだが
freeした値はその後使えないがその値を入れていた変数はその後も使える
923:デフォルトの名無しさん
22/02/11 12:21:34.19 zZVxGVeC.net
ownerに対する所有権があるような話になってよくわからんね。
924:デフォルトの名無しさん
22/02/11 12:25:48.71 vAEawTbN.net
>>903
参照は変数の種類で、借用は参照の使い方とか参照同士の関係とか状態のこと。
明�
925:mに書かれていないけど、そのへんを意識してThe Bookのreferences and borrowingあたりを見ると良いよ。
926:デフォルトの名無しさん
22/02/11 12:44:48.12 MSfgatap.net
>>905
C言語のfreeでも入れ物を解放している
入れ物の中にある値を解放しているわけではない
そしてmalloc/freeで対象となる変数は入れ物を指している
つまりその変数自体は一つ階層が異なりポインタである
そのポインタ変数を書き換えても別の入れ物を指すようになるだけ
入れ物の中身が書き換わるわけではない
927:デフォルトの名無しさん
22/02/11 13:17:26.35 6AYXkq/G.net
>>908
いいえfreeは入れ物にある値を解放しています
入れ物を解放しているわけではありません
そもそもfreeに限らずc言語の関数はすべて値渡しなのでfree(入れ物)と書いたらfreeには入れ物にある値が複製されたのが引数として渡されて入れ物に関する情報は一切渡されません
c言語の関数が操作できるのはこの複製された値です
もし入れ物を関数funcで操作したい場合はfunc(&入れ物)と書きます
この場合も&入れ物という値が操作されます
繰り返しになりますがc言語はすべて値渡しなので決して関数に入れ物を渡して解放するなどと言った操作をすることはできません 解放されるのは値です
入れ物の参照を関数に渡すには&入れ物という表記を使いますが&入れ物も値です これは参照呼びと言われますがただの値渡しです
あなたは明らかにプログラミング初心者なのでこのレスが理解できるようになるまでこのスレには書き込まないでください
928:デフォルトの名無しさん
22/02/11 13:27:03.79 MSfgatap.net
>>909
それは君が抽象的なセマンティクスとポインタ等を介するコードの区別が出来ていない初心者だから理解できないのだろう
Rustではこの違いが特に大きいのでその区別を付けることが非常に重要
929:デフォルトの名無しさん
22/02/11 13:43:08.13 UrRCo2Y3.net
>>900
これは同意
何が何を所有してるのかという主語目的語を意識せずに
フワッと分かったつもりになってるからなんだろうね
930:デフォルトの名無しさん
22/02/11 13:45:34.76 HZ9j/fjC.net
次スレはワッチョイ付けたほうが良さそうですね
931:デフォルトの名無しさん
22/02/11 14:02:29.28 m8Gesa51.net
俺は初心者なのでフワッとすら分かっておらず、このスレでは一体何が議論になっているのかよく分からない。
932:デフォルトの名無しさん
22/02/11 14:04:16.80 6AYXkq/G.net
>>910
別に抽象的なセマンティクスでもないよ
君が言っている「入れ物」でさえ操作的意味論的にはアドレスを表す単なる「値」として表現されていることを知るべきだね
ちゃんと理論的にはどのように定式化されているのかを知らないで入れ物だとか言った自分の無知を埋め合わすために勝手に導入したオレオレキーワード使って他の人を困らせてる辺り一向に君は初心者から脱却できないと思うよ
「入れ物」(笑)なんかじゃなくて実際に使われているテクニカルタームを使うことから始めれば？
知らないの？
933:デフォルトの名無しさん
22/02/11 14:05:22.34 6AYXkq/G.net
学術的に使われた用語だからテクニカルタームではないな
934:デフォルトの名無しさん
22/02/11 14:28:40.44 m8Gesa51.net
私は何も知らない。
935:デフォルトの名無しさん
22/02/11 14:35:23.81 05KWrNRV.net
freeに渡すアドレス値を「入れ物」と呼ぶか「値」と呼ぶかでもめているように見える
936:デフォルトの名無しさん
22/02/11 14:44:41.81 6Qn4bKwU.net
>>914
その理解はおかしいよ
例えば
struct S(i32);
struct SS(i32, i32);
let i = 100;
let s = S(200);
let ss = SS(300, 400);
let a = [500, 600, 700];
この時にあなたの理解だと各変数に入っている「値」はアドレスなの？
もちろん生成コードにおいてスタック上のアドレスが用いられるのは事実だけど
Rustというプログラミング言語のレベルではそのアドレスは出てこずに抽象的に捉えるべき話でしょう
937:デフォルトの名無しさん
22/02/11 15:04:06.88 6AYXkq/G.net
>>918
それらの変数にはすべてそれぞれの実体が入っています
アドレスではありません
全ての「アドレス」は「値」ですがだからといって全ての「値」も「アドレス」であるとは言っていません
まずは読解力を身に着けましょう
もっと正しく理解をしましょう
938:デフォルトの名無しさん
22/02/11 15:18:23.74 6Qn4bKwU.net
>>919
では、あなたの主張するアドレスはどこに出てくるの？
let a = [1,2,3];
let v = vec![1,2,3];
どちらもアドレスではないですよね
939:デフォルトの名無しさん
22/02/11 15:28:24.64 6AYXkq/G.net
>>920
失礼しました
配列は先頭要素のアドレスが変数に格納されるでしょう
これだけで済む話です
抽象化なぞそもそも必要とされる余地はありません
940:デフォルトの名無しさん
22/02/11 15:36:10.19 H8NApfSl.net
所有権を持つのは値じゃなく変数
これはいいよね
オライリー本とかは少し違うけど
少なくとも公式は値が別の値を所有するとか
値が別の値の所有権を持つという考え方は採用していない
で解放のほうだけど
解放する対象はメモリ領域であって値でも変数でも無いよね
便宜的に「変数(の指してるメモリ領域)を解放する」とか
「値(が格納されてるメモリ領域)を解放する」という言い方をすることがあるだけ
941:デフォルトの名無しさん
22/02/11 15:46:50.29 MSfgatap.net
>>921
それも違う
配列の先頭要素のアドレスが変数に格納されているわけではない
Rustではもっと抽象的なセマンティクスでプログラミングをするし配列の長さも持つ
942:デフォルトの名無しさん
22/02/11 15:47:39.62 zZVxGVeC.net
値に対する所有権を変数が持つってことなら>>808は特におかしいとは思わないが？
逆に「入れ物」(変数？)に対する所有権とか言っている>>900の方が理解しにくい。
943:デフォルトの名無しさん
22/02/11 15:47:44.62 6AYXkq/G.net
>>922
私は操作的意味論のモデルに乗っかって表現したまでです
操作的意味論ではメモリ領域を示すアドレスは値として表現されています
ある特殊な操作的意味論で定義された理論をベースにしているRustでメモリ領域のことを値だと表現するのは間違っていないでしょう
逆に入れ物や変数だといった表現をこの文脈で使うのは言語道断かと思われます
944:デフォルトの名無しさん
22/02/11 15:51:44.74 6Qn4bKwU.net
>>921
それは違いますよ
そこでアドレスという考え方はしませんし、実装で見ても間違っています
例えばあなたの考えでは以下の4つの変数のうちアドレスとなるのはどれですか？
struct S(i32);
struct SSS(i32, i32, i32);
let i = 100;
let s = S(200);
let sss = SSS(300, 400, 500);
let a = [600, 700, 800];
945:デフォルトの名無しさん
22/02/11 15:54:42.31 6AYXkq/G.net
>>923
すいません
さらに配列の長さも保持しているのならなおさら抽象化のレベルは下がりますよね？
自分が何を言ってるのかわかっておいでですか？
もしかしてRustの抽象化レベルってCよりも下なんじゃないんですか？(笑)
946:デフォルトの名無しさん
22/02/11 16:01:23.79 VlXZAIWT.net
なんでこのスレでは操作的意味論とC言語とRustをちゃんぽんして語ってるの？
みんな器用だね？
947:デフォルトの名無しさん
22/02/11 16:02:15.20 6AYXkq/G.net
>>926
変数という用語も正しくはありません
まず第一にRustでは束縛と呼ばれます
正しく理解してください
それができないならばあなたはこれ以上スレに書き込まないでください
ちなみに私がアドレスだと言っているものはあなたが変数だと言っている物です
そもそもアドレスという表現も不適切なものですが悪しからず
948:デフォルトの名無しさん
22/02/11 16:21:36.51 MSfgatap.net
>>929
ついに馬脚を現したな
Rustでも変数(variable)と呼ぶことすら知らないのか
もちろん束縛(binding)も狭義の代入(assignment)と区別するために用いるが
そこでも束縛や代入の対象は変数である
949:デフォルトの名無しさん
22/02/11 16:32:43.51 6Qn4bKwU.net
>>929
変数という用語で合っていますよ
早く>>926の質問に答えてください
Rustでアドレスという考え方をするあなたが間違っていると明白になりますから
950:デフォルトの名無しさん
22/02/11 16:36:33.29 6AYXkq/G.net
>>930
Rustの用語では束縛の対象は名前です
変数ではありません
Rustが便宜的に変数と使っているのは説明のためにユーザーにRustなりに歩み寄っているからです
あなたが「入れ物」だといったよくわからないキーワードを導入したのと基本的には理由は同じです
操作的意味論では束縛の対象は変数ですが代入の対象は変数ではありません
メモリ上のある位置です
便宜的に言えばアドレスです
再三の忠告になりますが正しい理解が出来ないのであればスレに書き込まないようおすすめします
951:デフォルトの名無しさん
22/02/11 16:45:09.37 6AYXkq/G.net
>>931
i,s,sss,aがアドレスです
まずは>>929を理解する読解力を身に着けてください
> Rustでアドレスという考え方をするあなたが間違っていると明白になりますから
逆にアドレスという考え方をしないのですか？(笑)
手続き型言語の重要な機能ですよ？
ocamlなどと言った非純粋な関数型言語にすらありますが(笑)
アドレスという考え方を他の言語利用者が使うのを許せないのであればこの機能がないHaskellなどをご利用してくださいとしか・・・(笑)(笑)(笑)
Rustには触れないでくださいね😂
952:デフォルトの名無しさん
22/02/11 16:50:42.53 6Qn4bKwU.net
>>933
残念ながら>>926の変数i,s,sss,aに入っているのはアドレスではありません
あなたが完全に間違っています
953:デフォルトの名無しさん
22/02/11 16:56:53.29 6AYXkq/G.net
>>934
変数i,s,sss,aにアドレスが入っているなどと言ってません
読解力も理解力もないんですね
i,s,sss,aは変数ではなくてアドレスという名の値だって言うことを理解できないとあなたはいつまで立っても初心者のままですよ？？(笑)
954:デフォルトの名無しさん
22/02/11 16:59:09.28 6AYXkq/G.net
>>934
間違っているのはあなたです
これで明白になりました
955:デフォルトの名無しさん
22/02/11 17:02:29.35 79iMdFI4.net
なんなんだよこのスレはw
956:デフォルトの名無しさん
22/02/11 17:03:16.70 WRuOVQdn.net
間違いを認めたくないおじさんが延々と言い訳するスレ
957:デフォルトの名無しさん
22/02/11 17:07:13.91 6Qn4bKwU.net
ID:6AYXkq/G氏は
>>919で「それらの変数にはすべてそれぞれの実体が入っています アドレスではありません」
>>921で「失礼しました 配列は先頭要素のアドレスが変数に格納されるでしょう」
これで全く理解できていないことが露呈してからさらに暴走中ですね
>>935
Rustにおいてそれらの変数i,s,sss,aはアドレスではありません
抽象的な考えが苦手ですか？
958:デフォルトの名無しさん
22/02/11 17:13:25.21 4QDnJV3g.net
即値とか知らなさそう
959:デフォルトの名無しさん
22/02/11 17:19:13.64 6AYXkq/G.net
>>939
Rustを含めアドレスという言語機能を持っている手続き型言語で変数と呼ばれているものはただのアドレスです
Rustでいう値が束縛された名前は操作的意味論における変数に対応していてあなた方がいう変数とは操作的意味論におけるアドレスを表現するものの対応物です
本来変数とアドレスは同義のものでc言語の規格で完全にポインタとアドレスが同じものとして扱われ区別されないのと同様に区別する必要性がないものです
現にポインタもアドレスも変数も操作的意味論では区別されていません
このあたりを理解できない限りID:6Qn4bKwUは永遠に初心者のままのようだ🤣
960:デフォルトの名無しさん
22/02/11 17:26:17.96 7ybYem6W.net
cのfreeは値「で」解放してるだけなんだけどなｗ
int *p = malloc(sizeof(int)); // 仮に p = 0x5617ae143260とする
free((int *)0x5617ae143260); // 値でfreeできる
値をfreeしてるわけでもなく
入れ物を解放してるわけでもなく
値をfreeに与えてやってあとはむこうでうまくヒープを解放してくれる
ヒープ解放のきっかけを値で指定してるだけ
961:デフォルトの名無しさん
22/02/11 17:40:06.20 WRuOVQdn.net
内部的には構造体なんだっけか
962:デフォルトの名無しさん
22/02/11 17:42:17.21 VlXZAIWT.net
>>941
横レスだけど
仮にこの世にコンパイラも実行するマシンもなくて、Rustのコードだけが紙に書かれてたとして
それでもi,s,sss,aは変数ではなく、アドレスという名の値だって言い張るの？
具体的にはどういう値なの？
963:デフォルトの名無しさん
22/02/11 17:45:23.35 6AYXkq/G.net
>>944
さあ？
実行するマシンが決まっているなら値はなんでもいいんじゃないんですか？
それこそ文字でも記号でもなんでもいい
その辺りの議論は操作的意味論の教科書で論じられていますよ
964:デフォルトの名無しさん
22/02/11 17:45:40.46 6AYXkq/G.net
決まっていないなら
965:デフォルトの名無しさん
22/02/11 17:56:17.41 VlXZAIWT.net
>>945
なんでもいいの？
書かれているコードが>>926だとして、
iの値が0x5617ae143260で
aの値が0x5617ae143260でもあなた的には問題ないってこと？
966:デフォルトの名無しさん
22/02/11 18:02:50.44 6AYXkq/G.net
>>947
新しいアドレスにはすでに使われているアドレスの値を使ってはいけないという制約は操作的意味論でも目にするでしょう
あなたが熱心に勉強するタイプの人であったなら私のレスを待たずにして自分で調べて自分で疑問を解決していただろうに残念ながらあなたは受動的にしか学習せず一生初心者のままに留まる人間なんでしょうね
967:デフォルトの名無しさん
22/02/11 18:14:14.82 6Qn4bKwU.net
>>942
その通りで、単なる識別子としての「値」で解放しているだけだね
そしてアロケーションライブラリによってはその「値」がアドレス自体でないかもしれない、と
C言語では抽象レベルと具体化レベルがほぼ一致のためアドレスが使われアドレスで考えてもいいけど
多くのプログラミング言語ではその部分は実装レベルに隠蔽されているからアドレスで考えてはよくないね
で、話を戻すと、大元の話ではその「『値で』解放している」かどうかではなくて
「『値を』解放している」のか、「なんらか抽象的な『空間を』解放しているのか」の話だったと認識してる
968:デフォルトの名無しさん
22/02/11 18:27:09.56 VlXZAIWT.net
>>948
ごめん、プログラミング歴20年超えてるんだわ
まあ>>947は意地悪だったけど、何が言いたいかっていうと、
有効なアドレスってのは実行時するかコンパイルしないことには定まらないでしょって話
でも言語仕様っていうのは、コンパイラが存在しなかったとしても存在し得るんだわ
で、他の人は言語仕様の話をしてるけど、一人だけ変数じゃなくてアドレスという値だって言い張るから、
マシンが存在しない状態だとどういう値なのよ？って思ったのね
意地悪なこと書いてごめんよ
969:デフォルトの名無しさん
22/02/11 18:35:25.52 7ybYem6W.net
おまえらって基本マジメなんやろな何か
意見の違いはあれどそんなに嫌いじゃないわ
（ただし複製おじは除く）
970:デフォルトの名無しさん
22/02/11 18:36:53.23 Y4IhV391.net
最適化で消えるようなもんが言語仕様なわけ無いですもんなー
971:デフォルトの名無しさん
22/02/11 18:39:18.92 6AYXkq/G.net
>>949
closeシステムコールはfile descriptorをcloseする
file descriptorでcloseするとは誰も言わない
file descriptorはファイルを参照する値であるがファイル自体ではない
それと同様freeはアドレスという値を解放しているのであってアドレスという値で解放してるとは誰も言わない
「値で解放するの表現が正しい」(笑)って言う意見に耳を傾けるのはまだあなたが初心者を脱することができていない証拠
URLﾘﾝｸ(linuxjm.osdn.jp)
こういうサイトにも「close() は、ファイルディスクリプターをクローズする。」 とある
972:デフォルトの名無しさん
22/02/11 18:51:10.18 XGwZjA15.net
>>951
真面目すぎてひねくれたパターンだろうな
出世もしないで片隅でコード書いてる人よくいるし
973:デフォルトの名無しさん
22/02/11 18:51:59.28 6Qn4bKwU.net
>>952
その最適化で消えるようなもんが言語仕様
例えばRustでは言語仕様で通常の参照ポインタはnullにならない
nullを言語仕様として扱わずNone値を持つOptionを導入にしている
そしてヌルポの先へアクセスすることを完全に封じている、というのが言語仕様
ところがその抽象レベルを離れて実装レベルになると話が違う
愚直にOptionを実装すると参照ポインタ以外にメモリを余分に使う
そこで最適化によってNone時は参照ポインタの実体アドレスを0すなわちnullポインタとしている
これでOption分の余分なメモリを使わずに済ませている
つまり言語仕様としての抽象化されたレベルと
実際にアドレスがどうなるかという具体化されたレベルは常に区別しないといけない
Rustプログラマーとしては実装でどうなるかは知らなくてもプログラミングできる
そしてまずはその抽象的なレベルのみ意識して学習すべき
974:デフォルトの名無しさん
22/02/11 18:58:14.24 GB4mq7wX.net
>>955
こりゃ失敬。なるほど確かにそうだわ。適当な事言いましたわ
975:デフォルトの名無しさん
22/02/11 21:48:20.48 Q/4j6JIT.net
>>925
まーたオジさんいい加減なこと書いてるねw
操作的意味論ではvariableとlocationとvalueを明確に区別するのが一般的
メモリ領域のことを値だと表現するのはRust的にも操作意味論的にも間違い
976:デフォルトの名無しさん
22/02/11
977:21:52:44.45 ID:38j0NNSx.net
978:デフォルトの名無しさん
22/02/11 22:35:25.65 6AYXkq/G.net
>>957
操作的意味論ではそれ以上簡約できない項を値と呼びます
varもlocもどちらもそれ以上簡約できないので値です
試しにTaPLで値ががどのようにBNFで帰納的定義されている集合なのか確認してみたら？
あなたが理解していないだけでは？
979:デフォルトの名無しさん
22/02/11 22:39:32.55 6AYXkq/G.net
>>958
スレ埋めてるのはどちらかというとこのような無意味なレスをするあなたでは？
私は自分のレスが正しいと知っておりますのでどうぞ余計なレスを書き込まないでこのスレを延命してくださいませ
980:デフォルトの名無しさん
22/02/11 22:48:24.70 6Qn4bKwU.net
6AYXkq/Gを相手にしても無駄だから元の話に戻りましょう
>>808について自分の意見は
○「型のインスタンスに所有権がある」
×「値に所有権がある」 ←値は途中で完全に置き変わっても構わないため×
×「変数に所有権がある」 ←変数はどんどん移動できて一時的な束縛にすぎないため×
×「アドレスに所有権がある」 ←アドレスは関数へ渡したり返したり途中で変わるため×
981:デフォルトの名無しさん
22/02/11 23:10:21.43 g7TOVgtJ.net
>>961
「所有権がある」という意味が「所有権を持つ」という意味であれば
「値の所有者は変数」だから「所有権を持つのは変数」だよ
スコープを抜ける時に所有リソースを解放する責任というのかownershipを持つということ
型のインスタンス？
説明してもらわないと意味分からないな
982:デフォルトの名無しさん
22/02/11 23:19:43.49 rRV0mw3H.net
>>961
> 値は途中で完全に置き変わっても構わないため
所有権というのは「後始末する責任」のこと。
内容が書き換えられることを許すのは所有権を手放しているわけではない。
983:デフォルトの名無しさん
22/02/11 23:22:41.86 jgApYu5Z.net
>>961
> 「変数に所有権がある」 ←変数はどんどん移動できて一時的な束縛にすぎないため×
変数は移動できなくない？ 何か別のことを言いたかったんかな？
変数が所有権を持つ、で良いんじゃないかな
値を変数に束縛するときに、変数が値を所有することになる
そして変数が値を所有したままスコープアウトすると、値をdrop(解放)する
984:デフォルトの名無しさん
22/02/11 23:25:49.74 jgApYu5Z.net
「変数が所有権を持つ」よりも、「変数が値を所有する」のほうがいいか
985:デフォルトの名無しさん
22/02/11 23:27:09.03 6Qn4bKwU.net
主語と目的語を逆に違う意味に誤解されるとわかったので補足します
○「型のインスタンスに対して所有権があるor生じる」
×「値に対して所有権があるor生じる」 ←値は途中で完全に置き変わっても構わないため×
×「変数に対して所有権があるor生じる」 ←変数はどんどん移動できて一時的な束縛にすぎないため×
×「アドレスに対して所有権があるor生じる」 ←アドレスは関数へ渡したり返したり途中で変わるため×
>>962
プログラミング言語の分野で一般的に用いられるインスタンスです
型とインスタンスは一般的に1対多の関係になります (シングルトンでは1対1ですが)
言語によっては型をクラスと表現する場合もあるようですがRustではそんな狭い範囲ではなく全ての型が対象です
>>963
そのように値は変わっていくものだから
値に対して所有権といっても曖昧さが残るでしょう
だから不変でない値に対して所有権があるとの考えはよろしくない
まだ>>964の言う変数を持ち出したほうがマシ
しかし変数との関係は一時的にすぎず所有権は別の変数へ移動していきます
所有権と常に1対1の関係にあるのは(型の)インスタンスです
986:デフォルトの名無しさん
22/02/11 23:32:51.77 rRV0mw3H.net
>>964
変数が所有権を持つというのは変な解釈。
結果的にはそういう挙動ではあるんだが
値が変数に捉えられている間は寿命が継続されるというルールによって
変数のスコープと連動してるだけ。
所有権を持っているのはあくまで値。
987:デフォルトの名無しさん
22/02/11 23:37:03.65 6Qn4bKwU.net
>>967
所有権を持っているのはインスタンスであって
値はそのときどきで変化するだけにすぎない存在だと思います
988:デフォルトの名無しさん
22/02/11 23:39:32.68 rRV0mw3H.net
>>968
いいえ。 そんな定義はないです。
989:デフォルトの名無しさん
22/02/11 23:45:01.94 MSfgatap.net
俺が入れ物に対して所有権があると>>900で書いたのも実質その型のインスタンスだ
インスタンスという言葉を使うと面倒になりそうなので抽象的に型の入れ物とした
いず�
990:黷ﾉせよ所有権の対象は値ではなく値が収容される入れ物orインスタンスだ
991:デフォルトの名無しさん
22/02/11 23:45:21.67 rRV0mw3H.net
実際のところ「値」と「インスタンス」の間にそんなに意味の差はないです。
特的の型を元に作られたということを強調するときにインスタンスと言うことはありますが、
どの値も型を持つのでインスタンスではない値などありはしません。
992:デフォルトの名無しさん
22/02/11 23:47:31.44 6Qn4bKwU.net
>>971
インスタンスはその型の形をした器(うつわ)であり解放されるまで不変
値はその器(うつわ)に入った内容にすぎず可変
993:デフォルトの名無しさん
22/02/11 23:48:11.08 rRV0mw3H.net
>>972
いいえ。 繰り返しますがそんな定義はないです。
994:デフォルトの名無しさん
22/02/11 23:49:47.15 3qua/k5E.net
>>967
＞所有権を持っているのはあくまで値。
で、その値は何の所有権を持ってるのさ？
995:964
22/02/11 23:51:18.52 jgApYu5Z.net
そもそも「所有権を持つ」ってのが苦しい
英訳すると "own the ownership" になってしまうが、そんな表現は公式ドキュメントでも避けられてるように思う
値が変数に束縛されるとき、その値を変数が所有することになる
変数をreturnしたり、変数を他の変数に代入するときには、所有権がtransferされることになる
ここまでは良いでしょ
例えば、公式ドキュメントにもこう書かれてる
URLﾘﾝｸ(doc.rust-lang.org)
> Returning values can also transfer ownership.
なので、強いて >>961 の中から選ぶなら変数が所有権を持つだけど、最初に書いたようにそもそも「所有権を持つ」が苦しいので、
「変数が値を所有する」とすれば良いと思う
996:デフォルトの名無しさん
22/02/11 23:51:21.22 3qua/k5E.net
>>965
＞「変数が値を所有する」
これが正解。
997:デフォルトの名無しさん
22/02/11 23:51:57.38 MSfgatap.net
>>973
皆がその点については定義がはっきりしないからこれだけ揉めてるんだろ
「そんな定義はないです」は反論にすらなっていない
998:964
22/02/11 23:53:29.17 jgApYu5Z.net
ああ、別に「持つ」を必ずしも "own" で訳す必要もないね
さっきから変なことばかり書いててすまんね、今日は冷静になっていったんもう寝る
999:デフォルトの名無しさん
22/02/11 23:54:02.65 rRV0mw3H.net
>>974
値自身を後始末する責任をもってる。
所有権という訳語がよくないというのはよく指摘されることだが、
何者かが値を所有しているという誤解のもとになるからだ。
変数が所有権を持っていることにしたら
一時オブジェクトの所有権はどうなってんだって話になるだろ。
1000:デフォルトの名無しさん
22/02/11 23:57:48.33 6Qn4bKwU.net
>>975 >>976
そんな話は誰もしていないと思う
所有権は何に対して付随するのか生じているのかが論点
そして所有権が消滅するのは型のインスタンスが最後に解放される時
だから所有権と1対1の関係にあるのは(型の)インスタンスだと主張しています
1001:デフォルトの名無しさん
22/02/12 00:03:26.33 mURtvSsP.net
>>972
> インスタンスはその型の形をした器(うつわ)であり解放されるまで不変
いいえ。
代入で内容が書き換えられる場合もあり、
そのときに drop が呼ばれます。
寿命の管理は値に付随します。
1002:デフォルトの名無しさん
22/02/12 00:19:59.58 kNBFVDwU.net
とりあえずbookの
4.1. What is ownership?
（URLﾘﾝｸ(doc.rust-lang.org)）
から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）をもつ
・所有者は同時に１つしか存在しない
・その所有者がスコープからいなくなる時、その値は破棄される
1003:デフォルトの名無しさん
22/02/12 00:26:03.97 lHDa3hl7.net
>>982
これが正解
1004:デフォルトの名無しさん
22/02/12 00:26:42.42 /iL1/Dd6.net
>>981
内容が書き換えられてdropすることはない
所有権と値は関係ない
値に付随するものではない
>>982に明記されているように所有権を持つ所有者は変数
所有者である変数がスコープから外れるとdrop
1005:デフォルトの名無しさん
22/02/12 00:31:23.69 FSqSWy2H.net
>>982
だよなぁ。「入れ物」とか妙ちきりんな説明する人はなんなんだろう？
1006:デフォルトの名無しさん
22/02/12 00:37:10.88 /iL1/Dd6.net
インスタンスというのも一理ある
その型のインスタンスが作られてから解放されるまで一貫して一つの存在なのに対して
変数は次々と移り変わって行く乗り物と捉えることができる
そしてインスタンスがたまたま束縛されている変数がスコープから消えると乗っていたインスタンスも巻き添えで消えると考えられないこともない
1007:デフォルトの名無しさん
22/02/12 01:06:37.82 Q5zckJeE.net
>>980
スレ立てヨロ
1008:デフォルトの名無しさん
22/02/12 01:26:58.40 aHobc4uM.net
次スレ
ｽﾚﾘﾝｸ(tech板)
1009:デフォルトの名無しさん
22/02/12 01:32:16.48 /iL1/Dd6.net
>>988
GJ
1010:デフォルトの名無しさん
22/02/12 01:58:18.50 eWE5dZha.net
横からすまんが、実際のメモリ上だと所有権ってどうなってるもんなの？
>>982にある仕組みからしたら・・・・メモリが確保されるのと同時に、併せて所有権情報（スタックへの参照か何か？）がメモリのどっか確保されるわけ？
俺、てっきりコンパイラへのただの指示だとばっか思ってたぜ
1011:デフォルトの名無しさん
22/02/12 02:19:56.25 dWh4TlR2.net
横からキターーー
コンパイラの課すルールの話なので
所有権情報が実行時にメモリに確保されたりしないよ
1012:デフォルトの名無しさん
22/02/12 04:01:34.21 tNCVqmWf.net
まじか、そうなんだ
1013:デフォルトの名無しさん
22/02/12 06:46:04.75 zeKxBusw.net
ワッチョイ無しか、次スレも荒れそう
1014:デフォルトの名無しさん
22/02/12 07:47:32.16 XghCcbPA.net
struct S;
impl Drop for S {
fn drop(&mut self) {
println!("drop");
}
}
fn main() {
S;
}
↑じゃあこれは何が所有権をもってて何がdropさせてんの？
インスタンス説のほうがまだシックリくる？
変数も所有権を持てるしスコープ終了で手放せる？
1015:デフォルトの名無しさん
22/02/12 08:42:47.12 4ZF6L5uh.net
>>961
お前が突っかかって来たんだろうが
ガイジｗｗｗｗ
1016:デフォルトの名無しさん
22/02/12 08:42:55.77 4ZF6L5uh.net
うんこ
1017:デフォルトの名無しさん
22/02/12 08:43:01.75 4ZF6L5uh.net
まんげ
1018:デフォルトの名無しさん
22/02/12 08:43:06.69 4ZF6L5uh.net
ちんげ
1019:デフォルトの名無しさん
22/02/12 08:43:39.79 4ZF6L5uh.net
>>957
お前の負けやでｗｗｗｗｗｗｗｗ
1020:デフォルトの名無しさん
22/02/12 08:44:18.55 4ZF6L5uh.net
無教養のガイジども阿鼻叫喚していて草ｗっｗｒ
ンゴｗｗｗｗｗｗｗ
1021:1001
Over 1000 Thread.net
このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 96日 22時間 39分 19秒
1022:過去ログ ★
[過去ログ]
■ このスレッドは過去ログ倉庫に格納されています