Rust part15 YouTube動画>1本 ->画像>11枚

公式
https://www.rust-lang.org/
https://blog.rust-lang.org/
https://github.com/rust-lang/rust

Web上の実行環境
https://play.rust-lang.org

日本語の情報
https://rust-jp.rs/

※Rustを学びたい人はまず最初に公式のThe Bookを読むこと
https://doc.rust-lang.org/book/

※Rustを学ぶ際に犯しがちな12の過ち
https://dystroy.org/blog/how-not-to-learn-rust

※Rustのasyncについて知りたければ「async-book」は必読
https://rust-lang.github.io/async-book/

※C++との比較は専用スレへ
C++ vs Rust
http://2chb.net/r/tech/1619219089/

※次スレは原則>>980が立てること

前スレ
Rust part14
http://2chb.net/r/tech/1644596656/

Rust The Book (日本語版)
https://doc.rust-jp.rs/book-ja/
Rust edition guide (日本語版)
https://doc.rust-jp.rs/edition-guide/
Rust by example (日本語版)
https://doc.rust-jp.rs/rust-by-example-ja/
Rust cookbook (日本語版)
https://uma0317.github.io/rust-cookbook-ja/
Rust API guideline (日本語版)
https://sinkuu.github.io/api-guidelines/
Rust nomicon book (日本語版)
https://doc.rust-jp.rs/rust-nomicon-ja/
Rust WASM book (日本語版)
https://moshg.github.io/rustwasm-book-ja/
Rust embeded book (日本語版)
https://tomoyuki-nakabayashi.github.io/book/
Rust enbeded discovery (日本語版)
https://tomoyuki-nakabayashi.github.io/discovery/

Rust CLI (Command Line Interface) apps Book
https://rust-cli.github.io/book/
Rust async-std Book
https://book.async.rs/
Rust The Unstable Book
https://doc.rust-lang.org/nightly/unstable-book/
Rust rustc Book
https://doc.rust-lang.org/rustc/
Rust Cargo Book
https://doc.rust-lang.org/cargo/
The Rust Reference
https://doc.rust-lang.org/reference/
The Rust Standard Library
https://doc.rust-lang.org/std/

c++スレやHaskelスレでああでもないこうでもないと実用性無視してごちゃごちゃ言ってたのがRustスレに移って来て
ああでもないこうでもないと不毛な話を繰り返してるだけなんだろうな…

let mut >>1乙

ごちゃごちゃ戻り値の型さえ理解してないで書いてる

またワッチョイなしですか

>>6
ちゃんと理解しましょう

乙
もっとRustが普及しますように☆彡

>>7
ﾜｯﾁｮｲなんて飾りです

>>7
ワッチョイスレはすでにあるだろ

>>8
正直言うと、俺たちは若い奴らが何やらワイワイさわいでCOBOLおじさんJAVAおじさん、C#おじさん扱いされないよう
カッコよさげだから、なんとなく雰囲気でRustを書いてるんだ。
でも、うまく言えないけど理解する必要性を全く感じない、下請けにおまえRustも分らんの？とマウントするのが夢なんだ
とやかく言われる筋合いは無い

再帰的なmacroはaliasしても展開時に
元の名前のマクロを使おうとしてエラーになるんだがこれって避けられない？

use foo_crate::foo as bar;
bar!(…)

cannot find macro `foo` in this scope
this error originates in the macro `bar`

>>13
foo! の定義中の foo! 呼び出しを $crate::foo!() みたいにすればいけるんじゃないかな

>>14
それだ、ありがとう

前スレで出ていたこの上限チェック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
})
}

複オジに毒されてるな

successors(Some(start), move |n| n.checked_add(&one))

>>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
}
})
}

unfoldでなんでもできるからunfoldしか使わなくなってしまった人
いろいろな人

>>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)
})
}

>>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利用版を記述することで要点のみに絞ることができる

>>19
全部同じやつだぞ
一人二役で会話してる

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)
})
}

大人が集まってくつろいでるところに
子供がガラッと入ってきて九九の暗唱しはじめたら
頑張ってるのがほほえましくて応援しちゃうでしょ
でも
大人がガラッと入ってきて九九の暗唱しはじめたら
ギョッとするし不安になってくるやろ
なぜそんなもんをお披露目しちゃうのか
なぜ得意げになって頑張ってるのかわからない
もういいよ！と単に言えばいいのか
続きはカーチャンに見えもらってね！と言えば良いのか
言って分かってもらえる気配もないので怖い

今回はこれでもいい

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))
}

はちみつおじさん悔しそうwww

九九と違って子供用のおもちゃプログラムでしか使えないコードなんだよなぁ

代案出さずに文句だけつける万年野党みたいなやつがいるな

>>25
それまんま>>17やんけ

九九のように簡単だという皆さま方に質問です
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, ...

>>30
「Rustのお題スレ」でも立ててそっちでやってくれ

>>31
難しくて解けないという表明ですか？
どういう点が難しかったのか教えてください

教えてもらったsuccessorsを披露したくてしょうがない幼児メンタルwww

>>24の言う通りだな

>>33
successorsは適用範囲が非常に狭いので>>30の例には使えないはず

>>33
ぜひそれを披露してやり方を教えてください

フィボナッチ数列イテレータ前スレでだれかが書いてたでしょ
それじゃいかんの

>>36
CopyやCloneを使っているから別問題だろう。
一般的にRustのプログラミングでは、
Copy(暗黙的な自動コピー)やClone(clone()による明示的な手動コピー)を使うと楽になるが、コストは高くなる。
そのため不要なclone()を見極めてそれを回避するプログラミングが出来るかどうか、というRustにおける根源的な話だろう。

Copyのコストが高い？

>>38
もちろんCopyは最もコストが高い。
個々のコスト自体は通常clone()と同じだが、常に自動的にclone()が起きるため最もコストが高くなる。

複製おじさんはいつも自分勝手な妄想を「一般的には～」とか「皆は～」と言って自分を正当化しようとするよね

>>40
間違いは誰にでもあるからまだいいんだが
指摘されても反省するどころかさらなる妄想を撒き散らすのがほんと迷惑

おじさん使いの人の自演がいつもよくわからん
唐突に妄想(?)を攻撃し出すが幻覚か何か見えてるのか

>>39
Cloneのコストが高い型にCopyを実装するな

Copyはコストが一番高いから出来る限り避けるべきだな
特にヒープを使うならCloneまでにしておくべき
可能ならばCloneも避けるべきだが

Copyは所有権を複製するから最も高コスト(ｷﾘｯ！！

もはやどのレスもギャグにしか見えん
俺のしってるCopyとは確実に違う

今までで一番意味不明なこと言ってるな
Copyのコストが高いならmoveのコストはどうなるのよ

>>45
所有権に複製という概念はない
Copyをimplすると使われる時に値が自動的に複製される
そのためCopyは最も高コスト

>>46
君のレスがギャグにしか見えん

Rust のムーブはビットパターンのコピーだもんな。
低レイヤの視点で見たらコピーと何の差も無い。

なるべく参照を使う場合にしても間接参照の実行コストとコピーの実行コストを天秤にかけてどちらが有利かは場合による。

>>47
それは理解不足すぎるぜ
大文字のCopyはCopyトレイトを意味しCopyトレイトを実装するか否かの話だろ
moveは別方向の話であり比較対象にすらならない
比較するならば「Copy実装(必然的にClone)も実装」「Cloneのみ実装」「どちらも実装なし」の3つだな

>>48
ギャグだと分からない人がいるとは想定していませんでした。
誤解を招いたのであれば申し訳ございません。

>>49
デタラメすぎ
ムーブでビットパターンのコピーは発生しない
ビットパターンのコピーが発生するのは引数の値渡し等であってムーブとは関係ない
さらに引数の値渡しでのでビットパターンのコピーとCopyのコピーも全く異なる
Copyのコピーはディープであって高コスト

そもそもフィボナッチ数列イテレータなんて誰も求めてないので
前スレのだれかさんの実装に問題があると思うなら自分で勝手に改善してなさい
そしてその結果はここに貼らなくていいぞ

「ヒープ使うならCloneまでにしとけ」
このセリフが一番刺さった

>>52
おじさんマジかよwww

>>54
Dropを実装する型はCopyを実装できないよ
BoxもRcもStringもVecもそもそもCopyを実装できないので、するかしないか考えること自体が無意味

どういう型にCopyを実装できるか、できないか、すべきかはdocsに書いてあるので
なんのかんの言う前にまずはこれを読もうね
https://doc.rust-lang.org/std/marker/trait.Copy.html

>>53
これだけCopyやCloneを理解していない連中が多い状況だと
>>30の質問に答えられるかどうかは最低限クリアすべきテストとして有用ではないか？
フィボナッチ自体はもちろんどうでもよい話だがCopyやCloneを避けるRustの基本ができるかどうかわかる点で

>>52
じゃあムーブでなにが起こるとおもってんの？

>>53
> フィボナッチ数列イテレータなんて誰も求めてない

それはそうなんだけど
唯一本人にとっては伝家の宝刀だから
少なくともこのスレいっぱいまでは引っ張って
何度も何度も参照するはず

フィボナッチがどうでもいいならこの話は終わりです

関数の深いところから順に構造体をムーブで返していって
各関数で渡ってきた構造体のアドレスを表示させてみた

#[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もアドレスが一致
ムーブではアドレスそのままであり
ビットパターンのコピーが為されないという結論

>>50
"Copyのコストが高い" は Copy を実装する行為そのもののコストが高いと解釈すべきということ？
そんなばかな

>>52
ドキュメント読みましょうねー

https://doc.rust-lang.org/stable/std/marker/trait.Copy.html
> 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.

>>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);
}

>>61
struct S {}
fn main() {
let s1 = S{};
println!("s1: {:p}", &s1);
let s2 = s1;
println!("s2: {:p}", &s2);
}

ごめん被った。やっぱそう思うよね。

>>56
ちょっとw
なんで刺さったのか少しは考えてよww
ギャグゴロシめ

>>61
>>63
その二つの相異なる結果を見るとビットパターンのコピーはムーブ以外の要因で起きている？？

>>57
一番分かってないお前が言うなよw

>>61
高コストなCopyも実装してから確認してみてねww

>>66
ごめんよ
刺さったって「ためになった」みたいな意味で言ってるのかと思ったよ
てっきりオジの自演かと

>>67
デバッグビルドだけじゃなくリリースビルドでも確認してねw

>>71
リリースモードでもどちらも同じ結果

>>72
ごめんよー
>>64と間違えた

このスレはいつもおかしい人間たちが集まってるな
Rustの何が人を狂わせるんだ？

おじさんイジリ飽きたので結論いっておく

Copyもmoveもスタックの中身をコピーしてるのは同じ
最適化によって不要なコピーが除去されるかどうかはLLVM次第
でかい配列やでかい構造体などの極一部を除けばCopyは参照の受け渡しよりも低コスト
ついでに言うと&TもCopy

>>75
頭悪すぎ
Copyが低コストなのではなく
低コストなものだけにCopyが実装されている
なぜならCopyは高コストであるため

>>76
ここでいうCopyのコストって具体的にどういう操作のコストのこと言ってる？
構造体データのbitwise-copyのこと？それとも別の何か？
Cloneやmoveの場合にそのコストは発生しないと主張しているの？

>>62
ほーCopyってCloneの実装によらずmemcpy相当の結果になるのか
自動的に.clone()が差し挟まれる感じかと思ってた

>>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 }
別物になった…

>>52
>>>49
>デタラメすぎ
>ムーブでビットパターンのコピーは発生しない
>ビットパターンのコピーが発生するのは引数の値渡し等であってムーブとは関係ない
>さらに引数の値渡しでのでビットパターンのコピーとCopyのコピーも全く異なる
>Copyのコピーはディープであって高コスト

このレス最強だな
一つ一つの文すべてが間違ってる
「デタラメすぎ」てw

ガイジムーブ来てんね

Copyはshallow copyだわな

色々と正確な情報が出揃ったところで質問

まず前提として話を明白かつ簡単にするため、
ここでは!DropつまりCopy実装可能な型のみ対象、
そしてもしClone実装するならば*selfつまりCopy実装と同一、
CloneやCopyを実装するかどうかは任意、
小文字のcloneとcopyはそれぞれCloneやCopyを実装した時にそれらが使われることを意味するとする

このとき、次のどちらの主張が正しい？
Ａ「copy/cloneはコストが生じるので、回避できるならば回避したほうが有利」
Ｂ「copy/cloneのコストはmoveと同じなので回避する必要はない」

場合による。
たとえコピーであっても結局は内容が同じものであると看破すれば
実際にはコピーしないようなコードを生成するといったことは有りうる。
Rust は原理的にエイリアス解析がやりやすい言語だと思うし。
実行コスト的にどうかなんて考えずに所有権管理の側面からの妥当性で決めたほうがよい。
その上でどうしても実行コストを切り詰めないといけないようになったならその時に考えればいい。

>>83
前提もまちがってるが
比較する対象がそもそも意味がない

もうちょっと勉強してから出直して

>>83
>Ａ「copy/cloneはコストが生じるので、回避できるならば回避したほうが有利」
何と比べてコストが生じると言ってるの？
回避した場合は何で代用するつもりなの？

考えてみたけどmove/copyが問題になるレベルの大きさの型をスタックに置いて扱ったことが無いな…

使うとすれば固定長配列のバッファ？
でもそんなものmove/copyするわけないし
やっぱり考える意味の無い二択だと思う

>>86
回避する前と回避した後の比較だろう
回避したコードが書けたならばcopyの代用の必要はない

>>83
一般的にはAが正しい
ただし>>84が言うように無駄なコピーが消える場合もある
Ａ「copy/cloneはコストが生じるので、回避できるならば回避したほうが有利になることがある」ならば正確
Bについては前半はある意味正しいとしても後半が間違い

>>85
批判や主張はその理由を伴わないと議論とならず意味がない

>>89
> 批判や主張はその理由を伴わないと議論とならず意味がない

基本的にはそうだが、こっちが説明しても理解できるレベルに達してない場合にはどうせ議論にならんのでな。

あっこの流れC++相談室で見たやつだ

要は参照使えるなら使っとけって？
今更すぎませんか

オナコードペタペタされてたほうがマシだったなこりゃ

>>92
それもあるが、例えば多数のコピーが行われているコードに対して、回避できる分を見直し、少数のコピーで済むように改善できる場合もある
Copy実装せずに明示clone()した方が見つけやすいかもしれない

>>88
さすがに意味が分からないよ
値の受け渡しにcopyを使わないなら何が他の方法を使う必要があるでしょ

一人だけ間違った思い込みをしてるのに
説明されても「俺は間違ってない、間違ってるのはお前ら」が続くだけだからな

>>95
頭が硬すぎないか？
回避できる分を回避するだけだろ
回避できない分まで回避する、と思い込んてるのはYouのみ

>>89
「○○はコストが生じるので、回避できるならば回避したほうが有利になることがある」

言葉の定義を明確にしないジェネリック文は
恣意的に常に真にも常に偽にもできる

>>90
無駄にプライド高いな
嫌われるぜ

大きいフィールドを持つ型には、Copyは実装しないだろうし普通はCopy/Moveのコスト差を気にすることなくない？
どちらにすべきかボーダーが難しいことはありそうだけど

>>94
データフローを見直して単純に消せるclone/copyは消せってことか？
それこそ今更すぎるわ
単純に消せないところまで消した後、さらにパフォーマンス改善するにはどうするかってことで、参照の話か？って聞いたんだけど

どこの誰とも知れないやつのフィボナッチのコードに対する指摘をされても知らねーよ
問題があって対策が分かってるなら自分で直すがいい

>>97
実行回数の話だったのかよww
まさかねw

>>101
フィボナッチの件はBigIntなど非Copyも対象で今回の話は全く無関係だろ
そこを区別できていないのは相当ヤバいぞ

流れからすると本当はジェネリックのフィボナッチにCopyを付けないほうが有利と主張したかったんじゃね？

でも後から回避できないことに気づいて苦しい言い訳を重ねてるだけと見た

>>85
根拠も示さず批判だけする一番アカン人間やな

>>104
フィボナッチはCopyを回避できないものなの？

分からないなら分からないから教えてって言えばいいのに意地を張るからこうなる
構えば構うほど意味不明な発言が出てくる

真面目に議論したいならせめてIDコロコロ変えるのやめな

フィボナッチってこれだろ
f(0) = 0
f(1) = 1
f(n) = f(n - 1) + f(n - 2)
関数呼び出しに足し算に大量のコピーは避けられない

>>87
async関数やasyncブロックで生成されるFutureは結構大きくなることがあって、boxingした方が性能出るケースもある

>>106
型制約からCopyを外すこことcopyを回避することは全く意味が違う
>>83の質問は明らかに後者

プリミティブも対象になるフィボナッチでcopyを回避するのは無理

>>110
型制約からCopyを外せばプリミティブと言えどもcopyされなくなる
具体的には個々のプリミティブ型へモノモーフィゼーゼーションされる前の段階でCopy実装していない型に対してのcopy発生エラーが生じる
フィボナッチでcopyを回避するのは可能

複オジの主張まとめ(1)
37, 39, 44
=====
CopyやCloneを使っているから別問題だろう。
一般的にRustのプログラミングでは、
Copy(暗黙的な自動コピー)やClone(clone()による明示的な手動コピー)を使うと楽になるが、コストは高くなる。
そのため不要なclone()を見極めてそれを回避するプログラミングが出来るかどうか、というRustにおける根源的な話だろう。

