Rust part13

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

---

---

[ 新着レスの取得/表示 (agate) ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef