22/05/12 18:28:20.99 cuIcFT6k.net
公式
URLﾘﾝｸ(www.rust-lang.org)
URLﾘﾝｸ(blog.rust-lang.org)
URLﾘﾝｸ(github.com)
Web上の実行環境
URLﾘﾝｸ(play.rust-lang.org)<)
※Rustを学びたい人はまず最初に公式のThe Bookを読むこと
URLﾘﾝｸ(doc.rust-lang.org)
※Rustを学ぶ際に犯しがちな12の過ち
URLﾘﾝｸ(dystroy.org)
※Rustのasyncについて知りたければ「async-book」は必読
URLﾘﾝｸ(rust-lang.github.io)
※C++との比較は専用スレへ
C++ vs Rust
ｽﾚﾘﾝｸ(tech板)
※次スレは原則>>980が立てること
前スレ
Rust part14
ｽﾚﾘﾝｸ(tech板)
2:デフォルトの名無しさん
22/05/12 18:30:00.00 cuIcFT6k.net
Rust The Book (日本語版)
URLﾘﾝｸ(doc.rust-jp.rs)
Rust edition guide (日本語版)
URLﾘﾝｸ(doc.rust-jp.rs)
Rust by example (日本語版)
URLﾘﾝｸ(doc.rust-jp.rs)
Rust cookbook (日本語版)
URLﾘﾝｸ(uma0317.github.io)
Rust API guideline (日本語版)
URLﾘﾝｸ(sinkuu.github.io)
Rust nomicon book (日本語版)
URLﾘﾝｸ(doc.rust-jp.rs)
Rust WASM book (日本語版)
URLﾘﾝｸ(moshg.github.io)
Rust embeded book (日本語版)
URLﾘﾝｸ(tomoyuki-nakabayashi.github.io)
Rust enbeded discovery (日本語版)
URLﾘﾝｸ(tomoyuki-nakabayashi.github.io)
3:デフォルトの名無しさん
22/05/12 18:30:13.50 cuIcFT6k.net
Rust CLI (Command Line Interface) apps Book
URLﾘﾝｸ(rust-cli.github.io)
Rust async-std Book
URLﾘﾝｸ(book.async.rs)
Rust The Unstable Book
URLﾘﾝｸ(doc.rust-lang.org)
Rust rustc Book
URLﾘﾝｸ(doc.rust-lang.org)
Rust Cargo Book
URLﾘﾝｸ(doc.rust-lang.org)
The Rust Reference
URLﾘﾝｸ(doc.rust-lang.org)
The Rust Standard Library
URLﾘﾝｸ(doc.rust-lang.org)
4:デフォルトの名無しさん
22/05/12 18:33:42.89 q5adbU17.net
c++スレやHaskelスレでああでもないこうでもないと実用性無視してごちゃごちゃ言ってたのがRustスレに移って来て
ああでもないこうでもないと不毛な話を繰り返してるだけなんだろうな…
5:デフォルトの名無しさん
22/05/12 21:06:22.42 EFEW+xd3.net
let mut >>1乙
6:デフォルトの名無しさん
22/05/12 23:07:25.38 13HXXMDq.net
ごちゃごちゃ戻り値の型さえ理解してないで書いてる
7:デフォルトの名無しさん
22/05/13 01:13:09.90 ufl1G9JB.net
またワッチョイなしですか
8:デフォルトの名無しさん
22/05/13 04:12:30.14 7BsdLj8J.net
>>6
ちゃんと理解しましょう
9:デフォルトの名無しさん
22/05/13 06:02:56 6rmlfzdI.net
乙
もっとRustが普及しますように☆彡
10:デフォルトの名無しさん
22/05/13 18:17:33.08 9chxx07M.net
>>7
ﾜｯﾁｮｲなんて飾りです
11:デフォルトの名無しさん
22/05/13 21:57:27.44 bn7J0pQ3.net
>>7
ワッチョイスレはすでにあるだろ
12:デフォルトの名無しさん
22/05/13 22:24:15.76 UR4E+9N6.net
>>8
正直言うと、俺たちは若い奴らが何やらワイワイさわいでCOBOLおじさんJAVAおじさん、C#おじさん扱いされないよう
カッコよさげだから、なんとなく雰囲気でRustを書いてるんだ。
でも、うまく言えないけど理解する必要性を全く感じない、下請けにおまえRustも分らんの？とマウントするのが夢なんだ
とやかく言われる筋合いは無い
13:デフォルトの名無しさん
22/05/13 23:48:07.30 uiqUB4xh.net
再帰的なmacroはaliasしても展開時に
元の名前のマクロを使おうとしてエラーになるんだがこれって避けられない？
use foo_crate::foo as bar;
bar!(…)
cannot find macro `foo` in this scope
this error originates in the macro `bar`
14:デフォルトの名無しさん
22/05/14 00:13:13.84 BgvoYA7m.net
>>13
foo! の定義中の foo! 呼び出しを $crate::foo!() みたいにすればいけるんじゃないかな
15:デフォルトの名無しさん
22/05/14 03:12:50.47 J3IrN4Ey.net
>>14
それだ、ありがとう
16:デフォルトの名無しさん
22/05/14 23:50:01.31 7gZW+FH0.net
前スレで出ていたこの上限チェックRangeFromだけど
fn countup<T>(start: T) -> impl Iterator<Item=T>
where T: Clone + TryFrom<usize> + num::CheckedAdd,
{
let one = T::try_from(1).ok().unwrap();
itertools::unfold((start, true), move |(n, is_first)| {
if *is_first {
*is_first = false;
Some(n.clone())
} else {
n.checked_add(&one)
.map(|new| { *n = new.clone(); new })
}
})
}
フラグ持たずにOptionで持ったほうがわかりやすくない？
fn countup<T>(start: T) -> impl Iterator<Item=T>
where T: Clone + TryFrom<usize> + num::CheckedAdd,
{
let one = T::try_from(1).ok().unwrap();
itertools::unfold(Some(start), move |n| {
let ret = n.clone();
if let &mut Some(ref m) = n {
*n = m.checked_add(&one);
}
ret
})
}
17:デフォルトの名無しさん
22/05/15 00:14:36.59 AindqZB4.net
複オジに毒されてるな
successors(Some(start), move |n| n.checked_add(&one))
18:デフォルトの名無しさん
22/05/15 02:25:52 /oKjcqbB.net
>>16
そのclone()は不要
トレイト境界からCloneを外せる
fn countup<T>(start: T) -> impl Iterator<Item=T>
where T: TryFrom<usize> + num::CheckedAdd,
{
let one = T::try_from(1).ok().unwrap();
itertools::unfold(Some(start), move |n| {
if let &mut Some(ref m) = n {
let mut next = m.checked_add(&one);
std::mem::swap(n, &mut next);
next
} else {
None
}
})
}
19:デフォルトの名無しさん
22/05/15 03:11:19.26 gyw6bZ1I.net
unfoldでなんでもできるからunfoldしか使わなくなってしまった人
いろいろな人
20:デフォルトの名無しさん
22/05/15 07:53:49.50 SgXGf86o.net
>>18
take()?でもっと簡潔に書ける
fn countup<T>(start: T) -> impl Iterator<Item=T>
where T: TryFrom<usize> + num::CheckedAdd,
{
let one = T::try_from(1).ok().unwrap();
itertools::unfold(Some(start), move |n| {
let cur = n.take()?;
*n = cur.checked_add(&one);
Some(cur)
})
}
21:デフォルトの名無しさん
22/05/15 08:07:10.15 SgXGf86o.net
>>19
unfoldは要点に絞って見やすい短縮記法として使われている
そのままunfoldを使わずに普通に構造体にimpl Iteratorする形へ置き換え可能なところがメリット
例えば>>20はそのまま機械的に以下へ展開できて同じく動作する
struct Countup<T> {
one: T,
n: Option<T>,
}
fn countup<T>(start: T) -> impl Iterator<Item=T>
where T: TryFrom<usize> + num::CheckedAdd,
{
Countup {
one: T::try_from(1).ok().unwrap(),
n: Some(start),
}
}
impl<T> Iterator for Countup<T>
where T: num::CheckedAdd,
{
type Item = T;
fn next(&mut self) -> Option<T> {
let cur = self.n.take()?;
self.n = cur.checked_add(&self.one);
Some(cur)
}
}
これだと長く冗長なので敢えてunfold利用版を記述することで要点のみに絞ることができる
22:デフォルトの名無しさん
22/05/15 10:14:06.42 2aUGzSw0.net
>>19
全部同じやつだぞ
一人二役で会話してる
23:デフォルトの名無しさん
22/05/15 10:54:06.34 +6kSxcdv.net
unfoldより関係が分かりにくくなるけど
キャプチャした変数を使うfrom_fnという手もある
fn countup<T>(start: T) -> impl Iterator<Item=T>
where T: TryFrom<usize> + num::CheckedAdd,
{
let mut n = Some(start);
let one = T::try_from(1).ok().unwrap();
std::iter::from_fn(move || {
let cur = n.take()?;
n = cur.checked_add(&one);
Some(cur)
})
}
24:デフォルトの名無しさん
22/05/15 10:54:14.40 duXfvT8B.net
大人が集まってくつろいでるところに
子供がガラッと入ってきて九九の暗唱しはじめたら
頑張ってるのがほほえましくて応援しちゃうでしょ
でも
大人がガラッと入ってきて九九の暗唱しはじめたら
ギョッとするし不安になってくるやろ
なぜそんなもんをお披露目しちゃうのか
なぜ得意げになって頑張ってるのかわからない
もういいよ！と単に言えばいいのか
続きはカーチャンに見えもらってね！と言えば良いのか
言って分かってもらえる気配もないので怖い
25:デフォルトの名無しさん
22/05/15 11:10:33.42 +6kSxcdv.net
今回はこれでもいい
fn countup<T>(start: T) -> impl Iterator<Item=T>
where T: TryFrom<usize> + num::CheckedAdd,
{
let one = T::try_from(1).ok().unwrap();
std::iter::successors(Some(start), move |n| n.checked_add(&one))
}
26:デフォルトの名無しさん
22/05/15 11:16:38.61 yna4qlqc.net
はちみつおじさん悔しそうwww
27:デフォルトの名無しさん
22/05/15 12:24:43.22 Q7/PweS0.net
九九と違って子供用のおもちゃプログラムでしか使えないコードなんだよなぁ
28:デフォルトの名無しさん
22/05/15 12:39:00.79 +mKsOYSe.net
代案出さずに文句だけつける万年野党みたいなやつがいるな
29:デフォルトの名無しさん
22/05/15 13:13:50.62 gyw6bZ1I.net
>>25
それまんま>>17やんけ
30:デフォルトの名無しさん
22/05/15 14:22:42.46 Cy+Jf1ha.net
九九のように簡単だという皆さま方に質問です
countup()が7通り(?)も色んな書き方が出てきて驚いたのですが
フィボナッチ数列だとどんな華麗なコードになりますか？
fn fibonacci<T>() -> impl Iterator<Item=T>
where T: TryFrom<usize> + num::CheckedAdd,
{
// ここを記述
}
出力仕様は一番ベーシックな0スタートとします
0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, ...
31:デフォルトの名無しさん
22/05/15 15:13:51.95 4TECkVdc.net
>>30
「Rustのお題スレ」でも立ててそっちでやってくれ
32:デフォルトの名無しさん
22/05/15 15:27:49.70 Cy+Jf1ha.net
>>31
難しくて解けないという表明ですか？
どういう点が難しかったのか教えてください
33:デフォルトの名無しさん
22/05/15 15:40:51.12 hZXiQ87C.net
教えてもらったsuccessorsを披露したくてしょうがない幼児メンタルwww
>>24の言う通りだな
34:デフォルトの名無しさん
22/05/15 15:49:35.48 AAncJnA8.net
>>33
successorsは適用範囲が非常に狭いので>>30の例には使えないはず
35:デフォルトの名無しさん
22/05/15 16:09:35.61 Cy+Jf1ha.net
>>33
ぜひそれを披露してやり方を教えてください
36:デフォルトの名無しさん
22/05/15 16:27:05.61 KYkY1Akn.net
フィボナッチ数列イテレータ前スレでだれかが書いてたでしょ
それじゃいかんの
37:デフォルトの名無しさん
22/05/16 07:04:42.44 nGMMRLLq.net
>>36
CopyやCloneを使っているから別問題だろう。
一般的にRustのプログラミングでは、
Copy(暗黙的な自動コピー)やClone(clone()による明示的な手動コピー)を使うと楽になるが、コストは高くなる。
そのため不要なclone()を見極めてそれを回避するプログラミングが出来るかどうか、というRustにおける根源的な話だろう。
38:デフォルトの名無しさん
22/05/16 07:28:24 JrfUQrzl.net
Copyのコストが高い？
39:デフォルトの名無しさん
22/05/16 08:00:50.97 nGMMRLLq.net
>>38
もちろんCopyは最もコストが高い。
個々のコスト自体は通常clone()と同じだが、常に自動的にclone()が起きるため最もコストが高くなる。
40:デフォルトの名無しさん
22/05/16 08:58:48.98 tFcB4vDN.net
複製おじさんはいつも自分勝手な妄想を「一般的には～」とか「皆は～」と言って自分を正当化しようとするよね
41:デフォルトの名無しさん
22/05/16 10:03:10.22 0DWo1Xps.net
>>40
間違いは誰にでもあるからまだいいんだが
指摘されても反省するどころかさらなる妄想を撒き散らすのがほんと迷惑
42:デフォルトの名無しさん
22/05/16 11:11:33 02kk6/+P.net
おじさん使いの人の自演がいつもよくわからん
唐突に妄想(?)を攻撃し出すが幻覚か何か見えてるのか
43:デフォルトの名無しさん
22/05/16 16:19:03.24 NE3SiQoq.net
>>39
Cloneのコストが高い型にCopyを実装するな
44:デフォルトの名無しさん
22/05/16 16:30:48.20 JLeK8lGd.net
Copyはコストが一番高いから出来る限り避けるべきだな
特にヒープを使うならCloneまでにしておくべき
可能ならばCloneも避けるべきだが
45:デフォルトの名無しさん
22/05/16 18:08:42.72 ThGcWJJo.net
Copyは所有権を複製するから最も高コスト(ｷﾘｯ！！
46:デフォルトの名無しさん
22/05/16 18:10:04.46 ThGcWJJo.net
もはやどのレスもギャグにしか見えん
俺のしってるCopyとは確実に違う
47:デフォルトの名無しさん
22/05/16 18:38:28.59 qW5+0T97.net
今までで一番意味不明なこと言ってるな
Copyのコストが高いならmoveのコストはどうなるのよ
48:デフォルトの名無しさん
22/05/16 18:44:18.84 Mb2xQVjt.net
>>45
所有権に複製という概念はない
Copyをimplすると使われる時に値が自動的に複製される
そのためCopyは最も高コスト
>>46
君のレスがギャグにしか見えん
49:デフォルトの名無しさん
22/05/16 18:47:50.19 /5k6Bg80.net
Rust のムーブはビットパターンのコピーだもんな。
低レイヤの視点で見たらコピーと何の差も無い。
なるべく参照を使う場合にしても間接参照の実行コストとコピーの実行コストを天秤にかけてどちらが有利かは場合による。
50:デフォルトの名無しさん
22/05/16 18:55:12.38 W7mPHnnh.net
>>47
それは理解不足すぎるぜ
大文字のCopyはCopyトレイトを意味しCopyトレイトを実装するか否かの話だろ
moveは別方向の話であり比較対象にすらならない
比較するならば「Copy実装(必然的にClone)も実装」「Cloneのみ実装」「どちらも実装なし」の3つだな
51:デフォルトの名無しさん
22/05/16 19:00:08.16 GLqKLCqS.net
>>48
ギャグだと分からない人がいるとは想定していませんでした。
誤解を招いたのであれば申し訳ございません。
52:デフォルトの名無しさん
22/05/16 19:06:18.85 78bNbDCr.net
>>49
デタラメすぎ
ムーブでビットパターンのコピーは発生しない
ビットパターンのコピーが発生するのは引数の値渡し等であってムーブとは関係ない
さらに引数の値渡しでのでビットパターンのコピーとCopyのコピーも全く異なる
Copyのコピーはディープであって高コスト
53:デフォルトの名無しさん
22/05/16 19:08:38.74 NE3SiQoq.net
そもそもフィボナッチ数列イテレータなんて誰も求めてないので
前スレのだれかさんの実装に問題があると思うなら自分で勝手に改善してなさい
そしてその結果はここに貼らなくていいぞ
54:デフォルトの名無しさん
22/05/16 19:11:06.58 zgsMMZOB.net
「ヒープ使うならCloneまでにしとけ」
このセリフが一番刺さった
55:デフォルトの名無しさん
22/05/16 19:11:50.62 rHnqcaqs.net
>>52
おじさんマジかよwww
56:デフォルトの名無しさん
22/05/16 19:22:59.76 NE3SiQoq.net
>>54
Dropを実装する型はCopyを実装できないよ
BoxもRcもStringもVecもそもそもCopyを実装できないので、するかしないか考えること自体が無意味
どういう型にCopyを実装できるか、できないか、すべきかはdocsに書いてあるので
なんのかんの言う前にまずはこれを読もうね
URLﾘﾝｸ(doc.rust-lang.org)
57:デフォルトの名無しさん
22/05/16 19:37:56.79 tTdd7GU5.net
>>53
これだけCopyやCloneを理解していない連中が多い状況だと
>>30の質問に答えられるかどうかは最低限クリアすべきテストとして有用ではないか？
フィボナッチ自体はもちろんどうでもよい話だがCopyやCloneを避けるRustの基本ができるかどうかわかる点で
58:デフォルトの名無しさん
22/05/16 19:45:37.77 /5k6Bg80.net
>>52
じゃあムーブでなにが起こるとおもってんの？
59:デフォルトの名無しさん
22/05/16 19:54:25.89 SHnkjBGX.net
>>53
> フィボナッチ数列イテレータなんて誰も求めてない
それはそうなんだけど
唯一本人にとっては伝家の宝刀だから
少なくともこのスレいっぱいまでは引っ張って
何度も何度も参照するはず
60:デフォルトの名無しさん
22/05/16 20:38:11.38 NE3SiQoq.net
フィボナッチがどうでもいいならこの話は終わりです
61:デフォルトの名無しさん
22/05/16 20:45:13.08 Mz4z3EAu.net
関数の深いところから順に構造体をムーブで返していって
各関数で渡ってきた構造体のアドレスを表示させてみた
#[derive(Debug)]
struct S([i32; 100]);
fn main() {
let mut s1 = sub1(100);
s1.0[1] = 111;
println!("s1: {:p}", &s1);
println!("{s1:?}");
}
fn sub1(p: i32) -> S {
let q = p + 3;
let mut s2 = sub2(q);
s2.0[2] = p - 300;
println!("s2: {:p}", &s2);
s2
}
fn sub2(s: i32) -> S {
let t = s * 2;
let mut s3 = S([123; 100]);
s3.0[3] = t;
println!("s3: {:p}", &s3);
s3
}
s1もs2もs3もアドレスが一致
ムーブではアドレスそのままであり
ビットパターンのコピーが為されないという結論
62:デフォルトの名無しさん
22/05/16 20:58:36.88 qW5+0T97.net
>>50
"Copyのコストが高い" は Copy を実装する行為そのもののコストが高いと解釈すべきということ？
そんなばかな
>>52
ドキュメント読みましょうねー
URLﾘﾝｸ(doc.rust-lang.org)
> It’s important to note that in these two examples, the only difference is whether you are allowed to access x after the assignment.
> Under the hood, both a copy and a move can result in bits being copied in memory, although this is sometimes optimized away.
...
> The behavior of Copy is not overloadable; it is always a simple bit-wise copy.
...
> The implementation of Clone can provide any type-specific behavior necessary to duplicate values safely.
> For example, the implementation of Clone for String needs to copy the pointed-to string buffer in the heap.
63:デフォルトの名無しさん
22/05/16 21:06:43.52 qW5+0T97.net
>>61
アドレスが同じか否かでコピーの有無を判断する意味はよくわからんが
その理屈だとこのコードだと違うアドレスが表示されるからビットパターンのコピーがされてるって結論になるのか？
#[derive(Debug)]
struct S([i32; 100]);
fn main() {
let mut s1 = S([0; 100]);
println!("s1: {:p}", &s1);
let s2 = s1;
println!("s2: {:p}", &s2);
}
64:デフォルトの名無しさん
22/05/16 21:07:20.55 f/Xu02FO.net
>>61
struct S {}
fn main() {
let s1 = S{};
println!("s1: {:p}", &s1);
let s2 = s1;
println!("s2: {:p}", &s2);
}
65:デフォルトの名無しさん
22/05/16 21:08:00.98 f/Xu02FO.net
ごめん被った。やっぱそう思うよね。
66:デフォルトの名無しさん
22/05/16 21:16:19.81 9Ab93Lwf.net
>>56
ちょっとw
なんで刺さったのか少しは考えてよww
ギャグゴロシめ
67:デフォルトの名無しさん
22/05/16 21:19:28.47 51EzJkQ/.net
>>61
>>63
その二つの相異なる結果を見るとビットパターンのコピーはムーブ以外の要因で起きている？？
68:デフォルトの名無しさん
22/05/16 21:30:56.46 W905eBh/.net
>>57
一番分かってないお前が言うなよw
69:デフォルトの名無しさん
22/05/16 21:38:19.38 /vD2A9J9.net
>>61
高コストなCopyも実装してから確認してみてねww
70:デフォルトの名無しさん
22/05/16 21:38:29.32 NE3SiQoq.net
>>66
ごめんよ
刺さったって「ためになった」みたいな意味で言ってるのかと思ったよ
てっきりオジの自演かと
71:デフォルトの名無しさん
22/05/16 21:39:12.01 DoCeaK1g.net
>>67
デバッグビルドだけじゃなくリリースビルドでも確認してねw
72:デフォルトの名無しさん
22/05/16 21:42:44.19 51EzJkQ/.net
>>71
リリースモードでもどちらも同じ結果
73:デフォルトの名無しさん
22/05/16 21:49:25.30 sElCPUyn.net
>>72
ごめんよー
>>64と間違えた
74:デフォルトの名無しさん
22/05/16 23:46:37.66 jfEIc0ZW.net
このスレはいつもおかしい人間たちが集まってるな
Rustの何が人を狂わせるんだ？
75:デフォルトの名無しさん
22/05/17 00:09:43.95 HbNyXd2X.net
おじさんイジリ飽きたので結論いっておく
Copyもmoveもスタックの中身をコピーしてるのは同じ
最適化によって不要なコピーが除去されるかどうかはLLVM次第
でかい配列やでかい構造体などの極一部を除けばCopyは参照の受け渡しよりも低コスト
ついでに言うと&TもCopy
76:デフォルトの名無しさん
22/05/17 00:26:01.61 +9bLcV37.net
>>75
頭悪すぎ
Copyが低コストなのではなく
低コストなものだけにCopyが実装されている
なぜならCopyは高コストであるため
77:デフォルトの名無しさん
22/05/17 02:09:56.03 2XRLgT14.net
>>76
ここでいうCopyのコストって具体的にどういう操作のコストのこと言ってる？
構造体データのbitwise-copyのこと？それとも別の何か？
Cloneやmoveの場合にそのコストは発生しないと主張しているの？
78:デフォルトの名無しさん
22/05/17 02:13:55.30 tAEVG8cC.net
>>62
ほーCopyってCloneの実装によらずmemcpy相当の結果になるのか
自動的に.clone()が差し挟まれる感じかと思ってた
79:デフォルトの名無しさん
22/05/17 07:41:41.18 1GDSnWAB.net
>>78
俺も同じくCopyは自動的にclone()されると思ってた
そう思ってた理由はClone実装せずにCopy実装するとエラーとなるため
そこで実験
#[derive(Debug,Copy)]
struct S { not_cloned: usize, cloned: usize }
impl Clone for S {
fn clone(&self) -> Self {
S { not_cloned: self.not_cloned / 3, cloned: self.cloned }
}
}
fn main() {
let s0 = S { not_cloned: 123, cloned: 456 };
let s1 = s0.clone();
let s2 = s0; // copy
println!("Cloned: {s1:?}");
println!("Copied: {s2:?}");
}
結果
Cloned: S { not_cloned: 41, cloned: 456 }
Copied: S { not_cloned: 123, cloned: 456 }
別物になった…
80:デフォルトの名無しさん
22/05/17 10:53:02 GxF458pr.net
>>52
>>>49
>デタラメすぎ
>ムーブでビットパターンのコピーは発生しない
>ビットパターンのコピーが発生するのは引数の値渡し等であってムーブとは関係ない
>さらに引数の値渡しでのでビットパターンのコピーとCopyのコピーも全く異なる
>Copyのコピーはディープであって高コスト
このレス最強だな
一つ一つの文すべてが間違ってる
「デタラメすぎ」てw
81:デフォルトの名無しさん
22/05/17 14:50:42.61 94ESmIzZ.net
ガイジムーブ来てんね
82:デフォルトの名無しさん
22/05/17 21:03:27.69 VS5jQHYL.net
Copyはshallow copyだわな
83:デフォルトの名無しさん
22/05/17 22:07:44 LjbtS7tD.net
色々と正確な情報が出揃ったところで質問
まず前提として話を明白かつ簡単にするため、
ここでは!DropつまりCopy実装可能な型のみ対象、
そしてもしClone実装するならば*selfつまりCopy実装と同一、
CloneやCopyを実装するかどうかは任意、
小文字のcloneとcopyはそれぞれCloneやCopyを実装した時にそれらが使われることを意味するとする
このとき、次のどちらの主張が正しい？
Ａ「copy/cloneはコストが生じるので、回避できるならば回避したほうが有利」
Ｂ「copy/cloneのコストはmoveと同じなので回避する必要はない」
84:デフォルトの名無しさん
22/05/17 22:30:37.28 VUKzLr9a.net
場合による。
たとえコピーであっても結局は内容が同じものであると看破すれば
実際にはコピーしないようなコードを生成するといったことは有りうる。
Rust は原理的にエイリアス解析がやりやすい言語だと思うし。
実行コスト的にどうかなんて考えずに所有権管理の側面からの妥当性で決めたほうがよい。
その上でどうしても実行コストを切り詰めないといけないようになったならその時に考えればいい。
85:デフォルトの名無しさん
22/05/17 22:33:27.98 5/60CrrJ.net
>>83
前提もまちがってるが
比較する対象がそもそも意味がない
もうちょっと勉強してから出直して
86:デフォルトの名無しさん
22/05/17 23:40:20.70 XaJZCLYj.net
>>83
>Ａ「copy/cloneはコストが生じるので、回避できるならば回避したほうが有利」
何と比べてコストが生じると言ってるの？
回避した場合は何で代用するつもりなの？
87:デフォルトの名無しさん
22/05/17 23:43:19.03 nlEgMvZ6.net
考えてみたけどmove/copyが問題になるレベルの大きさの型をスタックに置いて扱ったことが無いな…
使うとすれば固定長配列のバッファ？
でもそんなものmove/copyするわけないし
やっぱり考える意味の無い二択だと思う
88:デフォルトの名無しさん
22/05/17 23:47:41.13 FqAlYuq2.net
>>86
回避する前と回避した後の比較だろう
回避したコードが書けたならばcopyの代用の必要はない
89:デフォルトの名無しさん
22/05/17 23:49:36.53 YviCLBk+.net
>>83
一般的にはAが正しい
ただし>>84が言うように無駄なコピーが消える場合もある
Ａ「copy/cloneはコストが生じるので、回避できるならば回避したほうが有利になることがある」ならば正確
90: Bについては前半はある意味正しいとしても後半が間違い >>85 批判や主張はその理由を伴わないと議論とならず意味がない
91:デフォルトの名無しさん
22/05/17 23:54:01.76 VUKzLr9a.net
>>89
> 批判や主張はその理由を伴わないと議論とならず意味がない
基本的にはそうだが、こっちが説明しても理解できるレベルに達してない場合にはどうせ議論にならんのでな。
92:デフォルトの名無しさん
22/05/17 23:55:13.39 tAEVG8cC.net
あっこの流れC++相談室で見たやつだ
93:デフォルトの名無しさん
22/05/18 00:07:06.58 P5Km+xQv.net
要は参照使えるなら使っとけって？
今更すぎませんか
94:デフォルトの名無しさん
22/05/18 00:30:37.66 DGffctwq.net
オナコードペタペタされてたほうがマシだったなこりゃ
95:デフォルトの名無しさん
22/05/18 00:45:17.78 opn2S8Zb.net
>>92
それもあるが、例えば多数のコピーが行われているコードに対して、回避できる分を見直し、少数のコピーで済むように改善できる場合もある
Copy実装せずに明示clone()した方が見つけやすいかもしれない
96:デフォルトの名無しさん
22/05/18 01:26:17.77 lxQ5l4ey.net
>>88
さすがに意味が分からないよ
値の受け渡しにcopyを使わないなら何が他の方法を使う必要があるでしょ
97:デフォルトの名無しさん
22/05/18 01:42:43.25 d5NnfCmB.net
一人だけ間違った思い込みをしてるのに
説明されても「俺は間違ってない、間違ってるのはお前ら」が続くだけだからな
98:デフォルトの名無しさん
22/05/18 01:46:16.75 6ezlEFaX.net
>>95
頭が硬すぎないか？
回避できる分を回避するだけだろ
回避できない分まで回避する、と思い込んてるのはYouのみ
99:デフォルトの名無しさん
22/05/18 01:51:55.82 Da/MVUm8.net
>>89
「○○はコストが生じるので、回避できるならば回避したほうが有利になることがある」
言葉の定義を明確にしないジェネリック文は
恣意的に常に真にも常に偽にもできる
100:デフォルトの名無しさん
22/05/18 02:06:14.30 UgigdTUo.net
>>90
無駄にプライド高いな
嫌われるぜ
101:デフォルトの名無しさん
22/05/18 07:08:20 bcZKOTNR.net
大きいフィールドを持つ型には、Copyは実装しないだろうし普通はCopy/Moveのコスト差を気にすることなくない？
どちらにすべきかボーダーが難しいことはありそうだけど
102:デフォルトの名無しさん
22/05/18 07:14:11 P5Km+xQv.net
>>94
データフローを見直して単純に消せるclone/copyは消せってことか？
それこそ今更すぎるわ
単純に消せないところまで消した後、さらにパフォーマンス改善するにはどうするかってことで、参照の話か？って聞いたんだけど
どこの誰とも知れないやつのフィボナッチのコードに対する指摘をされても知らねーよ
問題があって対策が分かってるなら自分で直すがいい
103:デフォルトの名無しさん
22/05/18 07:41:25.51 4GWzufxp.net
>>97
実行回数の話だったのかよww
まさかねw
104:デフォルトの名無しさん
22/05/18 07:56:39.00 HgdHe2aE.net
>>101
フィボナッチの件はBigIntなど非Copyも対象で今回の話は全く無関係だろ
そこを区別できていないのは相当ヤバいぞ
105:デフォルトの名無しさん
22/05/18 08:12:27.72 BE/QrV8J.net
流れからすると本当はジェネリックのフィボナッチにCopyを付けないほうが有利と主張したかったんじゃね？
でも後から回避できないことに気づいて苦しい言い訳を重ねてるだけと見た
106:デフォルトの名無しさん
22/05/18 08:21:27.45 6swlbHlO.net
>>85
根拠も示さず批判だけする一番アカン人間やな
107:デフォルトの名無しさん
22/05/18 08:33:04.08 6hDwlDoy.net
>>104
フィボナッチはCopyを回避できないものなの？
108:デフォルトの名無しさん
22/05/18 08:45:43.18 2HNq06l+.net
分からないなら分からないから教えてって言えばいいのに意地を張るからこうなる
構えば構うほど意味不明な発言が出てくる
真面目に議論したいならせめてIDコロコロ変えるのやめな
109:デフォルトの名無しさん
22/05/18 09:10:15.39 Gy2qdhBc.net
フィボナッチってこれだろ
f(0) = 0
f(1) = 1
f(n) = f(n - 1) + f(n - 2)
関数呼び出しに足し算に大量のコピーは避けられない
110:デフォルトの名無しさん
22/05/18 09:28:25.87 3vPi03ro.net
>>87
async関数やasyncブロックで生成されるFutureは結構大きくなることがあって、boxingした方が性能出るケースもある
111:デフォルトの名無しさん
22/05/18 10:05:07.09 jV65BxdQ.net
>>106
型制約からCopyを外すこことcopyを回避することは全く意味が違う
>>83の質問は明らかに後者
プリミティブも対象になるフィボナッチでcopyを回避するのは無理
112:デフォルトの名無しさん
22/05/18 10:20:40.09 AWXqkW+Q.net
>>110
型制約からCopyを外せばプリミティブと言えどもcopyされなくなる
具体的には個々のプリミティブ型へモノモーフィゼーゼーションされる前の段階でCopy実装していない型に対してのcopy発生エラーが生じる
フィボナッチでcopyを回避するのは可能
113:デフォルトの名無しさん
22/05/18 10:38:43.35 2JRtSvHV.net
複オジの主張まとめ(1)
37, 39, 44
=====
CopyやCloneを使っているから別問題だろう。
一般的にRustのプログラミングでは、
Copy(暗黙的な自動コピー)やClone(clone()による明示的な手動コピー)を使うと楽になるが、コストは高くなる。
そのため不要なclone()を見極めてそれを回避するプログラミングが出来るかどうか、というRustにおける根源的な話だろう。
もちろんCopyは最もコストが高い。
個々のコスト自体は通常clone()と同じだが、常に自動的にclone()が起きるため最もコストが高くなる。
Copyはコストが一番高いから出来る限り避けるべきだな
特にヒープを使うならCloneまでにしておくべき
可能ならばCloneも避けるべきだが
114:デフォルトの名無しさん
22/05/18 10:39:05.95 2JRtSvHV.net
複オジの主張まとめ(2)
50, 52, 57
=====
それは理解不足すぎるぜ
大文字のCopyはCopyトレイトを意味しCopyトレイトを実装するか否かの話だろ
moveは別方向の話であり比較対象にすらならない
比較するならば「Copy実装(必然的にClone)も実装」「Cloneのみ実装」「どちらも実装なし」の3つだな
デタラメすぎ
ムーブでビットパターンのコピーは発生しない
ビットパターンのコピーが発生するのは引数の値渡し等であってムーブとは関係ない
さらに引数の値渡しでのでビットパターンのコピーとCopyのコピーも全く異なる
Copyのコピーはディープであって高コスト
これだけCopyやCloneを理解していない連中が多い状況だと
>>30の質問に答えられるかどうかは最低限クリアすべきテストとして有用ではないか？
フィボナッチ自体はもちろんどうでもよい話だがCopyやCloneを避けるRustの基本ができるかどうかわかる点で
115:デフォルトの名無しさん
22/05/18 10:41:41.09 2JRtSvHV.net
複オジの一連の主張を読んでから>>83の複オジ質問を読むべし
116:デフォルトの名無しさん
22/05/18 10:44:21.46 Jso4/z1R.net
複おじに反応するやつも複おじ
117:デフォルトの名無しさん
22/05/18 10:52:26.71 j9G6SOiS.net
主張が毎回変わる
口調も毎回変わる
表記も毎回変わる
間違いなく多重人格者
118:デフォルトの名無しさん
22/05/18 10:55:48.57 TXrPyH7a.net
>>98
この文脈では○○にはなんでも当てはまるから意味がないよね
以下なら議論になる？
Ａ「copy/cloneはmoveよりコストが生じるので、copyが必要な部分とそうでない部分で構造体を分離してでも出来るだけmoveを使用する」
Ｂ「copy/cloneのコストはmoveよりコストが生じるとは限らないので、一部でもcopyが必要な部分がある構造体は丸ごとcopyして構わない」
119:デフォルトの名無しさん
22/05/18 11:00:11.80 TXrPyH7a.net
>>116
そこまでいったらネット上では別人で良いだろ
120:デフォルトの名無しさん
22/05/18 11:05:55.27 f/6XNiB/.net
>>108
やってみた
fn main() {
for n in 0..100 {
let f = f(n);
println!("f({n}) = {f}");
}
}
fn f(n: i32) -> i32 {
match n {
0 => 0,
1 => 1,
n => f(n - 1) + f(n - 2),
}
}
このあたりから非常に重くなった
f(43) = 433494437
f(44) = 701408733
f(45) = 1134903170
f(46) = 1836311903
f(47) = -1323752223
f(48) = 512559680
121:デフォルトの名無しさん
22/05/18 11:24:29.81 Rx65yaNy.net
メモ化されてないんやから遅くなるのは当然
>>108は定義を示しただけちゃう？
122:デフォルトの名無しさん
22/05/18 11:25:30.07 Rx65yaNy.net
つかオーバーフローしとるな
123:デフォルトの名無しさん
22/05/18 11:29:30.10 e0i+LLok.net
>>119
そのコードだとcopyは何回くらい発生してるのだろう
0回？1回？2回？3回？たくさん？
124:デフォルトの名無しさん
22/05/18 12:13:31 QV9C5cPM.net
ぼくのかんがえたさいきょうのcountup<T>()をみんなバカにしたので
ぼくのかんがえたさいきょうのfibonacchi<T>()でやっつけようとしたら
わざをだすまえにボコボコにやられてしまいました
く、くやしいです！
125:デフォルトの名無しさん
22/05/18 13:41:52 mX15beFi.net
clone()が一個でコンパイル通ったからそのコードでのコピーは一回ではないか
use std::ops::{Add, Sub};
fn f<T>(n: T) -> T where T: Clone + PartialEq + TryFrom<usize> + Add<Output=T> + Sub<Output=T> {
let [zero, one, two] = [0, 1, 2].map(|n| T::try_from(n).ok().unwrap());
match n {
n if n == zero => zero,
n if n == one => one,
n => f(n.clone() - one) + f(n - two),
}
}
126:デフォルトの名無しさん
22/05/18 13:50:00 FQ8O/3lA.net
>>119
計算量はO(n), メモリ使用量は定数オーダーにできるのになんで定義どおり実装したの？
127:デフォルトの名無しさん
22/05/18 14:41:04.77 xTux5YG/.net
>>123
ぼくのかんがえたさいきょうのfizzbuzz<T>()もわすれないで
128:デフォルトの名無しさん
22/05/18 15:04:45.49 dI/aN4vs.net
>>125
そんな魔法はありません
129:デフォルトの名無しさん
22/05/18 16:48:40.40 pQAvghMm.net
>>127
え？
130:デフォルトの名無しさん
22/05/18 17:53:48.13 jsK0MVuh.net
Rust以前の問題じゃん
スレ違い
131:デフォルトの名無しさん
22/05/18 23:22:25.69 z2ufbs5N.net
>>124
そのclone()は子のf(n-1)とf(n-2)やそれらの子孫でも呼ばれるので1回ではなくO(n)より大きい
それをO(n)すなわちn回＋定数回以下に抑えられるのかどうか
あるいはO(0)回すなわち定数回以下に抑えられるのかどうか
132:デフォルトの名無しさん
22/05/18 23:41:48.24 RLh6XGtQ.net
フィボナッチはu128を使ってもf(187)でオーバフローするからBigInt必須
clone()はできる限り少なくしないと厳しい
133:デフォルトの名無しさん
22/05/19 00:10:47.96 SnnzWk5R.net
どうでもいいから複おじはTRPL読み直してきてね
134:デフォルトの名無しさん
22/05/19 00:16:28.52 IEr5OW/T.net
>>120
メモ化したら速くなったけど
memoをこちらで用意して毎回渡していくのを避けられないのかな？
fn main() {
let mut memo: Vec<usize> = Vec::new();
for n in 0..100 {
let f = f(n, &mut memo);
println!("f({n}) = {f}");
}
}
fn f(n: usize, memo: &mut Vec<usize>) -> usize {
if let Some(result) = memo.get(n) {
*result
} else {
let result = match n {
0 => 0,
1 => 1,
n => f(n - 1, memo) + f(n - 2, memo),
};
memo.push(result);
result
}
}
135:デフォルトの名無しさん
22/05/19 00:24:17.53 d4KplWCH.net
メモ化する必要ある？
直前の2つだけ記録しておけば次の一項が計算できるんだから再帰にする必要ないよね
136:デフォルトの名無しさん
22/05/19 00:33:12.40 IEr5OW/T.net
>>134
具体的にどうすればよいてすか？
137:デフォルトの名無しさん
22/05/19 00:46:08.98 HY3grr6d.net
>>135
"rust fibonacci"でググるとよいです
138:デフォルトの名無しさん
22/05/19 01:21:23 f3pwm4rC.net
>>134
直前の2つだけ記録して再帰にしない方法ならば
おそらくこうする案だと思うが
>>133がO(n)で済んでいるのに
139:対して これは二重のforによりO(n^2)になっていてこれは悪手 fn main() { for n in 0..100 { let f = f(n); println!("f({n}) = {f}"); } } fn f(n: usize) -> usize { match n { 0 => 0, 1 => 1, n => { let mut prepre = 0; let mut pre = 1; for i in 2..n { let tmp = pre; pre += prepre; prepre = tmp; } pre + prepre }, } }
140:デフォルトの名無しさん
22/05/19 01:31:14.77 d4KplWCH.net
>>135
fn main(){
for n in 0..10{
println!("f({}) = {}", n, f(n));
}
}
fn f(n:usize) -> usize{
let mut a = 0;
let mut b = 1;
for i in 0..n{
let tmp = b;
b = a + b;
a = tmp;
}
return a;
}
わざわざRustっぽい書き方をする必要はない
141:デフォルトの名無しさん
22/05/19 01:39:04.90 f3pwm4rC.net
>>138
それもforが二重となっていて全体でO(n^2)だから同じく悪手
142:デフォルトの名無しさん
22/05/19 02:09:27.74 XQuKTBpO.net
>>131
なら尚のことジェネリックにする意味ないよね？
143:デフォルトの名無しさん
22/05/19 03:45:23.95 jyObMdH0.net
>>137,139
悪手ってなにをもって悪手だよ
一般項の導出は高校生でもできるレベルで、そうすればO(log(n))で求められるし、つまらん計算量改善のためだけのアルゴリズム議論はもうやめろ
これ以上計算量の話をするなら別のスレでやってくれ
144:デフォルトの名無しさん
22/05/19 04:01:44.79 f3pwm4rC.net
>>141
mainに既にforループがある
だから個々をO(n)で求めると全体でO(n^2)となる
もし個々をO(log(n))で求めたとしても全体でO(n✕log(n))となる
一方で>>133は優れていて全体でO(n)だから圧倒的に良手
145:デフォルトの名無しさん
22/05/19 08:08:36.85 SnnzWk5R.net
まあ(usize) -> usizeのインターフェースを持たせつつ逐次処理したければメモ化が楽だわな
Rustとは特に関係の無いアルゴリズム一般論の話だけど
146:デフォルトの名無しさん
22/05/19 12:20:27.39 TVQgVkXp.net
なんでmainのループまで計算量に入れてるの？
今やってるのはフィボナッチ数列の計算量の話でしょ
余計なところまで話し広げてどうするの？
147:デフォルトの名無しさん
22/05/19 12:42:29.01 Y0RaHe9J.net
いい加減こんな語り尽くされた話終わってろ
何スレだよここ
148:デフォルトの名無しさん
22/05/19 12:44:11.02 2eGzkY/T.net
>>143
メモ化は良いが>>133のコードはインターフェースがあまりよくない
逆に>>138のコードはn個の列挙にO(n^2)も費やしている
以下のように書けばn個の列挙がO(n)に収まり、個別f(n)もO(n)で両立できる
fn main() {
println!("f(77) = {}", f(77));
for (n, f) in fibonacci_iter().enumerate() {
println!("f({n}) = {f}");
}
}
fn f(n: usize) -> usize {
fibonacci_iter().nth(n).unwrap()
}
fn fibonacci_iter() -> impl Iterator<Item=usize> {
let mut p = 0;
let mut q = 1;
std::iter::from_fn(move || {
let r = p;
p = q;
q += r;
Some(r)
})
}
149:デフォルトの名無しさん
22/05/19 12:47:27.97 wYj4kQtM.net
僕チンすごい！ってホルホルしたいんだろうけど
脳のワーキングメモリーが減ってこの程度の内容でしかコードが書けないんだろうな
150:デフォルトの名無しさん
22/05/19 13:06:09.75 TVQgVkXp.net
まず計算量にmainのループを勘定してる時点で…
151:デフォルトの名無しさん
22/05/19 13:18:54.57 u56F2Ocx.net
>>144
> 今やってるのはフィボナッチ数列の計算量の話でしょ
その通りでアンタが正しい
>>148
フィボナッチ『数列』の計算量だから
mainのループを勘定するのは当然
f(0)、f(1)、f(2)、…、f(n)がフィボナッチ『数列』
152:デフォルトの名無しさん
22/05/19 18:50:45.11 j8hvvms1.net
イテレーターにするとメリット多いんだな
Rustと相性いい
153:デフォルトの名無しさん
22/05/19 19:01:17.07 SnnzWk5R.net
>>146はメモ捨ててるから計算済みのf(n)引っ張ってくるのに毎回O(n)かかる
154:けどね イテレータと相性良いように見えるとしたら0..nループと組み合わせることしかしてこなかったmainが見せる幻想 そろそろRustの話に戻ってもらっていいですか？
155:デフォルトの名無しさん
22/05/19 19:56:30.02 X9gr9ket.net
>>151
マジで>>133のメモ化が好ましいと思っているのか？
イテレータはメモ化とも相性が良い
例えば>>146のfibonacci_iter()を含むイテレータ汎用メモ化は即席でこんな感じ
fn main() {
let mut memo = IterMemo::new(fibonacci_iter());
assert_eq!(memo.nth(10), Some(55));
assert_eq!(memo.nth(0), Some(0));
assert_eq!(memo.nth(30), Some(832040));
assert_eq!(memo.nth(5), Some(5));
assert_eq!(memo.nth(50), Some(12586269025));
}
struct IterMemo<I> {
iter: I,
memo: Vec<usize>,
}
impl<I: Iterator<Item=usize>> IterMemo<I> {
fn new(iter: I) -> Self {
IterMemo { iter, memo: Vec::new() }
}
fn nth(&mut self, n: usize) -> Option<usize> {
for _i in self.memo.len()..=n {
if let Some(x) = self.iter.next() {
self.memo.push(x);
}
}
self.memo.get(n).cloned()
}
}
156:デフォルトの名無しさん
22/05/19 21:07:44.82 wYj4kQtM.net
汚いな
157:デフォルトの名無しさん
22/05/19 21:11:33.57 +7PnyNeM.net
複オジは何が問題だと指摘されてるのか理解しないんだよなぁ
頭悪いのにとにかくマウントだけ取りたがって恥の上塗り上塗り上塗り
何回塗るねんっw
158:デフォルトの名無しさん
22/05/19 21:20:54.65 5LQoe3Bs.net
ほらなｗ
ぼくのかんがえたさいきょうのひぼなっちいてれーた！
どや！？ どやどやどや！！？
これで1000まで行くよｗ
159:デフォルトの名無しさん
22/05/19 21:27:22.70 SnnzWk5R.net
どうしてもイテレータが欲しいなら>>133に建て増ししたほうがよっぽど整理されていいよ
URLﾘﾝｸ(play.rust-lang.org)
160:デフォルトの名無しさん
22/05/19 21:29:51.14 u7/IlrFk.net
>>152
イテレータの規約に反したオレオレnth()はやめてくれ
IterMemoなんて名前の構造体にnth()が実装されてればイテレータのnth()と勘違いしてしまう
161:デフォルトの名無しさん
22/05/19 21:34:02.60 wYj4kQtM.net
その前に単純にバグ入りだけど
162:デフォルトの名無しさん
22/05/19 21:51:56.08 MGh63lg3.net
メモ化と個別機能が完全に分離できている>>152の方が良さげ
163:デフォルトの名無しさん
22/05/19 21:55:11.08 wYj4kQtM.net
このスレだけでなくRust書く人間はコケ前提なのが馬鹿らしい
未知の計算するのに対策してない馬鹿野郎ども
164:デフォルトの名無しさん
22/05/19 21:56:15.85 wYj4kQtM.net
目が覚めろ
目が覚めろ
コケ前提は恥ずかしい
165:デフォルトの名無しさん
22/05/19 21:56:34.11 iLpWQ9zs.net
>>159
分離できてねーよw
アホだろ
イテレータ使ったことないのか？
166:デフォルトの名無しさん
22/05/19 21:58:30.11 wYj4kQtM.net
Rust書く人間はレベルが低いと思われても平気なのか？
167:デフォルトの名無しさん
22/05/19 22:05:28.50 +v1Fmw4c.net
>>156は普通にフィボナッチ数列を順に表示するだけでも常にVecを使ったメモ化を伴うので筋がよくない
>>152はメモ化を付け外し可能で問題点も特に無いようだが
168:デフォルトの名無しさん
22/05/19 22:13:58.00 G2OEvBhv.net
「Rustでドヤりたい素人が犯しがちな12の過ち」
みたいな記事が捗りそう
169:デフォルトの名無しさん
22/05/19 22:18:44.85 iQApRYmM.net
>>164
関数の設計ができない人の発想
170:デフォルトの名無しさん
22/05/19 22:22:18.18 z7fdj+fO.net
>>164
なんでIDコロコロ変えてるの？
171:デフォルトの名無しさん
22/05/19 22:27:10.61 2ZXoSlQ2.net
>>165
複オジ特有の妄想を一般化するなよ
「複オジがドヤ顔で晒した恥ずかしい勘違い12選」にしとけ
需要ないけどな
172:デフォルトの名無しさん
22/05/19 22:29:47.42 EaXeIbDt.net
こんな数列ごときでヒープ必須の>>156はプログラミングが下手
173:デフォルトの名無しさん
22/05/19 22:47:12.76 AQMm07Qd.net
数列ごときのプログラムしか書けない複製おじさん……
174:デフォルトの名無しさん
22/05/19 23:33:01.93 wYj4kQtM.net
cargo run --releaseで予測した動きをしないコードを書くなよ
速やかにバグを取れ
175:デフォルトの名無しさん
22/05/19 23:33:20.92 vqaI/jC6.net
Rust 1.61.0
176:デフォルトの名無しさん
22/05/19 23:35:03.68 wYj4kQtM.net
このスレの底辺のコーダーもどき全員ゴミ
まともなコードすらかけないでiterが～とか言ってんじゃねえよ
バカども
177:デフォルトの名無しさん
22/05/20 00:27:37 xM0P3yOr.net
拗らせくんもいるのか
178:デフォルトの名無しさん
22/05/20 00:53:44 syYn06qN.net
このスレを見る限りRustプログラマは低レベルの人間ばかり
まともに動きもしないものでああだこうだ言いあってるだけだ
179:デフォルトの名無しさん
22/05/20 00:53:59 obugnqXb.net
フィボナッチ数列議論スレでやれ
180:デフォルトの名無しさん
22/05/20 00:54:42 syYn06qN.net
オーバーフローのまともな対処すら知らない馬鹿ばかり
181:デフォルトの名無しさん
22/05/20 01:04:06 syYn06qN.net
俺が小学生の頃はBASICで整数オーバーフロー考慮したプログラムは書いていた
多倍長整数演算も自分で考案して天文計算もやっていた
このスレの連中は小学生の頃の俺に負けるレベルの奴しかいない
Rustを書く人間はその程度のレベルばかり
182:デフォルトの名無しさん
22/05/20 01:16:05.19 P7xg55cn.net
エイリアン vs アバター
183:デフォルトの名無しさん
22/05/20 02:33:24.77 g6eOZZWy.net
天文計算なら多倍長じゃなくて浮動小数みたいに指数部と仮数部だけ保持しておくほうがいいだろう
184:デフォルトの名無しさん
22/05/20 07:35:06.49 SXN+DpBP.net
>>177
>>146のオーバーフロー対策をしてみた
これでいい？
fn fibonacci_iter() -> impl Iterator<Item=usize> {
let mut op: Option<usize> = Some(0);
let mut oq: Option<usize> = Some(1);
std::iter::from_fn(move || {
op.take().map(|p| {
op = oq.take().map(|q| {
oq = q.checked_add(p);
q
});
p
})
})
}
fn main() {
for (n, f) in fibonacci_iter().enumerate() {
println!("f({n}) = {f}");
}
}
185:デフォルトの名無しさん
22/05/20 08:11:12.19 YZ72zuyX.net
必要ないOptionまで追加してtake.mapのネストは汚すぎる
事前に設計せずコンパイラ駆動だけで書くと汚いコードになりがち
186:デフォルトの名無しさん
22/05/20 08:24:34.35 5N9lui0T.net
>>179
勝手に戦えww
複製おじさん vs 100点おじさん
187:デフォルトの名無しさん
22/05/20 08:33:57.56 7pe7/3hl.net
>>168
1レスで晒したこの4つの無知は外せないww
(1) ムーブでビットパターンのコピーは発生しない -> ムーブ無知
(2) ビットパターンのコピーが発生するのは引数の値渡し等であってムーブとは関係ない -> 値渡し無知
(3)さらに引数の値渡しでのでビットパターンのコピーとCopyのコピーも全く異なる -> Copy無知
(4)Copyのコピーはディープであって高コスト -> ディープコピー無知
188:デフォルトの名無しさん
22/05/20 08:44:11.52 SXN+DpBP.net
>>182
フラグは必要
それをOptionで簡潔に表現した
批判したいならば代替コードを出すべき
189:デフォルトの名無しさん
22/05/20 08:52:03.20 Te9amNUZ.net
フィボナッチ数列を他の計算の入力として使わないのなら何番目まで必要なのかをusizeとかで受け取ってBigUintのイテレータ返すので十分かな
190:デフォルトの名無しさん
22/05/20 08:54:16.47 Te9amNUZ.net
うげ
俺が出したのは>>185の言う代替案じゃないから
勘違いしそうだから念のため
191:デフォルトの名無しさん
22/05/20 09:01:03.34 SXN+DpBP.net
>>186
うん
今回はオーバーフローの対処をしろと言う>>177のリクエストに応じたのみ
192:デフォルトの名無しさん
22/05/20 09:03:09.77 SXN+DpBP.net
>>182
mapのネストが苦手と言うならば
mapを使わないバージョンも用意したのでどうぞ
fn fibonacci_iter() -> impl Iterator<Item=usize> {
let mut op: Option<usize> = Some(0);
let mut oq: Option<usize> = Some(1);
std::iter::from_fn(move || {
let p = op.take()?;
op = (|| {
let q = oq.take()?;
oq = q.checked_add(p);
Some(q)
})();
Some(p)
})
}
193:デフォルトの名無しさん
22/05/20 09:18:53.35 qCLhnuk6.net
firefoxってどのへんにrust使ってるんだっけ
194:デフォルトの名無しさん
22/05/20 10:35:37.22 t0eTe6yv.net
>>189
さらに汚くしてどうすんのw
195:デフォルトの名無しさん
22/05/20 10:55:09.60 SXN+DpBP.net
>>191
汚いと言うならば同じ動作をするもっと美しいコードを出そう
「汚い」と言う人はいつもコードを出せない人だから負け惜しみで言っているのかと
196:デフォルトの名無しさん
22/05/20 10:59:18.09 6DrTvbrK.net
>>185
unfold使ってた時と同じでフラグという捉え方がコードが汚くなる原因
命名を疎かにせず変数や関数の型を考えよう
そうすればOptionが必要なものと不要なものくらいは区別できるはず
ヒント終わり
コンパイルができた動けばいいだけのコードからは早めに卒業しようね
197:デフォルトの名無しさん
22/05/20 11:03:32.49 WF81UNfB.net
>>192
君のコードを汚いという人間は一人や二人ではないだろう？
それがなぜなのか？
なぜ汚いと言われるのか？
自分で考えて足掻いてこそ成長するんだよ
198:デフォルトの名無しさん
22/05/20 11:08:36.62 5NF4cE9g.net
>>192
ちなみに汚いコードの反対は汚くないコード
美しいコードである必要はない
実践で重要なのは美しいコードよりも汚くないコードを書くこと
199:デフォルトの名無しさん
22/05/20 11:16:04.61 SXN+DpBP.net
>>193
有無を表現することが必要だからOptionを使うのが最適
Optionを使わずに書けるのならばコードを出そう
>>194
今まで言われたことない
今回言われたから、いつも汚いを連呼しているがコードを出せないダメな人かなと
反論があるならばコードで示そう
200:デフォルトの名無しさん
22/05/20 11:26:17.74 SXN+DpBP.net
>>195
その通りだよ
だから汚くなく、簡素でわかりやすく、無駄をせずに効率も良いコードを>>189に出した
同じ動作と同じ効率でもっと簡素に書けるのならばコードを出してごらん
201:デフォルトの名無しさん
22/05/20 11:47:37.20 hTlaNj/P.net
ベンチも取らずに効率とな？
202:デフォルトの名無しさん
22/05/20 11:48:38.99 50J2u53j.net
>>184
その4つは全部並んでたからインパクト強いけど
個々で見るとムーブや値渡しの間違った理解は複オジ特有じゃないからちょっと弱いな
203:デフォルトの名無しさん
22/05/20 12:16:58.58 lLMUMPSU.net
>>196
>今まで言われたことない
すごーいwww
お薬必要ですね
204:デフォルトの名無しさん
22/05/20 12:28:38.69 pMSjr2Vl.net
後出しでどんどん条件が変わっていくから話がまとまる訳がない
これ以上続けたいならソース貼るときは前提条件を共有した上でコンパクトに議論を終わらせてくれ
205:デフォルトの名無しさん
22/05/20 19:05:29.84 eTvpznuT.net
複オジは断念したみたいだから
俺の考える汚くないコードを参考までに貼っとく
URLﾘﾝｸ(play.rust-lang.org)
206:デフォルトの名無しさん
22/05/20 19:24:47 P7xg55cn.net
まずイテレータやめろや
207:デフォルトの名無しさん
22/05/20 19:37:01 0DaneQt4.net
＿＿ ＿＿ ＿＿_ ＿＿＿＿＿ ＿＿＿＿_ ___ ___ ___
| | / / | ／/ | /＿＿ __/ [][] ＿| |_| |＿_ _| |_
| |. / / / / / /￣￣|. l / / | ＿ | |_ ﾚ'~￣|
| | / / / / / /. ／ / | |___ ￣| | / / / ／| |
| | / / / / / ￣￣ ／ ＼＿_| | | ￣ /_ / | |_
| |. / / / / / /￣￣￣ |＿| |__| ＼/
| |/ / / /. / /
|. / / / / /
| /. ／ | ./ /
￣￣￣ ￣￣￣. ￣￣
208:デフォルトの名無しさん
22/05/20 21:06:57.55 /0md/MJf.net
tauriどうよ
209:デフォルトの名無しさん
22/05/20 21:13:38.21 zMcvGPNW.net
>>202
successorsバージョンはシンプルでいいね
210:デフォルトの名無しさん
22/05/20 21:27:07.51 P7xg55cn.net
>>190
URLﾘﾝｸ(wiki.mozilla.org)
話題になったServo関連はもちろんとして、他は文字エンコーディングとか言語関連での採用が多いみたいね
URLﾘﾝｸ(4e6.github.io)
行数ではGecko全体の10%程度
211:デフォルトの名無しさん
22/05/20 21:57:08.66 j6iPiVjl.net
RustとC++を学ぼうと思ってるプログラミング初心者です。
両方ともそのうち学ぶとして、どっちを先にした方がいい感じですか？
212:デフォルトの名無しさん
22/05/20 21:59:12.98 j6iPiVjl.net
あ、スレチだったかも...すみません
213:デフォルトの名無しさん
22/05/20 22:06:04.12 j6iPiVjl.net
連投すみません...
C++ vs Rustのスレ終わってたから一応どっちにすべきかここで聞きたい
ちなみに自分の中では
・C++のほうがほんの少しだけ速い
・Rustのほうが書くのとかメモリとか楽
・C++のほうが実行環境とか充実してる
みたいな認識になってます。よろしくお願いします
214:デフォルトの名無しさん
22/05/20 23:40:49.05 1Ryh5lzf.net
>>207
ほー
ありがとう
215:デフォルトの名無しさん
22/05/21 00:10:36.10 gcU5DXZF.net
>>210
どういう領域のプログラムを作りたいかでどっちが適してるか変わるからもうちょっと学ぶ背景とか教えて
216:デフォルトの名無しさん
22/05/21 01:38:57.59 qnjM1Lxc.net
>>210
仕事で使うほう
217:デフォルトの名無しさん
22/05/21 01:45:27.47 7bviEaCH.net
なんのために学ぶのかにもよるけど、なんにせよC言語とJavaScriptはエンジニアなら全員勉強すべき
急いでないなら、そのあとでC++とRustを選んでもいい
218:デフォルトの名無しさん
22/05/21 01:46:40.74 t6WWJYF7.net
まぁC言語だよな
219:デフォルトの名無しさん
22/05/21 01:58:05.82 y9SWDgH5.net
せっかくRustのスレに来たんだしRustをやりなよ
C++をかじるのはいいけど仕事で使うわけでないなら
じゃじゃ馬を飼い馴らすバッドノウハウを今更学ぶ必要はないよ
220:デフォルトの名無しさん
22/05/21 07:32:51.54 yS5lPrM7.net
回答ありがとうございます…
とりあえずRustにしておこうと思います
221:デフォルトの名無しさん
22/05/21 09:16:08.98 iurUdiXY.net
>>217
Rustの入門書をぱらぱらと何冊か見たけど計算の優先順位の話とか普通のプログラム入門は全く書かれてないよね
C++の方は確実に書かれてる
入門はCやC++の方がいいと思うよ
222:デフォルトの名無しさん
22/05/21 09:22:23.20 iurUdiXY.net
個人的にRust以外にやったほうがいいと思う言語
C C++（深入りしない） java
多分必用になる（と思われる）言語
javascript python
223:デフォルトの名無しさん
22/05/21 09:40:03.63 wAUuWoIP.net
Cをざっと学んでからRustかな
C++は（深入りしない）が重要なんだけど、初心者が自分で判断するのは厳しい
既存の資料もC++98から20まで玉石混交という感じだし
224:デフォルトの名無しさん
22/05/21 09:44:15.57 iurUdiXY.net
自分はOOPは学んだほうがいいと思う派なのでRustだけでは不十分だと感じる
絶対業務で必要になるし
C++ java C# 学んだほうがいいと思う
225:デフォルトの名無しさん
22/05/21 10:11:16 gcU5DXZF.net
いろんなパラダイムの言語を触るのが良いよ
226:デフォルトの名無しさん
22/05/21 10:19:06 5oK/i29u.net
Rustを学ぶならばほとんどの分野でC++とJavaは不要
C言語は実用とは別に最初に基礎教養として学んでおいたほうがRustの理解が早い
C→Rustも可能だが、その前にスクリプト言語などでオブジェクト指向(のうちインスタンスとメソッド呼び出し等)と、非同期(async/await)をそれぞれ学んでおくと楽だと思う
その場合のスクリプト言語はJavaScript(ただしHTML/CSSに踏み込まなくて済むNode.js)がオススメかな
227:はちみつ餃子
22/05/21 10:46:13.19 JD6rd3hb.net
単に習得するためなら Rust を学ぶために他の言語を先に知っておく必要はないが、
C++ を先に使っていると Rust の「ありがたみ」に納得しやすいという意見はあるみたいだね。
まあ C が基礎教養であるというのは私も同意。
228:デフォルトの名無しさん
22/05/21 10:50:44.47 iurUdiXY.net
Rustだけを学ぼうとしてもその環境が整ってないんですよ
さっきも書いたけど入門書に演算子の優先順位とかそのレベルの話がどこにも書かれてない
他の言語に乗っかって入門するしかない
229:デフォルトの名無しさん
22/05/21 10:59:08.26 5oK/i29u.net
>>224
C++は不要
Cを習得しておけばRustのありがたみがわかる
230:デフォルトの名無しさん
22/05/21 11:34:26.44 jUaeJjgy.net
>>225
演算子の優先順位の話はオライリー本には書いてあるよ
プログラミングを初めて学ぶ人間がRustから始めるべきじゃないというのは完全同意だけど
231:デフォルトの名無しさん
22/05/21 11:47:35.41 vC8/2hE9.net
ぼくはガベージコレクションが嫌いです
232:デフォルトの名無しさん
22/05/21 11:50:19.62 KkLFGMWv.net
オライリー本もヒープとかスタックとか出てくるあたり、CやC++で動的メモリ確保の面倒くささを知ってる人向けだと思う
233:デフォルトの名無しさん
22/05/21 11:50:43.88 uR6sIAw1.net
メモリ管理まわりの勉強はcで必須
234:デフォルトの名無しさん
22/05/21 11:56:37.53 5oK/i29u.net
逆に考えよう
C→Rustと進むだけで十分であり、何か困ることある？
困ることないよな
235:デフォルトの名無しさん
22/05/21 12:04:35.32 CYzzzsUy.net
ゴミ集めてどうするんだっていう。
236:デフォルトの名無しさん
22/05/21 12:06:48.99 gyqhSlT2.net
十分かどうかはさておき
そもそもCをすべきかどうかというと微妙かもしれない
Cしかやってなさそうな人特有の
・変数がたくさんとっちらかった
・変数名が暗号めいてて
・ifやforが多重になってて
・グローバル変数を平気で使っちゃってる
コードみたことあるでしょ
それはそうするしかやり方を知らないから
一方、抽象度の高い言語からやった人は先にそっちに慣れるんで
List(8, 9, 3, 1).sorted.reverse.foreach(print)
こういうふうにスッキリ書けるのを目指してくれる
237:デフォルトの名無しさん
22/05/21 12:09:45.76 0tb1eDc3.net
オブジェクト指向がいちばん大事
238:デフォルトの名無しさん
22/05/21 12:10:08.62 Uoz2jgaJ.net
格下相手の話だけイキイキするな
239:デフォルトの名無しさん
22/05/21 12:12:07.01 5oK/i29u.net
>>233
それは同感で非常に重要
だから最初に>>223でCとJavaScriptを先に学ぶのをオススメと書いた
240:デフォルトの名無しさん
22/05/21 12:39:26.68 5HpZ3As+.net
ありがたみなんて知る必要ないでしょ
典型的な老害だな
241:デフォルトの名無しさん
22/05/21 12:39:58.62 0jWT+RR4.net
>>221
C++ と java はやったけど C# 必要ですか？
242:デフォルトの名無しさん
22/05/21 13:06:24.69 dZzrxVLl.net
Rustは、プログラミング経験者向けの情報が多い気がするから、PythonとかJavascript辺りをサラッと試してからでも良い気はする。
コンパイルとはとか、型って何？とか。
243:デフォルトの名無しさん
22/05/21 14:18:25 2XTF0B5o.net
>>235
それな
自演ネタふりの可能性すらある
244:デフォルトの名無しさん
22/05/21 14:45:48 is6KmnjI.net
いつも同じパターン
質問や
245:相談があると、答えたり情報を出したりせずに、それらをしている人たちをバカにする コードが出ると、代案コードを出すわけでもなく、とにかく批判のみ行なう
246:デフォルトの名無しさん
22/05/21 14:51:09.52 /NlDQvZW.net
プログラミング初心者は言語知識よりも
プログラミングという行為がどういうものなのか
どういうことを考える必要があるかというメタ認知を得ることが最も重要
メタ認知を獲得するために最も効果・効率ともに高い方法は
考えて・書いて・動かして結果を確認するというフィードバックサイクルをとにかく繰り返し回すこと
初心者は上記のサイクルが回しやすい言語から始めると後々の成長が早い
C/C++/Rustはサイクルを回すために越えなければならないハードルが相対的に高いため
現代では初心者向け言語ではない
247:デフォルトの名無しさん
22/05/21 14:57:49.13 7TYnpeBW.net
>>241
被害妄想はげしくね？
代案も代替コードもそれなりに出てるよね？
それに悪い物を悪い(汚い物を汚い)というためだけに毎回代案を用意する必要なんて全くないよ
248:デフォルトの名無しさん
22/05/21 15:08:42.12 d40Kl4Hf.net
意訳:
ぼくちゃんがかいたさいきょうのコードをひはんしないでくだしゃい
ぼくのかんがえたやつがさいきょうなんでしゅから
249:デフォルトの名無しさん
22/05/21 15:15:12.95 terB7Bhw.net
なでしこ（プログラミング言語）も使ってあげて、、
250:デフォルトの名無しさん
22/05/21 15:15:33.24 lzMNCHOR.net
お前ら>>205みたいなのにも反応してやれよ
251:デフォルトの名無しさん
22/05/21 15:46:51.93 zcBlczkH.net
>>246
前スレがいしゅつ
252:デフォルトの名無しさん
22/05/21 16:45:07.99 dBYh2+4n.net
>>218
そのかかれてるC++入門本のタイトルあげてみろ
253:デフォルトの名無しさん
22/05/21 16:48:39.25 dBYh2+4n.net
>>225
お前、>>218 で *計算*の優先順位って書いてるじゃん。
>>225 でしれっと演算子の優先順位にしてんじゃねーよ。
254:デフォルトの名無しさん
22/05/21 16:54:22.75 dBYh2+4n.net
お前ら新しい言語勉強する時に本読まないの？
たいていの本には想定する読者ってのが最初のほうに書いているだろ。
現在出版されてるRustの本で他の言語全く使った事ない読者を想定してる本はあるのか？
255:デフォルトの名無しさん
22/05/21 17:14:51.81 is6KmnjI.net
>>246
Tauriではなくweb-view crateがシンプルで良いと思う
256:デフォルトの名無しさん
22/05/21 17:17:44.98 is6KmnjI.net
>>250
新たなプログラミング言語を学ぶために本を読んだことがないのでRustについてもわからん
わざわざ本を買って学習する人は少数派ではないか？
257:デフォルトの名無しさん
22/05/21 17:21:24.15 7bviEaCH.net
おれは基本は本を読む派だけど、読まない派のほうが多そう
258:デフォルトの名無しさん
22/05/21 17:23:04.81 mDh+ij7H.net
昔は本買うか図書館行くかしかなかったもんね
二十年くらい前からこっちはもう本イランけど
ネットで見れるでしょ何もかも
259:デフォルトの名無しさん
22/05/21 17:26:29.76 ImS18vsK.net
最近はもっぱら言語公式のチュートリアル。Rustだと「the book」
260:はちみつ餃子
22/05/21 17:33:54.80 JD6rd3hb.net
>>252
必ずしも本でなくてもいいが……。 体系的にまとめられた入門用の文書は読むべきだと思う。
Rust に関して言えば >>1-3 で挙げられているような文書があるからありがたく利用させてもらう。
基礎が身についてない段階で詰まるたびにググるみたいな学び方だと個々の情報の断片を
自分の理屈で勝手に (誤った形で) 結び付けてにっちもさっちもいかなくなってるのはよく見る。
261:デフォルトの名無しさん
22/05/21 17:59:31.75 WnQbOX9f.net
確かにこのスレではよく見る
>>112,113
262:デフォルトの名無しさん
22/05/21 18:16:32.63 5PeJx3n4.net
複オジは本を読まないのが原因とは違うと思うぞ
本を読んでも自分勝手な理屈を脳内補完してそれが正しいと思い込むタイプ
263:デフォルトの名無しさん
22/05/21 18:31:09.43 Uoz2jgaJ.net
>>251
実際使ってるの？
github HEADの最終更新11ヶ月前とかだけど
264:デフォルトの名無しさん
22/05/21 18:55:12.40 is6KmnjI.net
>>259
web-view crateは非常にシンプルで
最初のwebviewビルダーと
JavaScript側からのRustの呼び出しと
Rust側でJavaScriptの実行の三つだけをサポート
学習コストもほぼゼロ
だから更新するようなことがほとんど無い
それでも例えばHTMLのonclick等でRust側を呼び出せてRust側で処理してJSで反映ということが出来てうれしい
265:デフォルトの名無しさん
22/05/21 19:02:17.99 qnjM1Lxc.net
>>252
じゃあ >>208 から始まる話題にはお前はおそらく不適切だからレスすんなよ。
266:デフォルトの名無しさん
22/05/21 19:12:43.38 is6KmnjI.net
>>261
唐突にポカーンだけど
そういった、人への批判は意味がなく荒れるだけで誰の役にも立たないので止めたほうがいいよ
267:デフォルトの名無しさん
22/05/21 19:21:14.01 v1GULhnc.net
たしかに
「そういった人」への批判は意味がなくて、荒れるだけで、誰の役にも立たない
268:デフォルトの名無しさん
22/05/21 19:27:36.73 tJscH9kk.net
「そういった」がかかるのは「人」ではなく「批判」じゃないのかな
269:デフォルトの名無しさん
22/05/21 19:30:02.17 gcU5DXZF.net
元のレスをもじっただけで
唐突に殴りかかってくる人には何を言っても無駄だよと諭してるだけでは
270:デフォルトの名無しさん
22/05/21 19:32:49.23 VA28KJC+.net
多くの人は良い人たちだが
残念ながらこのスレにも他人を叩いたり言いがかりを付けたりするのが好きなアレな人が紛れ込んでいる
271:デフォルトの名無しさん
22/05/21 19:43:36.19 7bviEaCH.net
そういうのは反応を見て楽しもうとしてるだけだろうから、無視するしかない
272:デフォルトの名無しさん
22/05/21 21:18:46 3ug0n3Zl.net
>>260
tauriも同じようなもんじゃないの？
273:デフォルトの名無しさん
22/05/21 23:40:28.85 GKlgLxBR.net
今流行のアプリをweb-viewのテストで作ってみたがこんな感じなのか
const HTML: &str = r#"
なぜかHTML部分はセキュリティうんぬん言われて貼れないので略
"#;
fn main() {
struct Fibonacci { index: usize, cur: usize, pre: usize }
let fibonacci = std::sync::Mutex::new(Fibonacci { index: 0, cur: 0, pre: 1 });
let webview = web_view::builder()
.content(web_view::Content::Html(HTML))
.invoke_handler(|webview, arg| {
match arg {
"next" => {
let mut f = fibonacci.lock().unwrap();
(f.index, f.cur, f.pre) = (f.index + 1, f.cur + f.pre, f.cur);
webview.eval(&format!("show({}, {})", f.index, f.cur))?;
},
"exit" => webview.exit(),
_ => unimplemented!(),
};
Ok(())
})
.user_data(()).build().unwrap().run().unwrap();
}
274:デフォルトの名無しさん
22/05/22 13:23:37.89 kzep88by.net
MozilaはFirefoxを丸ごとRustに書き換える予定はあるん？
今はまだ一部だけだよねRustになってるの
275:デフォルトの名無しさん
22/05/22 14:00:05.26 IGyJdnKj.net
>>270
そうなの？
276:デフォルトの名無しさん
22/05/22 14:06:50.95 1cbV2u9G.net
FirefoxはレンダリングエンジンをRustでゼロから作ってるんじゃないの？
277:デフォルトの名無しさん
22/05/22 14:11:38.83 s/f+VQic.net
自分で確かめて
URLﾘﾝｸ(github.com)
278:デフォルトの名無しさん
22/05/22 14:14:17.72 pc68DccV.net
servoはまだ実験段階だったと思う
279:デフォルトの名無しさん
22/05/22 14:54:56.44 kzep88by.net
>>273
ありがとう～
280:デフォルトの名無しさん
22/05/22 15:29:45.38 srSb/t9O.net
>>270
特にそういう予定はないと思う
servo自体も別に次世代Firefoxを目指してるとかではなく、Rustでwebブラウザを書く実験プロジェクトという感じ
その実験でうまく行ったコンポーネントを徐々にFirefoxに移植していっている
281:デフォルトの名無しさん
22/05/22 15:57:34.13 pc68DccV.net
アプローチとしては正しい姿なんだろうな
282:デフォルトの名無しさん
22/05/22 17:29:35.11 1mUE50i3.net
暇を持て余した神々の遊び
servoと言うよりモンスターエンジンだね…
283:デフォルトの名無しさん
22/05/22 17:37:14.17 7nmc6Bff.net
>>270
C++で書かれてる部分は置き換えられるかも知れないけどJSで書かれてる部分までは置き換えしないんでないかな
284:デフォルトの名無しさん
22/05/22 19:19:39.37 9fWZc0TE.net
JSとか言ってるのは君だけだと思うよ
285:デフォルトの名無しさん
22/05/22 19:22:44.24 7nmc6Bff.net
>>280
FirefoxではC++と同じくらいJS使われてるよ
URLﾘﾝｸ(www.openhub.net)
286:デフォルトの名無しさん
22/05/22 19:25:56.61 nrxT1a+p.net
JSの部分を置き換えるなんてはなから誰も思ってないってことだと思うが
287:デフォルトの名無しさん
22/05/22 19:26:01.69 LKVhbTwj.net
意訳すると「JSで書かれてる部分まで置き換えるとか言ってるのは君だけだと思うよ」かな？
言ってないね
288:デフォルトの名無しさん
22/05/22 19:29:03.65 7TIjBb30.net
>>282
正解
>>283
アホ
JSで書かれてる部分まで置き換えるかどうかとか言ってるのは君だけだと思うよ
289:デフォルトの名無しさん
22/05/22 19:33:12.87 LKVhbTwj.net
>>284
じゃ>>280で「言ってる」とか書くな
ボケ
290:デフォルトの名無しさん
22/05/22 19:46:00.83 u+qheqhP.net
>>285
はあ？
JSって言ってるよね？
バカなの？
>>279 JSで書かれてる部分までは置き換えしないんでないかな
291:デフォルトの名無しさん
22/05/22 19:56:58.26 nleMAmaj.net
>>270 が「Firefox を "丸ごと" 書き換える」と言っていたので全部はRustにならないよと伝えたんだけどなんかお気に召さなかった？
292:デフォルトの名無しさん
22/05/22 20:16:58.99 KMOjS2oh.net
>>270が言うのはservoのことでquantumの動機がcssパーサrustで書いたら
安全だったからC++で書かれたコンポーネント置換しよだからjs出る余地ないじゃん。
>>282で終わった話。
293:デフォルトの名無しさん
22/05/22 20:17:09.14 M3jNarf6.net
そうだね、そんなふうに言われたらシェルスクリプトやMakefileまでrustで置き換えるんじゃないかって思っちゃうよね。
馬鹿なん？
294:デフォルトの名無しさん
22/05/22 20:36:16 7nmc6Bff.net
FirefoxはXULのイメージがあってJSも主要な構成要素だと思ってたから変なレスつけちゃったね
皆さんの機嫌害しちゃって申し訳ない
295:デフォルトの名無しさん
22/05/22 20:54:23.92 KMOjS2oh.net
よく見たらID変えて暴れてるやつまだ居座ってるのか。
>>290
XULはだいぶ前に死んだよ。
XULRunnerが単体で利用困難な問題が解決できなくて存在意義を失った。
296:デフォルトの名無しさん
22/05/22 22:32:56.13 7nmc6Bff.net
>>291
XUL完全になくなったの？
XBLは完全に消えたって聞いたけどXULは細々と生き残ってるものだと思っていた
297:デフォルトの名無しさん
22/05/23 01:12:40.07 436cwmll.net
>>290
ほんと反省しろよ
298:デフォルトの名無しさん
22/05/23 02:27:31.54 n+tkR/ue.net
反省してま～す
299:デフォルトの名無しさん
22/05/23 19:27:40.26 qJLEBqNZ.net
>>189
おまえら全員そうだがフィボナッチ数列でusize固定はおかしいだろ
コード自体は問題ないが <T: Zero + One + CheckedAdd> を付けろ
あとは0と1をT::zero()とT::one()へ置き換えればi8型からBigUintまで何でも動作するようになる
URLﾘﾝｸ(play.rust-lang.org)
さらに今回はfrom_fn()利用をそのままsuccessors()利用へ変換できるので見やすくなる
fn fibonacci_iter<T: Zero + One + CheckedAdd>() -> impl Iterator<Item = T> {
let mut oq = Some(T::one());
iter::successors(Some(T::zero()), move |p| {
let q = oq.take()?;
oq = q.checked_add(p);
Some(q)
})
}
ちなみにCloneを要求しないためBigIntなどでも無駄なコスト増とならない
>>202
そのコードは暗黙のコピーが発生している
from_fn()使用版のコードはcurrがキャプチャ変数なので「let n = curr?;」でコピー発生
successors()使用版のコードはクロージャ引数「|&curr: &usize|」の「&」でコピー発生
usizeならば問題はないがBigIntなどでそのコードは動かないので劣る