もちろんCopyは最もコストが高い。
個々のコスト自体は通常clone()と同じだが、常に自動的にclone()が起きるため最もコストが高くなる。

Copyはコストが一番高いから出来る限り避けるべきだな
特にヒープを使うならCloneまでにしておくべき
可能ならばCloneも避けるべきだが

複オジの主張まとめ(2)
50, 52, 57
=====
それは理解不足すぎるぜ
大文字のCopyはCopyトレイトを意味しCopyトレイトを実装するか否かの話だろ
moveは別方向の話であり比較対象にすらならない
比較するならば「Copy実装(必然的にClone)も実装」「Cloneのみ実装」「どちらも実装なし」の3つだな

デタラメすぎ
ムーブでビットパターンのコピーは発生しない
ビットパターンのコピーが発生するのは引数の値渡し等であってムーブとは関係ない
さらに引数の値渡しでのでビットパターンのコピーとCopyのコピーも全く異なる
Copyのコピーはディープであって高コスト

これだけCopyやCloneを理解していない連中が多い状況だと
>>30の質問に答えられるかどうかは最低限クリアすべきテストとして有用ではないか？
フィボナッチ自体はもちろんどうでもよい話だがCopyやCloneを避けるRustの基本ができるかどうかわかる点で

複オジの一連の主張を読んでから>>83の複オジ質問を読むべし

複おじに反応するやつも複おじ

主張が毎回変わる
口調も毎回変わる
表記も毎回変わる
間違いなく多重人格者

>>98
この文脈では○○にはなんでも当てはまるから意味がないよね

以下なら議論になる？
Ａ「copy/cloneはmoveよりコストが生じるので、copyが必要な部分とそうでない部分で構造体を分離してでも出来るだけmoveを使用する」
Ｂ「copy/cloneのコストはmoveよりコストが生じるとは限らないので、一部でもcopyが必要な部分がある構造体は丸ごとcopyして構わない」

>>116
そこまでいったらネット上では別人で良いだろ

>>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

メモ化されてないんやから遅くなるのは当然
>>108は定義を示しただけちゃう？

つかオーバーフローしとるな

>>119
そのコードだとcopyは何回くらい発生してるのだろう
0回？1回？2回？3回？たくさん？

ぼくのかんがえたさいきょうのcountup<T>()をみんなバカにしたので
ぼくのかんがえたさいきょうのfibonacchi<T>()でやっつけようとしたら
わざをだすまえにボコボコにやられてしまいました
く、くやしいです！

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),
}
}

>>119
計算量はO(n), メモリ使用量は定数オーダーにできるのになんで定義どおり実装したの？

>>123
ぼくのかんがえたさいきょうのfizzbuzz<T>()もわすれないで

>>125
そんな魔法はありません

>>127
え？

Rust以前の問題じゃん
スレ違い

>>124
そのclone()は子のf(n-1)とf(n-2)やそれらの子孫でも呼ばれるので1回ではなくO(n)より大きい
それをO(n)すなわちn回＋定数回以下に抑えられるのかどうか
あるいはO(0)回すなわち定数回以下に抑えられるのかどうか

フィボナッチはu128を使ってもf(187)でオーバフローするからBigInt必須
clone()はできる限り少なくしないと厳しい

どうでもいいから複おじはTRPL読み直してきてね

>>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
}
}

メモ化する必要ある？
直前の2つだけ記録しておけば次の一項が計算できるんだから再帰にする必要ないよね

>>134
具体的にどうすればよいてすか？

>>135
"rust fibonacci"でググるとよいです

>>134
直前の2つだけ記録して再帰にしない方法ならば
おそらくこうする案だと思うが
>>133がO(n)で済んでいるのに対して
これは二重の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
},
}
}

>>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っぽい書き方をする必要はない

>>138
それもforが二重となっていて全体でO(n^2)だから同じく悪手

>>131
なら尚のことジェネリックにする意味ないよね？

>>137,139
悪手ってなにをもって悪手だよ
一般項の導出は高校生でもできるレベルで、そうすればO(log(n))で求められるし、つまらん計算量改善のためだけのアルゴリズム議論はもうやめろ
これ以上計算量の話をするなら別のスレでやってくれ

>>141
mainに既にforループがある
だから個々をO(n)で求めると全体でO(n^2)となる
もし個々をO(log(n))で求めたとしても全体でO(n✕log(n))となる
一方で>>133は優れていて全体でO(n)だから圧倒的に良手

まあ(usize) -> usizeのインターフェースを持たせつつ逐次処理したければメモ化が楽だわな
Rustとは特に関係の無いアルゴリズム一般論の話だけど

なんでmainのループまで計算量に入れてるの？
今やってるのはフィボナッチ数列の計算量の話でしょ
余計なところまで話し広げてどうするの？

いい加減こんな語り尽くされた話終わってろ
何スレだよここ

>>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)
})
}

僕チンすごい！ってホルホルしたいんだろうけど

脳のワーキングメモリーが減ってこの程度の内容でしかコードが書けないんだろうな

まず計算量にmainのループを勘定してる時点で…

>>144
> 今やってるのはフィボナッチ数列の計算量の話でしょ

その通りでアンタが正しい

>>148
フィボナッチ『数列』の計算量だから
mainのループを勘定するのは当然
f(0)、f(1)、f(2)、…、f(n)がフィボナッチ『数列』

イテレーターにするとメリット多いんだな
Rustと相性いい

>>146はメモ捨ててるから計算済みのf(n)引っ張ってくるのに毎回O(n)かかるけどね
イテレータと相性良いように見えるとしたら0..nループと組み合わせることしかしてこなかったmainが見せる幻想

そろそろRustの話に戻ってもらっていいですか？

>>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()
}
}

汚いな

複オジは何が問題だと指摘されてるのか理解しないんだよなぁ
頭悪いのにとにかくマウントだけ取りたがって恥の上塗り上塗り上塗り
何回塗るねんっw

ほらなｗ
ぼくのかんがえたさいきょうのひぼなっちいてれーた！
どや！？　どやどやどや！！？
これで1000まで行くよｗ

どうしてもイテレータが欲しいなら>>133に建て増ししたほうがよっぽど整理されていいよ
https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=86c556a9709d959e8b9ecff08223b099

>>152
イテレータの規約に反したオレオレnth()はやめてくれ
IterMemoなんて名前の構造体にnth()が実装されてればイテレータのnth()と勘違いしてしまう

その前に単純にバグ入りだけど

メモ化と個別機能が完全に分離できている>>152の方が良さげ

このスレだけでなくRust書く人間はコケ前提なのが馬鹿らしい
未知の計算するのに対策してない馬鹿野郎ども

目が覚めろ
目が覚めろ

コケ前提は恥ずかしい

>>159
分離できてねーよw
アホだろ

イテレータ使ったことないのか？

Rust書く人間はレベルが低いと思われても平気なのか？

>>156は普通にフィボナッチ数列を順に表示するだけでも常にVecを使ったメモ化を伴うので筋がよくない
>>152はメモ化を付け外し可能で問題点も特に無いようだが

「Rustでドヤりたい素人が犯しがちな12の過ち」
みたいな記事が捗りそう

>>164
関数の設計ができない人の発想

>>164
なんでIDコロコロ変えてるの？

>>165
複オジ特有の妄想を一般化するなよ
「複オジがドヤ顔で晒した恥ずかしい勘違い12選」にしとけ
需要ないけどな

こんな数列ごときでヒープ必須の>>156はプログラミングが下手

数列ごときのプログラムしか書けない複製おじさん……

cargo run --releaseで予測した動きをしないコードを書くなよ
速やかにバグを取れ

Rust 1.61.0

このスレの底辺のコーダーもどき全員ゴミ
まともなコードすらかけないでiterが～とか言ってんじゃねえよ
バカども

拗らせくんもいるのか

このスレを見る限りRustプログラマは低レベルの人間ばかり
まともに動きもしないものでああだこうだ言いあってるだけだ

フィボナッチ数列議論スレでやれ

オーバーフローのまともな対処すら知らない馬鹿ばかり

俺が小学生の頃はBASICで整数オーバーフロー考慮したプログラムは書いていた
多倍長整数演算も自分で考案して天文計算もやっていた

このスレの連中は小学生の頃の俺に負けるレベルの奴しかいない
Rustを書く人間はその程度のレベルばかり

エイリアン vs アバター

天文計算なら多倍長じゃなくて浮動小数みたいに指数部と仮数部だけ保持しておくほうがいいだろう

>>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}");
}
}

必要ないOptionまで追加してtake.mapのネストは汚すぎる
事前に設計せずコンパイラ駆動だけで書くと汚いコードになりがち

>>179
勝手に戦えww
複製おじさん vs 100点おじさん

>>168
1レスで晒したこの4つの無知は外せないww

