22/01/04 22:53:03.36 NZNEJALT.net
特殊な案件でしかGCを使うことはないため
その場合は汎用GCライブラリ利用よりも
データ構造とアロケーションとGCを密に設計する方がベターかも
453:デフォルトの名無しさん
22/01/05 00:28:17.64 GzN74lxE.net
ちゃんとしたスマートポインタを自作する時点で結構大変だから用途特化した方が確かによさそう
454:デフォルトの名無しさん
22/01/05 01:03:11.75 o/mlVe5X.net
グラフみたいなデータ構造を実装するだけでも、GCが必要になったりするもんなん？
455:デフォルトの名無しさん
22/01/05 01:37:16.98 hbslRCuW.net
>>441
ありがとうございます！
456:デフォルトの名無しさん
22/01/05 01:46:20.36 yOKwmyBj.net
グラフ構造表現するだけならArenaや、少し安全にするならGenerationalArenaで事足りるかと
copy GC的なものが必要になるのは大量にノードを作成してほとんど削除、一部残存みたいな状況でfreeできないArenaが残ってしまうケース
457:デフォルトの名無しさん
22/01/05 04:00:13.07 6kre97ZR.net
ちゃんとしたGCはないのに、参照カウントだけは標準ライブラリに入っていて循環参照には気をつけましょうねーって運用でカバーなのはなんか中途半端なものを感じる
そもそも参照カウントなんてGCとしてはかなりイケてない部類なのになんで参照カウントなんだ気持ちもある
458:デフォルトの名無しさん
22/01/05 04:09:37.27 VoX97L81.net
単純にRcやArcはGCを目的としたものではないから
459:デフォルトの名無しさん
22/01/05 06:50:20.96 wTheSKj8.net
分かってる風で語るのはカッコ悪いね
460:デフォルトの名無しさん
22/01/05 07:42:18.23 jCayWhDI.net
単なるスマートポインタをGCと言っちゃうあたり・・・
あれは単にRAIIでヒープを処理してるだけのことであって
わざわざGCと呼ぶような大したもんではない
461:デフォルトの名無しさん
22/01/05 07:48:16.03 yhx54h3v.net
9分で轟沈したのに２時間後に死体蹴りせんでも。
LLVMにレジスタとスタック使わないよう教える術がないし
rustは意地でもスタックに置きたがるしplacement系が削除されたから保守的になるよね。
実際、保守的gcってどれくらい回収できんの？
462:デフォルトの名無しさん
22/01/05 07:52:39.60 /PNLes9I.net
>>449
即時解放がやりやすい＆実装が簡単だから、だろ。
そういう説明をしないで>>452とか言うやつはRust普及の足を引っ張っているだけだから、書き込みしないほうがいいと思う。
463:デフォルトの名無しさん
22/01/05 08:39:25.19 yhx54h3v.net
>>454
>>450の言う通りrustのreference counting gcは
メモリ管理のためではなく共有された参照を数えるためのもので
シングルスレッド用のRcがあるのはrustがaffine typeだから
共有された可変を認めないからで、ついでに>>452の言うことも半分あってるよ。
rustは自動参照カウントにRAII併用するけどgcのない言語しか経験がない人が
gcをスマートポインタと混同するのもよくある事。
あと、rustの参照カウンタは弱参照があるから循環参照が切れる代わりに
単純な参照カウンタのオーバーヘッドが少ない・開放されるタイミングが
予測可能というメリットはないからrustが参照カウンタを用意する
メリットは>>450が指摘したものしか無いよ。
464:デフォルトの名無しさん
22/01/05 09:30:04.08 HAtvMNOo.net
学問的には参照カウントはGCの一方式として分類されるのが普通だよ
まあなんの前置きもなくGCといったらトレーシングGCがイメージされるというのもその通りだが
RcがGCだと言っても間違ってるということはない
RustのstdにトレーシングGCがないのは、単に標準ライブラリを大きくしない方針に従ってるだけじゃない？
本格的なGCが必要なケースは限られるし、外部クレートで十分と思うが
465:デフォルトの名無しさん
22/01/05 09:44:11.20 l0gfYUX+.net
いつものやつホント気持ち悪いな
466:デフォルトの名無しさん
22/01/05 12:11:20.98 g7d2BHp/.net
>>457
コテハンつけるかID変えないならまだいいんだけどな
467:デフォルトの名無しさん
22/01/06 01:29:23.74 Izanmpcc.net
気持ち悪さは長文から来る。reference counting gcとかわざわざ参照カウントを英文で書いてカッコつける所も
減点項目。個人の主観的には文中に>>を挟む特徴が読み手の事を一切考えないオナニーに見える
468:デフォルトの名無しさん
22/01/06 08:00:17.28 AA9pZn/O.net
それあなたの感想ですよね
469:デフォルトの名無しさん
22/01/06 08:47:42.41 zkS6fEay.net
文中に >> 挟むのだめなのか
どのレスのこと指してるのか明確になって良いと思うが
470:デフォルトの名無しさん
22/01/06 09:03:44.55 8b5imbdG.net
>>レス番
↑これで引用先に飛べるリンクが張られるの知らなさそう
5chにPCからアクセスしたり
専用ブラウザからアクセスしたときそうなってるのよ
471:デフォルトの名無しさん
22/01/06 10:12:38.67 soGE7KAW.net
Rustのメモリ安全性ってどうやって保証してんの？
テスト？
472:デフォルトの名無しさん
22/01/06 11:33:54.14 Djcmy5st.net
>>462
君はHTML知らなそうw
473:デフォルトの名無しさん
22/01/06 16:21:52.81 a887VGZI.net
ダメというわけじゃないが、同じ人が言ってるわけじゃないのに文中に一つにまとめて自分の考えだけを
長々と話している時点で意味わからん、リンクの話じゃない。気持ち悪さがどこからくるかという話。
感想といえばその通りで、個人的な主観と言ってるが多くの人はそう感じるのはこうではないか？という話
474:デフォルトの名無しさん
22/01/06 17:27:19.44 Gs63EiHG.net
長いから3文字にまとめて😪
475:デフォルトの名無しさん
22/01/06 17:28:58.84 fX6pq/OF.net
>>465
Rustスレで学級会始めるおまえも気持ち悪いよ
476:デフォルトの名無しさん
22/01/06 17:49:08.32 AA9pZn/O.net
>>がリンクにならない環境を知らんのだが
477:デフォルトの名無しさん
22/01/06 18:13:44.84 jbChckmf.net
>>465
よくわかる
いつも中身ないので即NG
だがやつは自演魔なんでマジタチ悪い
478:デフォルトの名無しさん
22/01/06 21:11:27.35 Q5dnJVm5.net
>>469がいつものキチガイの典型例
文句をつける意味不明な書き込みをしてその後に自演で同意のレスを付けてくる
スレを荒らすことが目的
479:デフォルトの名無しさん
22/01/06 22:28:23.35 s+xoikwS.net
お前らが誰と戦ってるのか
正直理解できない
480:デフォルトの名無しさん
22/01/06 23:39:45.17 ZA0J9QW6.net
このスレ常駐の荒らしは以下の特徴があるから無視すればよい
「気持ち悪」「ゲロ」「汚」などの言葉を好む
別案・別情報・別解釈などを具体的に出せず文句を付けるだけ
そのような無意味な書き込みになぜか賛同レス
481:デフォルトの名無しさん
22/01/06 23:48:00.39 NzY/+9uF.net
などと>>455氏が言っており
482:デフォルトの名無しさん
22/01/07 00:34:18.06 QTrF6/lG.net
・
483:デフォルトの名無しさん
22/01/07 00:34:18.20 cXPu1ueH.net
>>463
コンパイル時にチェックされるものと実行時にチェックされるものがあるよ
多くの場合は前者で済むけど、可変参照を複数箇所で共有したい場合は後者が必要になる
484:デフォルトの名無しさん
22/01/07 01:59:05.78 QJvziKfk.net
キモいと思うレスは黙ってNGしといてこれやるといいよ
URLﾘﾝｸ(dtolnay.github.io)
Rustの文法はもうバッチリと思ってる人向け
重箱の隅をつつく問題なんだけどすごく勉強になる
485:デフォルトの名無しさん
22/01/07 03:03:06.42 7ncHJZDo.net
クソむずい
486:デフォルトの名無しさん
22/01/07 08:11:58.75 AAqP4BQM.net
c++の悪いとこばっか真似してどうすんの。。
487:デフォルトの名無しさん
22/01/07 08:58:17.17 3q+e3WNv.net
>>475
コンパイル時のチェックって結局人手で書いたコードによるチェックなんでしょ？
ということは担保は単体テストってこと？
488:デフォルトの名無しさん
22/01/07 09:16:18.88 3w3matv0.net
>>479
実行時じゃなくて？
489:デフォルトの名無しさん
22/01/07 09:25:48.12 9KLybwvT.net
そもそもだかマシン語でみりゃ
メモリに型もなんもないよｗ
単なるバイトだらけ
コンパイルの段階で変なコードか
けないようにしてるだけ
でもこれだとぬるぽ！が回避できないので
仕方なく仕組み入れたのがRustでしょ
490:デフォルトの名無しさん
22/01/07 10:01:43.31 FjJ2oZu9.net
Rust書くときは常にIDEに直してもらいながら書いてるから>>476みたいなの全然解けないわｗ
491:デフォルトの名無しさん
22/01/07 10:06:26.42 27W+wb2V.net
>>476
確かにこれは勉強になる
知らなかったことばっかり
492:デフォルトの名無しさん
22/01/07 10:10:35.06 FVraLxVf.net
Rustのメモリ安全って、null安全のことだったの？しょぼ
493:デフォルトの名無しさん
22/01/07 10:57:05.72 9qeGIYdY.net
>>479
コンパイラのコードのこと？
安全性の保証に形式的証明を与えようという取り組みはあるけどコンパイラの実装が正しいかはコンパイラのテスト頼りだね
URLﾘﾝｸ(plv.mpi-sws.org)
494:デフォルトの名無しさん
22/01/07 11:28:53.58 9KLybwvT.net
「Rustは安全でも難しい」といわれる理由―メモリ安全を実現する「所有権」の仕組み
URLﾘﾝｸ(atmarkit.itmedia.co.jp)
495:デフォルトの名無しさん
22/01/07 12:00:56.69 24FxYl/s.net
>>486
初心者向けにわかりやすく解説しようという試みは評価するが
間違いが多すぎて萎える
ここで初心者の質問に回答してる初心者と同じ
496:デフォルトの名無しさん
22/01/07 12:22:15.55 9qeGIYdY.net
>>487
例えばどこが間違ってるの？
497:デフォルトの名無しさん
22/01/07 18:09:24.83 KzGvgOV1.net
>>488
整数型や浮動小数点型といったスカラー型の変数は、変数間の代入において所有権は基本的に複製されます。これを「所有権の複製（コピー）」といいます。変数間の代入などにおいて所有権は複製されるので、値の所有者は常に1個でなければならないというルールは守られます。
498:デフォルトの名無しさん
22/01/07 19:34:39.40 9qeGIYdY.net
>>489
正しいこと言ってるように見えるけど
どう間違ってるの？
499:デフォルトの名無しさん
22/01/07 19:39:44.12 pFd15XiZ.net
所有者が無能だったら終わりです
500:デフォルトの名無しさん
22/01/08 00:17:04.62 GxMqZbIC.net
所有権が複製されるって表現はなんかRcを想像してしまうな
501:デフォルトの名無しさん
22/01/08 00:19:22.76 tLJ6VgIA.net
整数型とかの単純のヤツはCopyだかCloneだかをderiveしててデフォのmove semantics機能してなかった気がするな
最近書いてねぇから忘れてんなこれ(´・ω・｀)
502:デフォルトの名無しさん
22/01/08 06:57:19.85 5x1u92SJ.net
数値型が特別扱いされているわけではない
Copy traitを実装すればcopyされる
Copy traitを実装しなければmoveされる
503:デフォルトの名無しさん
22/01/08 23:30:01.75 lz8RPHEi.net
Copyで複製されるのは所有権じゃなくて値だよね
代入先の変数が複製された新しい値の所有権を持つことになるけど、所有権が複製されるんじゃあない
504:デフォルトの名無しさん
22/01/09 16:14:36.11 uxfV5OFq.net
copyだけでなくmoveされるのも対象は値
所有権ではない
値をmoveした結果
値に紐付く所有権がくっついてくる
505:デフォルトの名無しさん
22/01/09 16:51:12.42 TifKF/RV.net
値と同時に所有権 "も" copy/moveされると捉えることもできるのでは
506:デフォルトの名無しさん
22/01/09 18:01:55.54 yd7evZmg.net
個人的に間違った捉え方をするのは自由だが
それを初心者に広めるのはやめていただきたい
507:デフォルトの名無しさん
22/01/09 18:56:17.00 KYx55eM0.net
あんたらのお仲間他スレで暴れてばかりだよ、引き取りに来い
508:デフォルトの名無しさん
22/01/09 19:06:20.22 EvEIewTi.net
これ結構いいな
概出？
URLﾘﾝｸ(docs.microsoft.com)
509:デフォルトの名無しさん
22/01/09 19:18:00.80 n32zl2Pe.net
所有権が複製できちゃったら｢一個の値に一個の所有者｣ってルールが守れないやん(´・ω・｀)
510:デフォルトの名無しさん
22/01/09 20:01:19.31 wa3WbZ82.net
所有権を持っていると年2回の配当金がもらえます
511:デフォルトの名無しさん
22/01/09 20:12:54.12 ASvenOj7.net
しょーゆー拳!
512:デフォルトの名無しさん
22/01/09 20:17:43.06 QVmVQA75.net
>>492
> 所有権が複製されるって表現はなんかRcを想像してしまうな
URLﾘﾝｸ(doc.rust-lang.org)
> The type Rc<T> provides shared ownership of a value of type T
shared ownershipという表現でうまく説明できててrustっていいなと思う
513:デフォルトの名無しさん
22/01/09 20:20:09.14 Yd6TUYc2.net
というかCあたりの関数の引数も
コピーじゃなかった？
中身を渡した先でもいじらせる場合とかは
ポインター渡しとかなんかやってた記憶
514:デフォルトの名無しさん
22/01/09 21:35:14.41 f6gH817b.net
大半の言語はデフォルトで値渡しだよ
515:デフォルトの名無しさん
22/01/09 21:41:43.59 QVmVQA75.net
Cでポインタ型の値を渡してるだけのことを
参照渡しと言っちゃう害悪がネットにチラホラ残ってて悲�
516:ｵい ポインタ渡しとかいうすっとんきょうな用語も必要性を感じない Javaで単に参照型変数の値を渡してるだけのことを 参照渡しと言っちゃうのも割りとあって悲しい
517:デフォルトの名無しさん
22/01/09 21:57:11.88 DflwLcIO.net
>>501
そう捉えるのが普通だよな
518:デフォルトの名無しさん
22/01/09 22:12:54.92 tE6q+RNQ.net
>>501
値が複製された場合なら問題ないんでないの？
519:デフォルトの名無しさん
22/01/09 22:21:03.82 uOSYnK8a.net
Rustは非常にシンプルで
Copy traitが実装されていない型は値と所有権がmoveされる
Cooy traitが実装されている型は値がcopyされてその値に新たな所有権が生じる
もちろんそれを所有権と値が複製されたとみてもよい
ちなみにRcは所有権の複製ではなく所有権の共有
520:デフォルトの名無しさん
22/01/09 22:28:10.17 ec1b4GYb.net
「所有権とは、文字通り変数が値を所有できる権利のことです。」
ふむふむ
「スカラー型の変数は、変数間の代入において所有権は基本的に複製されます。これを「所有権の複製（コピー）」といいます。」
ふむふむ・・・
「変数間の代入などにおいて所有権は複製されるので、値の所有者は常に1個でなければならないというルールは守られます。」
・・・は？
元の値を所有できる権利を複製したんじゃなかったの？
521:デフォルトの名無しさん
22/01/09 22:37:27.87 uOSYnK8a.net
>>511
所有権と値は必ずセットで複製される
当たり前だが片方だけが複製されることはありえない
必ず1対1の関係になる
ちなみにRcの場合は所有権は複製されずに所有権の共有となる
522:デフォルトの名無しさん
22/01/09 22:41:22.81 zMIZ+Krn.net
>>511
>変数が値を所有できる権利のこと
"所有できる権利"という捉え方が良くないね
523:デフォルトの名無しさん
22/01/09 23:30:44.08 enp/nJFU.net
>>489
所有権だけが複製されるわけじゃないし、たしかに不自然だな
524:デフォルトの名無しさん
22/01/10 00:03:57.12 x5u3TTyT.net
>>509
複製された
525:(結果的に値は同じだけどメモリ上の位置は異なる)新たな値に対する新たな所有権を｢所有権が複製される｣って表現するのはおかしいべ？ >>510 そこよく勘違いされてるけど値自体はCopyトレイトと関係なく常に複製されてるよ(最適化で除かれるとかは別として) https://doc.rust-lang.org/std/marker/trait.Copy.htmlに全部書いてあるけど Copyな型は｢プリミティブ型みたいに単純にメモリの内容を複製するだけでオッケー=copy｣ 非Copyな型は｢ポインタとか含まれてたりして単純にメモリの内容を複製するだけだとNGな可能性があるから古い方は使えなくするよ=move｣ ってだけ
526:デフォルトの名無しさん
22/01/10 11:29:11.88 0oVbzL+8.net
>>515
ルールを守れるか守れないかという話。
表現としておかしいかどうかは結論なんて出せないんじゃね？公式ドキュメントででも謳ってない限り。
527:デフォルトの名無しさん
22/01/10 20:14:15.89 tVKp4zEB.net
著者のバックグラウンド見る限りC/C++の経験があるオレならRustも分かっちゃうよ？みたいな連載だから表現が慣れてなくても気にしない
監修もRustの人っぽくなさそうだし…多分、関数型の語彙が無いんじゃないかね
528:デフォルトの名無しさん
22/01/10 20:29:16.07 DRRBVfd3.net
うんこ言語を好意的に連載してる記事をこき下ろす性格の悪いRusterが集まる駄スレ
529:デフォルトの名無しさん
22/01/11 03:16:23.27 DWOD4ihn.net
>>515
> そこよく勘違いされてるけど値自体はCopyトレイトと関係なく常に複製されてるよ(最適化で除かれるとかは別として)
>
> URLﾘﾝｸ(doc.rust-lang.org)に全部書いてあるけど
へー、なるほど、いろいろ納得したわ
530:デフォルトの名無しさん
22/01/11 11:05:54.30 U35zy9ok.net
>>518
だよなぁ。
誰か筆者に指摘した？
あと、「所有権の複製（コピー）」はRustだと実際は何て言ってるの？
531:デフォルトの名無しさん
22/01/11 12:25:22.53 yQgVkZD8.net
｢所有権の複製｣でググってもほぼ誰も使って無い用語で草
532:デフォルトの名無しさん
22/01/11 12:27:41.85 zYBpR5AJ.net
所有権だけをすることなんてないだろうし、そんな言葉なくね
そもそも意味わからん
処理系を実装してる人にとっては考えることかもしれんが
533:デフォルトの名無しさん
22/01/11 12:28:11.69 zYBpR5AJ.net
所有権だけを複製すること、の間違い
534:デフォルトの名無しさん
22/01/11 21:25:05.09 On+Ztxm9.net
まあ無駄にややこしいだけの説明だわな。
これで間違ってない！とか意地張るような輩は俺だったら落とすわ。
535:デフォルトの名無しさん
22/01/11 21:31:59.06 xKqG3MQU.net
どっちに解釈しても問題ない話の一方に固執する方がお断りだな。
536:デフォルトの名無しさん
22/01/11 22:00:42.75 7fHp9GHd.net
所有権の複製の意味が分からん
不用意に独自用語使うのを野放しにしちゃいけない
専門用語とその定義がなぜあるのかを考えて欲しい
537:デフォルトの名無しさん
22/01/11 22:43:07.52 2061HgWk.net
>>519
実際に生ポインタ(アドレス)を見る形で実験したところ
「関数に値渡し(≠参照渡し)する」時は
「Copy trait実装の有無」に関係なく
「必ず値は複製されている(＝別アドレスになる)」という
よく考えれば当たり前の挙動となった
つまり話をまとめると
・Copy trait実装の有無と関係なく「値は必ず複製される」
・Copy trait実装がある時は「所有権も複製される」
・Copy trait実装がない時は「所有権は移動する」
これ以外に表現しようがないことがわかった
538:デフォルトの名無しさん
22/01/11 23:09:26.60 On+Ztxm9.net
メモリ上の動きと言語上のルールの違いもまともに理解してなさそうな連中だな。
539:デフォルトの名無しさん
22/01/11 23:49:06.82 t1MM9BO+.net
mutの時に書き換えると元の値と別の値に出来るのだから新たな所有権が生じているのは事実
あとは、所有権の複製、という表現の問題
間違ってはいないが理解しにくいならば別の良い表現で置き
540:換えればよいが何がいいだろう？
541:デフォルトの名無しさん
22/01/12 00:52:45.70 1lKX/EK6.net
値が複製されるのに伴って新たな所有権が生成される
542:デフォルトの名無しさん
22/01/12 08:45:55.15 zdKxvEH9.net
ムーブの場合は元の所有権が破棄されて新たな所有権が生成される
543:デフォルトの名無しさん
22/01/12 10:38:50.42 uD0wFQGQ.net
値を複製したらメモリの領域が別なのに｢所有権の複製｣は何を複製すると思ってんだろ
544:デフォルトの名無しさん
22/01/12 18:27:19.23 5pTy1wN9.net
>>532
さっぱりわからんよな
>>529
> 間違ってはいないが理解しにくいならば
何言ってんのコイツ？
545:デフォルトの名無しさん
22/01/12 21:24:46.00 zdKxvEH9.net
全く同じものを新しく生成するのと複製は外から見て区別しようがないんだから
546:デフォルトの名無しさん
22/01/12 22:30:30.00 y9ayzVSo.net
所有権はコンパイル時のはなし
メモリの動きは実行時のははし
547:デフォルトの名無しさん
22/01/12 23:21:45.30 mVKgaRWA.net
セマンティクスの話をしろ
548:デフォルトの名無しさん
22/01/12 23:51:37.77 DMKGOQqO.net
現実世界の所有権が複製可能な権利だったのなら
複製されると勘違いする人がいても不思議はないが・・・
549:デフォルトの名無しさん
22/01/13 08:49:48.70 +PFReeTS.net
質量保存則に縛られる現実世界の複製との対比には限界があるわな。
550:デフォルトの名無しさん
22/01/13 10:12:58.78 8S0jzhzB.net
権利のような無形物は質量保存則には縛られない
Borrow Checkerが課すルールをわかりやすく説明するためのメタファーとして
現実世界の所有権という概念を借りてきてるのに
そのメタファーを分かりにくくするエクストリームなルールを勝手に追加して広めるのはやめよう
551:デフォルトの名無しさん
22/01/13 10:57:22.74 VN3LqOp5.net
URLﾘﾝｸ(users.rust-lang.org)
なんか同じようなやり取りして同じように最終的にグダグダなまま閉じてて草
552:デフォルトの名無しさん
22/01/13 11:03:58.63 4F526BmN.net
というかRustの実装のところ見ればいいんじゃね？
仕組みのコードはあるだろうし
553:デフォルトの名無しさん
22/01/13 11:11:48.72 0M0jmEeK.net
見るまでもないだろw
554:デフォルトの名無しさん
22/01/13 12:20:30.48 k/BdCeDW.net
URLﾘﾝｸ(doc.rust-lang.org)
ここでは所有権が移動される(the ownership of the resources is transferred)とあるから
ここからの類推で所有権の複製という言葉が出てきたのかな
555:デフォルトの名無しさん
22/01/13 12:30:05.91 H8cLP4dt.net
Ownershipを所有権と訳したから
「所有権とは、文字通り変数が値を所有できる権利のことです」
という間違った解釈がされて
さらには「所有権の複製」なんていうトンデモ説が出現しちゃう
556:デフォルトの名無しさん
22/01/13 14:09:36.75 O06YpWsI.net
>>543
ownershipが所有権ならtransferは譲渡
move(移動)とは明確に使い分けられてる
557:デフォルトの名無しさん
22/01/13 14:28:13.33 LRlvXHH5.net
結局はどこにも原典がないオレオレ用語でワロタ
技術は研鑽していかないといけないのに
ポエムと独自解釈と拡大解釈によって逆方向に突き進むボンクラ
558:デフォルトの名無しさん
22/01/13 15:21:48.48 4OU2rK55.net
まぁ、オープンソースですらねぇし専門家の目すら通ってない様なサイトだし
それっぽい事書いときゃいいんだよってのが大抵のweb界隈
itで何か知りたいなら手っ取り早い話公式ドキュメント当たれって事だろ(´・ω・｀)
559:デフォルトの名無しさん
22/01/13 15:31:14.25 iHsQmzfW.net
それでわかりやすくなるんなら別にいいけど、余計わかりにくくしてるってさぁ。。
560:デフォルトの名無しさん
22/01/13 15:55:36.32 k/BdCeDW.net
>>545
URLﾘﾝｸ(doc.rust-jp.rs)
修正のpull req出しておいて
561:デフォルトの名無しさん
22/01/13 16:12:14.47 VN3LqOp5.net
ルー語で言うと｢ownershipがtransferされることをmoveって呼ぶ｣的な？
562:デフォルトの名無しさん
22/01/13 16:19:48.57 VN3LqOp5.net
this is known as a move.
英語のほうだと｢ムーブとして知られています｣か
実際コンパイラのソースみてもownershipはtransferとかtakeっていう表現でmoveだのcopyとは言ってないね
563:デフォルトの名無しさん
22/01/13 16:53:50.81 qAhzUFbZ.net
>>549
公式リファレンスくらいは英語で読もうよ
そんな変なサイト見てるからOwnershipの意味すら取れなくなるんだぞ
564:デフォルトの名無しさん
22/01/13 17:08:41.31 2BXAobev.net
>>552
それは変なサイトではなくRust公式ページの日本語訳。
元のRust公式ページでも同様。
Ownership and moves
URLﾘﾝｸ(doc.rust-lang.org)
Because variables are in charge of freeing their own resources,
resources can only have one owner.
This also prevents resources from being freed more than once.
Note that not all variables own resources (e.g. references)
When doing assignments (let x = y) or passing function arguments by value (foo(x)),
the ownership of the resources is transferred.
In Rust-speak, this is known as a move.
565:デフォルトの名無しさん
22/01/13 17:27:36.08 W1ZKAEcb.net
>>553
Google翻訳にかけてごらんw
主語も目的語も受動態の意味もわかってないような翻訳はゴミ
566:デフォルトの名無しさん
22/01/14 00:21:00.58 hAOjwXhX.net
DeepL で翻訳してみた
なぜなら、変数は自身のリソースを解放する役割を担っているからです。
リソースは一人のオーナーしか持つことができません。
これはまた、リソースが複数回解放されるのを防ぐためでもあります。
すべての変数がリソースを所有するわけではないことに注意してください（例：参照）。
代入（let x = y）や関数の引数を値で渡す場合（foo(x)）。
リソースの所有権は移転する。
Rustの用語では、これを「移動」と呼びます。
567:デフォルトの名無しさん
22/01/14 00:30:32.83 hAOjwXhX.net
「所有権の複製」とか、意味の分からない事を書いている、香具師がいるのか？
568:デフォルトの名無しさん
22/01/14 00:36:35.57 kUhlpB/h.net
>>556
!Copyの場合は所有権がtransferされるのであれば
Copyの場合はどう表現すべきかという話
569:デフォルトの名無しさん
22/01/14 02:45:20.76 InXswW/0.net
>>557
元の値の所有権はそのまま、複製された新しい値の所有権が新しく発生する。
元の値の所有権について何も操作は行われておらず、表現すべきことも無い。
570:556
22/01/14 03:32:18.88 hAOjwXhX.net
所有権が複製されるという書き方よりも、むしろ、
primitive を含むコピー型変数は、コピーされると、
所有権は移動しないので、元の変数にもアクセスできる、みたいに使う
コピーされると新たに、別のオブジェクト(実体・メモリ領域)と所有権が作られるとか
571:デフォルトの名無しさん
22/01/14 08:35:26.86 8BRe3wDd.net
- 所有権ごと複製するという表現がわかりやすいかわかりにくいか⇒人それぞれ
- 所有権を複製するという表現が逆になにか問題を生ずるか⇒今のところ挙げられてない
572:デフォルトの名無しさん
22/01/14 08:46:30.94 y5w5F0v6.net
>>556
そう
「水素の音」みたいなもん
「水素の音」って言いたい人がいるだけ
573:デフォルトの名無しさん
22/01/14 09:28:53.08 n8eH8EkW.net
>>558
これだよな
574:デフォルトの名無しさん
22/01/14 09:48:26.29 20065uel.net
所有権の複製では意味が通らない事は明らかなので、
誰か >>489 の文をサクッと直してくれていいんだぞ
575:デフォルトの名無しさん
22/01/14 09:59:56.29 wd6QtXqe.net
流れ見てると｢所有権の複製｣は
おかしいから使うな派が半分
おかしいけどまあ好きにすれば派が半分
おかしくない派が約1名
みたいな感じ？
576:デフォルトの名無しさん
22/01/14 12:13:02.65 8BRe3wDd.net
この生産性のない議論に参加している人の割合と考えればさもありなん。
577:デフォルトの名無しさん
22/01/14 12:25:28.10 kUhlpB/h.net
>>564
どうでもいい派が抜けてる
578:デフォルトの名無しさん
22/01/14 13:03:41.15 bXd4RL2X.net
>>560
全く別の所有権なんだからコピーとか言うとわかりにくいだろ。
579:デフォルトの名無しさん
22/01/14 21:39:59.21 +ggCJzG3.net
所有権というか、ポインタなのか、実体なのかって考えれば所有権もすぐに理解できると思うが
580:デフォルトの名無しさん
22/01/14 22:02:26.42 hgiR/8Zn.net
>>568
それは所有権を理解してないのでは？
581:デフォルトの名無しさん
22/01/14 22:22:42.07 8BRe3wDd.net
>>:567
1つだったものが2つになることを複製と呼ぶのはべつにわかりにくいとは思わんがなぁ
582:デフォルトの名無しさん
22/01/14 22:37:39.46 WRwvxAen.net
現実のものに例えると適する例がないけど
近い分野だとOSでのプロセスのfork()に近いかな
どちらも初期状態は同じでその後は別の道を歩んで値(メモリ)が別の値を取れるようになる
これをプロセスの複製と呼ぶから複製という単語自体はわかりやすいと思う
583:デフォルトの名無しさん
22/01/14 22:45:21.62 bXd4RL2X.net
>>570
だから「所有権」に関しては全く別物だろうがよ。。いつまでアホなこと言ってんだか。
584:デフォルトの名無しさん
22/01/14 22:49:30.67 IfPg31YF.net
ジエンさんも複製されてるねw
585:デフォルトの名無しさん
22/01/14 22:54:57.45 k9ZagSOx.net
>>570
所有権は複製はできないが分割は可能
共有名義の不動産持分みたいなやつ
Rustに当てはめるとRcにあたる
586:デフォルトの名無しさん
22/01/14 22:59:38.88 8BRe3wDd.net
>>572
>だから「所有権」に関しては全く別物だろうがよ
「全く別物」という理由は？2つになるのは変わるまい。
587:デフォルトの名無しさん
22/01/14 23:04:12.94 8BRe3wDd.net
>>574
人それぞれだと思うが俺は所有権の分割って方がわかりにくいと思うがな。
Rcと紛らわしいから「複製」は使うなというのは納得できるが。
588:デフォルトの名無しさん
22/01/14 23:08:16.48 wd6QtXqe.net
>>571
プロセスはtask_structとかがあってしかも実際に複製されてるからな
Rustの所有権はそういうふうに実際にstruct Ownership;みたいのが有るわけじゃない
上の方でも言ってるやつがいるけどborrowcheckerとかのルールや制約を所有権って概念で説明してるだけ
だからメモリ上でCopyな(=単純なmemcpyで矛盾が起きない)型が複製されりゃ新しい所有権が作られるし!Copyな(=単純なmemcpyだと矛盾が起きる可能性が有る)型なら所有権もtransferされるってだけ
そこに解釈云々だのの余地はなく複製もクソもない
589:デフォルトの名無しさん
22/01/14 23:11:40.41 Gij7VB+L.net
>>571
そこで言う複製は値の複製
forkしてもPIDは複製されないのと同じで所有権も複製されない
590:デフォルトの名無しさん
22/01/14 23:13:06.72 hAOjwXhX.net
複製という用語は、2つの実体が作られたよりも、
その2つの同値性が強調される
例えば、一卵性双生児は同一の遺伝子だから複製だけど、
二卵性双生児は複製じゃない。
単に、別々の2つの実体が発生しただけ
二卵性双生児間には同値性が無いから
ただ、文書を書いた外人は、copy を同値性という意味で使っていない
長文で説明するのが面倒くさいので、copyという短い単語で、
単に、2つの実体が作られたみたいに、気軽に使っているのだろう
だから、copyを翻訳すると複製になってしまう
591:デフォルトの名無しさん
22/01/14 23:23:12.29 b+sgeTEs.net
複製という訳の問題じゃないよね
「所有権のコピー」と言っても「copy ownership」と言っても何も変わらない
592:デフォルトの名無しさん
22/01/14 23:34:11.11 b8FVBfqE.net
PIDとか二卵性双生児とか、根拠や脈絡がない例え話が次々に出てくるのが笑える。
なんでそこまで必死なのかと。
593:デフォルトの名無しさん
22/01/14 23:56:50.14 ErNyx2qm.net
fork出してきたお前が言うなやw
594:デフォルトの名無しさん
22/01/15 00:13:28.41 5R4N3qYj.net
>>571は曲がりなりにも根拠らしきものを挙げているけど
>>578のPIDはまったくの根拠レスじゃん、
forkで複製されないものを探したらPIDが出てきたとかじゃね？
595:デフォルトの名無しさん
22/01/15 01:02:15.31 l/1QpEiq.net
>>570
値はそうかも知れんが所有権は新しくできたものだろ。
新しくできたものを複製ってのは変だろうが。
596:デフォルトの名無しさん
22/01/15 01:19:56.24 KOUnkRnZ.net
C++の例外をちゃんと扱うのは難しい、Rustのほうが簡単やろ
597:デフォルトの名無しさん
22/01/15 01:20:44.09 KOUnkRnZ.net
スレ間違えた
まあいいや
598:デフォルトの名無しさん
22/01/15 02:34:21.16 LQYSNqi+.net
>>583
そう感じちゃうのがRustの所有権を理解してない何よりの証拠なんだよなぁ
599:デフォルトの名無しさん
22/01/15 08:00:13.06 SUNY4hKu.net
>>587
根拠を挙げて主張しているかそうでないかの違い。国語の問題。
所有権を理解しているかどうかは関係ないんだがお前さんの読解力にも問題があるな。
600:デフォルトの名無しさん
22/01/15 08:48:58.88 MrK/oPRe.net
根拠があるってんなら単にrust公式から定義をひっぱってくればいいのではｗ
それが無いから単なる珍妙なオレオレ用語で終了なんだよこの話は
こーいう手合いをいちいち構ってると時間足りないぞ人生は短いぞ
601:デフォルトの名無しさん
22/01/15 09:24:09.35 i5tbAI8Y.net
>>588
複製おじさん必死だなww
602:デフォルトの名無しさん
22/01/15 10:37:04.68 SKIF+upB.net
もう誰か本家のissueに｢CopyとMoveって何をcopy、moveしてるの？所有権のcopyっておかしい？｣って突撃してこいよw
603:デフォルトの名無しさん
22/01/15 10:38:54.35 zYbpVr1V.net
スレ追い切れてないけど所有権だけcopy/moveしてるという主張してる人がいるの？
604:デフォルトの名無しさん
22/01/15 11:23:39.22 xPHqeDv2.net
>>591
聞くまでもなくおかしいだろwww
何をcopy、moveしてるのかはチュートリアル読めよ
605:デフォルトの名無しさん
22/01/15 11:24:43.51 ZhZU0a8B.net
>>592
複製おじさんちーっすw
606:デフォルトの名無しさん
22/01/15 12:21:18.07 NVDl8gUD.net
参照の説明に合わせてCopy Typeには所有権は無いという捉え方ならかろうじて理解はできる
607:デフォルトの名無しさん
22/01/15 13:06:56.98 SKIF+upB.net
>>593
おれら匿名の有象無象におかしいって指摘されても聞く耳持たねぇみたいだから本家でぶった切られてこいっていう皮肉なw
608:デフォルトの名無しさん
22/01/15 16:47:14.84 MrK/oPRe.net
Cでポインタへのポインタをダブルポインタと言い張ったり
Cで関数へポインタで値渡ししてるだけのことを参照渡しと言い張ったり
酷いと思わんかね？
思わん人も居ることのほうが問題
609:デフォルトの名無しさん
22/01/15 17:52:02.36 gzKdcX6j.net
>Cでポインタへのポインタをダブルポインタと言い張ったり
>Cで関数へポインタで値渡ししてるだけのことを参照渡しと言い張ったり
c++でポインタ渡しを参照渡し言うならそりゃ誤解は出てくるが、そんなに問題にならんわ。
てか extern C で参照渡しは普通にポインタ扱いになるしな。
rustで所有権のコピー言うのは明確に意味がおかしい。
610:デフォルトの名無しさん
22/01/15 18:25:43.70 V6fKEShR.net
もうええやろこの話題は…こんな枝葉の問題でギャーギャー騒いでたら何も身につかんで…
Rust棒を使って気に食わないやつを殴りたいだけなんか…？
611:デフォルトの名無しさん
22/01/15 18:25:58.18 T5sD8sXT.net
所有権 → リソースの解放義務
コピーしたらアカン
612:デフォルトの名無しさん
22/01/15 19:00:19.86 Pt/mdzot.net
c++23以降で契約プログラミングのサポートが入るらしいけど、rustって言語レベルで契約プログラミングサポートしてる？
613:デフォルトの名無しさん
22/01/15 19:35:04.98 Ipn+w0vn.net
1週間以上も議論が続いている原因はおそらく
copyとmoveの対象の非対称性にあると思う
Copy trait非実装の型は「所有権がmoveされる」
Copy trait実装の型は「値がcopyされる」そして「新たな所有権が生じる」
614:デフォルトの名無しさん
22/01/15 20:06:03.10 gzKdcX6j.net
そんな複雑な理屈じゃなくてただのバカが意固地になってるだけだろ。。
615:デフォルトの名無しさん
22/01/15 21:12:26.97 U8m/+TaT.net
>>602
議論が続いてる気になってるんだw
616:デフォルトの名無しさん
22/01/15 21:34:33.77 5CQZXOEN.net
>>602
moveの対象も値だぞ
the bookのownershipの解説ページに1つでもmoveの対象がownershipになってる箇所あるか？
URLﾘﾝｸ(doc.rust-lang.org)
@ITの記事はそこも間違ってる
617:デフォルトの名無しさん
22/01/15 21:37:55.34 5CQZXOEN.net
>>600
ホントこれ
所有権が何かわかってれば複製なんて考えは絶対出てこない
618:デフォルトの名無しさん
22/01/15 21:44:00.10 +D8ShBal.net
俺は中立派なので
「Copyトレイト実装型は値と所有権が複製される」
でも構わないし9割以上の人々にはこれで通じるだろう
あとはどこまでこだわるかだけだ
これ以上その表現は容認できないと続けるならばスレ荒らしと変わらない
619:デフォルトの名無しさん
22/01/15 21:52:50.82 MrK/oPRe.net
>>607
｢所有権の複製｣は根拠の無いオレオレ用語であり
rust公式による定義は一切示されなかった
でオシマイの話
議論ですらないし
どっち派という派閥の話でもない
620:デフォルトの名無しさん
22/01/15 22:04:56.72 Ipn+w0vn.net
一般的に「批判や反対だけならバカでもできる」と言われるので
ここは代替案、修正案、改善案を示してはどうだろうか？
621:デフォルトの名無しさん
22/01/15 22:09:17.84 im+Hgbd+.net
匿名掲示板のやりとりで意見を変える人なんていないしとっとと次の話題に移るに限る
622:デフォルトの名無しさん
22/01/15 22:17:16.04 xn0tLhqJ.net
複製おじさんが必死過ぎて草www
自分の間違いに気づいてもなお苦し紛れの言い訳テラワロスw
623:デフォルトの名無しさん
22/01/15 22:29:40.11 SUNY4hKu.net
>>597
参照渡しという用語は定義があるからCのポインタ値渡しに使うのは明らかに間違いなわけだが
ダブルポインタの方は正式に仕様で規定されているわけではないが俗語として通用しているな。
俗語だから前提無しに誰にでも通じるわけじゃないというところ注意が必要だが。
624:デフォルトの名無しさん
22/01/15 22:30:43.34 daomKUdj.net
複製おじさんは自演して複数人を装ういつもの人
いつも間違いを指摘されるが全く反省せず
嘘を書き続けて強弁しつつ自演擁護するのが趣味
C++じいさんと一緒にここに隔離されてる
625:デフォルトの名無しさん
22/01/15 22:33:34.89 im+Hgbd+.net
所有権も複製されるとするとrustの所有権システム破綻するの？
そういう話ではなくて用語の用法に違和感があるという議論だよね？
理解合ってる？
626:デフォルトの名無しさん
22/01/15 22:44:35.60 Ipn+w0vn.net
>>614
その通り
俺は既に書いたように
『Copy trait実装の型は「値がcopyされる」そして「新たな所有権が生じる」』だが
これを『値と所有権が複製される』と表現する人がいても特に困らないしRustの理解で破綻することもない
現実にある所有権に照らし合わせると『所有権の複製』という用法に違和感があるだろうという話
627:デフォルトの名無しさん
22/01/15 23:04:44.12 psZvEbv8.net
>>613
今日いきなり「複製おじさん」とかいう特異な単語を使う人が立て続けに現れたんですがｗ
628:デフォルトの名無しさん
22/01/15 23:42:27.61 IhXEZL2k.net
>>614
複製されたら破綻するよ
当たり前じゃん
所有権を何だと思ってんの？
わかってないの複製おじさんだけだよ
629:デフォルトの名無しさん
22/01/16 10:16:15.91 FbMoDLfJ.net
>>614
＞所有権も複製されるとすると
所有権は複製されない。
630:デフォルトの名無しさん
22/01/16 10:41:29.77 78YeqR3t.net
一週間バカにされ続けても自ら学ぼうとしないメンタルすごいよな
記事書いたやつも複製おじさんも所有権を変数単位のフラグみたいに認識してるんだよ
Copyなら変数の値をコピーして所有権フラグの値もコピーするイメージ(何か問題でも?w)
現実の所有権のように各所有権が個別リソースに紐づくと考えてないから「所有権を複製」しても問題ないと思っちゃう
所有権のメタファー台無し
631:デフォルトの名無しさん
22/01/16 10:49:19.61 78YeqR3t.net
>>617
>所有権を何だと思ってんの？
この質問に答えられるようなら1週間前に終わってる話
自信がなくバカにされるのが怖くて答えられない
だから自演して印象操作に走ってしまう
それで余計にバカにされちゃう悪循環
632:デフォルトの名無しさん
22/01/16 10:53:40.34 zLzfdhk5.net
Rustスレは
仲介イテレータおじさん
所有権の複製おじさん
算数100点おじさん
の提供でお送りします
633:デフォルトの名無しさん
22/01/16 10:57:58.12 Ew12sdpw.net
みんなサビサビや!
634:デフォルトの名無しさん
22/01/16 12:33:17.26 hGTA6e5C.net
仲介おじさんと複製おじさんは同一人物でしょ
635:デフォルトの名無しさん
22/01/16 14:09:05.15 KLhMVNjz.net
しょーゆー拳！の複製とは・・・所有してない事では・・・？それとも共有？創造イテレーターおじさん。。。
636:デフォルトの名無しさん
22/01/17 22:59:06.94 Y2e2eRad.net
Rust 1.58で使えるようになったね
let var = 123.45;
assert_eq!(" 123.450", format!("{var: >10.3}"));
let vec = (5..=9).collect::<Vec<i32>>();
assert_eq!("[5, 6, 7, 8, 9]", format!("{vec:?}"));
637:デフォルトの名無しさん
22/01/19 19:54:17.44 E5BGSNnr.net
rust学習してるんだけど
コンパイル時検査で並列処理の安全性（可変参照が1つである事）を証明できるんだろうか？
実行時に借用チェックが行われてるという説明があったけどそれは必要なの？
638:デフォルトの名無しさん
22/01/19 19:59:57.13 E5BGSNnr.net
勘違いかも
この記事実行時にチェックしてるという意味じゃないかもしれない
639:デフォルトの名無しさん
22/01/19 21:18:54.23 gQYkvdGO.net
>>626
複数スレッドから参照される変数はコンパイル時に保証できないから実行時に保証されるよ
Mutexとか
640:デフォルトの名無しさん
22/01/19 21:23:52.62 tIKoVln/.net
Rc<RefCell<T>>のように所有権が共有されてる値を変更する場合なんかは実行時チェックしかできない
interior mutability patternと呼ばれるやつはみんなそう
641:デフォルトの名無しさん
22/01/19 21:24:20.06 tIKoVln/.net
ガブリンチョ
642:デフォルトの名無しさん
22/01/20 10:26:42.45 O3OMKZ6x.net
実行時に動的に借用のチェックをさせたいという動機は分かるんだが
RefCellっていう名前でそれが表現できてると思えないし
一方で内部可変性を表現してるとも思えないし
そもそも内部可変性と実行時借用規則強制と二つのことが一つの名前になってるし
じゃあどうすべきだったということも思いつかないけど
なんかモヤモヤしてる
643:デフォルトの名無しさん
22/01/20 12:30:05.06 Rdmkjysn.net
Cell<T> は Mutable<T>
RefCell<T> は DynamicMutable<T>
Cellが何かを一度イメージできるようになると
今のネーミングでも困らないから名前が変わることはないと思う
interior mutabilityという名前も最初は分かりにくかった
こっちはまだ変わる可能性あると思う
644:デフォルトの名無しさん
22/01/20 12:40:28.40 z2ZQEaJV.net
URLﾘﾝｸ(internals.rust-lang.org)
議論はあったが決定的な代替案があったわけでもないみたいね
645:デフォルトの名無しさん
22/01/20 12:41:15.85 lj0NmUaq.net
あー、なるほど、名前が分かりづらいのはおれが日本人のせいなのかな、とか
646:思ってたけど、やっぱり慣れてないと分かりづらいネーミングだったか
647:デフォルトの名無しさん
22/01/20 13:06:17.45 wvPJOB1p.net
そもそもBoxってなんやねん！😡
648:デフォルトの名無しさん
22/01/20 13:18:31.58 hnvUf8sg.net
>>631
中身を書き換えられる『セル』という分かりやすい名前
Cellは内部可変がOK
RefCellは内部可変参照がOK
違いが分かりやすいように3種類を持つ構造体を用意
struct S {
a: [i32; 3],
c: Cell<[i32; 3]>,
r: RefCell<[i32; 3]>,
}
let s = S {
a: [1, 2, 3],
c: Cell::new([1, 2, 3]),
r: RefCell::new([1, 2, 3]),
};
// s.a = [4, 5, 6]; // コンパイルエラー (sがmutじゃないため)
// s.a[1] = 5; // コンパイルエラー (sがmutじゃないため)
s.c.set([4, 5, 6]); // OK 内部可変
{
let mut p = s.r.borrow_mut(); // OK 内部可変参照
p[1] = 5;
// このブロックを抜けるとborrow自動返却
}
assert_eq!([1, 2, 3], s.a);
assert_eq!([4, 5, 6], s.c.get());
assert_eq!([1, 5, 3], *s.r.borrow());
649:デフォルトの名無しさん
22/01/20 13:20:34.04 O3OMKZ6x.net
メソッド名が動的←→静的と対称的であったりもしないし・・・
Cell: get, get_mut, set
RefCell: get_mut, borrow, borrow_mut
ただしget_mutはそれぞれ
URLﾘﾝｸ(doc.rust-lang.org)
> this method expects self to be mutable, which is generally not the case when using a Cell.
URLﾘﾝｸ(doc.rust-lang.org)
> this method expects self to be mutable, which is generally not the case when using a RefCell.
とあり通常の用途とやらで考えると
Cell: get, set
RefCell: borrow, borrow_mut
共に"Cell"で内部可変性を表現しつつ
用途はメソッド名で十分わかるしまぁもういいのかこれで
650:デフォルトの名無しさん
22/01/20 13:27:05.24 O3OMKZ6x.net
>>632
>>636
Cellっていう短い名前にクッキリした役割を描いたのはRust陣営は成功かもね
Rust以前に前例があるかどうかは知らんけど
>>634
名前の説得力が不足してる疑いはあるよね
>>635
それなｗ
651:デフォルトの名無しさん
22/01/20 13:39:18.98 hnvUf8sg.net
>>637
Cell⇔RefCell は 静的⇔動的 の関係ではない
Cell⇔RefCell は 直接⇔参照 の関係
そのため余分にRefが付く
静的⇔動的 の関係にあるのは
「&」⇔「RefCell::borrow()」)
「&mut」⇔「RefCell::borrow_mut()」
652:デフォルトの名無しさん
22/01/20 13:52:05.11 O3OMKZ6x.net
>>639
少なくとも構造体の説明としては
URLﾘﾝｸ(doc.rust-lang.org)
> A mutable memory location.
URLﾘﾝｸ(doc.rust-lang.org)
> A mutable memory location with dynamically checked borrow rules
↑のように書いてあるね
だから
SCell // A mutable memory location with statically checked borrow rules
DCell // A mutable memory location with dynamically checked borrow rules
こんなんでもよかったんじゃないかなぁと思ったがこれはこれで石投げられそう
653:デフォルトの名無しさん
22/01/20 14:13:35.66 hnvUf8sg.net
>>640
それは違う
間違った解釈で無関係な場所に「with statically checked borrow rules」を付けてはいけない
参照借用規則『multi readers xor single writer』に対して
以下が「静的チェック⇔動的チェック」の関係にある
静的チェック: multi「 &」xor single「&mut」
動的チェック: multi「RefCell::borrow()」xor single「RefCell::borrow_mut()」
一方でCellとRefCellの関係は
内部可変性が「直接書き換えOK」⇔「参照書き換えOK」の関係
だからCellに対してRef(参照)が付くRefCellという名前になっている
そして参照となるRefCellに対してのみ上述の参照借用規則が適用される
654:デフォルトの名無しさん
22/01/20 14:23:25.93 O3OMKZ6x.net
>>641
なるほどね
URLﾘﾝｸ(doc.rust-lang.org)
> If you require interior mutability by reference,
> consider using RefCell which provides run-time checked mutable borrows through its borrow_mut method.
↑ここでもまずは「参照による
655:内部可変性が必要な場合は」と先に来てるね 「実行時に動的に借用のチェックをさせたいという」のが動機だと俺勝手に思いこんでたけど それは一番じゃないみたい
656:デフォルトの名無しさん
22/01/20 14:32:46.88 XZNQ8H/m.net
>>635
Cell/RefCellと違ってBoxは分かりやすくていい名前だと思うぞ
Boxing/Unboxingは他の言語でも普通に使われてるよね？
旧名のOwned<T>や代替案のHeap<T>に比べると確実にいい
657:デフォルトの名無しさん
22/01/20 14:45:20.72 nm3lJD8v.net
Boxing/UnboxingはC#やJavaにもあるからBoxには全く違和感なかったけど
よく考えるとソースコード上にBoxという文字列が出現するのはRustだけかも？
658:デフォルトの名無しさん
22/01/20 14:54:02.35 3oKX7/s6.net
Scheme でも次の規格に Box が入ることになっている。
(既に導入している処理系も結構ある。)
659:デフォルトの名無しさん
22/01/20 15:32:21.48 hnvUf8sg.net
通常の型TやBox<T>などがSend+Syncである一方
Cell<T>とRefCell<T>は!Send+!Syncであることと引き換えに内部可変性を得ている
つまりmutではない参照の内部にあったとしても
「Cell<T>」は「mut T」のように成れて直接書き換え可能
「RefCell<T>」は「&mut T」を得られて参照書き換え可能
ここでCellとRefCellの違いは「&」すなわち「Ref」だからこの命名自体は分かりやすいと思う
660:デフォルトの名無しさん
22/01/20 16:52:16.46 O3OMKZ6x.net
>>644
むしろJava等にあるからこそ戸惑ったわ
既にあるBoxing/Unboxingへの理解に対して
Rustでは突如構造体としてBoxだもん
661:デフォルトの名無しさん
22/01/20 23:14:12.74 c3YxPrqk.net
まあBox と名前を合わせてBoxCellとか逆にBoxをRefにするかした方が統一的な名前づけだったとは思う。
662:デフォルトの名無しさん
22/01/21 07:08:34.56 zwVIa7Oi.net
>>648
Box<T>はヒープ上にTの場所を確保してそこを指し示します
Cell<T>はヒープ上かどうかは無関係で例えば>>636の使用例では全てスタック上
したがって「Boxと名前を合わせてBoxCellとか」はおかしいです
TとCell<T>はメモリ上の格納場所も実体も同じです
つまりCellとは内部可変性という特性を与え示していると考えたほうがわかりやすいでしょう
RefCell<T>も同様ですがこちらは参照借用規則の実行時チェックのためのborrowフラグが余分に確保されます
もうひとつの「BoxをRefにするかした方が統一的な名前づけだったとは思う」もおかしいです
refは参照(reference)の略としてあちこちで使われておりヒープ上かどうかは無関係ですが
Box<T>はあくまでもTがヒープ上にあることが主眼です
余談ですがこの関係でRefといえばstd::cell::Refという構造体があり
これはRefCell::borrow()が返す型として直接意識することはなく使われています
ちなみにRefCell::borrow_mut()が返す型はstd::cell::RefMutです
663:デフォルトの名無しさん
22/01/21 10:40:22.86 a7B69/kD.net
何も分かってねーなこいつ。
なぜBoxにするか、なぜRefCellにするかってのは要するに構造体のサイズを決定できない場合を想定してるわけよ。
スタックにそういういう動的にサイズが異なる実体をおくことも最近のコンパイラではないこともないが、通常はヒープに置くわ。
文字通りしか考えないで実際の使い方なんか一切考えないやつってのが丸わかりになるって意味では
分かってなさそうなやつにこの辺りについて問いただすってのは割と良いかも。
664:デフォルトの名無しさん
22/01/21 11:50:08.61 ePel1TKs.net
皆の言ってることがよくわからん
そもそもBoxとRefCellって対比させるようなものか？
665:デフォルトの名無しさん
22/01/21 12:13:07.97 a7B69/kD.net
T -- Box<T>
Cell<T> -- RefCell<T>
って普通に考えれば対比させると思うけど。
666:デフォルトの名無しさん
22/01/21 13:03:50.49 ePel1TKs.net
RefCell<T>はTへのrefが作れるCell (実行時にborrow checkする)
TとBox<T>はborrowに関しては同じ振る舞いでデータの場所がヒープか否かの違い
全然関係性違うと思うんだけど
667:デフォルトの名無しさん
22/01/21 16:26:46.26 HthXViD+.net
>>653と>>649は合っている
>>650は間違っている
BoxとRefCellには共通点も類似性も関係性も何もない
668:デフォルトの名無しさん
22/01/21 16:43:50.31 9uS/kBRP.net
「所有権の複製」がおかしいってことは納得言ってくれたん？ｗ
669:デフォルトの名無しさん
22/01/21 23:30:48.05 HnzI5Wog.net
表現の問題だけど別にいいんじゃね？
670:デフォルトの名無しさん
22/01/22 00:49:37.07 FWRR5JB/.net
ダメです
明らかにおかしい
ポインタ渡しと参照渡しを間違えてるくらいにはおかしい
671:デフォルトの名無しさん
22/01/22 01:05:08.77 7E1QrPk4.net
それは解釈のレイヤの問題。
JIS の情報処理用語の定義では参照呼び (参照渡しという言葉は定義がないが実質的に同じだろう) はオブジェクトの場所を渡すことと定義されていて、
ポインタという形で場所を渡すのも参照呼びの一種ということになる。
言語仕様の話をしているところで異なるレイヤが混ざるのはおかしくはあるが、
実例を示そうとしたり、逆に抽象的に説明しようとしたりすると境界が曖昧になることはある。
672:デフォルトの名無しさん
22/01/22 19:22:08.25 1QIe2ldW.net
じゃああなたはポインタ渡しと参照渡しを間違えてもいいよ
673:デフォルトの名無しさん
22/01/22 19:59:43.90 n0owABsu.net
>>658
ポインタ渡しと参照渡しが同じなら、nullptrを渡すのと同じことを参照渡しでどうやるか教えてくれ。
674:デフォルトの名無しさん
22/01/22 20:05:58.29 DSkywrpw.net
>>657
参照渡しじゃなくてダブルポインタの方だろ。
675:デフォルトの名無しさん
22/01/22 20:32:06.98 9yXjOkuN.net
ポインタ渡しっていう用語も使わないでほしい
ポインタ型の時に特別なもんでもなんでもなく
他の場合と同じcall by valueなのだから
676:デフォルトの名無しさん
22/01/22 20:53:17.10 vfyV6CZn.net
rustにおいて参照渡しと言ったらどういう意味になるんだろうか
677:デフォルトの名無しさん
22/01/22 22:32:38.62 g0imoAcW.net
>>657
そんなレベルじゃないだろw
「値の参照外し」くらいのありえねーやつだぞ
678:デフォルトの名無しさん
22/01/22 23:03:41.04 bh/4ELt7.net
>>663
&Tを渡すこと
679:デフォルトの名無しさん
22/01/22 23:09:33.04 j/zdYx9z.net
>>654
>BoxとRefCellには共通点も類似性も関係性も何もない
そうそう、何の共通点も類似性も関係性もないのに
The BookではBoxとRefCellを対比させてどういうケースにどっちを使うかわざわざ解説してるんだよなぁ
何の共通点も類似性も関係性も無いにも関わらずw
680:デフォルトの名無しさん
22/01/22 23:45:04.56 YZScTEQ/.net
>>666
マジでその二つは関連も類似も何もない
大きく分類してもBoxはスマートポインタの一種だが
RefCellはスマートポインタではなく内部可変性という性質の指定のみ
681:デフォルトの名無しさん
22/01/23 00:16:51.00 GGOFm3A0.net
>>666
URLﾘﾝｸ(doc.rust-lang.org)
URLﾘﾝｸ(doc.rust-jp.rs)
ここのこと？
682:デフォルトの名無しさん
22/01/23 01:50:05.66 N2HN4NXS.net
clippy様がvoldemort typeを説明せよと仰せなのだが
もしかして、名前を言ってはいけないあの人のことをご存じない？
>>668
そこはinterior mutabilityの前提としてborrowing rulesを
おさらいするためにBoxを出してるだけだから違うだろ。
多義的なオレオレ用語が多くて質は悪いけど
the bookに意味もなくBoxとRefCellを登場させてる章なんてなかったと思う。
683:デフォルトの名無しさん
22/01/23 09:58:49.85 I/0ReqFd.net
なんでわざわざ自演するのかね？
684:デフォルトの名無しさん
22/01/23 10:23:00.27 pcY9kzKW.net
それが仲介おじの悪癖なんよ
685:デフォルトの名無しさん
22/01/23 14:04:42.46 Tw7cio1+.net
病気だな
病名は知らんけど
686:デフォルトの名無しさん
22/01/23 15:19:04.05 Qjn377p7.net
rust勉強しはじめたばかり、C,C++はだいぶ昔少し経験がある程度
Cとかじゃ、constなpointerは、変数自体がconstと、指ししめす対象自体がconstである場合があり
const T * const p;
みたいな宣言があったが
Rustはデフォルトでイミュータブルなのはわかるけど、mutを付けると、変数自体も指し示す対象もmutableになってしまう？
let mut v = vec![1, 2, 3];
v.push(2);
v = vec![4,5,6];
どっちか一方を禁止する方法とかあるのですか？
687:デフォルトの名無しさん
22/01/23 17:38:28.44 v0FQj8Ao.net
C上がりのヤツって意味のないところにconst付けがち
関数の引数にconst DWORD vとか
688:デフォルトの名無しさん
22/01/23 19:54:52.69 GGOFm3A0.net
>>673
どういうことをしたいのかによるけど
let x = Vec![...];
let mut y = &x;
みたいにすればyは再代入可能だけどxやvecの中身は変更不可になる
689:デフォルトの名無しさん
22/01/23 20:02:24.55 N2HN4NXS.net
末尾oとかWとかで荒らしてるやつ回線なんだ？亡霊か？
690:デフォルトの名無しさん
22/01/23 20:58:37.79 sgP3cX+L.net
えっ、一人二役まだ続けるのか
691:デフォルトの名無しさん
22/01/23 22:45:59.41 N2HN4NXS.net
お前Lはないだろ
692:デフォルトの名無しさん
22/01/23 23:46:00.51 QpDxG2zZ.net
ちなみにRustでのconstとはコンパイル時点で定数(どんな複雑な型でもよい)であること
プログラミング言語によってはconstなのに実行時に決まる値(がその後変化しないこと、つまり単なるimmutable)を意味しているので意味の差に注意
693:デフォルトの名無しさん
22/01/23 23:59:31.12 2V1gRdrY.net
>>674
Rustでは関数の引数にconstはないな
ジェネリクスとしてのパラメータにはconstがありこちらは便利
694:デフォルトの名無しさん
22/01/24 00:27:06.65 bSZB9aci.net
>>675
ありがとうございます。
やりたいことは、だいたい同じですけど、少し違って
v.push(2)か再代入のv= vec![4,5,6];のどちらかを禁じたいでしたけど
あなたの投稿みて考えて
let v = &mut vec![1, 2, 3];
v.push(2);
//v = vec![4, 5, 6]; エラーになる
で一応できました。
でも再代入可能で、中身変更不可にｖをする方法は思い浮かびませんでした。
675のようにして、vからｙに代入したらyはそうなりますが。
695:デフォルトの名無しさん
22/01/26 20:11:49.47 IHm+4QQV.net
すまんが、Replit使って学習してるんだけどさ
たまたま海外勢の動画見たら、同じReplitのはずなのに波線の指摘とかコード補完とか効いててびっくりしたわ
URLﾘﾝｸ(www.youtube.com)
うちではこんなのならないんだけど・・・・やり方わかる人いたら教えてくれんかな？
696:デフォルトの名無しさん
22/01/26 22:40:12.84 e2k0MxNT.net
Repl.itは、リンターやデバッガーからサードパーティのパッケージ、ホスティング、デプロイまで、
すべてを備えた、ブラウザー内の完全な共同クラウド開発環境です
697:デフォルトの名無しさん
22/01/27 14:52:35.89 kmz9k/kc.net
プログラミングRustの第2版の訳書出たんだな
698:デフォルトの名無しさん
22/01/27 17:03:59.04 O/Xb3RdK.net
t
699:デフォルトの名無しさん
22/01/30 18:39:19.14 Np8aVX2s.net
Rustはゼロ除算はコンパイルエラーになるの？
700:デフォルトの名無しさん
22/01/30 18:46:47.93 iWlFH2We.net
const文脈ならコンパイルエラーになったはず
701:デフォルトの名無しさん
22/01/30 19:13:28.33 9ei8l7Ku.net
コンパイル時に判明しないゼロ除算やオーバーフロー除算 ex. -128_i8 / -1_i8 はpanicとなるので
それが困る場合はchecked_div()を使えばOption型が返りNoneとなる
702:デフォルトの名無しさん
22/01/30 20:48:51.55 iWlFH2We.net
>>688
ほんとだ、定数式じゃなくてもエラーになるんだね
URLﾘﾝｸ(play.rust-lang.org)
即値じゃなくてもエラーにしてくれてある程度賢そう
URLﾘﾝｸ(play.rust-lang.org)
703:デフォルトの名無しさん
22/01/30 21:12:48.50 2J0C/Vn/.net
const fn divide(x:i32, y:i32) ->i32 {
x / y
}
let x = divide(1, 0); //panic
const y: i32 = divide(1, 0); //compile error
704:デフォルトの名無しさん
22/01/31 00:45:03.08 wgfsi16C.net
>>690
定数式の文脈でゼロ除算起きるとコンパイルエラーになるのはある意味当然だと思うんだけど
そうじゃないところでエラーになるのが意外だった
デバッグビルドでもMIRの最適化とかで定数畳み込みみたいなことやってるのかな
705:デフォルトの名無しさん
22/01/31 07:35:21.99 qlFEomu1.net
>>691
Rustではconst fnな関数を使ってconstな定数を作ることができる
つまりコンパイラがその定数を算出するためコンパイル時点で判明する
706:デフォルトの名無しさん
22/01/31 10:25:13.89 y6tOo2ii.net
とあるデータフォーマットを扱うライブラリを作っています。
一定形式のレコードが連続で書き込まれて最後には終端レコードが書き込まれるという単純な形式です。
Rust 上でもレコードを追加するのと終端処理のふたつのメソッドがあるだけです。
要は ↓ のように使えるライブラリだということです。
let mut file = File::create("file.hoge").unwrap();
Hoge::new(&mut file).add_entry("string1")?.add_entry("string2")?.finish();
このとき
・ 終端処理は必ずしたい
・ 終端処理はエラーの可能性もあり、それは捕捉したい (ので drop でさせられない)
という制約を静的に表現できるでしょうか？
現状では終端処理のメソッドが実行されたときにフラグを立てておいて
drop 内でそのフラグを検査するという形にしています。
可能ならコンパイル時に発見できるようにしたいです。
707:デフォルトの名無しさん
22/01/31 11:02:40.38 qlFEomu1.net
エラーを捕捉したいことをデストラクタに任せない
つまりそのような終端処理はdropされる前に終える
例えばBufWriter利用時も終える時は明示的にflushを呼ぶ
そしてflushはResultを返しエラーが判明する
708:デフォルトの名無しさん
22/01/31 11:32:28.54 LhFaS6j7.net
finishの呼び忘れを静的に捕捉したいということだからflushの例では不十分かな
add_entryの戻り値型の暗黙のdropを防げばいいけど、そういった機能はまだない（RFCにはあるけど進んではない）
URLﾘﾝｸ(users.rust-lang.org)
このスレッドではdropの実装に存在しないC FFI呼び出しを書いておいて、リンクエラーとして捕捉する方法が提案されているね
709:デフォルトの名無しさん
22/01/31 11:35:46.57 y6tOo2ii.net
>>694
それを制約として表現できるか (終端処理をしていないときにエラーになるように制約を書けるか) という質問をしてる。
つまり出来ないってこと？
710:デフォルトの名無しさん
22/01/31 11:53:47.47 y6tOo2ii.net
>>695
それは残念。
言語の機能として用意されてないまわりくどい方法を使うと
エラーメッセージがよくわからん (本来の問題とは違う内容が出てくる) ことになりがちだし、
使うときに unsafe や forget をいちいち書いてもらわなきゃならないのは
ライブラリとして提供するときにはちょっと汚すぎるなぁ。
711:デフォルトの名無しさん
22/01/31 12:37:43.75 pXNCEmdM.net
PhantomType的な？
712:デフォルトの名無しさん
22/01/31 12:39:21.72 pXNCEmdM.net
エラーメッセージがよくわからん事になりがちだからNGか
713:デフォルトの名無しさん
22/01/31 12:47:03.61 qlFEomu1.net
>>696
なるほど
コンパイラは解析してdropさせるべき位置を把握しているから
そこへ至る全ての経路上で例えばFinalize trait実装型はそのメソッドfinalize()を呼んでいないとコンパイルエラーとなる
というような制約をするFinalize trait
が存在していれば要望を満たす？
714:デフォルトの名無しさん
22/01/31 13:15:16.14 wgfsi16C.net
>>692
非const fnについての話なんだけど
715:デフォルトの名無しさん
22/02/01 18:21:42.44 EUosKgIx.net
amazon primeの記事経由でegui見てみたが結構いいな
ネイティブで試してみたが充分実用レベル
716:デフォルトの名無しさん
22/02/01 21:04:57.74 YxH4csZd.net
GCは標準からは消えたけどライブラリでやればいいってかつてこのスレで言われたことがあるのだが、GCライブラリのデファクトスタンダードってどれだ
717:デフォルトの名無しさん
22/02/01 21:52:48.48 noSg7Gj9.net
>>703
デファクトなんてあるわけないじゃん
マークスイープGCするならRust使う意味ないんだから
718:デフォルトの名無しさん
22/02/01 22:04:01.37 YxH4csZd.net
>>704
いや一部だけGC欲しい時は普通にあるからそれは言い過ぎ
719:デフォルトの名無しさん
22/02/01 22:51:54.30 l+/c7OlD.net
クッソ身につまされる記事があったので共有する
URLﾘﾝｸ(dystroy.org)
720:デフォルトの名無しさん
22/02/01 23:11:34.83 rVnoodM/.net
>>706
これはいい記事だな
次からテンプレ入り希望
721:デフォルトの名無しさん
22/02/01 23:23:08.93 rLXhSAw+.net
>>702
eguiは毎回60fpsで全画面を描き直すことで差分描き直しを避けて簡単にしてるようだけど
省力化したい方針と合わないや
ゲーム向き？
>>705
GC使ってもRustのRAIIを無くせるわけじゃないから
そういう時はVecに入れて使って
あとは任意のタイミングで未使用の要素の区画を再利用という感じにしてる
>>706
Rustは各種bookを読んであとはstd docとreference見ながら
コンパイルエラーの通り直すだけで何とかなるから書かれている通りだね
付け加えると基本要素については覚えていないメソッドのために回り道しがちなので
Option Result slice str Iteratorあたりの全メソッドは一通り認識しておくといいかな
722:デフォルトの名無しさん
22/02/02 10:20:38.88 OC/eznuR.net
複製おじは自分では何とかなってると思ってるのか
723:デフォルトの名無しさん
22/02/02 11:48:12.13 yXsdGz3O.net
🐜蟻型蜂🐝はポジティブシンギング🤯だから
724:デフォルトの名無しさん
22/02/02 18:24:25.46 LUGaOk8s.net
>>706
>Mistake 3 : Start by implementing a graph based algorithm
その通りだとは思うけどRustと相性の良いアルゴリズム集的なのは欲しいとも思う
725:デフォルトの名無しさん
22/02/02 19:18:50.51 aYiI+nmg.net
>>711
汎用データ構造の大部分を使うな、という話になりそうだからなぁ。
スタックとキューくらいは楽に使えるのかね。
726:デフォルトの名無しさん
22/02/02 20:06:31.96 9W9+AwqU.net
dynや lifetime heavyは失敗しながら学ぶのでいいと思う
普通の人はしばらくやってれば気づくから
727:デフォルトの名無しさん
22/02/02 20:34:19.12 ljjcfSf9.net
deny(rust_2018_idioms)はガチのマジでオススメです
728:デフォルトの名無しさん
22/02/02 22:05:12.51 cdYzXGt/.net
データ構造が大事なんだって言われながら育ってきた身としちゃあ辛い話じゃねえか
自分で作らなけりゃいいんだな！ってslab_tree使って
「ある条件に合致した子ノードから、ルートまでの値をリストで取り出す」
みたいな処理を書こうとしたら怒られるんだよな。
node_ref.parent() : &Self<T> -> Option<NodeRef<T>
っていう型なもんだから、次々に親をたどるために
while Some(parent) = node.parent() { node = parent; ...}
みたいな処理書くと、当然怒られる。
何とか抜け道無いかって探したら、node自身じゃなくてそのIDを使えばよかったんだけど、
いつも抜け道があるとは思えない。辛い。
729:デフォルトの名無しさん
22/02/02 22:39:17.87 O+j3A95O.net
Rustで普通にやってるとスレッドセーフを強いられるから制約がキツくなるんだよね
730:デフォルトの名無しさん
22/02/02 22:41:53.47 J71gX0gE.net
大昔からの単純なポインタ相互参照だと
ダングリングポインタ・多重解放・解放忘れなどが全く存在しないことを検証すべき範囲が一般的には広くなりすぎる
もし狭い範囲に閉じ込められるケースならば閉じ込めた中でunsafeを用いたとしても効率的な型を提供すればよい
標準ライブラリにあるヒープを用いる型は全てそのようにして作られている
731:デフォルトの名無しさん
22/02/03 23:00:23.96 KgH5nhZs.net
>>684
今それ読んでる
出版物だけあって日本語の質はずっといい
732:デフォルトの名無しさん
22/02/03 23:17:16.89 VxNIdQ9k.net
Craterについて教えてください
733:デフォルトの名無しさん
22/02/04 00:50:00.86 Ueb60Gjp.net
>>718
もしかしてThe Bookの勝手訳の質と比べてる？
734:デフォルトの名無しさん
22/02/04 21:15:13.65 fCF+Tqbd.net
>>720
勝手訳というのがなにを指すのか不明だけどオリジナルのThe Bookからリンクされている日本語訳のことであればそれと比べている
735:デフォルトの名無しさん
22/02/04 21:21:32.40 b3SZZj/4.net
そんなのを見るのは極初期だけで些細な話
その後はdoc.rust-lang.orgとdocs.rsしか見ないのだから
736:デフォルトの名無しさん
22/02/05 13:22:14.88 XET6D0Ck.net
その極初期の人が見る和訳の質の話をしてるんだろ
737:デフォルトの名無しさん
22/02/05 14:41:30.63 e42LAXmg.net
あれは害悪レベルの訳だから初期でも見ない方がいいよ
ここでよくおかしなレスしてる人もあれの影響なんじゃないか？
738:デフォルトの名無しさん
22/02/05 15:12:20.92 WBcMnxrA.net
どうせ>>722のドキュメント見ないと先へ進めないしほとんどは中学生でもわかる平易な英語
日本語訳の質にこだわるような低レベルのやつはほっとけばいい
739:デフォルトの名無しさん
22/02/05 15:52:33.91 2hiBx8fY.net
Mistake 2 : Dive in without looking at the book
740:デフォルトの名無しさん
22/02/05 15:59:05.92 WBcMnxrA.net
>>726
まさにそれで最初は日本語訳でもいいがその後にthe bookを直接見るべき
そしてどの英単語でどう表現されているかを掴めば日本語訳がどうかに関わらず先へ進める
741:デフォルトの名無しさん
22/02/05 16:02:12.98 2hiBx8fY.net
>>727
言ってること変わってますけど
742:デフォルトの名無しさん
22/02/05 16:03:52.79 WBcMnxrA.net
一貫してるぞ
日本語訳の質にこだわるような低レベルのやつはほっとけばいい
これしか主張していない
743:デフォルトの名無しさん
22/02/05 16:09:07.88 2hiBx8fY.net
そこ以外の文章はポエムか何かだったの？
744:デフォルトの名無しさん
22/02/05 16:22:12.93 XET6D0Ck.net
じゃあ和訳の質を話題にしている低レベルの人同士の会話はほっとけばいいのにｗ
745:デフォルトの名無しさん
22/02/05 17:02:52.76 VkrSTqtm.net
日本語イラネ言っている人は技術資料が英語でも
日本語でも生産性が変わらない人なんだよね？
アメリカの仕事でもした方が稼げるんじゃない？
746:デフォルトの名無しさん
22/02/05 17:05:29.47 nog/R4+C.net
和訳の質にこだわってる人たちも唯一役に立つチャンスがあるよ
それは和訳の改善案を提案して質の向上に貢献すること
しかし和訳の質にこだわってるここの人たちは批判だけで提案がないから残念な人たち
747:デフォルトの名無しさん
22/02/05 17:15:34.64 9gZgvarh.net
和訳の質にこだわっている人たちの質にこだわっている人は何の役にたつの？
748:デフォルトの名無しさん
22/02/05 17:36:04.99 XET6D0Ck.net
どこの食堂が美味いか話しているところに割り込んで、
不味い方を立て直してこいと言うくらいナンセンス。
749:デフォルトの名無しさん
22/02/05 17:36:55.75 Z82/7dFa.net
>>725
その結果、所有権を複製しちゃったんでしょw
750:デフォルトの名無しさん
22/02/05 17:58:18.58 oHTbhGZf.net
とはいえ元の話は
無料の炊き出しがレストランより不味い
みたいな話なのでそりゃそうだろうとしか
誰もがオライリーを気軽に買えるわけでもないし
それぞれ意味はあるだろう
751:デフォルトの名無しさん
22/02/05 18:14:45.46 9gZgvarh.net
ざんねんながら悪文どころか誤訳だらけで無料の炊き出しよりひどいのがままあるのが技術書の世界
752:デフォルトの名無しさん
22/02/05 18:19:44.18 nog/R4+C.net
>>738
誤訳だと言うなら改善案を提案して質の向上に貢献するのがいいよ
それができないなら単なるイチャモン付けるだけの残念な人
753:デフォルトの名無しさん
22/02/05 18:40:50.96 SfaxLljQ.net
クソ不味い飯屋にわざわざ改善案を提案するやつww
「批判するなら対案出せ」と同じアホ理論www
754:デフォルトの名無しさん
22/02/05 18:44:43.09 NEwj3nV7.net
両立するよ。
改善に取り組みつつ現時点では良くないところもある (信頼しすぎるな) と初心者に警告するのは何も矛盾しない。
755:デフォルトの名無しさん
22/02/05 18:55:08.74 RA3mCqKO.net
>>741
>両立するよ。
何と何が両立するの？
756:デフォルトの名無しさん
22/02/05 19:15:32.20 9gZgvarh.net
>>739
ではイチャモン付けるだけの残念じゃない君が俺の代わりに改善案を提案しておいてくれ
757:デフォルトの名無しさん
22/02/05 19:38:56.71 nog/R4+C.net
>>743
自分は現状の和訳で問題ない派
そんな些細なことよりも和訳だけでなく原文も併用した方がよく
その後は原文だけの世界なのだから
758:デフォルトの名無しさん
22/02/05 19:43:44.48 9gZgvarh.net
なんだ、日本語が読めない人だったか
759:デフォルトの名無しさん
22/02/05 19:50:42.02 WBcMnxrA.net
日本語訳の質にこだわるような低レベルのやつはその先へ行けないため日本語訳にこだわる
760:デフォルトの名無しさん
22/02/05 21:53:27.09 tUU0u0u/.net
複製おじさんが言っても説得力ゼロ
761:デフォルトの名無しさん
22/02/05 22:32:09.49 nog/R4+C.net
和訳にイチャモン付けるだけの残念な人は「複製おじさん」を連呼する人でしたか
762:デフォルトの名無しさん
22/02/06 10:19:03.76 rpYaxfPG.net
>>543からの流れを見ると確かに複製おじさんは英語読めないっぽいが
Copyを「所有権の複製」と思い込むのは日本語訳の質が原因ではない気がする
763:デフォルトの名無しさん
22/02/06 21:49:38.13 iA9Wv++J.net
そんな超初心者入門のところでもめてるのかね
trait Copyを実装している型は複製されて、実装していなかったら移動となるだけだぞ
所有権は難しくない
764:デフォルトの名無しさん
22/02/06 21:58:58.41 nXnmaz3p.net
>>750
何が複製されて
何が移動するのかな？
765:デフォルトの名無しさん
22/02/06 22:11:28.10 BkoYcqr9.net
>>489 の文章が間違ってる、いやおかしくない、って揉めてただけだよ
まあ気付けば普通はおかしいと思うんだけど
766:デフォルトの名無しさん
22/02/06 22:13:32.98 iA9Wv++J.net
>>751
所有権
Copy実装型は常に所有権が分岐する
767:デフォルトの名無しさん
22/02/06 22:39:23.39 JXWBQEX4.net
>>753
複製(copy)と分岐(branching)
768:は全く違う意味だけどCopy実装型だと所有権が複製されつつ常に分岐する？？ どういう意味？
769:デフォルトの名無しさん
22/02/06 22:43:41.39 iA9Wv++J.net
>>754
初期状態は全く同じ
つまり複製されて分岐する
それ以降は異なりうる
770:デフォルトの名無しさん
22/02/06 22:57:43.95 VdsOdvUM.net
Rustの所有権というのは権利というよりも所有しているリソースの解放義務を指している
複製できたら所有権管理の意味がない
分岐はもっと意味不明
771:デフォルトの名無しさん
22/02/06 22:59:53.55 9tkt2bmo.net
489から始まった議論をまたやり直すの？
772:デフォルトの名無しさん
22/02/06 23:01:30.97 s1W7Zv37.net
複製おじさんが分岐して所有権分岐おじさんにw
773:デフォルトの名無しさん
22/02/06 23:04:45.50 iA9Wv++J.net
>>756
複製され分岐するため
リソース解放義務はそれぞれに生じる
774:デフォルトの名無しさん
22/02/06 23:09:58.47 Woj/yg4T.net
>>759
複製おじさん、嘘ついちゃダメだよ
詳しくはdoc.rust-lang.orgとdocs.rs見てねw
775:デフォルトの名無しさん
22/02/06 23:26:57.07 kRmD/jh4.net
複製おじさん連呼する人は、もちっと具体的に指摘してくれるとありがたいんだが。
776:デフォルトの名無しさん
22/02/06 23:31:49.27 iA9Wv++J.net
嘘ではない
もちろんCopy実装型の時点でヒープは使われないので解放といってもスタッフ上のみだから実質何も行われない
そのためデストラクタも容認されていない
その観点からCopy実装型は所有権がないと主張する人もいるくらいだ
777:デフォルトの名無しさん
22/02/06 23:59:50.68 fxuI+J0l.net
>>761
おじさんを連呼してる人はスレを荒らしているだけのクズ
説明や代案や根拠などを語れない
778:デフォルトの名無しさん
22/02/07 00:00:24.28 eBqtDcmM.net
>>762
何も行われないのに複製されて分岐してそれ以降は異なりうるってどういうことだよ
矛盾だらけ
779:デフォルトの名無しさん
22/02/07 00:09:06.68 sOY0eIf2.net
>>761,763
複製おじさん得意の自演乙www
嘘つきは分岐の始まり
780:デフォルトの名無しさん
22/02/07 00:19:43.65 +QREW3s6.net
> そんな超初心者入門のところでもめてるのかね
> 所有権は難しくない
【超初心者向け所有権の説明】
Copy実装型は所有権が複製されて分岐してそれ以降は異なりうる
難しくないw
781:デフォルトの名無しさん
22/02/07 00:23:15.30 A0JQeUWh.net
>>764
この件は有名な話でRustコンパイラのサボり。
Copy型は複製分岐されて各々がdropされるのが正しいけど、スタック変数のみだからそれをサボっている。
つまり現在のコンパイラ実装は正しくなくて、dropしちゃうとサボりのせいでメモリunsafetyを引き起こす可能性がある。
だからCopy型はDropを現状では許していないという話。
rustc --explain E0184 を見てね。
782:デフォルトの名無しさん
22/02/07 01:29:41.70 6Fl/+EdH.net
>>767
なんか仕様と実装を混ぜて話してるけどなんで？
普通、仕様にそって実装がされるはずだけど、(この部分に関しては)実装に仕様が引きずられてるってこと？
それとも仕様通りではないってこと？
783:デフォルトの名無しさん
22/02/07 08:04:57.91 cIffYd5J.net
>>725
順調に滅びの道を歩んでいるな。
784:デフォルトの名無しさん
22/02/07 12:36:41.09 E3rdzbcC.net
将来実現されるであろうあるべき仕様が実装の都合で実現できていないから、それと矛盾しない範囲に仕様の範囲を制限した、という理解で良い？
785:デフォルトの名無しさん
22/02/07 13:38:44.35 ZeQEvlq1.net
>Copy型は複製分岐されて各々がdropされるのが正しいけど、スタック変数のみだからそれをサボっている。
まーた勝手な思い込みの妄想で嘘垂れ流してる
いい加減にしろ
786:デフォルトの名無しさん
22/02/07 18:29:28.92 lRQrpp2a.net
>>767
それ1.0以前の話で今とは実装も前提も全く違うからエラーメッセージ修正したほうがいいやつ
もし仮にDropかつCopyな型が実装できるようになったとしても所有権は複製されないから
787:デフォルトの名無しさん
22/02/07 21:58:52.41 pvg7UzFi.net
>>768
「currently disallowed」「current implementation is incorrect」「disabled for now」と強調されてるように、
あくまでも現在の実装は本来とは異なり正しくなくて、問題を引き起こすために、CopyとDropの両立を現時点では禁止してる。
理論的にはCopy型は複製分岐されて各々がdropされる形が正しくてCopyとDropの共存が可能。
この暫定的な実装に引きずられた暫定的な仕様が、将来は正される可能性も残す表現となっている。
両立禁止で実害が出てないため優先順位は低いと思われるが、もし将来に共存可能になったとしても後方互換性は生じない。
>>772
最新のエラーメッセージで合っている。
URLﾘﾝｸ(github.com)
Latest commit 9e5f7d5 on 28 Aug 2020
788:デフォルトの名無しさん
22/02/07 22:27:06.61 zI1SZbAO.net
>>773
>理論的にはCopy型は複製分岐されて各々がdropされる形が正しくて
複製分岐されるのが正しいという根拠は？
789:デフォルトの名無しさん
22/02/07 22:38:57.39 pvg7UzFi.net
>>774
Copyなので複製分岐されるのは当たり前。
今はそこが論点ではなくて、複製分岐の後に各々に解放処理が生じるけど、現在は正しく実装されていないので仕様に制限があるとコンパイラのメッセージでも出る話。