21/12/19 10:13:36.41 1R2jF/rb.net
>>321
なるほど
じゃあ最初の標準ライブラリのみはどのように分けるのかな
println!("{}", if BufReader::new(stdin()).lines().next().unwrap().unwrap().split(' ').any(|s| s.parse::<isize>().unwrap() & 1 == 0) { "Even" } else { "Odd" });
329:デフォルトの名無しさん
21/12/19 10:17:01.07 KXG/wmTu.net
>>322
proconio使うｗ
Rustで競プロするにはIOごときに専用ライブラリ使うことになってなんかなあって思うけど、そう思いながら使う
330:デフォルトの名無しさん
21/12/19 12:54:53.29 XhCh7cuL.net
>>315
ワンライナーやクロージャでまとめて書くと所有権やライフタイムの問題が出にくいんだよ
他の言語と違ってRustで適切に分割して読みやすく書くのは初心者には難しい
331:デフォルトの名無しさん
21/12/19 13:44:27.43 JD8Mu2Jr.net
わけわからんくてビビってたらよく見るとPythonスレじゃなかった
332:デフォルトの名無しさん
21/12/19 15:04:40.83 9UFbsF2U.net
rustfmt使うでしょ普通
333:デフォルトの名無しさん
21/12/19 21:36:12.89 1R2jF/rb.net
>>326
println全体が改行されてしまった
println!(
"{}",
if BufReader::new(stdin())
.lines()
.next()
.unwrap()
.unwrap()
.split(' ')
.any(|s| s.parse::<isize>().unwrap() & 1 == 0)
{
"Even"
} else {
"Odd"
}
);
一方で分割するとこうなった
let cond = BufReader::new(stdin())
.lines()
.next()
.unwrap()
.unwrap()
.split(' ')
.any(|s| s.parse::<isize>().unwrap() & 1 == 0);
println!("{}", if cond { "Even" } else { "Odd" });
if式自体はワンライナーーで正解とrustfmtはおっしゃってる
334:デフォルトの名無しさん
21/12/19 21:50:26.03 gPlFWszB.net
ワンライナー云々はフォーマットの話ではないやろ
335:デフォルトの名無しさん
21/12/19 22:05:50.34 1R2jF/rb.net
例えば>>321がif式を5行に分割しているが
それもrustfmtにより1行に修正された
Rust標準ライブラリのソースでもワンライナー
bool.rs: if self { Some(t) } else { None }
result.rs: let n = if self.inner.is_some() { 1 } else { 0 };
time.rs: let prefix = if f.sign_plus() { "+" } else { "" };
>>328
では何の話かね？
336:デフォルトの名無しさん
21/12/19 22:37:44.04 D79ys1jH.net
構造と書式を区別できんのはヤバイで
337:デフォルトの名無しさん
21/12/19 23:10:30.41 ZhiL7Huf.net
心底どうでもいい。
保守性に貢献するどころかマイナスになるようなクソプライドコードの導入すんなよ。
338:デフォルトの名無しさん
21/12/19 23:14:48.39 4jRnwXL4.net
また性懲りもなくコードべたべた書いてんのか
339:デフォルトの名無しさん
21/12/19 23:21:45.51 cDs+Q4pL.net
rustfmtだから書式の話やで
340:デフォルトの名無しさん
21/12/19 23:25:17.24 /BRS7QS/.net
区別できなかったからrustfmtを持ち出したんやろ
どこに改行入れるべきかって話だと思ったんだろなww
341:デフォルトの名無しさん
21/12/19 23:41:46.15 1R2jF/rb.net
rustfmtを持ち出したのは俺じゃないぜ
あと今回のケースならここは分割するよな
let reader = BufReader::new(stdin());
let line = reader.lines().next().unwrap().unwrap();
let is_even = line.split(' ').any(|s| s.parse::<isize>().unwrap() & 1 == 0);
342:デフォルトの名無しさん
21/12/19 23:48:52.91 m2ZvKw+8.net
汚コード
343:デフォルトの名無しさん
21/12/19 23:59:56.43 cDs+Q4pL.net
問題文が>>314でこうなってるから
>> | 入力は以下の形式で標準入力から数値が与えられる。
>> | a b c d e
if let [a, b, c, d, e] = line
.splitn(5, ' ')
.map(|s| s.parse::<isize>().unwrap())
.collect::<ArrayVec<_, 5>>()[..] {
あとこれでいい
let is_even = a & b & c & d & e & 1 == 0;
344:デフォルトの名無しさん
21/12/20 05:23:59.31 XPDM+Al+.net
そういえばいつの間にか
let variable = 3;
println!("{variable}");
みたいな書き方が出来るんだけどこれ前からだっけ？
345:デフォルトの名無しさん
21/12/20 05:50:08.07 MpI5dMic.net
>>338
それはまだnightlyだけですよ
来月の1.58からstableになって使えるようになる予定
346:デフォルトの名無しさん
21/12/20 11:31:40.46 vxPhPqzv.net
>>335
構造化の基本を学びましょう
347:デフォルトの名無しさん
21/12/20 18:38:24.90 +mZvzmRI.net
どちらのコードも正解
348:デフォルトの名無しさん
21/12/20 18:57:17.41 rubGoZ9q.net
コードに「間違い」はあっても「正解」はない
349:デフォルトの名無しさん
21/12/20 19:04:29.92 MpI5dMic.net
間違っているコードは出ていないような
問題視してる人は具体的に何を問題にしているの？
350:デフォルトの名無しさん
21/12/20 20:55:59.37 lwZpjeWf.net
アスぺ思考はこれだから
351:デフォルトの名無しさん
21/12/21 11:25:19.41 TTfv6HaA.net
URLﾘﾝｸ(doc.rust-jp.rs)
ここの最後のところに
パターンと関わるマッチガードの優先度は、以下のように振る舞います:
(4 | 5 | 6) if y => ...
以下のようにではありません:
4 | 5 | (6 if y) => ...
とあるんですが、後者のようになってほしい場合は4|5と6 if yを別々に書くしか無いですか？
352:デフォルトの名無しさん
21/12/21 11:56:47.99 BV9oeByN.net
>>345
ガード構文がこう「『Pattern』 if 『Expression』」なのでそうなりますね
353:デフォルトの名無しさん
21/12/22 20:44:35.79 7pEHjDF/.net
sixtyfpsってどう？
354:デフォルトの名無しさん
21/12/22 22:58:00.27 mfli1g17.net
> しかし競プロでみんなproconioとかいう謎の専用ライブラリ使ってるの見た目悪すぎて笑える
いや、ほぼ公認のクレートなんだが・・・
謎の専用ライブラリとかいってる時点で、お察しか？
あと、見た目悪いってどういうことなんかね
includeしたら見た目悪すぎなわけ？
355:デフォルトの名無しさん
21/12/22 23:53:48.10 Wk3NOZd2.net
Rust bookの以下の記述について質問です
URLﾘﾝｸ(doc.rust-jp.rs)クロージャを返却する
> 以下のコードは、クロージャを直接返そうとしていますが、コンパイルできません:
>
> fn returns_closure() -> Fn(i32) -> i32 {
> |x| x + 1
> }
> コンパイラには、クロージャを格納するのに必要なスペースがどれくらいかわからないのです。
> この問題の解決策は先ほど見かけました。
>
> fn returns_closure() -> Box<Fn(i32) -> i32> {
> Box::new(|x| x + 1)
> }
とBox化しなさいと書かれているのですが
以下のようにimplを付けるとBoxを使わなくてもコンパイルが通り動きました
fn make_closure_add1() -> impl Fn(i32) -> i32 {
|x| x + 1
}
このimpl付加は暗に自動的にBox化されているということなのでしょうか？
356:デフォルトの名無しさん
21/12/23 00:23:38.98 p+r9sE2/.net
ここを読む
URLﾘﾝｸ(doc.rust-lang.org)
357:デフォルトの名無しさん
21/12/23 07:21:11.33 esNMmzKz.net
>>348
そりゃあcratesio に上がったものは空っぽでもゴミでも全部公認だわなｗ
358:デフォルトの名無しさん
21/12/23 15:17:54.33 BEeWZFks.net
>>342
逆だ、コードは常に「正解」で動いていて「間違い」ない。
あんたの書いたバグもコンピューターにとっては一部の隙もなく正解であり、書かれたその通りに動き、無慈悲である。
同じ目的で、多数、あるいは二人の人が書いたコードで違いが出るのは「表現の違い」であり「間違い」と決めつける
のは人間の主観や嗜好でしかなく、仮にコードへ正誤を求めるなら明確に表現できていなればならず、矛盾が生じる
359:デフォルトの名無しさん
21/12/23 15:32:21.87 GoKXBRn5.net
コンパイルが通らないコードも正解なのかい？
360:デフォルトの名無しさん
21/12/23 15:39:30.16 9VjYa60R.net
えらいポエミーやな
361:デフォルトの名無しさん
21/12/23 18:55:13.24 TD851Muu.net
”動いていて”と言っているからコンパイルは通ってる前提だろう、”コードへ正誤を求める”といっているから
仮にコンパイルが通らないコードは明確にそれ（誤り・間違い）が表現できている
ポエミーなのはその通りだろう
362:デフォルトの名無しさん
21/12/23 21:22:53.78 NwYcCv97.net
>>349
Boxとはヒープを使うということです
Rustではコードで明示的に指定しない限り勝手にヒープが使われることはないです
(もちろんBox以外にもVecやStringなどヒープを使うものを使ってもそれは明示的に指定したことになります)
その Box<Fn(i32) -> i32> は今は Box<dyn Fn(i32) -> i32> と書く必要があります
では本題の impl Fn(i32) -> i32 と書いた場合はどうなるのでしょうか？
以下のように3種類のクロージャを作ってサイズや型を表示させてみると
fn main() {
let direct_closure = |x: i32| x + 1;
let impl_closure = make_impl_closure();
let box_closure = make_box_closure();
println!("{} {}", std::mem::size_of_val(&direct_closure), type_of(&direct_closure));
println!("{} {}", std::mem::size_of_val(&impl_closure), type_of(&impl_closure));
println!("{} {}", std::mem::size_of_val(&box_closure), type_of(&box_closure));
}
fn make_impl_closure() -> impl Fn(i32) -> i32 {
|x| x + 1
}
fn make_box_closure() -> Box<dyn Fn(i32) -> i32> {
Box::new(|x| x + 1)
}
fn type_of<T>(_: &T) -> &'static str {
std::any::type_name::<T>()
}
実行結果は以下のように表示されます
0 tmp::main::{{closure}}
0 tmp::make_impl_closure::{{closure}}
16 alloc::boxed::Box<dyn core::ops::function::Fn<(i32,)>+Output = i32>
つまりimplでは直接クロージャ指定したのと全く同じです
(上記では定義した関数名だけが異なる)
363:デフォルトの名無しさん
21/12/23 21:33:09.04 soQwByyI.net
今日はポエマー多いなw
364:デフォルトの名無しさん
21/12/23 22:34:57.88 NwYcCv97.net
では常に impl を使えばよいのかというと
以下のような条件によって異なるクロージャを返す時
ここで Box を使わず impl Fn(i32) -> i32 にしようとすると
2つのクロージャの型が違うとコンパイラに怒られます
fn make_closure(curry: Option<i32>) -> Box<dyn Fn(i32) -> i32> {
if let Some(curry) = curry {
Box::new(move |x| x + curry)
} else {
Box::new(|x| x + 1)
}
}
結局クロージャでない場合と同じ話で
同じトレイトでも型が異なるものが同居する時にBox化します
>>349のRust bookの例はBox化が不要なケースでBox化だから混乱しますね
365:デフォルトの名無しさん
21/12/24 11:53:17.86 8qqh3vKr.net
コンパイル通って�
366:黷ﾎ全て正解とかバカ丸出し。 厳密な定義でも使えない定義があるってことすら理解してなさそう。
367:デフォルトの名無しさん
21/12/24 12:05:46.49 0hdsBqvb.net
型安全だったらコンパイル通れば実行時エラーにならないという点で全て正解っていうのは別に間違ってないと思うけど？
これにケチつけるのは流石にどうかと
368:デフォルトの名無しさん
21/12/24 12:44:01.96 2tHLRFeD.net
バカ丸出しにお前バカだろとわざわさ言うのもバカなんじゃなかろうか
369:デフォルトの名無しさん
21/12/24 15:42:15.21 8qqh3vKr.net
>>360
実行時エラーにならないなんて最低限のところだっつーの。だからバカだっていうんだよ。
370:デフォルトの名無しさん
21/12/24 16:05:46.66 GD01KKAb.net
もしかしてrustはlinuxに取り込まれるわけねーだろって言い張っていた人？
予言外していたよね。お疲れ様です。
371:デフォルトの名無しさん
21/12/24 16:08:19.93 7q1GmIfa.net
バカをスルーできないバカっているよねー
>>364
お前の事な
372:デフォルトの名無しさん
21/12/24 16:10:39.10 GD01KKAb.net
なんか草
373:デフォルトの名無しさん
21/12/24 16:20:12.59 GD01KKAb.net
25 デフォルトの名無しさん sage 2021/04/27(火) 08:00:23.09 ID:/+bIFNU8
>>23
あのね。。書けばそうなるってものじゃなくてそれを実装しなきゃならんのよ。。
コンパイラにそういったコンテクストを判断させるのがめちゃくちゃ難しいっていってるでしょ？
なんでそんなに読み取れないの？
27 デフォルトの名無しさん sage 2021/04/27(火) 16:10:45.63 ID:/+bIFNU8
>>26
だからそのコードじゃpanic捉えきれねーからカーネルに入れるわけねーだろって
言ってんじゃん。。何読んでんだよ。
28 デフォルトの名無しさん sage 2021/04/27(火) 18:23:48.67 ID:n/AWrch2
まあ半年後どうなるかで誰が正しかったかは分かるわな
29 デフォルトの名無しさん sage 2021/04/27(火) 20:32:29.92 ID:/+bIFNU8
半年も経たなくてももうわかってるっつーの。。だからちゃんと英語の勉強しましょうね。
完全に同一人物だよね
374:デフォルトの名無しさん
21/12/24 16:26:02.78 GD01KKAb.net
URLﾘﾝｸ(lkml.org)
英語読めんならこれになんて書かれているのかわかるよね？
375:デフォルトの名無しさん
21/12/24 16:31:02.04 GD01KKAb.net
予想が完全に外れたID:8qqh3vKrを晒し上げ♪♪♪
ここまで簡単な予想を外すとかバカ過ぎて生きていけなさそうｗｗｗ
馬鹿丸出しですねｗｗｗｗｗｗ
376:デフォルトの名無しさん
21/12/24 16:40:31.03 8qqh3vKr.net
素でバカなんだな。。もうコンパイル通ったんで俺の仕事終わりとか現場で言ってろよ。。話にもならん。
377:デフォルトの名無しさん
21/12/24 16:42:14.31 /xk3NPni.net
>>362
最低限の性質を満たしている⇔正解って言ってんじゃん。。何読んでんだよ。
なんでそんなに読み取れないの？
だからバカだっていうんだよ。
だからちゃんと日本語の勉強しましょうね。
378:デフォルトの名無しさん
21/12/24 16:45:16.93 /xk3NPni.net
>>369
なお予言を外したことについては一貫してノータッチｗｗｗｗｗ
話をしたくないのは君だよねｗｗｗｗｗｗ
379:デフォルトの名無しさん
21/12/24 16:46:19.44 /xk3NPni.net
>>369
同一人物だってことはバレバレだっつーの。バカ丸出し。ｗｗｗｗｗｗｗｗｗｗ
380:デフォルトの名無しさん
21/12/24 17:12:05.04 jmk0MHfo.net
どうでもええわRustの話しろ
381:デフォルトの名無しさん
21/12/24 17:38:56.03 8qNIErj3.net
厳密な定義でも使えない定義？Rustに特定条件下でCのような未定義になる動作あったっけ？
382:デフォルトの名無しさん
21/12/24 18:41:11.93 759ZBatD.net
スレの文脈はしらんけど、
Rustではunsafeを使ってなければコンパイラが、未定義動作が起きないということや、データ競合がないことを保証をしてくれるよ
383:デフォルトの名無しさん
21/12/24 19:10:24.57 /xk3NPni.net
>>369
予言外れましたよね？ｗｗｗｗｗｗｗｗ
384:デフォルトの名無しさん
21/12/25 15:28:33.08 lsYj53Mi.net
Rustでフロントエンドしてる奴おる？
385:デフォルトの名無しさん
21/12/26 12:56:45.57 NwCcamJz.net
Rustの勉強を昨日から開始した。後は構造体とかかな。
386:デフォルトの名無しさん
21/12/26 17:26:13.09 r
387:Nqv+UWs.net
388:デフォルトの名無しさん
21/12/26 19:27:36.42 IL2U4vJU.net
Rustはこう謳っている
>なぜRustか？
>パフォーマンス
>信頼性
>生産性
真っ向から反するコードを貼ってりゃゴミ・クソ言われて当然なんだよなぁ
389:デフォルトの名無しさん
21/12/26 19:29:23.79 Haex5ds9.net
すまんが、配列に入った数値の平均ってパッと出せないもんなの？
他言語でふにゃふにゃになった俺の頭でコードを書いたら、桁の溢れとか精度とか酷えことになりそう・・・・
390:デフォルトの名無しさん
21/12/26 20:24:04.94 s+fXV5dW.net
コードもゴミだったがそれ以上に考え方がゴミだったからな
391:デフォルトの名無しさん
21/12/26 20:42:21.32 M+F+5/6j.net
>>381
これ使ったらよいのでは
URLﾘﾝｸ(docs.rs)
392:デフォルトの名無しさん
21/12/26 22:30:25.75 L9HJqboW.net
>>381
普通に平均を求めるだけではダメなのでしょうか？
fn main() {
assert_eq!(5.5, (1..=10).average());
assert_eq!(6.8, [2.3, 8.7, 9.4].average());
}
use num::ToPrimitive;
trait Average {
fn average(self) -> f64;
}
impl<I> Average for I
where I: IntoIterator, <I as IntoIterator>::Item: ToPrimitive,
{
fn average(self: I) -> f64 {
self.into_iter().fold((0.0, 1.0), |(ave, size), n| (ave + (n.to_f64().unwrap() - ave) / size, size + 1.0)).0
}
}
393:デフォルトの名無しさん
21/12/27 00:09:24.17 wxukv015.net
カハンの加算アルゴリズムというのがある
394:デフォルトの名無しさん
21/12/27 09:11:03.63 9DXmjbrK.net
汚コードｷﾀ━！
395:デフォルトの名無しさん
21/12/27 10:50:10.93 BFpPIAiX.net
何でもトレイト化するアホ
396:デフォルトの名無しさん
21/12/27 12:29:15.17 PxL7gTAR.net
ゴミをゴミだといって何が悪い！
397:デフォルトの名無しさん
21/12/27 12:32:52.22 OyINMfYQ.net
ここの人たちってplaygroundとかなんで完全に動かせるコードで提示しないんだろ・・・？
アドバイス貰うにも回答するにも一生懸命スペース全角置換したり、まじ両方キモイｗ
trait Averageｗｗｗｗｗ
398:デフォルトの名無しさん
21/12/27 13:09:28.61 PX/mZ8bI.net
こう言う時って普通の関数にしちゃいかんの？
399:デフォルトの名無しさん
21/12/27 14:19:38.18 Btn3kp2t.net
普通の関数にすべきかどうかはメソッドチェーンにしたいかどうかで判断すればよろしい
400:デフォルトの名無しさん
21/12/27 14:43:10.42 0vghZEjd.net
>>389
playgroundでは自己顕示欲が満たせないんだよw
まあplaygroundでは動かせないコードもあるけどな
401:デフォルトの名無しさん
21/12/27 15:03:42.29 6JVZDUUj.net
>>381
こういう子は、移動平均出したくなった時とかどうすんだろ…
愚直に毎回平均出す関数とか使っちゃうわけ？
402:デフォルトの名無しさん
21/12/27 21:04:27.03 K3JIQJJi.net
しょうがない、一応は専門家が書いているであろう他言語の実装を参考にしよう・・・・
URLﾘﾝｸ(source.dot.net)
俺様、信頼して使っていたメソッドの衝撃の事実を知る
403:デフォルトの名無しさん
21/12/27 21:09:19.15 h+0xE8z4.net
浮動小数点型ならそういう素直な実装で十分だよ
404:デフォルトの名無しさん
21/12/27 21:53:06.04 N7w3YVE+.net
>>384
それだと桁溢れは防止できているが誤差蓄積の対処ができていない
もう一つパラメタを増やしてこうしたほうがいい
fn average(self: I) -> f64 {
self.into_iter().fold((0.0, 1.0, 0.0), |(ave, size, fix), n| {
let diff = (n.to_f64().unwrap() - ave) / size - fix;
let new_ave = ave + diff;
(new_ave, size + 1.0, (new_ave - ave) - diff)
}).0
}
>>387
イテレータメソッド化するにはそのためのtrait宣言が必須
もしわからないならitertoolsなどのイテレータ拡張ライブラリを見よう
>>389
標準ライブラリのsum()がtrait Sumを使っているからtrait Averageでもまあいいとは思う
ただし今回はイテレータメソッド拡張のみに用いているようだからtrait IteratorExtなどの命名がわかりやすいとは思う
405:デフォルトの名無しさん
21/12/27 21:56:50.25 20E7BwbM.net
IteratorExt大草原、まじに入院してほしいｗ
406:デフォルトの名無しさん
21/12/27 22:01:57.73 6/3kWl6D.net
イテレータメソッドにする必要ある？
407:デフォルトの名無しさん
21/12/27 22:15:24.91 N7w3YVE+.net
>>398
標準ライブラリにおいてsum()やproduct()
それを一般化したfold()やreduce()
さらにmax()やmin()など当然イテレータメソッドになっている
むしろ今回のaverage()だけをイテレータメソッドにしない理由が見当たらない
408:デフォルトの名無しさん
21/12/27 22:20:18.56 6/3kWl6D.net
>>399
じゃあなんで標準ライブラリにないの？
409:デフォルトの名無しさん
21/12/27 22:25:16.01 h+0xE8z4.net
カハンの加算使ったのか
410:デフォルトの名無しさん
21/12/27 22:31:56.63 /o/Y1bP3.net
>>400
入力型と出力型で大量の組み合わせ(例:i32→f32)が用途に応じて要求されるのと
単純に合計をサイズで割った平均でよい用途もあれば
件数が多いと合計がオーバーフローするからその対策が欲しい用途もあれば
桁が大きく異なるデータ列の場合に浮動小数点の誤差改善が欲しい用途など多岐にわたる
だから平均を標準ライブラリで何か一つ用意は無理
411:デフォルトの名無しさん
21/12/27 22:51:58.74 Btn3kp2t.net
単にこれまで標準ライブラリに入れようとした人がいなかったか
そういう人はいたが必要性を説得できなかっただけでしょう
sumやproductに比べるとユースケース限られるしね
412:デフォルトの名無しさん
21/12/27 23:21:10.48 iNGO9QKv.net
"ave"のせいで頭に入ってこない
413:デフォルトの名無しさん
21/12/28 00:10:56.21 THzUMFur.net
「件数が多いと合計がオーバーフローするからその対策が欲しい用途」そんな考えがオカシイ
sumですらオーバーフローに言及しているだけで対策が欲しいから、だからstdじゃないという理由では無い
URLﾘﾝｸ(doc.rust-lang.org)
When calling sum() and a primitive integer type is being returned, this method will panic if the computation overflows and debug assertions are enabled.
必要性を説得出来ないだけというのが正しい。浮動小数の加減算による誤差蓄積だって、浮動小数を扱うなら当然起こることだが
誤差改善が欲しい用途があるからstdじゃないとか嘘ばっかり言わないで？おまえさ、迷惑だからRust辞めてくれよ？
最小限、分かったふりで糞まき散らすな？
414:デフォルトの名無しさん
21/12/28 00:45:10.69 vzPVHyZI.net
>>405
それは君が無知
平均算出にはsumを求めずとも差分を逐次的に適用するアルゴリズムがあるoverflowを回避する対策で一般的に使われている
例えば>>383のstatsもその方法で平均を算出している
sumの例を出すのは見当違い
415:デフォルトの名無しさん
21/12/28 00:52:41.14 We8KhoPF.net
>>406
アルゴリズムの話じゃなくてstdに入ってない理由の説明がおかしいという指摘だと思うよ
言葉汚いし何言ってるかわかりづらいけど
416:デフォルトの名無しさん
21/12/28 01:20:29.34 vzPVHyZI.net
>>407
stdに入ってない理由？
一長一短ある複数のアルゴリズムがあるから外部でいいだろう
417:デフォルトの名無しさん
21/12/28 01:57:17.15 We8KhoPF.net
>>408
その理屈だとsortも該当するが
そもそも前提としてaverageをstd
418:デフォルトの名無しさん
21/12/28 02:00:22.76 We8KhoPF.net
>>409
途中で書き込んでしまった
そもそもaverageか類似の関数をstdに取り込む議論が過去にあったならそれをポイントしてほしい
419:デフォルトの名無しさん
21/12/28 02:37:31.31 vzPVHyZI.net
多数あり外部で十分派なのでそこは興味ない
sortは2種類しかなく2種類とも標準ライブラリでサポートしている
420:デフォルトの名無しさん
21/12/28 09:30:51.41 y5zg5Cpt.net
>>411
じゃ一番メジャーな外部ライブラリを教えてよ
421:デフォルトの名無しさん
21/12/28 10:24:44.25 ZpntEDp9.net
外部で十分と言えば、cratesは先着順で名前取れるからこの先優良ライブラリ程クソみたいな名前になっていくよね
422:デフォルトの名無しさん
21/12/28 10:41:12.74 zga8SsrA.net
>>413
マジでこれ
いい名前取るだけ取って何年も放置とか多すぎ
なんかいい方法無いかねぇ…
423:デフォルトの名無しさん
21/12/28 11:15:50.74 ZpntEDp9.net
ライブラリの永続性を保つのに名前でマッチさせるのやめてUUIDかハッシュか何かでマッチさせれば良かったのにみたいな気持ちはある
424:デフォルトの名無しさん
21/12/28 11:32:06.72 HJMjm+0C.net
>>414
横から失礼。
個人的にはそもそもcrate.io に頼るのがあまり好きでないなと。
Rust に限らない話だけど、こういった中央集権的なリポジトリを用意すること自体が名前争奪戦の元になるのではないかなと。
それぞれのWEBサイトで勝手に配布すればいいのにってね。
バージョン管理方法の方法論なんかも関わるから簡単な事ではないんだろうけど。
425:デフォルトの名無しさん
21/12/28 11:35:30.26 QBGkL4gv.net
現状でもGitHubから直接落としてくることも出来るけど、GotHubのリポジトリは消せてしまうからな
426:デフォルトの名無しさん
21/12/28 13:40:51.12 XD/wAJcN.net
cargo updateでマイナーバージョンアップやらせるのも規約決めたり工夫ご必要だし
専用のリポジトリ用意する方がわかりやすくはあるような
crates.io以外にも複数のリポジトリを混在して使えるようにできれば良いのかな
427:デフォルトの名無しさん
21/12/28 14:10:43.98 Qs/YVt0a.net
cargoはどこからでも落とせる
crates.ioなみに安全性、信頼性、永続性が確保できるんなら好きにすればいい
428:デフォルトの名無しさん
21/12/28 14:45:21.34 ZpntEDp9.net
永続性を謳うサービスで名前で管理したらそりゃあいい名前の取り合いになるよなあ
429:デフォルトの名無しさん
21/12/28 14:48:37.23 XD/wAJcN.net
>>419
ほんとだ、packageごとにregistry指定できるんだね
URLﾘﾝｸ(doc.rust-lang.org)
430:デフォルトの名無しさん
21/12/28 15:16:22.59 c9bIiubz.net
GoみたいにGithubがデファクトスタンダードなレジストリになっても一覧性の面で不便だし、crates.ioでいいと思うけどなあ
431:デフォルトの名無しさん
21/12/28 21:31:42.32 VUBOa1a1.net
セキュリティ監査付きのcrates.ioクローンが欲しい
432:デフォルトの名無しさん
21/12/28 21:33:45.43 m5VlhgmG.net
average()が気になってcratesだかcargoだか話逸らしに聞こえる
433:デフォルトの名無しさん
21/12/28 22:07:01.63 a7HoB6QX.net
ぼぼぼ、ぼくちんのために誰か優秀なaverage()をおながいします
434:デフォルトの名無しさん
21/12/28 22:22:38.58 ndrZKvgW.net
>>423
cargo auditでは足りない？
435:デフォルトの名無しさん
22/01/01 09:34:17.63 f7mn356m.net
>>411
「多数あり外部で十分派」なのに>>412には答えられないの？？
436:デフォルトの名無しさん
22/01/01 19:34:25.31 u2SyaqDt.net
Why is my Rust build so slow?
437:デフォルトの名無しさん
22/01/01 20:01:31.38 YfLqYQwV.net
Because your PC is poor spec.
438:デフォルトの名無しさん
22/01/01 23:44:42.88 193tzZ58.net
URLﾘﾝｸ(fasterthanli.me)
この人の場合クソデカ型のせいでコンパイルが遅かったという話
439:デフォルトの名無しさん
22/01/02 10:42:43.84 adsjh4PJ.net
warpがクソみたいに重いって書いてるな
440:デフォルトの名無しさん
22/01/02 11:21:24.79 ulXuEZX0.net
sccacheとか入れてみるか
441:デフォルトの名無しさん
22/01/02 13:52:17.06 o9R7ffl7.net
当日お急ぎ便でSSDを買った
442:デフォルトの名無しさん
22/01/02 14:41:20.14 N3sGBcjr.net
>>432
bin crateのビルドに時間かかるなら sccache は効果薄いのでは
443:デフォルトの名無しさん
22/01/02 14:53:21.62 3FXnOBLq.net
高度IT人材、富士通は最大年収3500万円へ
「富士通年収3500万！」日本のIT企業の年収も、高額化してきました
AI人材の獲得に超本気 NECが新人事制度を9人に適用、富士通は最大年収3500万円へ
【年収３５００万円も】富士通、「ジョブ型」人事制度を導入 幹部社員から 高度IT人材
来年度から副業解禁 人材多様化へ―大同生命次期社長
第一生命HD、副業解禁 約1万5000人対象
第一生命ＨＤ、副業解禁 １万５０００人対象―大手生保初
IHI、国内8000人の副業解禁 重厚長大企業も転機
ＩＨＩ、社外兼業を解禁 社内副業もルール化
444:デフォルトの名無しさん
22/01/02 21:56:13.39 Uu3cvt4h.net
効率を求め過ぎてモノリシックになりすぎると様々なコストが上昇してしまう
そこで分割
さらに内部もcrate分割で並行コンパイル
445:デフォルトの名無しさん
22/01/04 02:27:09.98 L+p8nbVX.net
Rustでノードが追加されたり消されたりする双方向グラフ扱いたくなったらどうするんだろ
Arenaじゃ追加削除してるうちにゴミがメモリ圧迫していくし
446:デフォルトの名無しさん
22/01/04 09:43:25.00 aGnbM+4r.net
>>437
Cursor使う
Arenaの場合はfree list用意して削除済み要素を再利用すればよい
Arenaが埋まったらreallocするのではなく同じサイズの新たなArenaを獲得していくようにすれば
不要になったArenaから解放できるからmalloc使う場合と同等のメモリ使用量に抑えられるかと
これでも不足するなら copy GC 的に compaction するしかなさそう
447:デフォルトの名無しさん
22/01/04 18:15:54.62 L+p8nbVX.net
>>438
なるほど…… 結構ガッツリ実装しなきゃいけなそうね。ありがとう。最後はGCを実装することになりそうなので、それならいい感じのGCを残しておいてくれたら良かったのにって気になるな
448:デフォルトの名無しさん
22/01/04 18:22:33.23 L+p8nbVX.net
Cursorってなんでしょう？
449:デフォルトの名無しさん
22/01/04 19:44:07.16 aGnbM+4r.net
>>440
これのこと (まだunatable)
URLﾘﾝｸ(doc.rust-lang.org)
450:デフォルトの名無しさん
22/01/04 20:59:48.62 /2oFrrnl.net
>>439
GCを必要とする用途は非常にレア
だから標準ライブラリには不要だが外部ライブラリに色々あるので大丈夫
451:デフォルトの名無しさん
22/01/04 22:15:51.15 aGnbM+4r.net
>>442
GCのライブラリ使ったことある？実用的だった？
452:デフォルトの名無しさん
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にするかってのは要するに構造体のサイズを決定できない場合を想定してるわけよ。
スタックにそういういう動的にサイズが異なる実体をおくことも最近のコンパイラではないこともないが、通常はヒープに置くわ。
文字通りしか考えないで実際の使い方なんか一切考えないやつってのが丸わかりになるって意味では
分かってなさそうなやつにこの辺りについて問いただすってのは割と良いかも。