(1) ムーブでビットパターンのコピーは発生しない　-> ムーブ無知
(2) ビットパターンのコピーが発生するのは引数の値渡し等であってムーブとは関係ない　-> 値渡し無知
(3)さらに引数の値渡しでのでビットパターンのコピーとCopyのコピーも全く異なる　-> Copy無知
(4)Copyのコピーはディープであって高コスト　-> ディープコピー無知

>>182
フラグは必要
それをOptionで簡潔に表現した
批判したいならば代替コードを出すべき

フィボナッチ数列を他の計算の入力として使わないのなら何番目まで必要なのかをusizeとかで受け取ってBigUintのイテレータ返すので十分かな

うげ
俺が出したのは>>185の言う代替案じゃないから
勘違いしそうだから念のため

>>186
うん
今回はオーバーフローの対処をしろと言う>>177のリクエストに応じたのみ

>>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)
})
}

firefoxってどのへんにrust使ってるんだっけ

>>189
さらに汚くしてどうすんのw

>>191
汚いと言うならば同じ動作をするもっと美しいコードを出そう
「汚い」と言う人はいつもコードを出せない人だから負け惜しみで言っているのかと

>>185
unfold使ってた時と同じでフラグという捉え方がコードが汚くなる原因
命名を疎かにせず変数や関数の型を考えよう
そうすればOptionが必要なものと不要なものくらいは区別できるはず
ヒント終わり


コンパイルができた動けばいいだけのコードからは早めに卒業しようね

>>192
君のコードを汚いという人間は一人や二人ではないだろう？
それがなぜなのか？
なぜ汚いと言われるのか？
自分で考えて足掻いてこそ成長するんだよ

>>192
ちなみに汚いコードの反対は汚くないコード
美しいコードである必要はない
実践で重要なのは美しいコードよりも汚くないコードを書くこと

>>193
有無を表現することが必要だからOptionを使うのが最適
Optionを使わずに書けるのならばコードを出そう

>>194
今まで言われたことない
今回言われたから、いつも汚いを連呼しているがコードを出せないダメな人かなと
反論があるならばコードで示そう

>>195
その通りだよ
だから汚くなく、簡素でわかりやすく、無駄をせずに効率も良いコードを>>189に出した
同じ動作と同じ効率でもっと簡素に書けるのならばコードを出してごらん

ベンチも取らずに効率とな？

>>184
その4つは全部並んでたからインパクト強いけど
個々で見るとムーブや値渡しの間違った理解は複オジ特有じゃないからちょっと弱いな

>>196
>今まで言われたことない
すごーいwww
お薬必要ですね

後出しでどんどん条件が変わっていくから話がまとまる訳がない
これ以上続けたいならソース貼るときは前提条件を共有した上でコンパクトに議論を終わらせてくれ

複オジは断念したみたいだから
俺の考える汚くないコードを参考までに貼っとく
https://play.rust-lang.org/?edition=2021&gist=cb739f9fa655a73ced7e87e681237d9f

まずイテレータやめろや

tauriどうよ

>>202
successorsバージョンはシンプルでいいね

>>190
https://wiki.mozilla.org/Oxidation#Shipped
話題になったServo関連はもちろんとして、他は文字エンコーディングとか言語関連での採用が多いみたいね

https://4e6.github.io/firefox-lang-stats/
行数ではGecko全体の10%程度

RustとC++を学ぼうと思ってるプログラミング初心者です。
両方ともそのうち学ぶとして、どっちを先にした方がいい感じですか？

あ、スレチだったかも...すみません

連投すみません...
C++ vs Rustのスレ終わってたから一応どっちにすべきかここで聞きたい
ちなみに自分の中では
・C++のほうがほんの少しだけ速い
・Rustのほうが書くのとかメモリとか楽
・C++のほうが実行環境とか充実してる
みたいな認識になってます。よろしくお願いします

>>207
ほー
ありがとう

>>210
どういう領域のプログラムを作りたいかでどっちが適してるか変わるからもうちょっと学ぶ背景とか教えて

>>210
仕事で使うほう

なんのために学ぶのかにもよるけど、なんにせよC言語とJavaScriptはエンジニアなら全員勉強すべき
急いでないなら、そのあとでC++とRustを選んでもいい

まぁC言語だよな

せっかくRustのスレに来たんだしRustをやりなよ
C++をかじるのはいいけど仕事で使うわけでないなら
じゃじゃ馬を飼い馴らすバッドノウハウを今更学ぶ必要はないよ

回答ありがとうございます…
とりあえずRustにしておこうと思います

>>217
Rustの入門書をぱらぱらと何冊か見たけど計算の優先順位の話とか普通のプログラム入門は全く書かれてないよね
C++の方は確実に書かれてる

入門はCやC++の方がいいと思うよ

個人的にRust以外にやったほうがいいと思う言語
C C++（深入りしない） java

多分必用になる（と思われる）言語
javascript python

Cをざっと学んでからRustかな
C++は（深入りしない）が重要なんだけど、初心者が自分で判断するのは厳しい
既存の資料もC++98から20まで玉石混交という感じだし

自分はOOPは学んだほうがいいと思う派なのでRustだけでは不十分だと感じる
絶対業務で必要になるし
C++ java C# 学んだほうがいいと思う

いろんなパラダイムの言語を触るのが良いよ

Rustを学ぶならばほとんどの分野でC++とJavaは不要
C言語は実用とは別に最初に基礎教養として学んでおいたほうがRustの理解が早い
C→Rustも可能だが、その前にスクリプト言語などでオブジェクト指向(のうちインスタンスとメソッド呼び出し等)と、非同期(async/await)をそれぞれ学んでおくと楽だと思う
その場合のスクリプト言語はJavaScript(ただしHTML/CSSに踏み込まなくて済むNode.js)がオススメかな

単に習得するためなら Rust を学ぶために他の言語を先に知っておく必要はないが、
C++ を先に使っていると Rust の「ありがたみ」に納得しやすいという意見はあるみたいだね。
まあ C が基礎教養であるというのは私も同意。

Rustだけを学ぼうとしてもその環境が整ってないんですよ

さっきも書いたけど入門書に演算子の優先順位とかそのレベルの話がどこにも書かれてない
他の言語に乗っかって入門するしかない

>>224
C++は不要
Cを習得しておけばRustのありがたみがわかる

>>225
演算子の優先順位の話はオライリー本には書いてあるよ
プログラミングを初めて学ぶ人間がRustから始めるべきじゃないというのは完全同意だけど

ぼくはガベージコレクションが嫌いです

オライリー本もヒープとかスタックとか出てくるあたり、CやC++で動的メモリ確保の面倒くささを知ってる人向けだと思う

メモリ管理まわりの勉強はcで必須

逆に考えよう
C→Rustと進むだけで十分であり、何か困ることある？
困ることないよな

ゴミ集めてどうするんだっていう。

十分かどうかはさておき
そもそもCをすべきかどうかというと微妙かもしれない
Cしかやってなさそうな人特有の
・変数がたくさんとっちらかった
・変数名が暗号めいてて
・ifやforが多重になってて
・グローバル変数を平気で使っちゃってる
コードみたことあるでしょ
それはそうするしかやり方を知らないから

一方、抽象度の高い言語からやった人は先にそっちに慣れるんで
List(8, 9, 3, 1).sorted.reverse.foreach(print)
こういうふうにスッキリ書けるのを目指してくれる

オブジェクト指向がいちばん大事

格下相手の話だけイキイキするな

>>233
それは同感で非常に重要
だから最初に>>223でCとJavaScriptを先に学ぶのをオススメと書いた

ありがたみなんて知る必要ないでしょ
典型的な老害だな

>>221
C++ と java はやったけど C# 必要ですか？

Rustは、プログラミング経験者向けの情報が多い気がするから、PythonとかJavascript辺りをサラッと試してからでも良い気はする。

コンパイルとはとか、型って何？とか。

>>235
それな
自演ネタふりの可能性すらある

いつも同じパターン
質問や相談があると、答えたり情報を出したりせずに、それらをしている人たちをバカにする
コードが出ると、代案コードを出すわけでもなく、とにかく批判のみ行なう

プログラミング初心者は言語知識よりも
プログラミングという行為がどういうものなのか
どういうことを考える必要があるかというメタ認知を得ることが最も重要

メタ認知を獲得するために最も効果・効率ともに高い方法は
考えて・書いて・動かして結果を確認するというフィードバックサイクルをとにかく繰り返し回すこと

初心者は上記のサイクルが回しやすい言語から始めると後々の成長が早い
C/C++/Rustはサイクルを回すために越えなければならないハードルが相対的に高いため
現代では初心者向け言語ではない

>>241
被害妄想はげしくね？
代案も代替コードもそれなりに出てるよね？
それに悪い物を悪い(汚い物を汚い)というためだけに毎回代案を用意する必要なんて全くないよ

