乙
＞前スレの質問「間違って同じ変数名つけたコード片突っ込んでしまった系だと他言語にあるらしい２重宣言エラーないの怖くないですか？」 >>4 ある値をちょっとだけ処理したものにどんな名前を付けたいかってのは、
何を問題にしてるのか分からんけど、コンパイラから見たら、同じ変数名宣言でも連番で構文解析しているわけで
>>7 ん？まあありうるだろうけど、そんな意図を持ってシャドーイングをするコードは捨てろよ？明示じゃねーわ
>>996 >>7 >>11 >>5 を今gcc test.cしたけどその警告出ない intellijでも、シャドーイングがあったときは警告出てなかったっけ？
そんなことよりもだ！Rustに限らないけど
let acc1: u32 = (0..).map(|n| n * n)
>>5 shadowing嫌いな人はdeny(clippy::shadow_same)などすればよい
>>16 >>18 のコードは大きな配列とかメモリ大量消費とかしないだろ >>22 メソッドチェーンなら、メソッドごとに単体テストができるし、テストを用意しとけばすぐにバグがわかるような気がするが。
ほんと日本語読めない奴ばっかり。経過いうてるのにメソッド毎だとか、バグのことなんて言って
翻訳は、Chrome, Edge の翻訳機能、
言語は素晴らしいのにやってる奴が意識高い系のウンコ野郎ばっかり
まあコミュニティに馴染めるかどうかも本人の適性によるところがあるしな
>>25 >>16 課題forを使うか>>18 のメソッドチェーンを使うかの話に配列は一切関係ない 配列とスライスとベクタが別物なのこういう場所で会話するときに地味に混乱しがち
Stringとstrって日本語でどう呼び分けるんですか？
>>30 >>25 ほんとここに来るやつは皆を騙す詐欺師の気持ちや悪い奴ばかり、一切関係ないぞ！
どんなに適当に書いてもコンパイラさんがうまいこと最適化してくれるのでヨシ！
最初から大して違いも出ないが、分かりやすさを重視するなら高階関数かな？
>>39 rustの得意とする高パフォーマンス領域だとactix(-web)なんかはスレッド数=物理コア数で
>皆を騙す詐欺師の気持ち悪い奴ばかり
async/awaitが高階関数と（今の所）相性良くない
>>44 静的チェックでオールOKみたいな言語って意識高い系のバカを呼び寄せやすいんだよ。
自分のことを言われて怒っちゃったのか。
>>32 うん、完全理解した。こんスレは同じrustガンダム乗りなのに連邦の白い悪魔以外は認めないんだ Vecに入ったi32(空っぽの可能性もあり)の平均を計算するのってどうするのが一番スマート？
副作用持つときはfor文でそれ以外はメソッドチェーン繋げてやります
>>34 そういや平均求めるメソッドってstd::iterにもitertoolsにもないんか？
>>47 そんな簡単な実装を一々stdに入れてたら、糞関数だらけのLLライクになるじゃん？
>>58 >>59 オーバーフローしないように型を選択することとか、
Vecとかに入った複数のtokio::task::JoinHandleをjoinするのはどうやるんでしょうか？
thread::JoinHandleは並列で(マルチスレッドとなり)
futures::future::join_allでいいんじゃね
task::JoinHandleの方はFuture trait実装なので >>65 let mut a = 'a';
パターンには代入される側の変数しか書けないけどガードは自由自在
そして範囲指定を使いたいんだったらこう
bのところが式かも知れないのでxにマッチさせてこの方がベターか
>>69 Rangeを含むジェネリックな関数を作りたいのですが例えば単純化した例
>>73 >>74 格闘しているうちにコンパイラがstableじゃダメだとかfeature指定しろとか無茶を言って来るので従ってnightlyにしたりfeature指定したりしたところようやく動いたのですが何か変ですよね
うーん
nightlyにせずstableのままで範囲指定nをジェネリック化できた方いましたらやり方教えて下さい
>>75 >>79 >>80 リテラル`0`の問題とstd::iter::Stepがunstableなのと2つ問題を解決する必要がある
やはり..を使う限りstableでは無理でnightlyでないと以下のような素朴な実装も無理ということでしょうか
>>83 >>85 更にtimes()自体をイテレータにしてしまえば汎用的になるだけでなく
timesなら精々u64::MAX回も繰り返すことなさそうだしTからu64に変換するのではだめなの？
トレイト境界が短くなって素晴らしい原因ですがもしかして >>83 では要のops::Range<T>型がコードに明示されてないので条件のiter::Stepを要求されてしまい >>85 ではそのops::Range<T>型をトレイト境界に登場させたためiter::Stepが不要となり >>87 ではそのops::Range<T>型を返り値として明記したためトレイト境界にも不要となった？？ 指定するトレイト境界が減った代わりにAPIが劣化してる
>>90 >>87 わざわざ外部crateと独自trait使って
>>92 >>88 >>91 で必要なZeroとOneとAddを定義すれば動くはず >>93 の続き >>91 のnum::range利用イテレータ版times()が動くはず >>93 >>95 >>93 の型Xはnum::range利用だと動いたが どうしてもstableでやりたいという話ならRangeとStepを独自に用意するしかなさそう
>>97 >>93 の型Xでは動かないね StepがunstableなのはさておきFromLiteralみたいなトレイトがあるとZeroやOneの出番が減ってうれしいのかね
言葉足らずでしたね
const fnが言いたいだけやろ、だれが＝演算子でcopyでもなく、言語上ないことになってるコンストラクタでもなく
>>110 m..nをiter::Step使わず素直にPartialOrd + One + Addだけで実装してくれれば汎用的で分かりやすいと思う >>93 のX型でも動いたよ 特徴もないリテラルを勝手に解釈するとかあり得んわ
>>112 >>114 Stepがstable入りしたら要らなくなる話になにとんでもない破壊的変更を持ち出しているんだ
Age型をn.times().for_each()
>>119 >>112 とかありえないよ >>117 >>106 >>122 の続き >>112 をそのまま使うと >>123 の続き >>124 の続き >>93 に出てきた変なX型ですね 結局Derefみたいにコンパイラが自動的に適用して変換してくれればそのintoやfromをプログラムには書かなくて済むんやろ
ファイルを開く操作って普通に考えたらFile::open_ほにゃらら()みたいなメソッドにOpenOptionsを渡すほうが自然だと思うんですが
>>129 >>129 メソッドチェーンって過去の遺物だよね？
>>133 パイプライン演算子大好きとかLisp方面から来た人とかなのかも……
え？メソッドチェーンってjqueryが流行ってたころの名残でしょ？
>>136 >>133 >>135 >>139 >>132 通常のCのオープン関数のほうが100倍キレイで簡潔で合理的だと思うが個人差はあるんだろうな
これが美しいと言う人はそれこそ逆ポーランド次元から来た異次元人だと思うよ
おまいら日本語否定ですか。 >>144 は設計が悪いんじゃない？ >>144 ファイルを開こうと思うときにoptions型から思考がスタートする人は天才なんだろうな
言語否定じゃなくてライブラリ設計がおかしい
File::open_with_options("foo.txt", &OpenOptions::new().read(true).create(true));
OpenOptionsって名前で明らかに｢ファイル開く時のオプションですよ｣って名前なのにファイル開く操作まで持ってるから気持ち悪いんだよな
確かに他だったらoptionのインスタンスを作ってopenに食わせる感じだな
慣れない人にとっては分かりにくいAPIにならざるを得ないのは確か
>>154 >>153 > 通常のCのオープン関数のほうが100倍キレイで簡潔で合理的
OpenOptionsが分かりにくいってのはそのとおりだと思うし、実際みんなそう思ってるみたいで
>>159 >>158 >>161 仮想のコードで例が適切かどうかわからないけど
あ、ミスった
>>162 >>134 >>166 cのfopenはメソッドチェーンより簡潔だ
そんなに変わらへんやん、むしろuseで引き込む名前が増えて美しくないやん
foo(true, false, true, false) や foo(None, None, None, Some(true)) みたいな呼び出しよりは100倍マシ
ところでreadwrite()とかnewfile()ってなんですか？
OpenOptionsの名称問題はともかく
チェーンの話なら、出来るだけチェーン派が多いけど.NETのLINQみたいになったら嫌？ https://github.com/StardustDL/Linq-in-Rust >>173 >>176 >>174 それはElixirと同じ「なんちゃってパイプライン」でメソッドチェーンが実現できるというだけでは。
自由関数ってなんだっけ？
定義を示してほしいわな
何気なく使ってたけど調べてみたらC++用語だったか。しかも日本じゃ「フリー関数」という表記の方が一般的なんだな。
その意味ならElixirは自由関数も部分適用も使えると思うが・・・
そっちか。
C++でもフリー関数と言われたら free() のこと思い浮かべそうだが
>>178 >>189 >>185 その「フリー関数」とはクラスのメンバー関数ではない非メンバー関数として
メソッド呼び出しできない関数は「フリー関数」ってことでええんちゃう？
>>197 >>200 重要なのはフリー関数の定義じゃなくてパイプライン演算子の適用範囲だぞ
>>201 >>204 の続き >>201 config部分が静的に決まってるならいいけど
>>201 のコードがいいと感じる感性が理解できないよ >>201 ここまで意味不明な文章書けるのって逆に凄いよ
Javaコードの識別子の部分を日本語で書いて
普通のBuilderであまり困ったことないからなあ
>>217 >>218 >>219 ifの閉じカッコにセミコロンが必要となる条件を教えてください
>>223 >>221 の例でもif式の値は明瞭に()ですね help: consider adding semicolon after the expression so its temporaries are dropped sooner, before the local variables declared by the block are dropped
>>225 >>223 の以下の部分を >>224 >>226 >>226 すまん、投稿ミス。
ふむむ
なんでセミコロン付けると一時オブジェクトの寿命変わるんだって思ったけどそういえばC++にもそんな仕様あったな……
>>230 なんでBufReadトレイトはあるのにBufWriteトレイトは無いんですか？
>>234 flushしなけりゃ下のレイヤのどこかで勝手にバッファリングされることがほとんどだから用意する意味がないんだろな。
>>237 REPL的にコードスニペットの実行確認するために使ったりはできるのかな
Read::read_to_end()に空のVecを渡した時に戻り値のusizeとVecのlen()が違う値になる事って有り得ますか？
同じと思う
＞ loop式はbreakで指定した値を返せるのに
>>243 >>243 のダミーloop使用がベストアンサーなのか！？ >>244 結局見やすくこう書けるといいんだよね
最近知ったボクの大発見書いていい？
>>248 >>247 >>248 >>250 >>249 >>252 >>254 12次元までならiproduct!が使える
ARM版のWindowsでRustのコードを書くのってめんどくさいな
>>258 rustはどんどん新しい機能が追加されていくのはいいけど、
実際2021editionではレンジパターンの ... が削除されて ..= に一本化された
>>258 ARM は安物のイメージがある。
原理的には ARM のほうがインテル系 (もはや AMD 系と呼ぶべきか) よりも高速化できる可能性があるとは言われている。
>>267 CISCRISCの話じゃなくてメモリモデルの話ならそうかなって思う
リソースの話だけなら命令デコーダーとか？
今どきのプロセッサだと分岐予測器やキャッシュが支配的でデコーダなんて誤差だと思う
こういうことをしたいのですがコンパイルエラーとなってしまいます
namaeじゃなくてnameな
>>272 >>273 >>275 みなさんありがとうございます >>272 のように&strにする方法は無いのでしょうか？ >>279 場合によってはこれでもいいのかな？
>>281 1.40からas_derefっつうのがあるんだってさ
どの型で統一すべきかは
おそらくその通りだけど、CLIツールの初回一回だけのアロケーションにそこまでこだわるのがそもそも無駄って気もする
>>285 >>284 文字列についてはStringにするかCow<str>にするか迷うくらいならinternしちゃうのも手かと
>>281 ken okabeのqiitaの記事がまた炎上してるよ
あれ、Qiitaには垢バンされて投稿できないんじゃなかった？
ググってもよくわからないのですが、どういった方なんですか？
>>291 P2P方式の2D対戦ゲームを作りたいと考えています。
>>297 >>298 そんだけの情報ではなんともいえん。
>>300 >>299 >>302 技術を高める目的なら windows-rs や wgpu-rs みたいな一段下から積み上げるのも楽しいよ。
既出だったらすいません
>>297 VIDEO >>308 熟読はしてないけど、外部ライブラリで簡単に実現可能であるなら
C++のiostreamが失敗作だから慎重になるのもわかる笑
>>306 しかし競プロでみんなproconioとかいう謎の専用ライブラリ使ってるの見た目悪すぎて笑える
競プロ全然知らないけどstdinに入力数値がくるからか >>313 >>315 >>316 どの言語でも三項演算子(相当)はワンライナーで書くんじゃね？
これでいいかね？
俺ならこんな感じかなあ
>>321 >>322 >>315 わけわからんくてビビってたらよく見るとPythonスレじゃなかった
>>326 例えば>>321 がif式を5行に分割しているが >>328 心底どうでもいい。
区別できなかったからrustfmtを持ち出したんやろ
rustfmtを持ち出したのは俺じゃないぜ
問題文が>>314 でこうなってるから そういえばいつの間にか
>>338 間違っているコードは出ていないような
>>345 > しかし競プロでみんなproconioとかいう謎の専用ライブラリ使ってるの見た目悪すぎて笑える
Rust bookの以下の記述について質問です https://doc.rust-jp.rs/book-ja/ch19-05-advanced-functions-and-closures.html# クロージャを返却する >>348 >>342 ”動いていて”と言っているからコンパイルは通ってる前提だろう、”コードへ正誤を求める”といっているから
>>349 では常に impl を使えばよいのかというと >>349 のRust bookの例はBox化が不要なケースでBox化だから混乱しますね コンパイル通ってれば全て正解とかバカ丸出し。
型安全だったらコンパイル通れば実行時エラーにならないという点で全て正解っていうのは別に間違ってないと思うけど？
バカ丸出しにお前バカだろとわざわさ言うのもバカなんじゃなかろうか
>>360 もしかしてrustはlinuxに取り込まれるわけねーだろって言い張っていた人？
バカをスルーできないバカっているよねー >>364 25 デフォルトの名無しさん sage 2021/04/27(火) 08:00:23.09 ID:/+bIFNU8 >>23 >>26 予想が完全に外れたID:8qqh3vKrを晒し上げ♪♪♪
素でバカなんだな。。もうコンパイル通ったんで俺の仕事終わりとか現場で言ってろよ。。話にもならん。
>>362 >>369 >>369 厳密な定義でも使えない定義？Rustに特定条件下でCのような未定義になる動作あったっけ？
スレの文脈はしらんけど、
Rustの勉強を昨日から開始した。後は構造体とかかな。
コード貼ったら糞だボケだゴミだと自称上級者に罵倒されるから注意しろ
Rustはこう謳っている
すまんが、配列に入った数値の平均ってパッと出せないもんなの？
コードもゴミだったがそれ以上に考え方がゴミだったからな
>>381 ここの人たちってplaygroundとかなんで完全に動かせるコードで提示しないんだろ・・・？
普通の関数にすべきかどうかはメソッドチェーンにしたいかどうかで判断すればよろしい
>>389 >>381 >>384 >>387 >>389 IteratorExt大草原、まじに入院してほしいｗ
>>398 >>400 単にこれまで標準ライブラリに入れようとした人がいなかったか
「件数が多いと合計がオーバーフローするからその対策が欲しい用途」そんな考えがオカシイ https://doc.rust-lang.org/std/iter/trait.Iterator.html#panics-3 >>405 >>383 のstatsもその方法で平均を算出している >>406 >>407 >>408 >>409 多数あり外部で十分派なのでそこは興味ない
>>411 外部で十分と言えば、cratesは先着順で名前取れるからこの先優良ライブラリ程クソみたいな名前になっていくよね
>>413 ライブラリの永続性を保つのに名前でマッチさせるのやめてUUIDかハッシュか何かでマッチさせれば良かったのにみたいな気持ちはある
>>414 現状でもGitHubから直接落としてくることも出来るけど、GotHubのリポジトリは消せてしまうからな
cargo updateでマイナーバージョンアップやらせるのも規約決めたり工夫ご必要だし
cargoはどこからでも落とせる
永続性を謳うサービスで名前で管理したらそりゃあいい名前の取り合いになるよなあ
GoみたいにGithubがデファクトスタンダードなレジストリになっても一覧性の面で不便だし、crates.ioでいいと思うけどなあ
セキュリティ監査付きのcrates.ioクローンが欲しい
average()が気になってcratesだかcargoだか話逸らしに聞こえる
ぼぼぼ、ぼくちんのために誰か優秀なaverage()をおながいします
Why is my Rust build so slow?
Because your PC is poor spec.
>>432 高度IT人材、富士通は最大年収3500万円へ
効率を求め過ぎてモノリシックになりすぎると様々なコストが上昇してしまう
Rustでノードが追加されたり消されたりする双方向グラフ扱いたくなったらどうするんだろ
>>437 >>438 >>439 >>442 特殊な案件でしかGCを使うことはないため
ちゃんとしたスマートポインタを自作する時点で結構大変だから用途特化した方が確かによさそう
グラフみたいなデータ構造を実装するだけでも、GCが必要になったりするもんなん？
グラフ構造表現するだけならArenaや、少し安全にするならGenerationalArenaで事足りるかと
ちゃんとしたGCはないのに、参照カウントだけは標準ライブラリに入っていて循環参照には気をつけましょうねーって運用でカバーなのはなんか中途半端なものを感じる
単純にRcやArcはGCを目的としたものではないから
単なるスマートポインタをGCと言っちゃうあたり・・・
9分で轟沈したのに２時間後に死体蹴りせんでも。
>>449 >>452 とか言うやつはRust普及の足を引っ張っているだけだから、書き込みしないほうがいいと思う。 >>454 >>450 の言う通りrustのreference counting gcは >>452 の言うことも半分あってるよ。 >>450 が指摘したものしか無いよ。 学問的には参照カウントはGCの一方式として分類されるのが普通だよ
>>457 気持ち悪さは長文から来る。reference counting gcとかわざわざ参照カウントを英文で書いてカッコつける所も
文中に >> 挟むのだめなのか
>>レス番
Rustのメモリ安全性ってどうやって保証してんの？
ダメというわけじゃないが、同じ人が言ってるわけじゃないのに文中に一つにまとめて自分の考えだけを
>>465 >>465 >>469 がいつものキチガイの典型例 このスレ常駐の荒らしは以下の特徴があるから無視すればよい
>>463 >>475 そもそもだかマシン語でみりゃ
Rust書くときは常にIDEに直してもらいながら書いてるから>>476 みたいなの全然解けないわｗ >>476 Rustのメモリ安全って、null安全のことだったの？しょぼ
>>486 >>488 >>489 所有権が複製されるって表現はなんかRcを想像してしまうな
整数型とかの単純のヤツはCopyだかCloneだかをderiveしててデフォのmove semantics機能してなかった気がするな
数値型が特別扱いされているわけではない
Copyで複製されるのは所有権じゃなくて値だよね
copyだけでなくmoveされるのも対象は値
値と同時に所有権 "も" copy/moveされると捉えることもできるのでは
個人的に間違った捉え方をするのは自由だが
あんたらのお仲間他スレで暴れてばかりだよ、引き取りに来い
所有権が複製できちゃったら｢一個の値に一個の所有者｣ってルールが守れないやん(´・ω・｀)
というかCあたりの関数の引数も
Cでポインタ型の値を渡してるだけのことを
>>501 Rustは非常にシンプルで
「所有権とは、文字通り変数が値を所有できる権利のことです。」
>>511 >>511 >>489 >>509 >>510 https://doc.rust-lang.org/std/marker/trait.Copy.html に全部書いてあるけど >>515 著者のバックグラウンド見る限りC/C++の経験があるオレならRustも分かっちゃうよ？みたいな連載だから表現が慣れてなくても気にしない
うんこ言語を好意的に連載してる記事をこき下ろす性格の悪いRusterが集まる駄スレ
>>518 ｢所有権の複製｣でググってもほぼ誰も使って無い用語で草
所有権だけをすることなんてないだろうし、そんな言葉なくね
まあ無駄にややこしいだけの説明だわな。
どっちに解釈しても問題ない話の一方に固執する方がお断りだな。
所有権の複製の意味が分からん
>>519 メモリ上の動きと言語上のルールの違いもまともに理解してなさそうな連中だな。
mutの時に書き換えると元の値と別の値に出来るのだから新たな所有権が生じているのは事実
ムーブの場合は元の所有権が破棄されて新たな所有権が生成される
値を複製したらメモリの領域が別なのに｢所有権の複製｣は何を複製すると思ってんだろ
>>532 >>529 全く同じものを新しく生成するのと複製は外から見て区別しようがないんだから
所有権はコンパイル時のはなし
現実世界の所有権が複製可能な権利だったのなら
質量保存則に縛られる現実世界の複製との対比には限界があるわな。
権利のような無形物は質量保存則には縛られない
というかRustの実装のところ見ればいいんじゃね？
Ownershipを所有権と訳したから
>>543 結局はどこにも原典がないオレオレ用語でワロタ
まぁ、オープンソースですらねぇし専門家の目すら通ってない様なサイトだし
それでわかりやすくなるんなら別にいいけど、余計わかりにくくしてるってさぁ。。
ルー語で言うと｢ownershipがtransferされることをmoveって呼ぶ｣的な？
this is known as a move.
>>549 >>552 https://doc.rust-lang.org/rust-by-example/scope/move.html >>553 DeepL で翻訳してみた
「所有権の複製」とか、意味の分からない事を書いている、香具師がいるのか？
>>556 >>557 所有権が複製されるという書き方よりも、むしろ、
- 所有権ごと複製するという表現がわかりやすいかわかりにくいか⇒人それぞれ
>>556 所有権の複製では意味が通らない事は明らかなので、 >>489 の文をサクッと直してくれていいんだぞ 流れ見てると｢所有権の複製｣は
この生産性のない議論に参加している人の割合と考えればさもありなん。
>>560 所有権というか、ポインタなのか、実体なのかって考えれば所有権もすぐに理解できると思うが
>>:567
現実のものに例えると適する例がないけど
>>570 >>570 >>572 >>574 >>571 >>571 複製という用語は、2つの実体が作られたよりも、
複製という訳の問題じゃないよね
PIDとか二卵性双生児とか、根拠や脈絡がない例え話が次々に出てくるのが笑える。
>>571 は曲がりなりにも根拠らしきものを挙げているけど >>578 のPIDはまったくの根拠レスじゃん、 >>570 C++の例外をちゃんと扱うのは難しい、Rustのほうが簡単やろ
>>583 >>587 根拠があるってんなら単にrust公式から定義をひっぱってくればいいのではｗ
もう誰か本家のissueに｢CopyとMoveって何をcopy、moveしてるの？所有権のcopyっておかしい？｣って突撃してこいよw
スレ追い切れてないけど所有権だけcopy/moveしてるという主張してる人がいるの？
>>591 参照の説明に合わせてCopy Typeには所有権は無いという捉え方ならかろうじて理解はできる
>>593 Cでポインタへのポインタをダブルポインタと言い張ったり
>Cでポインタへのポインタをダブルポインタと言い張ったり
もうええやろこの話題は…こんな枝葉の問題でギャーギャー騒いでたら何も身につかんで…
所有権 → リソースの解放義務
c++23以降で契約プログラミングのサポートが入るらしいけど、rustって言語レベルで契約プログラミングサポートしてる？
1週間以上も議論が続いている原因はおそらく
そんな複雑な理屈じゃなくてただのバカが意固地になってるだけだろ。。
>>600 俺は中立派なので
>>607 一般的に「批判や反対だけならバカでもできる」と言われるので
匿名掲示板のやりとりで意見を変える人なんていないしとっとと次の話題に移るに限る
複製おじさんが必死過ぎて草www
>>597 複製おじさんは自演して複数人を装ういつもの人
所有権も複製されるとするとrustの所有権システム破綻するの？
>>614 >>613 >>614 >>614 一週間バカにされ続けても自ら学ぼうとしないメンタルすごいよな
>>617 Rustスレは
しょーゆー拳！の複製とは・・・所有してない事では・・・？それとも共有？創造イテレーターおじさん。。。
Rust 1.58で使えるようになったね
rust学習してるんだけど
勘違いかも
>>626 Rc<RefCell<T>>のように所有権が共有されてる値を変更する場合なんかは実行時チェックしかできない
実行時に動的に借用のチェックをさせたいという動機は分かるんだが
Cell<T> は Mutable<T>
あー、なるほど、名前が分かりづらいのはおれが日本人のせいなのかな、とか思ってたけど、やっぱり慣れてないと分かりづらいネーミングだったか
>>631 >>632 >>636 >>634 >>635 >>637 >>640 >>635 Boxing/UnboxingはC#やJavaにもあるからBoxには全く違和感なかったけど
Scheme でも次の規格に Box が入ることになっている。
通常の型TやBox<T>などがSend+Syncである一方
>>644 まあBox と名前を合わせてBoxCellとか逆にBoxをRefにするかした方が統一的な名前づけだったとは思う。
>>648 >>636 の使用例では全てスタック上 何も分かってねーなこいつ。
皆の言ってることがよくわからん
T -- Box<T>
RefCell<T>はTへのrefが作れるCell (実行時にborrow checkする)
「所有権の複製」がおかしいってことは納得言ってくれたん？ｗ
ダメです
それは解釈のレイヤの問題。
じゃああなたはポインタ渡しと参照渡しを間違えてもいいよ
>>658 >>657 ポインタ渡しっていう用語も使わないでほしい
rustにおいて参照渡しと言ったらどういう意味になるんだろうか
>>657 >>654 >>666 clippy様がvoldemort typeを説明せよと仰せなのだが >>668 rust勉強しはじめたばかり、C,C++はだいぶ昔少し経験がある程度
C上がりのヤツって意味のないところにconst付けがち
>>673 末尾oとかWとかで荒らしてるやつ回線なんだ？亡霊か？
ちなみにRustでのconstとはコンパイル時点で定数(どんな複雑な型でもよい)であること
>>674 >>675 すまんが、Replit使って学習してるんだけどさ VIDEO Repl.itは、リンターやデバッガーからサードパーティのパッケージ、ホスティング、デプロイまで、
コンパイル時に判明しないゼロ除算やオーバーフロー除算 ex. -128_i8 / -1_i8 はpanicとなるので
const fn divide(x:i32, y:i32) ->i32 {
>>690 >>691 とあるデータフォーマットを扱うライブラリを作っています。
エラーを捕捉したいことをデストラクタに任せない
>>694 >>695 エラーメッセージがよくわからん事になりがちだからNGか
>>696 >>692 amazon primeの記事経由でegui見てみたが結構いいな
GCは標準からは消えたけどライブラリでやればいいってかつてこのスレで言われたことがあるのだが、GCライブラリのデファクトスタンダードってどれだ
>>703 >>704 >>706 >>702 >>705 >>706 >>706 >>711 dynや lifetime heavyは失敗しながら学ぶのでいいと思う
deny(rust_2018_idioms)はガチのマジでオススメです
データ構造が大事なんだって言われながら育ってきた身としちゃあ辛い話じゃねえか
Rustで普通にやってるとスレッドセーフを強いられるから制約がキツくなるんだよね
大昔からの単純なポインタ相互参照だと
>>684 >>718 >>720 そんなのを見るのは極初期だけで些細な話
あれは害悪レベルの訳だから初期でも見ない方がいいよ
どうせ>>722 のドキュメント見ないと先へ進めないしほとんどは中学生でもわかる平易な英語 Mistake 2 : Dive in without looking at the book
>>726 一貫してるぞ
じゃあ和訳の質を話題にしている低レベルの人同士の会話はほっとけばいいのにｗ
日本語イラネ言っている人は技術資料が英語でも
和訳の質にこだわってる人たちも唯一役に立つチャンスがあるよ
和訳の質にこだわっている人たちの質にこだわっている人は何の役にたつの？
どこの食堂が美味いか話しているところに割り込んで、
>>725 とはいえ元の話は
ざんねんながら悪文どころか誤訳だらけで無料の炊き出しよりひどいのがままあるのが技術書の世界
>>738 クソ不味い飯屋にわざわざ改善案を提案するやつww
両立するよ。
>>739 >>743 日本語訳の質にこだわるような低レベルのやつはその先へ行けないため日本語訳にこだわる
和訳にイチャモン付けるだけの残念な人は「複製おじさん」を連呼する人でしたか
>>543 からの流れを見ると確かに複製おじさんは英語読めないっぽいが そんな超初心者入門のところでもめてるのかね
>>489 の文章が間違ってる、いやおかしくない、って揉めてただけだよ >>751 >>753 >>754 Rustの所有権というのは権利というよりも所有しているリソースの解放義務を指している
>>756 >>759 複製おじさん連呼する人は、もちっと具体的に指摘してくれるとありがたいんだが。
嘘ではない
>>761 >>762 >>761 ,763 > そんな超初心者入門のところでもめてるのかね
>>764 >>767 将来実現されるであろうあるべき仕様が実装の都合で実現できていないから、それと矛盾しない範囲に仕様の範囲を制限した、という理解で良い？
>Copy型は複製分岐されて各々がdropされるのが正しいけど、スタック変数のみだからそれをサボっている。
>>767 >>773 >>774 >>774 いつも傍から見ていてパターンがわかってきた >>771 のように「勝手な思い込みの妄想で嘘」と否定するだけだったり >>774 のように「正しいという根拠は？」とこれも同じパターン >>775 >>779 >>781 Copyを実装する型の変数にはそもそも所有権が存在しないということかな。
ソケット、ファイルハンドラあたりがコピーされたらそら問題だろうからな。
>>782 値が複製されることに異論は無いんだけど、彼は>>753 などで所有権が複製されると言っていて、そこがおかしい。 たとえ話って逆に理解を妨げることも多いよね(´・ω・｀)
複製おじさんにも唯一役に立つチャンスがあるよ
複製おじさん大人気だな
Rustの学習してるのですが、モジュールがどう使われるものなのかいまいち想像がつきません
なんで所有権が複製分岐なんていう言葉を発明しちゃうんだろな
>>791 複製は値と所有権のペアがまるごと複製されるというイメージでわからなくもないが分岐は本当によくわからない
>>792 複製おじさん自演認定連呼の人も大概だけどな
変数毎のメタデータに所有権管理のためのフラグか状態変数があってその値も複製されるイメージだったんでしょ
>>784 複おじはまずコテハンかトリップつけてほしい
>>799 で合ってると思う私も何か勘違いしてる？ >>803 >>804 >>802 >>799 で正しい。 「所有権が複製される」のではなくて、「値が複製されるとき、複製された値には新しい所有権が生まれる」と表現すべき、ってこと？
>>806 単なる揚げ足取りでしょ
あちこちでrustおじさんが暴れてるんだけどこのスレでも暴れてんのな
>>808 論理性がない、客観性もない、実績もないのに上から目線の奴いるよね
>>812 所有権を実装の観点からだけ見た場合はCopy型に所有権は(設定されて)ないと考えるのは妥当
>>808 >>818 TRPLの説明では take ownership という表現も登場するし辞書的な意味で ownership が使われているのでルールのことを指すだけではないようだ
Each value in Rust has a variable that’s called its owner.
aという変数が持つ1という値とそのownershipがまとめて複製されてbに渡されると思えば、owenershipの複製という言葉も不自然ではないように思う
それは単に値のコピーですやん
>>824 >>824 >>827 オーナーシップの説明にオーナーシップを使っているのか
所有権をCopyするって書くのをやめて、値をCopyする、にしてくれればそれで済むのに、なぜ所有権の複製を正当化しようとするのか
べつに値をコピせずに所有権だけコピーするとか言っているわけでもなし、そんなに問題かね？
>>824 let a = 1; は値1の所有権をaが持つということ
Copy実装型にも所有権はあって借用ルールに従う
複製するという言い方は、複数の権利者が
どうでもいいならそれでいいんだけどね
>>836 その通り
wwww
>>835 OwnershipのルールとReferenceのルールが整理できてないんだね
>>836 >>844 >>836 の説明で納得した >>836 >>846 複製派の人って複製元の所有権と複製先の所有権の
>>848 じゃあ「所有権」って言葉を使うのもやめることを提案してみたら？
>>849 >>848 >>849 リアルな世界では土地もその所有権も複製できないけど
こまけえこたあ良いんだよ！！ コンパイラ黙らせた奴の勝ち！！
>>852 >>847 そもそも発端は入門者向けドキュメント >>486 にて、「所有権の複製（コピー）」とかいう言葉が出てきてこれではダメだ、っていうのが発端だからね 結局のところ元の記事にあったように
>>858 土地は複製できないって主張もよくわからなくて
>>857 リソースの所有者はリソースを解放する責務がある
ここで"もの"かそうでないかを区別する意味ってある？その場合の"もの"ってなに？
所有権とは所有にまつわるルールのことというのはTRPLに書いてある通りだと思うんだが
所有権の話はもう禁止してくれ、唾飛ばしながら「ワイが一番所有権分かってるぞ！」とかほんまどうでもいいわ
>>868 が言ってる通り公式ドキュメントと矛盾がないように書くべきでしょ >>866 の最初に書かれてることは良いけど、そのあとは意味不明 この自演おじさん、そこらじゅうで同じ芸風で荒らし回ってるから本当にタチ悪い。
結論：
>>868 >>875 unixのファイルシステムの権限周りの継承とかその辺とごっちゃになってんのかね？
謎だよな
>>876 >>879 所有権ルールと参照ルールを混同してたり
ここまで見てる限りどっちでもOKな話だな
>>886 >>870 で正しいの書いてくれてるのに、公式でもそうなってるのに何故に頑なに所有権の複製を広めようとしてるのよ笑食べて Rustの公式ドキュメントを調べると "copy of the value" という表現はたくさん出てくるが、 "copy of the ownership" のような表現は見つけられない https://rustc-dev-guide.rust-lang.org/contributing.html ownership の take や transfer という言葉が出てくるのは !Copy な値についての説明で、
>>886 >>836 >>868 >>888 >>890 個人が複製を分かりやすいと思うのは自由だけど
自分の理解不足を何で公式の落ち度みたいにすり替えてるんだ。間違いを認めたら死んじゃう病なの？
>>881 勘違い勘違い言うけど>>808 以上の話じゃないように思うんだが。 自分も>>808 で良いと思うけど公式の説明と表現が同じになってるかは気になる >>808 >>808 を肯定する連中はRustをわかっていない 複製オジが遂に撤退戦をはじめたかw
>>900 流れぶった切ってすまんけど質問
>>902 >>904 ownerに対する所有権があるような話になってよくわからんね。
>>903 >>905 >>908 >>909 >>900 俺は初心者なのでフワッとすら分かっておらず、このスレでは一体何が議論になっているのかよく分からない。
>>910 学術的に使われた用語だからテクニカルタームではないな
freeに渡すアドレス値を「入れ物」と呼ぶか「値」と呼ぶかでもめているように見える
>>914 >>918 >>919 >>920 所有権を持つのは値じゃなく変数
>>921 値に対する所有権を変数が持つってことなら>>808 は特におかしいとは思わないが？ >>900 の方が理解しにくい。 >>922 >>921 >>923 なんでこのスレでは操作的意味論とC言語とRustをちゃんぽんして語ってるの？
>>926 >>929 >>929 >>926 の質問に答えてください >>930 >>931 >>929 を理解する読解力を身に着けてください >>933 >>926 の変数i,s,sss,aに入っているのはアドレスではありません >>934 >>934 間違いを認めたくないおじさんが延々と言い訳するスレ
ID:6AYXkq/G氏は >>919 で「それらの変数にはすべてそれぞれの実体が入っています アドレスではありません」 >>921 で「失礼しました 配列は先頭要素のアドレスが変数に格納されるでしょう」 >>935 >>939 cのfreeは値「で」解放してるだけなんだけどなｗ
>>941 >>944 >>945 >>926 だとして、 >>947 >>942 >>948 >>947 は意地悪だったけど、何が言いたいかっていうと、 おまえらって基本マジメなんやろな何か
最適化で消えるようなもんが言語仕様なわけ無いですもんなー
>>949 https://linuxjm.osdn.jp/html/LDP_man-pages/man2/close.2.html >>951 >>952 >>955 >>925 >>941 >>957 >>958 6AYXkq/Gを相手にしても無駄だから元の話に戻りましょう >>808 について自分の意見は >>961 >>961 >>961 「変数が所有権を持つ」よりも、「変数が値を所有する」のほうがいいか
主語と目的語を逆に違う意味に誤解されるとわかったので補足します >>962 >>963 >>964 の言う変数を持ち出したほうがマシ >>964 >>967 俺が入れ物に対して所有権があると>>900 で書いたのも実質その型のインスタンスだ 実際のところ「値」と「インスタンス」の間にそんなに意味の差はないです。
>>971 >>972 >>967 そもそも「所有権を持つ」ってのが苦しい https://doc.rust-lang.org/book/ch04-01-what-is-ownership.html >>961 の中から選ぶなら変数が所有権を持つだけど、最初に書いたようにそもそも「所有権を持つ」が苦しいので、 >>965 >>973 ああ、別に「持つ」を必ずしも "own" で訳す必要もないね
>>974 >>975 >>976 >>972 とりあえずbookの https://doc.rust-lang.org/book/ch04-01-what-is-ownership.html ） >>981 >>982 に明記されているように所有権を持つ所有者は変数 >>982 インスタンスというのも一理ある
横からすまんが、実際のメモリ上だと所有権ってどうなってるもんなの？ >>982 にある仕組みからしたら・・・・メモリが確保されるのと同時に、併せて所有権情報（スタックへの参照か何か？）がメモリのどっか確保されるわけ？ 横からキターーー
struct S;
>>961 無教養のガイジども阿鼻叫喚していて草ｗっｗｒ
lud20220923011912ca
このスレへの固定リンク： http://5chb.net/r/tech/1636247099/ ヒント： 5chスレのurlに
http ://xxxx.5ch
b .net/xxxx のように
b を入れるだけでここでスレ保存、閲覧できます。
TOPへ TOPへ
全掲示板一覧 この掲示板へ 人気スレ |
Youtube 動画
>50
>100
>200
>300
>500
>1000枚
新着画像 ↓「Rust part13 YouTube動画>2本 ->画像>1枚 」 を見た人も見ています：・Naru Sato Rust vs Go Rust part9 Rust part8 SUPER GT+ PUSHIM Part1 Rust part14 Rust part15 Rust Part6 Rust Part5 Rust Part7 Rust part10 C++ vs Rust Rust part12 Rust part6 Rust part11 Porteus Linux Nexus 5X Part30 Castle Burn OnePlus Part96 OnePlus Part87 OnePlus Part79 JUSWANNA Part.3 OnePlus Part81 Nexus 5X Part26 OnePlus Part94 Oneplus Part.4 Oneplus Part.5 Nexus 5 Part106 OnePlus Part46 Nexus 6 Part34 OnePlus Part20 Duelyst Part6 OnePlus Part91 OnePlus Part95 mist survival OnePlus Part29 OnePlus Part77 OnePlus Part34 OnePlus Part22 ZOZOUSED part1 BEAT CRUSADERS 79 IPLE HOUSE Part5 OnePlus Part72 A-Studio Part4 Rustアンチスレ OnePlus Part57 Android Studio 2 OnePlus Part10 iPhone6Plus Part4 Infected Mushroom Russkij Avanpost DE DE MOUSE☆Part3 Lost Frequencies BURST in パンク板 STU48専用 うたコン Change Request. CRUSTスレ Part.13 乃木坂46専用 MUSIC FAIR Houston Rockets 68 trap houseってなに？ Houston Rockets 67 the HIATUS Part 60
01:45:07 up 22 days, 2:48, 0 users, load average: 8.52, 11.65, 14.00
in 0.063818216323853 sec
@0.063818216323853@0b7 on 020415