意訳:
ぼくちゃんがかいたさいきょうのコードをひはんしないでくだしゃい
ぼくのかんがえたやつがさいきょうなんでしゅから

なでしこ（プログラミング言語）も使ってあげて、、

お前ら>>205みたいなのにも反応してやれよ

>>246
前スレがいしゅつ

>>218
そのかかれてるC++入門本のタイトルあげてみろ

>>225
お前、>>218 で *計算*の優先順位って書いてるじゃん。
>>225 でしれっと演算子の優先順位にしてんじゃねーよ。

お前ら新しい言語勉強する時に本読まないの？
たいていの本には想定する読者ってのが最初のほうに書いているだろ。
現在出版されてるRustの本で他の言語全く使った事ない読者を想定してる本はあるのか？

>>246
Tauriではなくweb-view crateがシンプルで良いと思う

>>250
新たなプログラミング言語を学ぶために本を読んだことがないのでRustについてもわからん
わざわざ本を買って学習する人は少数派ではないか？

おれは基本は本を読む派だけど、読まない派のほうが多そう

昔は本買うか図書館行くかしかなかったもんね
二十年くらい前からこっちはもう本イランけど
ネットで見れるでしょ何もかも

最近はもっぱら言語公式のチュートリアル。Rustだと「the book」

>>252
必ずしも本でなくてもいいが……。 体系的にまとめられた入門用の文書は読むべきだと思う。
Rust に関して言えば >>1-3 で挙げられているような文書があるからありがたく利用させてもらう。

基礎が身についてない段階で詰まるたびにググるみたいな学び方だと個々の情報の断片を
自分の理屈で勝手に (誤った形で) 結び付けてにっちもさっちもいかなくなってるのはよく見る。

確かにこのスレではよく見る
>>112,113

複オジは本を読まないのが原因とは違うと思うぞ
本を読んでも自分勝手な理屈を脳内補完してそれが正しいと思い込むタイプ

>>251
実際使ってるの？
github HEADの最終更新11ヶ月前とかだけど

>>259
web-view crateは非常にシンプルで
最初のwebviewビルダーと
JavaScript側からのRustの呼び出しと
Rust側でJavaScriptの実行の三つだけをサポート
学習コストもほぼゼロ
だから更新するようなことがほとんど無い
それでも例えばHTMLのonclick等でRust側を呼び出せてRust側で処理してJSで反映ということが出来てうれしい

>>252
じゃあ >>208 から始まる話題にはお前はおそらく不適切だからレスすんなよ。

>>261
唐突にポカーンだけど
そういった、人への批判は意味がなく荒れるだけで誰の役にも立たないので止めたほうがいいよ

たしかに
「そういった人」への批判は意味がなくて、荒れるだけで、誰の役にも立たない

「そういった」がかかるのは「人」ではなく「批判」じゃないのかな

元のレスをもじっただけで
唐突に殴りかかってくる人には何を言っても無駄だよと諭してるだけでは

多くの人は良い人たちだが
残念ながらこのスレにも他人を叩いたり言いがかりを付けたりするのが好きなアレな人が紛れ込んでいる

そういうのは反応を見て楽しもうとしてるだけだろうから、無視するしかない

>>260
tauriも同じようなもんじゃないの？

今流行のアプリを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();
}

MozilaはFirefoxを丸ごとRustに書き換える予定はあるん？
今はまだ一部だけだよねRustになってるの

>>270
そうなの？

FirefoxはレンダリングエンジンをRustでゼロから作ってるんじゃないの？

自分で確かめて
https://github.com/mozilla/gecko-dev

servoはまだ実験段階だったと思う

>>273
ありがとう～

>>270
特にそういう予定はないと思う
servo自体も別に次世代Firefoxを目指してるとかではなく、Rustでwebブラウザを書く実験プロジェクトという感じ
その実験でうまく行ったコンポーネントを徐々にFirefoxに移植していっている

アプローチとしては正しい姿なんだろうな

暇を持て余した神々の遊び

servoと言うよりモンスターエンジンだね…

>>270
C++で書かれてる部分は置き換えられるかも知れないけどJSで書かれてる部分までは置き換えしないんでないかな

JSとか言ってるのは君だけだと思うよ

>>280
FirefoxではC++と同じくらいJS使われてるよ
https://www.openhub.net/p/firefox/analyses/latest/languages_summary

JSの部分を置き換えるなんてはなから誰も思ってないってことだと思うが

意訳すると「JSで書かれてる部分まで置き換えるとか言ってるのは君だけだと思うよ」かな？
言ってないね

>>282
正解

>>283
アホ
JSで書かれてる部分まで置き換えるかどうかとか言ってるのは君だけだと思うよ

>>284
じゃ>>280で「言ってる」とか書くな
ボケ

>>285
はあ？
JSって言ってるよね？
バカなの？

>>279 JSで書かれてる部分までは置き換えしないんでないかな

>>270 が「Firefox を "丸ごと" 書き換える」と言っていたので全部はRustにならないよと伝えたんだけどなんかお気に召さなかった？

>>270が言うのはservoのことでquantumの動機がcssパーサrustで書いたら
安全だったからC++で書かれたコンポーネント置換しよだからjs出る余地ないじゃん。
>>282で終わった話。

そうだね、そんなふうに言われたらシェルスクリプトやMakefileまでrustで置き換えるんじゃないかって思っちゃうよね。


馬鹿なん？

FirefoxはXULのイメージがあってJSも主要な構成要素だと思ってたから変なレスつけちゃったね
皆さんの機嫌害しちゃって申し訳ない

よく見たらID変えて暴れてるやつまだ居座ってるのか。

>>290
XULはだいぶ前に死んだよ。
XULRunnerが単体で利用困難な問題が解決できなくて存在意義を失った。

>>291
XUL完全になくなったの？
XBLは完全に消えたって聞いたけどXULは細々と生き残ってるものだと思っていた

>>290
ほんと反省しろよ

反省してま～す

>>189
おまえら全員そうだがフィボナッチ数列でusize固定はおかしいだろ
コード自体は問題ないが <T: Zero + One + CheckedAdd> を付けろ
あとは0と1をT::zero()とT::one()へ置き換えればi8型からBigUintまで何でも動作するようになる
https://play.rust-lang.org/?edition=2021&gist=929f3df48db39182558dfad6fe8d1cda

さらに今回は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などでそのコードは動かないので劣る

暗黙のコピー発生って気にするべき？
!Copyならコンパイルエラーになるしこれまで気にしたことなかった

あとcurrはmoveでキャプチャされるからcurr?で発生するのはmove(とそれに伴うmemcpy)だけど、moveのコストも気にすべき？

>>296
それは逆
そのキャプチャされた変数はクロージャが呼ばれるたびに何度も使われる
つまりムーブされてはいけない、つまりムーブ禁止となる
したがって n = curr? で currの中身は nへムーブされずコピーとなる

>>297

>>296
必ずCopy前提の型しか扱わないときは気にしなくていい
しかし今回は!Copyの数値型でも動かないと話にならないからコピーが起きるコードを避けないと

>>299
!Copyの場合はコンパイルエラーになるからわざわざ人間が注意を払う必要はないと思うが、気にすべき？
usizeしか使わなくてもTに置き換えた場合を想定してコードを書くべきということ？

>>300
u128を使ってもf(200)がオーバフローするような今回の案件でCopy型が前提のコードはよくない
案件次第だけど今回はコピーの有無を気にすべき案件

>>295
自分のレスに他人のふりしてレスするキチガイ汚コーダーこと複オジさんちぃーすっ

>>296
それはmoveの意味を間違えているぞ
>>202のcurr?はコピーが発生する
FnOnceじゃないんだからcurrの値がmoveされたら次に使えなくなる
move禁止となりCopy型ならコピーが発生し!Copy型ならエラーとなるコード

>>301
copyを気にするのではなくusize or BigIntのどちらを使うべきか意識すべきと解釈した
usizeで良い場合はcopyは気にせずして良い

>>303
FnOnceかFnMutかFnかは関係なくて
moveなclosureでキャプチャしたらmove発生するよ
moveでキャプチャされた値をクロージャの中でさらにmoveできるか、refしかとれないかがFnOnceとFnの違い

https://www.reddit.com/r/rust/comments/3wubj0/comment/cxzlvt4/

num_traitsによるジェネリクスは絶対の正解ではないから適当なところで諦めようね

>>304
それは別の話でその違いを理解できていないようにみえる
クロージャへのmoveはクロージャが作られた時に終っていてクロージャ内のコードでの動作なは関係ない
間違っているのは後者の話でこの部分

>>296
> curr?で発生するのはmove(とそれに伴うmemcpy)

curr?でmoveは起きない
curr?で起きるのはコピーである(!Copy型ならエラー)

>>296
コピーもmoveも同じでそれがボトルネックかどうかが重要
数値プリミティブの場合はコピーを他の方法に変えたところでボトルネックが解消されることはまずないから気にする必要はない

BigUint前提ならVecと同じでmoveやクローンやのオーバーヘッドはそれなりに気にした方がいい
逆に現実的にはオーバーフロー考慮する必要がなくなるからCheckedAddが余計なオーバーヘッドになる

特性の違う物をジェネリック等でまとめたほうがいい場面なのかそれぞれ別の実装を用意したほうがいい場面なのか判断できることが大事

>>307
それは間違ってるぜ
BigUintのchecked_add()は常にSomeを返すためにチェックとSomeは消えてオーバーヘッドとならない
さらにRustのジェネリックは各型にmonomorphizationされるためジェネリックで書いてもプリミティブ型やBigUint型のコードはそれぞれに最適化される

ヒント:
Ratio<T> where T: Integer + Clone + CheckedAdd + CheckedMulは>>295の条件を満たす

fibonacci_iter::<Ratio<u8>>()すると
ちゃんと最後233で止まるのね
ジェネリック凄い

ククク……RatioのCheckedAddの実装を見ても果たして同じことが言えるかな

汚染が始まった！

>>311
たしかにRatioの実装が悪いな
まずAddと同様に
if self.denom == rhs.denom {の分岐をし
そして1の場合は
self.numberとrhs.numberでchecke_addするくらいはしないとな

ジェネリックに書いてもRatio専用コードを書いても
どちらもRatioの実装を使わざるをえないのだから同じ結果となる

そしてRatio専用コードを書こうとしても外部からは工夫のしようがないため
ジェネリックからコンパイル時にモノモーフィゼーションされるコードと全く同じになる

このスレごちゃごちゃした書き込み多すぎ

各型を個別に確認しないと良いか悪いか判断できないならジェネリックにしちゃだめでしょ

>>316
そんな個別に確認しなきゃいけないことは起きないから大丈夫
Rustの標準ライブラリも大半はジェネリックに書かれている

>>307
>特性の違う物をジェネリック等でまとめたほうがいい場面なのかそれぞれ別の実装を用意したほうがいい場面なのか判断できることが大事
禿同だわ
コードパズルやってるやつにいつも感じる違和感の原因はこれだな
こういう能力って何て言うんだろ？

>>318
でも今回の件の数列ならばジェネリックが正解やろな
わざわざ各数値型に個別に実装しなくて済む
分けるほうが不自然で手間

男の人って気持ち悪い…
どうして少女をそんなに汚したがるの？
お母さんに悪いとわおもわないの？

>>318
広く言えば設計能力
狭く言えば実装パターンの選択能力

総合的な能力だから一朝一夕には身に付かない
実装パターンの整理が進んでないRustだと特に

KISS原則だろ

>>202のlet n = curr?;の部分を
>>189はlet n = curr.take()?;としてコピーになるのを回避しているだけかと思ったら
両者が全く異なるアルゴリズムを採用していることに気付いた
>>202のアルゴリズムだとどうやってもコピーを避けられないから詰んでるね

prev, currの状態管理だとcurrの値をprevに代入するのと戻り値として使うのと2箇所に必要になるからね
curr, nextで管理すればいい

アルゴリズムというほど大げさな話ではないだろ
f(n)を求めるnext()が呼ばれた時に

>>189は内部にf(n)とf(n+1)を持っていて、足し算してf(n+2)を作る
そして内部にf(n+1)とf(n+2)を残して、f(n)を返す

>>202は内部にf(n-1)とf(n)を持っていて、足し算してf(n+1)を作る
そして内部にf(n)とf(n+1)を残して、f(n-1)は捨てて、f(n)をコピーして返す
つまりムダ

>>324
同意

フィボナッチ数のような単純な問題でもプログラミングセンスに差が出るものなんだな

>>218
まずはCから始めるのは間違ってない
Cは仕様が小さいからひと通り学ぶのにそんなに時間は掛からないからね

Webシステム中心ならRustとRails どっちを中心に勉強すればいい？

どうせ仕事で使うのPHPとjsだけど

RustでETみたいなのって書けるん?
てかテンプレートはC++みたいに汎用性高いの?
それともC#みたいに適用範囲絞ってる?

>>329
C++ で言うところのテンプレートは Rust には無いよ。 ジェネリクスは ML 風の型システムでやってる。
マクロは Lisp 風と言えると思うけどトークンが型付けされてるから Template Haskell とかのほうが近いかもしれない。

なんだじゃあRustだめじゃん。

>>331
むしろC++のテンプレートよりもRustのの方がほとんどの利用方法で便利かつプログラミングしやすく快適になった

>>331
そうだよ。ダメだから君もRustは使わないほうがいい

行列クラスを作って

X += A*(B+C)/D

みたいな演算子の多重定義して、すっきり1式で書くことできますか?

Matrix<Complex> X(2,2 );
Matrix<double> Y(2,2 );

Y << 1., 2.,
3., 5.;

X = (double)(Y^3);

みたいなことrustで書きたい

>>335
もちろんできる
こういうのがほしいんでしょ
https://docs.rs/simple-matrix/latest/simple_matrix/

初心者の題材としては適切そうだから、自分で実装してみてはいかがか

スマソ
X=(Complex)Y^3
だた

>>332
そこんとこ詳しく
解説サイトでもいいけど

とりあえず一度は the book を読め。
根本的な言語デザインが違うからそこだけ抜き出して詳しい説明なんてできないよ

rustてこんなコードも許すんだな

fn main() {
println!("Hello, world!");
main();
}

https://play.rust-lang.org/
でやってみるとスタック溢れて死んだけど一応実行できるのねww

そんなことで草生やすのはおそらくキミひとり
他の人らは真顔でキミの発言を見守ってるよ

>>341
いや、そんなふうに思ってるのはキミひとりだから

エントリポイントであるmainの停止条件のない再帰が
何のerrorもwarningもなくコンパイルできてしまい、
当然スタックオバフロで停止してしまうなんて間抜けすぎると思ったんだけどね
これが先進言語なのか?ww

>>343
最適化したら、ループに変換されて死ななくなるとか？

Go でやってみたら gopls(Language Server)で infinite recursive call って warning が出た
実行できるけど、

runtime: goroutine stack exceeds 1000000000-byte limit

と表示されて強制終了

>>343
警告出るよ

https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=2c7c027a6cf5a2e1c065faaad3a63680

warning: function cannot return without recursing

じゃあGoのほうが良いんじゃん。

そこに気づくとはやはり天才か

>>347
RustもGoもどちらもwarningが出る
そして実行するとスタックが溢れて止まる
完全に同じ

草

イキッてスタックを増し続ける再帰を書くのは愚か、まともなら限界値でブレイクする、天才と努力家は末尾再帰でスタックを増やさない

リリースビルドだと最適化されてスタックオーバーフローにならない
loopと同じになる
fn main() {
loop{ println!("Hello, world!"); }
}

あれ？
前にRustは末尾呼び出し最適化はしないって聞いたけど

言語仕様的に最適化を保証してるわけではないというだけでは？
LLVMがある程度やってくれる
https://godbolt.org/z/os9YMfozf

わかりやすい例
確実にスタックが溢れるusize::MAX回の再帰

fn main() {
assert_eq!(usize::MAX, count(usize::MAX));
}

fn count(n: usize) -> usize {
// println!("{:p}", &n);
match n {
0 => 0,
n => 1 + count(n - 1),
}
}

①デバッグモードだとスタックオーバフロー
②リリースモードだと溢れずアサートも通る
③リリースモードでもコメントになっているprintlnの//を外すと最適化されなくなるようでスタックオーバフロー

>>355
わかりやすい？
println入れるとなぜ最適化されなくなるの？

>>356
再帰だと&nは毎回異なる
つまり再帰をループ化する阻害要因

ごめん
n表示だけでもあかんわ
ループ化されず溢れる
調査のために、printよりもっと軽くて最適化で消えない操作、何かないかな

>>358
ターミナルが標準出力に出てきたのを表示するのがボトルネックになってるだろうな
./a.out > /dev/null するか、printlnの代わりにファイル書き込みするのが手っ取り早い

traitでasync fnなメソッドを宣言してはいけない理由を教えてください

https://github.com/rust-lang/rfcs/issues/2739

async fnはsyntax sugarだから例えば以下は同じ

async fn delayed_add(a: i32, b: i32) -> i32 {
sleep(Duration::from_secs(5)).await;
a + b
}

fn delayed_add(a: i32, b: i32) -> impl Future<Output = i32> {
async move {
sleep(Duration::from_secs(5)).await;
a + b
}
}

つまり現在のRustコンパイラではまだimpl Traitを使える場所が限定されているというもっと大きな問題のために今は使えない
GATsなど現在進行中の諸問題が解決すればいずれ使えるようになるはず

現状の対策方法としてはimpl FutureをdynにしてBox::pinして返す

trait Foo {
fn delayed_add(a: i32, b: i32) -> Pin<Box<dyn Future<Output = i32>>>;
}

impl Foo for () {
fn delayed_add(a: i32, b: i32) -> Pin<Box<dyn Future<Output = i32>>> {
Box::pin(async move {
sleep(Duration::from_secs(5)).await;
a + b
})
}
}

fn main() {
block_on(async {
let x = <() as Foo>::delayed_add(1, 2).await;
println!("x = {x}");
});
}

これでtraitにて非同期関数を使える

それを手動で変換するのは面倒かつコードも見にくいので自動変換してくれる#[async_trait]を使えばasync fnと書ける

use async_trait::async_trait;

#[async_trait]
trait Foo {
async fn delayed_add(a: i32, b: i32) -> i32;
}

#[async_trait]
impl Foo for () {
async fn delayed_add(a: i32, b: i32) -> i32 {
sleep(Duration::from_secs(5)).await;
a + b
}
}

おじさん調査お疲れ様でした。

・塩野義製薬が週休3日制導入へ 来年4月、副業も解禁
・塩野義製薬が「週休３日」選択可能に　給与は『週休２日の８割』副業や学び直しを支援
・【フォーカス】サタケ／週休３日制　通年導入めざし夏季のみ試行中　交代制で水曜を休日に
・旅館なのに週休3日!?陣屋・若女将の常識を覆した組織改革
・“時代錯誤”から残業ゼロ、週休3日に！　鳥取の不動産会社が
　レガシー企業からDX先進企業になれたワケ
・ネクスウェイ、週休4日制・1日3時間勤務選択できる勤務体系を導入
・日本初「週休4日制度」で、優秀な人材を採用するしくみとは？ ?
　ナレッジソサエティ久田社長に聞いてみた

もう借りまっか

ジェネレーターはいつstableになりますか

stableを期待しているということは現状の仕様で納得なんだろうけど
resumeの仕方とか値の受け取り方とか軽快じゃなくね？

let mut generator = || {
yield 1;
yield 2;
yield 3;
return "end"
};
assert_eq!(GeneratorState::Yielded(1), Pin::new(&mut generator).resume(()));
assert_eq!(GeneratorState::Yielded(2), Pin::new(&mut generator).resume(()));
assert_eq!(GeneratorState::Yielded(3), Pin::new(&mut generator).resume(()));
assert_eq!(GeneratorState::Complete("end"), Pin::new(&mut generator).resume(()));

例えばresume構文を用意して記述を見やすくするとか
return値は廃止してOption<T>で返しreturn;でNoneにするとか

個人的にはIteratorがyield使って実装できるようになれば満足なのでGeneratorそのものの型とかはそんなに気にしてなかった

>>370
yieldを使うとIteratorの実装が楽になる？
from_fn()のようなfrom_generator()を用意するのかな

またイテレータの話してる……

結局イテレータを作るには構造体か何かを用意してnext()実装するしかないぜ
それが面倒ならfrom_fnやunfoldなどの汎用イテレータ作成関数を使うしかないな
こんな感じか

fn iter_from_generator<G: Generator + Unpin>(mut generator: G) -> impl Iterator<Item = G::Yield> {
iter::from_fn(move || {
match Pin::new(&mut generator).resume(()) {
GeneratorState::Yielded(n) => Some(n),
_ => None,
}
})
}

fn main() {
let one_two_three = || {
yield 1;
yield 2;
yield 3;
};
for n in iter_from_generator(one_two_three) {
println!("{n}");
}
}

複クンなんですぐここに貼り付けてしまうん？
それお母さんに見てもらうだけでは不満なん？

すまんが、関数とジェネリックについてわかんないんだけどさ
https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=c548f2825b9f164eeabdd479c4950484
これってなんで動かないん？

>>375
<T>という型情報だけじゃT{b:1}が正しい式か分からないから
値の内容にまで踏み込みたければtrait boundを付けてtraitが許す範囲内でやるしかない

>>375
Tに渡されるのがいつもAだとは限らないからrustはエラーを出すんや
c++だったらエラーにならないが

そういうことなのか！ありがとう！
だからサンプルコードみんなTを引数で受け取って戻値Tを返してるのばっかなのか

「(i64 の) 1 から変換可能な型」という制約を付けるのであればたとえばこんな感じかな。

https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=73e1d04ceeb2c0aff1dae461126dfb6e

>>378
Tを引数に取らずにTを返すことも一般的に可能
その場合もTに何らかのトレイト境界を付けてそのトレイトのメソッドを呼ぶ形で実現する
fn c<T>() -> T {
T { b: 1 }
}
↓修整
fn c<T: Trait1>() -> T {
T::method1()
}

自分を返すmethod1()を持つトレイトTrait1を宣言しておく
trait Trait1 {
fn method1() -> Self;
}

そして型Aに対してそのトレイトを実装すれば動く
impl Trait1 for A {
fn method1() -> Self {
Self { b: 1 }
}
}
もちろんmethod1を引数付きのメソッドにしてもOK

>>377
C++すごいな
なんでエラーにならんのかわからん

>>381
Tに依存する箇所のコンパイルを保留してから、実際にT=Aとしてみてインスタンス生成するからね。
https://wandbox.org/permlink/zOH2lP3k2MEPYwsp

conceptで制限はかけられるけど本質は変わらん
https://wandbox.org/permlink/CdKBg61cUgFy2tBs

なんだじゃあRustダメじゃん。

そうだよ
ダメだからお前はRust使わないほうがいいよ

どう見てもRustの方が安全安心
C++では>>382においてb以外のメンバ変数(フィールド)があっても動作してしまう
つまり初期化されていない部分が残り未定義動作となる

未定義動作ではない。

単一の機関が作ってるなら未定義動作なんて生じないんだけどなｗ

C++では未初期化部分がある時
そこを利用した全体が未定義動作となる

>>382
なるほど
俺の知ってるジェネリックの常識とは違うがある種の合理性はあるな

未初期化領域があっても未初期化領域を読み出さなければ未定義動作にはならない
なので後からでも読み出す前にデータを書き込めば合法

そもそも初期化されます

https://ja.cppreference.com/w/cpp/language/aggregate_initialization

struct A { int x; int y; int z; };
A a{.y = 2, .x = 1}; // エラー、指示子の順序が宣言の順序と一致しません。
A b{.x = 1, .z = 2}; // OK、 b.y は 0 に初期化されます。

>>385
嘘つき。

Rustのジェネリクスは
型Tに対してトレイト境界を増やせば増やすほど型Tを使って様々なことができるようになっていく
今回のように型Tに対してトレイト境界が何も無ければ任意の型に適用できる代わりにできることが非常に少ない

例えばC++とは異なりRustではデフォルト値で初期化することすら指定なしにはできない
Defaultトレイトをトレイト境界に持ち、さらにそのメソッドを用いてT::default()することで、
初めてようやくデフォルト値で初期化されたT型を得ることができる
これにより「ある型にとってデフォルト値とは何か」「そもそもその型にデフォルト値はあるのか」「デフォルト値が使われるのはいつか」
といった諸問題を全て解決している
C++の複雑なルールと異なりRustでは非常に簡単でわかりやすくなっている

一方C++erはデフォルトコンストラクタを使ってデフォルト値を定義した

長いからデフコンって略したほうが良くないっすか？

全てを明瞭シンプルにしたことがRustの勝因

なんだじゃあJavaと一緒じゃん。

明示的に指示されないメンバも初期化されることに気づけなかったのはC++の仕様が複雑すぎるため
僕が悪いのではないことは明らか

Rustは綺麗に整理されてるいるから複雑な個別ルールを覚えなくて済むね

トレイトを増やしすぎて普段は必要ない補完候補が気持ち悪いぐらい出てくる破綻言語

C#は良い言語ですよ

>>400
ほんこれ

そんなに補完優秀だったっけ？
rust-analyzer?

RustはDと同じ臭いがする

言ってることはHaskellと同じだと思います！

・コンパイルを通ればバグがないことが保証される。
・静的に解決するのでCの10倍速い。
・C++は遅い。
・C++は危険。

Rust批判は専用スレでどうぞ

Rustアンチスレ
http://2chb.net/r/tech/1509028624/

>>405
> ・静的に解決するのでCの10倍速い。
意味わからんw

Rust屋さんはCを目の敵にしてるから。

Rust批判はこのスレでどうぞ

Ruby批判もこのスレで良いですか？

>>405
haskellでそんなこと聞いたこと無いが。

>>410
それはダメ

>>369
Pinは1回だけでいい
そしてas_mutしてresumeする
let mut g = Pin::new(&mut generator);
assert_eq!(GeneratorState::Yielded(1), g.as_mut().resume(()));
assert_eq!(GeneratorState::Yielded(2), g.as_mut().resume(()));
assert_eq!(GeneratorState::Yielded(3), g.as_mut().resume(()));
assert_eq!(GeneratorState::Complete("end"), g.as_mut().resume(()));

CLI向けのコマンドラインオプションと設定ファイルと環境変数統一的に扱えるライブラリとかない？
コマンドラインで指定があればそれを、なければ環境変数を、それもなければ設定ファイルを、どれもなければデフォルト値を読む
っていう動作を各オプションについてやってくれるライブラリが欲しい

clap+argfileでいけるかな？

大量じゃなければdotenv＋clapで列挙していけばいいね

#[derive(Parser)]
struct Args {
#[clap(long, env = "TEST_NAME", default_value = "デフォルト値")]
test_name: String,
}

dotenv::from_filename("設定ファイル名").ok();
let args = Args::parse();
println!("{}", args.test_name);

argsをparseする前にdotenvで設定ファイルから環境変数へ流し込んでおくと
CLI引数→環境変数→設定ファイル→デフォルト値の順

>>407
全部プリプロセッサで完了するCみたいなイメージじゃね
知らんけど

回答ありがとう

>>415
clapで環境変数読むの行けるのか、知らなかった
argfileはコマンドラインオプションをファイルに書くと読み込んでくれる感じなのかな

>>416
なるほど、環境変数自体を.envファイルに書いてもらってそれをコマンドラインオプションに読み替えるわけね
これは良さそうだ

env feature指定すると扱える
あと今時の形式>>416ではderive featureも必須

>>404
Dust言語
あると思います

配列の中で移動コピーする方法を教えてください
例えば
移動前 [X, X, X, X, 4, 5, 6, 7, 8, 9]
移動後 [4, 5, 6, 7, 8, 9, X, X, X, X];
Xは任意の値で構わないです
可能ならばstable safeでお願いします

複おじか？お前

>>421
xs.rotate_left(4);

コピーとあるからcopy_within(4.., 0)でいいんじゃないか
rotate_leftだと大きな配列で後方と前方の間の小さいサイズのコピーでも全体のコピーが発生して無駄

なるほど、任意の値で構わないってのはそういうことだったのか

ありがとうございました
ところで文字列にはfindメソッドがあって便利なのですが
指定した値が配列の中で前から何番目にあるかを返すメソッドはありますか？

>>426
slice::iter::position

positionでもfindでも行ける

let buf = b"abc\ndef\n";
assert_eq!(Some(3), buf.iter().position(|&b| b == b'\n'));
assert_eq!(Some(3), (0..buf.len()).find(|&i| buf[i] == b'\n'));

文字列でのこの簡潔さと比べるとスライス直結findが欲しくなるのはわかる

let str = "abc\ndef\n";
assert_eq!(Some(3), str.find('\n'));

bikeshed

str::findは部分列も対応
let str = "abc\r\ndef\r\n";
assert_eq!(Some(3), str.find("\r\n"));
なぜslice::findを作らなかったのだろう？

出た
汚コード

Rustの仕様自体が汚いんだよ

汚コードでもいいやん
反面教師になるんだから

ただし単発の短いコードに限る
フィボナッチ汚コードのペタペタ連投みたいなのはもう勘弁

汚コードなの？初心者だからマジわからん
docのstd::slice::iter::position をみたら似たようなコードだったけど

>>430
sliceから部分sliceを探索する頻度が文字列から部分文字列を探索する頻度に比べて圧倒的に低いから、じゃないの
C++のSTLも文字列にしかメンバ関数としてのfindは無いし、これも同じ理由ではないかな

Rustのエラー表示すばらしいなほんとに
めちゃくちゃ楽だわな

いつも汚コード言ってるやつはキチガイだから無視しとけ

>>430
部分スライスに対してもiterの代わりにwindowsを使えば同じようにpositionで部分文字列findと同じ結果を得られる

let buf = b"abc\r\ndef\r\n";
assert_eq!(Some(3), buf.windows(2).position(|b| b == b"\r\n"));

エラー表示が出ている時点で(ry

bikeshed bikeshed bikeshed

文字列のPatternに相当するものがsliceになないからでは

>>434
汚いかどうかの判断ができるようになるには言語に限らずその分野である程度の経験が必要

汚いなと思ってたコードが慣れるとそうでもなくなる逆の現象もある

汚コード公式汚コードですわ～！

>>434
公式exampleと同じなのでもちろん汚コードではない
もし何か問題がある場合は必ず誰かが代わりのコードを示すので大丈夫
汚コード連呼を相手にする必要なし

こんなスレに質問しに来る初学者なんてものは最初から存在しないんだろうな

ん？
「初心者だからわからん」というのが汚コーダーの自演だろってこと？

そうだよ

複クンはね
みんなに見てもらいたいんよ
つきあってあげてよ

なるほど言われてみればそうかも
流れ的に>>208なんかも怪しいな
気をつけよう

自演臭くなるからアレなんだけど
暇潰しに公式ドキュメントと照らし合わせて疑問に思ったから書き込んだだけで
ただの通りすがりだからね

>>449
あれは何もかも自演に見えてくる病気な人による連投だから気にする必要なし
何でもかんでも自演だ！汚コードだ！と言うダメな人

書いてあるコードよりましなコードを出せずに汚コードって呟くしかない可哀想な人は暖かくスルーしてやってくださいな

>>448
汚いというならオマエのコードを出せとイキってたのに
実際にコードが出てきてダンマリ決め込んだタイミング・・・

ありえそう
変な初心者が来たなとは思ってたが・・・

汚コードを連呼してる人が初めて出したコードがこれ。>>202
しかしアルゴリズムに問題があってフルボッコにされて撃沈。
汚コードを連呼の人が普段コードを示せない理由が判明してしまった事件。

うわーこれ確定じゃん
複くんRustなんかやめてネトサポやれば？

>フルボッコにされて撃沈。
主砲「Copyはディープで高コストだから避けるべき」発射！ ==> ドッカーンwww撃沈www

真面目に書いとくとusizeみたいな数値プリミティブの場合はCopy前提で全く問題ないよ
気になる人はベンチにかけてね

>>456
一般的にはその通り
しかし今回はusizeだとすぐ溢れるからBigUintなどを見越してのコードの話
>>202への批評内容はいずれもusizeでしか通用しないアルゴリズムをわざわざ採用したという点
一方で>>202が汚コードとみなした元のコードはusizeでもBigUintでもちゃんと動作するアルゴリズムになっていた

汚コード連呼厨は信頼できない
代わりのコードをいつも出せない
珍しく出してきたら元より劣化してた

最初のコードでだいたいあってるんですよ
それを君がずっと引っ掻き回してるだけ
最初からあるんだからわざわざ出す必要もない

>>427で終わってた話を>>428で誰も求めてないfindで書き直したり

毎週This Week in Rustのリンクでも貼ればこのくだらない流れは終わるのだろうか

ところでスライスへのfindメソッドなどの後付けはRustのorphan ruleを犯さずに可能なの？

trait定義すればできる

> 誰も求めてないfindで書き直したり

そもそも、誰ももとめてない
「ぼくのかんがえたさいきょうふぃぼなっちいてれーた」
をどんだけ貼り付けたんだろうな彼はｗ

誰も求めてないものを必死でシコってるからうんざりなんよ

複クンはなぜ汚いと言われるのか理解しないね
言語やライブラリの制約で避けられないような汚なさならここまで言われない

シンプルに意図が伝わりやすい書き方が他にあっても
ぼくのかんがえたさいきょうのシコシココードを我慢出来ずに開陳しちゃうからここが汚部屋になる

findバージョンで答えようとしたところで
>>427のレスがあったから「findでも行ける」に方向転換したんじゃね？
幼稚園児と同じでママン達に誉めて欲しかったのに
汚いと一蹴されて涙目

>>460
ブログへのリンクやアップデートはややマンネリ気味だけど
今週のcrateはいつもチェックしてる

>>467
そういう話をしたいのにRustと関係ない話や批判で荒らす連中がうざい
Rustの話ならば最新動向から初心者の質問まで何でも歓迎
しかし他人叩きしている連中は邪魔

可読性や汎用性を犠牲にしてもfindがpositionより優位に速いとか
ユースケース次第ではデメリットを補うだけのメリットがあるなら多少汚くても受け入れられる
フィボナッチの>>202と比較対象の>>181や>>189も同様

速度はベンチを取ってから
ユースケースは具体的に示してから
そういうことを主張してください

そして本当に互いのやり方にメリデメがあると認めているのなら、>>295のような他人叩きはやめましょうね

まーたふぃぼなっち言ってるｗ
バカのひとつ覚えすなあｗ

>>470
その>>295は他人叩きではないだろう
そのアルゴリズムではBigIntで無駄なコピーが発生するというRustで気をつけるべき技術的な問題の指摘にみえる
そして回避コードもきちんと示しているのでそういう書き込みは歓迎