Rust part27

**デフォルトの名無しさん** · 2024/12/02(月) 22:32:50.31

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

公式ドキュメント
https://www.rust-lang.org/learn

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

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

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

前スレ
Rust part26
https://mevius.5ch.net/test/read.cgi/tech/1726838318/

ﾜｯﾁｮｲスレ
プログラミング言語 Rust 4【ﾜｯﾁｮｲ】
https://mevius.5ch.net/test/read.cgi/tech/1514107621/

**デフォルトの名無しさん** · 2024/12/02(月) 22:43:23.38

乙巳

**デフォルトの名無しさん** · 2024/12/03(火) 07:46:32.00

**デフォルトの名無しさん** · 2024/12/03(火) 07:46:58.75

Rust Reference Book
https://doc.rust-lang.org/reference/
Rust Standard Library
https://doc.rust-lang.org/std/
Rust rustc Book
https://doc.rust-lang.org/rustc/
Rust rustdoc Book
https://doc.rust-lang.org/rustdoc/
Rust rustup Book
https://rust-lang.github.io/rustup/
Rust Cargo Book
https://doc.rust-lang.org/cargo/
Rust unstable Book
https://doc.rust-lang.org/nightly/unstable-book/
Rust macro Book
https://danielkeep.github.io/tlborm/book/
Rust CLI (Command Line Interface) apps Book
https://rust-cli.github.io/book/
Rust Future Book
https://cfsamson.github.io/books-futures-explained/
Rust async-std Book
https://book.async.rs/
Rust tokio Book
https://tokio.rs/tokio/tutorial
Rust serde Book
https://serde.rs/
Rust Performance Book
https://nnethercote.github.io/perf-book/

**デフォルトの名無しさん** · 2024/12/03(火) 10:17:10.99

>>3
何年も更新されてない上に誤訳だらけの非公式翻訳を貼り続けるのいい加減やめろ

前スレの「変数束縛」とか含めて非公式翻訳が勘違い野郎を生む諸悪の根源

**デフォルトの名無しさん** · 2024/12/03(火) 12:48:40.49

スタバのマルチスレッドって効率悪いよね

**デフォルトの名無しさん** · 2024/12/03(火) 12:56:13.69

はいはい、説教おじさんはほっといて気楽に質問してね～。勘違いでもなんでもok。サンプル欲しければコード書きますよ～。

**デフォルトの名無しさん** · 2024/12/03(火) 15:07:30.04

日頃GC付き言語で開発しているからメモリリークがどういったプログラムで起こるのかあんまり実感できない
C言語で書かれたプログラムでメモリリークしやすいプログラムってどんなもんなの？

**デフォルトの名無しさん** · 2024/12/03(火) 15:08:58.63

>>8
最近のPCはメモリたくさん積んでるから、リークしても気にしなくていいよ

**デフォルトの名無しさん** · 2024/12/03(火) 16:10:27.68

メモリプレッシャーがかかっても不必要にメモリをつかみ続けるFirefoxのようなお行儀の悪いプログラムか増えてるからメモリが潤沢にあってもリークは気にしたほうがいい

使い捨てプログラムや低品質でもいいプログラムなら気にしなくてもいいけどそういうのはGC言語でやる

**デフォルトの名無しさん** · 2024/12/03(火) 16:16:53.07

>>8
仕事の製品開発ならgc言語でもメモリプロファイラ一使えよ
ハードの性能向上を無駄に消費するクソソフト多すぎだろ

**デフォルトの名無しさん** · 2024/12/03(火) 16:51:09.72

GC 付きでもメモリリークのようなことが起こることはある。
多くの場合に表面化しないだけ。
プロセスが終わるときにはどうせまるごと回収されるからガッと処理してすぐ終わるようなプログラムでは特に表面化しにくい。
見えにくいからこそ意識的に調査すべきで、 >>11 の意見に同意する。

逆に問題が表面化しやすいのは長期的に起動しっぱなしなもので、わかりやすい例ではウェブサーバ (またはその後ろでサービスを提供するプログラム) などが挙げられる。
ウェブサーバの H2O はそれを防止するのと高速化のためにセッションごとにメモリの塊を確保してその塊の頭から順番に使っていき、セッションが終わると塊をまるごと解放するというメモリ戦略を取ってる。

**デフォルトの名無しさん** · 2024/12/03(火) 17:09:00.60

C言語でリークという話なのでこんな感じ。

// メモリリーク例1: mallocした後にfreeし忘れる関数
void leak_in_function() {
char* ptr = (char*)malloc(100);
strcpy(ptr, "Hello");
// freeがないのでメモリリーク
}

// メモリリーク例2: 条件分岐でfreeを飛ばしてしまう
void conditional_leak(int value) {
int* numbers = (int*)malloc(sizeof(int) * 100);
if (value < 0) {
return; // ここでreturnするとfreeされない
}
// 処理
free(numbers);
}

// メモリリーク例3: ポインタの上書きによるリーク
void pointer_overwrite() {
char* ptr1 = (char*)malloc(50);
ptr1 = (char*)malloc(100); // 最初のメモリブロックへの参照が失われる
free(ptr1); // 2番目のメモリブロックだけがfreeされる
}

**デフォルトの名無しさん** · 2024/12/03(火) 17:15:10.75

// メモリリーク例4: 動的配列の不完全な解放
typedef struct {
char* name;
int age;
} Person;

void struct_array_leak() {
Person* people = (Person*)malloc(3 * sizeof(Person));

for (int i = 0; i < 3; i++) {
people[i].name = (char*)malloc(50);
strcpy(people[i].name, "John Doe");
}

free(people); // name用のメモリがリークする
}

こういうパターンが多いかな。
C++だと生ポインタ使わなくなるので大分解消されるけど。

**デフォルトの名無しさん** · 2024/12/03(火) 17:23:27.47

バグが0になるまで投資を続けるのは誰もやらないのに
メモリリークを0にしようって言われたら投資してしまうのが人情というものだ

**デフォルトの名無しさん** · 2024/12/03(火) 17:54:33.42

>>8
ここはRustスレなのに
なぜRustについて全く触れずにC言語の質問をするの？
C言語のスレがあるのだからそちらでしなさい

Rustについて触れずに他の言語の話だけをしている人たちも同罪
必ずRustについても言及しなさい

**デフォルトの名無しさん** · 2024/12/03(火) 18:02:49.57

Rustのメモリ安全性の目的はメモリリークの回避じゃなくてダングリング参照の回避定期
ついでに競合アクセスも防ぐ

**デフォルトの名無しさん** · 2024/12/03(火) 18:49:23.67

今度は「競合アクセス」と来たか

**デフォルトの名無しさん** · 2024/12/03(火) 19:03:08.79

C言語はfree()しても断片化という問題が発生すると聞いたことがある
断片化してもOSが落ちたりはしないんだろうけど遅くなるとかならないとか・・・

**デフォルトの名無しさん** · 2024/12/03(火) 20:08:22.57

>>19
断片化によって起こるのはメモリ効率の悪さ。
空いてるメモリの総量が充分にあっても必要分だけ連続したメモリがない(メモリ確保に失敗する)ということが起こる。
C では確保したメモリの場所が変わる(アドレスが変わる)ということは起すわけにいかないので断片化はそれなりに深刻な問題になりうる。
GC には copying gc のように不要メモリの回収と同時に再配置するものもある。

**デフォルトの名無しさん** · 2024/12/03(火) 20:58:33.67

64bitのアドレスが枯渇したとして・・・全オブジェクトに印をつけるGCを使うか？

**デフォルトの名無しさん** · 2024/12/03(火) 21:39:20.42

Rustは長時間動かすとメモリが断片化するから、サーバープログラミングに向いてない

**デフォルトの名無しさん** · 2024/12/03(火) 21:49:34.08

https://www.publickey1.jp/blog/22/cloudflarenginxrusthttppingoracdncpu31.html
CDN世界トップシェアのCloudflareは、同社のグローバルなCDNの基盤として長らく利用してきたC製のNGINXに代えて、
Rust製のHTTPプロキシサーバである「Pingora」を開発して利用していることを明らかにしました。

Pingoraはすでに同社のCDNに採用され、毎日1兆回以上のリクエストを処理し、性能向上や数多くの新機能の提供を実現しており、
従来のNGINXと比較してCPUとメモリリソースの消費はいずれも3分の1程度に収まっているとのこと。

**デフォルトの名無しさん** · 2024/12/03(火) 21:59:19.12

今時の標準アロケーターはよほどでかい領域を確保しない限りメモリの断片化は起きないようになってる。それでも問題ならカスタムアロケーター書くよ。

**デフォルトの名無しさん** · 2024/12/03(火) 22:11:45.28

アマゾンのAWSもRust製
Webサーバサイドでリソース節約したいならRust一択

**デフォルトの名無しさん** · 2024/12/03(火) 22:47:57.47

>>10
現代的には使われていないメモリがあるほうが「無駄がある」と考える思想なので、メモリはあればあるだけ使う(キャッシュやプリロードなど投機的な処理で体感的な速度を上げる)設計になってる。
本当に足りなくなるまでは掴んだままのほうが良いと判断してやってる。
現代のニーズに合わせた意図的な設計としてやってるのでリークとは違う。
良いか悪いかは知らんがリークとは違う。

**デフォルトの名無しさん** · 2024/12/03(火) 23:07:54.92

Rustはいつメモリのコンパクションできるようになるの？

**デフォルトの名無しさん** · 2024/12/03(火) 23:30:37.95

いつも渋滞している道路は無駄がない道路か
まあ徒歩より遅いなら燃料いらないからな

**デフォルトの名無しさん** · 2024/12/03(火) 23:59:32.38

>>13
具体的で勉強になったわ

**デフォルトの名無しさん** · 2024/12/04(水) 00:52:46.84

>>26
メモリ足りなくなったから不要なメモリ掴んでたら解放してくれと
OSからのメッセージが出ても掴み続けてるアプリが結構あるので
メモリが潤沢にあるからといってリークは気にしなくてもいいなんていう心構えでプログラミングしたらダメだぞという話

難しい話じゃないと思うんだけど1回で伝わらないのは悲しい

**デフォルトの名無しさん** · 2024/12/04(水) 07:53:11.74

サーバでもアプリでもその他でも
プログラム起動中ずっと必要になるデータは
leak()して&'staticにしてしまっても構わない
これはメモリリークではない
一方ですぐ不要となるデータはleak()してはいけない
これはメモリ使用量が増えていってメモリリークになる
この違いをきちんと認識した上でleak()を活用しよう
ずっと必要になるデータを&'staticにできる大きなメリットがある

**デフォルトの名無しさん** · 2024/12/04(水) 11:14:58.27

FireFoxのメモリリークは本当に酷い
Rust使ってるっていうのは嘘だろ

**デフォルトの名無しさん** · 2024/12/04(水) 11:21:44.43

>>32
そこはC++コード
FireFoxでRustを使っているのはHTML/CSSレンダリング部分
メモリ管理部分を含めてメインはC++で記述されている
ソースが公開されているので誰でも確認できる

**デフォルトの名無しさん** · 2024/12/04(水) 11:22:03.58

>>13
さすがにレベル低すぎだろ

**デフォルトの名無しさん** · 2024/12/04(水) 11:41:12.45

リークしてるんじゃなくて意図的に解放してないだけ

本当にやばくなったら解放されるようになってる

メモリ食いが嫌ならAuto Tab Discardアドオンを入れろ

**デフォルトの名無しさん** · 2024/12/04(水) 11:52:22.74

>>31
それを普及させて何がやりたいのか分からなかった
が「やりたいことと合致しない現実」を報道する自由を欲しているらしいと最近分かった

**デフォルトの名無しさん** · 2024/12/04(水) 11:55:25.36

もし仮に特定のアプリに問題があったとしても
それはC++やRustの言語の問題ではない
このスレで特定のアプリの問題の話を始める人は愚か

**デフォルトの名無しさん** · 2024/12/04(水) 11:58:57.37

>>33
何でいつまでたってもRustで書き直さないんだろな

**デフォルトの名無しさん** · 2024/12/04(水) 12:11:29.24

>>30
主旨に反論したわけじゃない。 Firefox が例として不適当と言ってる。
Firefox は貪欲にメモリを使うが本当に足りなくなる手前で抑制的なモードに切り替わる。
Windows からメモリ不足のメッセージを出したときに Firefox がメモリを掴んだままなのは手放せるものは既に手放してるからだ。
メモリ不足になったときは本当にメモリ不足なんだよ。

**デフォルトの名無しさん** · 2024/12/04(水) 12:21:47.57

FirefoxもChromeもその他のブラウザもやっていないが
究極的にはアクティブウィンドウのアクティブタブ以外の全ての使用メモリを原理的には解放できる
どの方針を採るにしてもC++やRustといった使用言語の問題ではなくどの言語でも可能だ
明らかにスレ違いの話題だから他のスレでやってくれ

**デフォルトの名無しさん** · 2024/12/04(水) 13:53:37.60

tab閉じてもそのtabが使ってたメモリ解放しないんじゃリークだろ

**デフォルトの名無しさん** · 2024/12/04(水) 14:10:57.24

>>40
長く表示していないタブを一旦解放する仕組みが導入されたこともあるんだが思ったより問題が大きくて消極的になった。
コンテキストの管理とレンダラは不可分な部分もあるので再レンダリングに必要な情報を残しつつ他は解放するってのは手間がかかって割に合わないと考えられてる。

>>41
閉じた時じゃなくてアクティブタブじゃなくなったときの話を >>40 はしてるのにそれがわからないなら黙ってろ。

モダンなブラウザはプロセスを分離しまくっていてプロセス間通信で協調する仕組みになってる。
タブひとつ (または数個のグループ) に対応するプロセスがあって適当な条件でプロセスごと消えて作り直されたりするので仮にメモリ管理に多少の問題があっても全体の堅牢さは維持される。

**デフォルトの名無しさん** · 2024/12/04(水) 14:24:21.96

>>39
>Firefox がメモリを掴んだままなのは手放せるものは既に手放してるからだ。
これは嘘
単にお行儀が悪いだけ

>>40
>FirefoxもChromeもその他のブラウザもやっていないが
Safariは閉じたタブのメモリはもちろんのこと
長く非アクティブなタブのメモリは割と積極的に解放してる

**デフォルトの名無しさん** · 2024/12/04(水) 14:30:50.31

いずれにしても各アプリのレベルのメモリ管理の話であってプログラミング言語と関係がない
しかもFirefoxのメモリ管理部分はC++で記述されている
ここRustスレで無関係な話をいつまで続ける気だ

**デフォルトの名無しさん** · 2024/12/04(水) 14:35:33.45

>>39
>主旨に反論したわけじゃない
いやいや主旨を理解してないのに主旨に反論してるもしてないもあるかいな

**デフォルトの名無しさん** · 2024/12/04(水) 15:57:30.78

Firefoxで失敗してるRustw

**デフォルトの名無しさん** · 2024/12/04(水) 17:22:43.92

ふむ、広告ブロックを強化すればメモリ節約できるのでは

**デフォルトの名無しさん** · 2024/12/04(水) 20:44:10.29

循環参照が起きやすい場面の一つだし、これこそプログラミング言語の仕様と関係のある場面じゃないのかな

**デフォルトの名無しさん** · 2024/12/04(水) 20:50:21.75

>>48
C++が悪いということ？

**デフォルトの名無しさん** · 2024/12/04(水) 21:15:04.07

Webページ毎に別なので
アリーナ的管理により循環参照があろうと一気に解放するためリークが起きようがない

**デフォルトの名無しさん** · 2024/12/04(水) 22:53:20.36

メモリリークと脆弱性の混合物なら急を要するが完全に分離されたから意識低くなった

**デフォルトの名無しさん** · 2024/12/04(水) 23:26:00.62

>>48
悪いっていうより、自由が利きやすいんじゃない

**デフォルトの名無しさん** · 2024/12/05(木) 21:10:58.63

iterator traitのnextでiteratorの中のデータの参照を返すことがどうしてもできません
教えてください

**デフォルトの名無しさん** · 2024/12/05(木) 21:32:40.26

>>53
コードで出して。

**デフォルトの名無しさん** · 2024/12/05(木) 21:37:09.52

>>53
lending iteratorでググるといい

**デフォルトの名無しさん** · 2024/12/05(木) 23:37:21.58

// まず、データを保持する構造体を定義
struct DataHolder {
items: Vec<String>,
}

// イテレータ構造体を定義
// ライフタイムパラメータ 'a を使って、参照の寿命を明示
struct DataIterator<'a> {
data: &'a DataHolder, // データへの参照
index: usize, // 現在の位置
}

// DataHolderにイテレータを作成するメソッドを実装
impl DataHolder {
fn new() -> Self {
DataHolder {
items: vec![String::from("one"), String::from("two"), String::from("three")],
}
}

// イテレータを返すメソッド
fn iter(&self) -> DataIterator {
DataIterator {
data: self,
index: 0,
}
}
}

**デフォルトの名無しさん** · 2024/12/05(木) 23:38:23.20

// Iteratorトレイトの実装
impl<'a> Iterator for DataIterator<'a> {
// 返り値の型を&'a Stringと指定
type Item = &'a String;

fn next(&mut self) -> Option<Self::Item> {
if self.index < self.data.items.len() {
let item = &self.data.items[self.index];
self.index += 1;
Some(item)
} else {
None
}
}
}

// 使用例
fn main() {
let holder = DataHolder::new();

// イテレータを使用
for item in holder.iter() {
println!("{}", item);
}
}

やりたいことはこんな感じ？

**デフォルトの名無しさん** · 2024/12/06(金) 07:47:51.83

こんな感じです
struct It<'a>{
i: &'a mut i32
}

impl<'a> Iterator for It<'a>{
type Item= &'a i32;
fn next(&mut self)->Option<Self::Item>{
Some(self.i)
}
}

**デフォルトの名無しさん** · 2024/12/06(金) 10:39:26.47

mut いらん

**デフォルトの名無しさん** · 2024/12/06(金) 10:45:37.08

iter()が作りたいのか、iter_mut()が欲しいのかどっちかな？
あとこれだと無限に続くイテレータになるけど終了条件は？

**デフォルトの名無しさん** · 2024/12/06(金) 12:04:36.97

struct It<'a>{
i: &'a mut i32
}

impl<'a> Iterator for It<'a>{
type Item= &'a i32;
fn next(&mut self)->Option<Self::Item>{
self.i+=1;
Some(self.i)
}
}
こんな感じなのでmutはいります
本当はiter_mutが作りたいけれど難しそうなので
iterを作ろうとしたけれどどうしても出来ません
初心者です教えてください

**デフォルトの名無しさん** · 2024/12/06(金) 12:07:14.30

すいません*つけわすれました

**デフォルトの名無しさん** · 2024/12/06(金) 12:08:12.03

>>60
終了条件は２５です

**デフォルトの名無しさん** · 2024/12/06(金) 12:19:03.26

結局毎回同じ参照返すならイテレータじゃなくてよくね

**デフォルトの名無しさん** · 2024/12/06(金) 12:49:52.12

自分の可変参照を返したいならGATでこうする
use lending_iterator::prelude::*;

fn main() {
let mut v: Vec<String> = ["a", "b", "c", "d", "e"].into_iter().map(str::to_string).collect();
my_iter_mut(&mut v)
.skip(1)
.take(3)
.for_each(|s| s.push('x'));
assert_eq!(v, ["a", "bx", "cx", "dx", "e"]);
}

fn my_iter_mut<'a, T>(slice: &'a mut [T]) -> MyIterMut<'a, T> {
MyIterMut { slice, index: 0 }
}
struct MyIterMut<'a, T> {
slice: &'a mut [T],
index: usize,
}

#[gat]
impl<'a, T> LendingIterator for MyIterMut<'a, T> {
type Item<'next> where Self : 'next = &'next mut T;
fn next(self: &'_ mut MyIterMut<'a, T>) -> Option<Item<'_, Self>> {
if self.index < self.slice.len() {
self.index += 1;
Some(&mut self.slice[self.index - 1])
} else {
None
}
}
}

**デフォルトの名無しさん** · 2024/12/06(金) 17:58:05.19

>>65
自己レス
即興で作って冗長な表記があったため
next()関数はこれで

fn next(&mut self) -> Option<Item<'_, Self>> {
(self.index < self.slice.len()).then(|| {
let nth = &mut self.slice[self.index];
self.index += 1;
nth
})
}

**デフォルトの名無しさん** · 2024/12/06(金) 18:45:17.16

>>61
next()で返された不変参照r1（&i32）が生きてる間に次のnext()が呼ばれたら
r1の参照先の値が変わることになるからこの形はIteratorだと実現できないな
同じ値に対する&Tと&mut Tが共存できないルールに引っかかる

next()の戻り値にIt自体のライフタイム（&'b mut selfの'b）を含めて
戻り値の参照が存在してる間は次のnext()を呼べない形にしないといけないけど
Iteratorはそういう制限を想定してない

**デフォルトの名無しさん** · 2024/12/07(土) 00:37:25.75

Vecなどを作れて逆順にもできるイテレータとは性質が異なる
異なるものを、どっちも同じだと頑なに主張し続ける必要はない気がする

**デフォルトの名無しさん** · 2024/12/07(土) 02:06:00.13

67は一般的なイテレータの概念じゃなくstd::iter::Iteratorの話
このtraitを実装すると例えばIterator::max()も自動的に使えるようになるけど
この実装はSelf::Itemの暫定の最大値を保持しながら次のnextを呼ぶ必要がある
前の値を解放しないと次のnextを使えない状態だと
std::iter::Iteratorが使用者側に保証してる条件を満たせないし
安全なコードの範囲でimpl Iteratorのコンパイルも通せない

自前のIteratorトレイトを用意してもいいけど
それだとstd::iter::Iteratorが要求される処理には使えなくなる

**デフォルトの名無しさん** · 2024/12/07(土) 08:46:15.51

>>68
Vecを作れるのも逆順も全て別の話
それぞれ別の要件を備えていないと一般的なイテレータではどちらも不可能
例えばイテレータ「1..」はVecを作れない＆逆順に呼ぶのも無理
std::iter::repeat(1)はVecを作れないがDoubleEndedIteratorを実装しているのでメソッドrev()が使えて逆順に呼べる！
自己可変参照を返す>>65のMyIterMutはスライス&mut [T]を内部に持っているため逆順呼び出しrev()メソッドの実装が可能

**デフォルトの名無しさん** · 2024/12/07(土) 09:01:24.50

>>69
そのmax()は自動的に全てのイテレータに使えるわけではない
Self::Itemがstd::cmp::Ordを実装している時のみ使える
前の値を保持したままにできるか否かの性質についてもmarker traitを用意することで同じ枠組みに組み込めた可能性がある
それを出来ていないのがstd::iter::Iteratorの欠陥なので他を併用するのがRustでは当たり前になっている

**デフォルトの名無しさん** · 2024/12/07(土) 09:28:12.85

イテレータの前の値を保持できるか否かのどちらが優れているかといえば
より効率的な機能を提供できる点で「前の値を保持できない」方が優れた機能を提供できる
例えばstd::io::BufReadのlines()を考えてみよう
毎回新たなStringを返してくるので前の値を保持できる仕様となっている
しかしlines()の利用で前の値なんて不要なことも多いからその観点からは無駄な仕様ともいえる
一方で「前の値を保持できない」性質にも対応出来ていたとしたら同じStringを使い回すことが出来て明らかに効率が良い
このような例は多数あり自己参照返しイテレータが別途必要とされて使われている理由である

**デフォルトの名無しさん** · 2024/12/07(土) 12:31:06.78

>>70
長さが有限でも実行時にメモリが足りなければVecもreverseもないけど
「実行時に」という要件は備えなくて良いというルールがあるんだよね？

**デフォルトの名無しさん** · 2024/12/07(土) 12:55:43.06

61（初心者）が実現できないimpl Iteratorで詰まってるんだから
できない理由を分かってもらうのが優先でしょ
イテレータの優劣とか代替案はその後でいい

**デフォルトの名無しさん** · 2024/12/07(土) 13:24:25.81

>>73
rev()メソッドのtrait DoubleEndedIteratorはゼロコスト抽象化
逆順に並べ替えることはしないのでそのためのメモリは必要ない
既にある任意の構造を後ろからたどる、あるいは、後ろから計算するだけ

**デフォルトの名無しさん** · 2024/12/07(土) 13:35:30.31

>>74
それならば別の条件が必要となるIterator::max()を事例に出すのはよろしくないかな
説明するためには単純にこれだけでいいよ
let first = iter.next();
let second = iter.next();
println!("{first:?} {second:?}");

**デフォルトの名無しさん** · 2024/12/07(土) 14:11:16.76

>>76
next２回呼ぶだけだとstd::iter::Iteratorと関係なくなるだろ
自分がそういう使い方をしなければ問題ないってなるだけ

maxはstd::iter::Iteratorの実装に求められる条件の分かりやすい例として挙げた
別の条件まで気にするならmax_byでもいいけどそれはそれで初心者には余計なノイズが増える

**デフォルトの名無しさん** · 2024/12/07(土) 14:52:07.98

コピーもcloneもできないデータの存在自体がノイズだね
本当はcloneできるんだけどゼロコストではできないとか言ってるのもノイズだ

**デフォルトの名無しさん** · 2024/12/07(土) 15:42:48.47

結局>>53は何がしたかったのか

**デフォルトの名無しさん** · 2024/12/07(土) 16:58:02.14

>>67
stdのIterator::nextの&mut selfのライフタイムはnextメソッドを抜けるところまで
(次のnextが呼ばれるまで生きてない)

つまりstdのIteratorでは&mut selfのライフタイムに依存するような参照を返すことはできないということ
そういう参照を返したいならlending iterator
逆に言えば&mut selfのライフタイムに依存しない参照であればstdのIteratorでも返せるということ

**デフォルトの名無しさん** · 2024/12/07(土) 17:27:34.95

>>77
max_byも同じ
Ord実装型そのものかOrd実装型に変換してOrd::cmp()できる時のみ利用できる
それらを持ち出さなくてもSelf::Itemの条件なくcollect()すなわち収納型へのFromIteratorが適用される
つまりfirst要素とsecond要素が同時に存在することになると矛盾の説明で十分となる
そのため自己参照を返すイテレータはstd::iter::Iteratorがカバーする範囲になく別途必要となる話をしてきた

**デフォルトの名無しさん** · 2024/12/07(土) 17:32:25.17

>>78
イテレータが返すのはデータ値自体とは限らず参照も返す
特に今回の質問者が返したい可変参照は明確に!Cloneが定義されていてもちろん!Copyでもある
それでも可変参照をイテレータが返すことができてVecへ収容することも可能なのはCloneもコピーも行われないためだ
さらにそれらと全く独立した話としてイテレータ自体への参照/可変参照を返す場合はstd::iter::Iteratorで扱えないためLendingIteratorを使うという話が本題

**デフォルトの名無しさん** · 2024/12/07(土) 18:53:41.33

そんなに移動がしたいならこれでいい

first = into_next(iter); // iterはもう値を所有しない
second = into_next(first) // firstはもう値を所有しない

**デフォルトの名無しさん** · 2024/12/07(土) 19:21:07.13

>>83
それによって新たにできるようになることや新たに生じるメリットは何？

**デフォルトの名無しさん** · 2024/12/07(土) 21:52:51.51

C++でもRustでも変わらないメリットはcloneとdropをしなくてすむことだが

そういえば、Rust固有のメリットは'aが出てこないことと
'staticも出てこないことだな

**デフォルトの名無しさん** · 2024/12/08(日) 15:04:28.36

全然話変わるんだけどPinky Crush新曲のlowercase lifetimeってRust関係あるのかな

**デフォルトの名無しさん** · 2024/12/08(日) 22:46:56.54

>>61
mutでないiterも出来なくて困ってるとのことなので
スライスのiter()と同じものがLendingIteratorを使わずに書けるよ

struct MyIter<'a, T>(&'a [T]);

fn my_iter<'a, T>(slice: &'a [T]) -> MyIter<'a, T> {
MyIter(slice)
}

impl<'a, T> std::iter::Iterator for MyIter<'a, T> {
type Item = &'a T;
fn next(&mut self) -> Option<Self::Item> {
if let [first, rest @ ..] = self.0 {
self.0 = rest;
Some(first)
} else {
None
}
}
}

fn main() {
let a = ["foo", "bar"];
let mut iter = my_iter(&a);
assert_eq!(iter.next(), Some(&"foo"));
assert_eq!(iter.next(), Some(&"bar"));
assert_eq!(iter.next(), None);
}

**デフォルトの名無しさん** · 2024/12/09(月) 08:04:13.18

組み込みFW屋さんなんだけどRustやってみようかな…
組み込み屋視点でRustはC++の何を解決してると思う？
組み込み屋なんて古いシステムばかりだからすぐに取って代わることは無いとは思うけど
年々複雑な製品を求められるから選択肢としては持っておきたい

**デフォルトの名無しさん** · 2024/12/09(月) 09:11:23.41

zulip行けば？
ここにはカスしかおらん

**デフォルトの名無しさん** · 2024/12/09(月) 09:29:03.77

>>88
ダングリング参照を発見出来るだけ……とは言えそれが重要ではあるのだけど。
C++ は結局は人が気を付けなきゃならないことだらけで、複雑になると手におえない。
知ってることでも複雑に絡み合った状況では間違う。
C++ よりは機械的に検証可能な範囲を広げてるだけでもありがたいものだよ。

**デフォルトの名無しさん** · 2024/12/09(月) 09:59:55.51

>>90
え？マジ？
俄然興味湧いてきた
さっさと定時で帰って環境整えるか

**デフォルトの名無しさん** · 2024/12/09(月) 10:35:05.93

ビット幅気にするようなケースだと
数値型の暗黙の型変換がないとか演算時のオーバーフローの扱いを明示的に書けるとかが結構ありがたい

**デフォルトの名無しさん** · 2024/12/09(月) 13:24:01.49

科学＋ 5ch

【AI】AIはわずか2時間の対話で人間の性格をコピーできる [すらいむ★]
https://egg.5ch.net/test/read.cgi/scienceplus/1733576027/

コメントに面白いことが書かれている

**デフォルトの名無しさん** · 2024/12/09(月) 13:32:22.31

>>92
たしかに基礎的なことではあるがC/C++ではうっかり数値型の自動キャストでハマることもあるし
何よりも未定義動作が多くてこれも沼にハマる原因だな
それらを無くしたRustは賢明だ

**デフォルトの名無しさん** · 2024/12/09(月) 13:59:10.18

釣れますか？

**デフォルトの名無しさん** · 2024/12/09(月) 20:25:44.95

struct RefMutex<'a, T>(&'a Mutex<T>);
impl<'a, T> Iterator for RefMutex<'a, T> {
type Item = std::sync::MutexGuard<'a, T>;
//略
}

try_lockが失敗したらループが止まります
マルチスレッドならランダムに止まります知らんけど

**デフォルトの名無しさん** · 2024/12/09(月) 20:57:28.00

FnMut() -> Option<T>っぽいあらゆる処理を全部Iterator化しようという気概を感じるな

近寄らんとこ

**デフォルトの名無しさん** · 2024/12/09(月) 22:22:52.93

イテレータが勝手にループすることはない
ループするよう別途コードを書かなければならない
Option<T>を返す関数をfとすると
while let Some(x) = f() { ... } で十分である
つまりイテレータ実装する意味がない
イテレータメソッドに繋げたい！という反論もあろう
それなら std::iter::from_fn(f) で十分である

**デフォルトの名無しさん** · 2024/12/10(火) 01:03:26.70

Iteratorの話は、lifetimeの棍棒で殴られたという文脈で出てきただけだな

構造体のメンバーが&'a Mutex<T>なら
reborrowではなくmoveで取得した値に対しderef_mutが使える
moveなら殴られない

**デフォルトの名無しさん** · 2024/12/10(火) 12:58:54.26

>>88
c++使ってる組み込みって組み込みLinuxとかじゃねーの？
あんまり組み込み特有の制限ないだろ
好きに組めや

**デフォルトの名無しさん** · 2024/12/11(水) 12:00:23.09

これはポリシーというか戦略が違ってて、「今より少しでも改善するなら採用」だからじゃないかと
従来型の「最低限のクオリティに達するまではreject」へのアンチテーゼでもあるから
そして(文句あるかもしれんが)crates開発者は元々のエンジニアの質がそこそこ高かったからそれでも何とかなったものの、
同じ事をGitでやったからあの「ぼくがおもいついたすごいcrates」の山になったのだと思う
交通整理すらやる気無かったわけだ

とはいえ、「使われなくなったcratesは、いつしか動かなくなった事すら認識されなくなり、死んでいく」という、
Gitコマンド内でのライフゲームをやるつもりなら、ありなんだろうさ

**デフォルトの名無しさん** · 2024/12/12(木) 23:08:54.89

C/C++からRustへ：Googleが示すファームウェア進化の道筋
https://xenospectrum.com/google-revamps-firmware-with-rust/

**デフォルトの名無しさん** · 2024/12/14(土) 11:03:48.81

読み終わった

>>102
具体的なアプローチは以下の通りである：
(1) 段階的なRust導入：
　略
(2) 既存のCコードベースとの統合：
　略
(3) ベアメタル環境への対応：
　略
(4) ビルド最適化とパフォーマンスの考慮：
　略

**デフォルトの名無しさん** · 2024/12/15(日) 23:03:38.24

Rustで連番IDを発行する関数はこれでいい？

fn new_id() -> Option<usize> {
thread_local! {
static ID: Cell<usize> = Cell::new(0);
}
ID.get().checked_add(1).inspect(|&new_id| ID.set(new_id))
}

**デフォルトの名無しさん** · 2024/12/15(日) 23:37:25.98

mutableなRange（0..）をIteratorとして使う小技があるけど
オーバーフローは意識したことないな

fn new_id() -> Option<usize> {
use std::cell::RefCell;
use std::ops::RangeInclusive;

thread_local! {
static ID: RefCell<RangeInclusive<usize>> = RefCell::new(0..=usize::MAX);
}

ID.with_borrow_mut(|ids| ids.next())
}

**デフォルトの名無しさん** · 2024/12/15(日) 23:49:49.46

>>105
Cellで済むところがRefCellになってしまってメリットがよくわからないです

**デフォルトの名無しさん** · 2024/12/16(月) 00:17:21.21

合わせたつもりだったけど104の実装だと最初のidは1か

**デフォルトの名無しさん** · 2024/12/16(月) 00:32:53.11

0から開始できる形でCellにこだわるなら↓みたいな実装もありそう

fn new_id() -> Option<usize> {
thread_local! {
static ID:Cell<Option<usize>> = Cell::new(Some(1)); // ←0開始ならSome(0)
}
ID.replace(ID.get().map(|i| i.checked_add(1)).flatten())
}

**デフォルトの名無しさん** · 2024/12/16(月) 01:08:38.61

スレッド単位の連番て何やの？

**デフォルトの名無しさん** · 2024/12/16(月) 12:39:36.29

>>104をマルチスレッド対応するなら
まず初心者入門向け版としてはCellをMutexに変更で動く

fn new_id() -> Option<usize> {
static ID: Mutex<usize> = Mutex::new(0);

let mut id = ID.lock().unwrap();
id.checked_add(1).inspect(|&new_id| *id = new_id)
}

**デフォルトの名無しさん** · 2024/12/16(月) 18:51:07.44

inspectの間違った使い方

**デフォルトの名無しさん** · 2024/12/16(月) 19:41:56.01

正しいようだが何を問題視してる？
ちなみにRustではmatch(またはif let)で書いた時に
次のようなパターンになる場合に
わかりやすく短くメソッドにして繋げることができる

and_then(f)
　| Some(x) => f(x),
　| None => None,

map(f)
　| Some(x) => Some(f(x)),
　| None => None,

inspect(f)
　| Some(x) => { f(x); Some(x) }
　| None => None,

or_else(f)
　| Some(x) => Some(x),
　| None => f(),

unwrap_or_else(f)
　| Some(x) => x,
　| None => f(),

ok_or_else(f)
　| Some(x) => Ok(x),
　| None => Err(f()),

など

**デフォルトの名無しさん** · 2024/12/17(火) 10:28:51.72

全然判り易くないぞ
語彙に直交性が全く無い

**デフォルトの名無しさん** · 2024/12/17(火) 12:02:56.17

語彙の問題もあるのかもしれないけどasyncの問題もあって中の人たち含めみんな昔ほどコンビネータで書かなくなった

**デフォルトの名無しさん** · 2024/12/17(火) 12:27:03.59

Optionを自然に真偽値ベースで英語で読むと判り易くなっている
例えばunwrap_or_elseは
真ならunwrapすなわちSome(x)→x
orは前提が偽つまりNoneの場合がfの対象でNone→f()

似ているor_elseは
Some(x)→Some(x)となる部分だけ違うとすぐわかる

その逆は当然and_thenとなり
andは前提が真の場合がfの対象でSome(x)→f(x)となる

通常の動詞1つの時は真つまりSome(x)の時が対象で
mapは値を写像してSome(x)→Some(f(x))
inspectは値を変化させずに実行Some(x)→{ f(&x); Some(x) }
filterも値は変化させずに実行して偽なら捨ててNone
Some(x)→if f(&x) { Some(x) } else { None }

**デフォルトの名無しさん** · 2024/12/17(火) 13:56:28.23

現状追認オジの意見ほど意味のないものはない

**デフォルトの名無しさん** · 2024/12/17(火) 13:58:12.78

バカでも読めるコードが正解なんだよ

**デフォルトの名無しさん** · 2024/12/17(火) 14:25:44.95

コボラーがそんな事言っていたなw

**デフォルトの名無しさん** · 2024/12/17(火) 15:37:01.20

あほくさ。
そこらの医学でも物理でも法律でもいいが適当な論文が単語や言い回しだけ平易にすればバカでも読めるようになるか？
前提知識がないとどうせ意味なんかわからん。
プログラミングも同じ。
理屈が理解できるだけの能がなければ表現ばかり平易にしても無意味。

不必要に難解にする意味はないが、言い回しだけ過度に平易にする意味もない。

**デフォルトの名無しさん** · 2024/12/17(火) 15:40:38.28

特定のプログラミング言語を使えることを物理医学レベルと思ってるのは思い上がり

**デフォルトの名無しさん** · 2024/12/17(火) 15:52:02.93

>>120
どこをどう読んだらそんな風に読めるんだ？
言語は当然にそれで表現すべき何事かがある (書く人はそれを理解している) という話なんやが。

**デフォルトの名無しさん** · 2024/12/17(火) 15:54:52.82

>>121
自分はバカだと自覚したほうがいいぞ
ソフトウェア開発するならな

**デフォルトの名無しさん** · 2024/12/17(火) 16:01:39.84

>>122
それは大変によくわかる。
自分で書いたものすら意味わからんようになるのは普通のことだからな……。

だから意図を表現することが大事で、小さなロジックの断片にでも名前を付ける。
その状況を表すための名前 (専門用語) こそが大事。
訓練されていない人にとって平易であることとは違う。

**デフォルトの名無しさん** · 2024/12/17(火) 16:33:22.09

>>116
現状追認主義なのに推奨されてる用量・用法は守らず動くだけのコードを披露したがるのは理解できないんだが

**デフォルトの名無しさん** · 2024/12/17(火) 17:43:30.54

ママに褒めてもらいたい幼児の心理だよ
わかりやすいだろ

**デフォルトの名無しさん** · 2024/12/17(火) 20:27:48.43

>>117
「ごっちゃに書いて見通しの悪いコードにはせずに、
高階関数のメソッドチェーンにして、
各々のメソッドで個別に関数またはクロージャで処理を指定する。」
ここまでは共通認識でいいんだよね？
万が一これにも反対の人がいるならばまずは代案を明示的に出してほしい

以上の共通認識の上で
語彙の問題という話が出ているからメソッド名の付け方に問題があるということなのか？
それともメソッドが多すぎる(機能が多すぎる)またはメソッドの分別の仕方に問題があるということなのか？
まさか高階関数がわかりにくいという話ではないと思うが

**デフォルトの名無しさん** · 2024/12/17(火) 21:50:43.67

なんでもメソッドチェーンで繋げればいいわけでもなければ
なんでも分割して書けばいいわけでもない
ケースバイケース

一番ダメなのは慣習や暗黙の了解を無視したコード
>>104や>>110はその一番ダメなやつ

つかこんな基本的なことから説明させようとするなよ

**デフォルトの名無しさん** · 2024/12/17(火) 22:05:47.16

>>127
んでお前ならどう書くんだ？
Rust使った新システムで慣習や暗黙の了解はまだない時に自分で考えてソース書くときはどうするんだ？

**デフォルトの名無しさん** · 2024/12/17(火) 22:08:10.40

>>127
また自分勝手な慣習や思い込みの暗黙の了解かよ

**デフォルトの名無しさん** · 2024/12/17(火) 22:18:10.64

vecs.iter().map(|x| x.iter()).flatten().filter(...)

みたいなのは書いてて気持ち良いけど、全員が賛同するわけではないよな
Rustの公式のドキュメントだって関数型スタイルの書き方と手続き型スタイルの書き方の両方を紹介してるわけだし
そういう「高度な書き方」をバッサリ切り捨ててるGO言語が人気というのもそう

**デフォルトの名無しさん** · 2024/12/17(火) 22:20:51.38

>>127
具体的に何を問題視してるのかわからん
Mutexを使わずに効率よく実装できるケースのようにみえるが
初心者入門向けと書かれてるからMutex利用もアリだろう

**デフォルトの名無しさん** · 2024/12/17(火) 22:42:34.79

>>130
そのコード自体はともかく
そういうメソッド連鎖は標準ライブラリや有名クレートのソースにいくらでも出てくるぜ
まずはソース読んでみな

**デフォルトの名無しさん** · 2024/12/17(火) 23:29:57.24

>>132
自分も好みとしては関数スタイルを使うよ
だけど >>126 のような「それが正しい形であり、みんなそちらを使うべき」みたいな言説はあほらしい
有名どころのOSSのコントリビューターだって、利用者からの質問への回答やチュートリアルでは「for文で一つずつ要素を Vec に push_back で詰める」コードを示すことも実際にある

Rust開発者は関数スタイルを好む人も多いと思うけど、それは好みの域を出ないと思う

**デフォルトの名無しさん** · 2024/12/18(水) 09:42:19.11

まあ存在する以上はユースケースがあるってことだからな。

**デフォルトの名無しさん** · 2024/12/18(水) 12:59:18.01

コードゴルファーのために存在してるわけじゃないからな

**デフォルトの名無しさん** · 2024/12/18(水) 13:17:46.53

そろそろitertoolsを標準ライブラリ化する話はないのか？

**デフォルトの名無しさん** · 2024/12/18(水) 18:37:10.88

個別に取り入れられてる
まとめて標準化はない
棲み分け

**デフォルトの名無しさん** · 2024/12/18(水) 19:09:54.98

>>127
そのマルチスレッド対応コードに
指摘の「慣習や暗黙の了解を無視したコード」とやらが見当たらないのだが
そもそも慣習や暗黙の了解とはどういう意味で使ってる？

>> マルチスレッド対応するなら
>> まず初心者入門向け版としてはCellをMutexに変更で動く
>>
>> fn new_id() -> Option<usize> {
>> static ID: Mutex<usize> = Mutex::new(0);
>>
>> let mut id = ID.lock().unwrap();
>> id.checked_add(1).inspect(|&new_id| *id = new_id)
>> }

**デフォルトの名無しさん** · 2024/12/19(木) 11:45:17.60

こういう C のコードを Rust で描く場合どうやればいい？
https://www.youtube.com/watch?v=n2Q1Sp7iew4
もちろん unsafe 利用 ok として

**デフォルトの名無しさん** · 2024/12/19(木) 11:55:22.77

型のキャストは
std::mem::transmute

**デフォルトの名無しさん** · 2024/12/19(木) 12:16:13.05

assert_eq!((3.14_f32).to_bits(), 0b1000000010010001111010111000011_u32);
assert_eq!(f32::from_bits(0b1000000010010001111010111000011_u32), 3.14_f32);

**デフォルトの名無しさん** · 2024/12/20(金) 15:29:01.33

JAIST、「並行量子通信プロトコル」の完全な自動形式検証を実現
http://news.mynavi.jp/techplus/article/20241220-3090485/

**デフォルトの名無しさん** · 2024/12/22(日) 22:27:16.01

>>138
中級者向けにはこれでええんかね

fn new_id() -> Option<usize> {
static ID: AtomicUsize = AtomicUsize::new(0);

let mut old_id = ID.load(Relaxed);
while let Some(new_id) = old_id.checked_add(1) {
match ID.compare_exchange_weak(old_id, new_id, Relaxed, Relaxed) {
Ok(_) => return Some(new_id),
Err(updated_old_id) => old_id = updated_old_id,
}
}
None
}

**デフォルトの名無しさん** · 2024/12/23(月) 22:20:47.40

Rustに興味出てきたからとりあえず、とほほさんのサイトに目を通してみたんだけど
…もしかしてあの方、非同期処理と並列処理をごっちゃに理解している？

https://www.tohoho-web.com/ex/rust.html#async-await

**デフォルトの名無しさん** · 2024/12/23(月) 22:54:25.61

>>143
lock freeはそう
今回のアルゴリズムはRelaxedでも大丈夫だがmemory orderingに注意を要する

>>144
executor (runtime) とそこでの使い方次第
single thread で並列(parallel)なく並行(concurrent)のみも可能であるし
それをmulti threadで並行並列も可能であるし
blockさせて並行なく専属並列も可能

**デフォルトの名無しさん** · 2024/12/28(土) 15:51:05.67

Rustしか勝たん

**デフォルトの名無しさん** · 2024/12/28(土) 17:09:23.73

こういうアホが湧いてきたときがピークだな

**デフォルトの名無しさん** · 2024/12/28(土) 17:20:50.92

WebAssemblyはRustが主流なイメージだけど実際どんなもんだろ

**デフォルトの名無しさん** · 2024/12/28(土) 18:28:20.06

linuxカーネルがシェルスクリプトの付属品にならなかったのはシェルを変更できるから
だがjsは、変更不可能にすればjsが永久に主流だというのを意図的にやっている

**デフォルトの名無しさん** · 2025/01/01(水) 12:59:04.47

>>149
何いってんだお前？

**デフォルトの名無しさん** · 2025/01/01(水) 18:48:34.00

触るな触るな

**デフォルトの名無しさん** · 2025/01/03(金) 23:49:31.66

ひといないねこのすれ

**デフォルトの名無しさん** · 2025/01/04(土) 10:08:52.56

だからマルチスレッドで発生しうる競合はその2つだけじゃないから

それだけで安全と言い切れるわけないだろ

そもそも安全性ってお前が作るアプリで必要なの？
Linuxカーネルや組み込みだったらわかるけどそんな高度なプログラム作ってんの？
飛行機のシステム作ってて命がかかってるとかならわかるが、その辺のアプリで安全性とかどうでもいいよね

Rust馬鹿信者は開発生産性を軽視しすぎだ、開発生産性を犠牲に安全性に振ってるのがRustだがアプリの特性によって安全性なんぞどうでもいいことが多い

開発生産性が一番重要

**デフォルトの名無しさん** · 2025/01/04(土) 11:56:56.49

難しさによる障壁はあるけど、慣れれば生産性自体は高い言語だと思う
ライブラリ多いし、ちょっとしたツールを作る程度ならエラーハンドリングもそんなに頑張らなくて良いし (anyhow を使えば割と雑に書ける)

流石にPythonのような手軽さは無いけど、C++よりは遥かに書きやすいし、個人的にはC#やJavaよりも楽だと思うくらい
これは言語仕様でなくツールの話だけど、プロジェクトを作ったり、ライブラリを追加したりするのが楽

学習コストが高いのはその通りで、誰かが書いたツールを他の人が保守しづらいみたいな問題はどうしようもないけど…
(そういう用途ならGoが良さそう)

**デフォルトの名無しさん** · 2025/01/04(土) 12:23:29.13

>>154
他人が書いたコードの保守しやすさはGoより上だと感じてるけどな
型含めてコード上に情報が豊富で作者の意図を取りやすいから
かなり巨大なOSSでも割と楽にプルリクとか出せる

**デフォルトの名無しさん** · 2025/01/04(土) 12:59:21.10

>>155
「自分がRustに慣れてるなら」それは自分も同意
自分の意見は
・Rustは分かるようになるまでが大変
・理解できれば開発者にとって強力な言語
で、「Goの方が向く」というのはとっつきやすさを含めた話のつもりで書いた
他言語の経験者から見たら、たぶんRustは型やトレイトの意味を理解するのが難しいし、参照などのルールを理解しないとコンパイルすら通らないから、Goの方が触りやすいんじゃないかと思う

Arc, Rc, Cell, Mutex とかの型は分かる人にとってはmeaningfulだけど、初学者がすぐに分かるものではないと思う

**デフォルトの名無しさん** · 2025/01/04(土) 13:59:36.84

>>156
単純にメンテする人員を確保しづらいという意味ならそれはそう

**デフォルトの名無しさん** · 2025/01/04(土) 22:40:45.82

rustのいい所はresultやoption.その他色々な型について文脈が大体決まっていること。なので慣れると人が書いたコードでも読みやすい。c#やjavaとの比較であれば開発効率は大体同じか、勝っているぐらい。nullや例外がある言語はプログラムがどうしても汚くなる。
rustはaiにコード生成させた時の品質も割といい。コンパイルエラーでても対応方法が具体的なのでそのままメッセージをaiに渡すだけで直る。

**デフォルトの名無しさん** · 2025/01/04(土) 22:49:58.13

AIが当たり前の時代においてはコードの記述量そのものは開発効率に直結するものではなくなる。どの言語でも似たような事は出来る。でも作られたコードが、正しいかどうかは別の問題。
AIはたまに嘘を付くので、それをコンパイラで厳密にチエックする必要がある。そういう意味では関数型言語へのシフトは進むし、rustはいい位置にいると思う。

**デフォルトの名無しさん** · 2025/01/04(土) 23:01:31.53

関数型関係ないから

**デフォルトの名無しさん** · 2025/01/04(土) 23:15:15.09

>>159
関数型である部分ではなく
Rustが安全性にも役立つ史上最強の型システムを構築したことが決め手かな
特にトレイトそしてトレイト境界
さらに例えばSendやSyncといった概念的なトレイトなど

**デフォルトの名無しさん** · 2025/01/05(日) 00:44:18.92

そうなんだ、Rustってすごいんだね！

**デフォルトの名無しさん** · 2025/01/05(日) 11:01:38.28

関数型関係ないから

**デフォルトの名無しさん** · 2025/01/05(日) 13:34:15.55

お前ら9連休はちゃんと楽しめたか？

**デフォルトの名無しさん** · 2025/01/05(日) 16:19:33.22

九連休に一回もコード書いてない陽キャはこのスレ書き込み禁止な

**デフォルトの名無しさん** · 2025/01/05(日) 18:30:14.16

体力落ちないように散歩しまくってたら脚の裏に豆出来たよ

**デフォルトの名無しさん** · 2025/01/05(日) 18:46:31.56

陰キャなのに今年のコード書いてなかった

fn main() {
println!("{}年", (0..10u64).map(|i| i.pow(3)).sum::<u64>());
println!("{}年", (0..10u64).sum::<u64>().pow(2));
}

sum()の型アノテーション外せないの？

**デフォルトの名無しさん** · 2025/01/06(月) 00:22:47.46

>>167
型アノテーションは必要。
オーバーフローしない十分に大きな型を選定しなきゃならないから。
浮動小数点ならオーバーフローはしないが必要な精度を推論しようがないことにかわりない。

**デフォルトの名無しさん** · 2025/01/06(月) 00:30:50.77

その論理は明らかにおかしい

**デフォルトの名無しさん** · 2025/01/06(月) 03:11:05.95

0..10がu64なんだからsumの結果も当然u64だろうという気持ちにはなる

**デフォルトの名無しさん** · 2025/01/06(月) 08:35:26.36

そこは指定必須
例えばu64の和をu128で求める型を以下のように増やせるから無指定を許すとコードが曖昧になる

struct MySum(u128);

impl std::iter::Sum<u64> for MySum {
fn sum<I: Iterator<Item = u64>>(iter: I) -> Self {
iter.fold(MySum(0), |sum, n| MySum(sum.0 + n as u128))
}
}

fn main() {
// u64の和をu128で計算できる
let x = [u64::MAX, u64::MAX].into_iter().sum::<MySum>().0;
assert_eq!(x, u64::MAX as u128 * 2);

// このコードはデバッグモード時にoverflowして悪手
let x = [u64::MAX, u64::MAX].into_iter().sum::<u64>();
assert_eq!(x, u64::MAX - 1);

// ラップアラウンドさせたいならこうする
use std::num::Wrapping;
let x = [u64::MAX, u64::MAX].into_iter().map(|n| Wrapping(n)).sum::<Wrapping<u64>>().0;
assert_eq!(x, u64::MAX - 1);
}

このように必ず型を指定して使い分けをする

**デフォルトの名無しさん** · 2025/01/06(月) 16:43:43.88

Monoidを先に整備すればこんなことにはならずに済んだろうに

**デフォルトの名無しさん** · 2025/01/06(月) 17:02:00.56

>>171
そういうのは本来sumの役割じゃなくないかという気持ち

**デフォルトの名無しさん** · 2025/01/06(月) 18:43:17.81

オーバーフローとかは関係なくて型システムの制約と標準ライブラリの実装方法の問題だよ

**デフォルトの名無しさん** · 2025/01/06(月) 19:00:20.90

sum()の戻り値の型をIterator::Itemに固定するとItemが参照型の場合に対応できないな

**デフォルトの名無しさん** · 2025/01/06(月) 21:13:46.20

そら固定したらダメだよ

**デフォルトの名無しさん** · 2025/01/06(月) 21:49:35.38

ジェネリクスで良いとは思うけど、デフォルトの型として元の型になってくれると便利な気はする
参照の場合とかは、数値型なら .copied() で値にできるし

**デフォルトの名無しさん** · 2025/01/07(火) 23:41:33.61

>>177
copy可かつcopyでコスト増にならないのはプリミティブな数値型だけだよ
巨大な整数値やタプルや行列などもありうる
例えば std::simd::Simd のimpl Sumでも参照を扱ってるね
impl<'a, const N: usize> Sum<&'a Simd<u32, N>> for Simd<u32, N>

**デフォルトの名無しさん** · 2025/01/08(水) 00:21:31.60

もうfoldでいい気がしてきた

fn main() {
use std::ops::Add;
println!("{}年", (0..10u64).map(|i| i.pow(3)).fold(0, u64::add));
println!("{}年", (0..10u64).fold(0, u64::add).pow(2));
}

３乗の総和＝総和の２乗の証明は今年の入試で狙われそうだな
帰納法使えば簡単だけどn(n+1)/2の導出からだとだるい

**デフォルトの名無しさん** · 2025/01/08(水) 23:11:07.72

そのSimdのSum実装のこれを見てそこに落ち着いたのか
iter.fold(Simd::splat(0 as $type), Add::add)

**デフォルトの名無しさん** · 2025/01/11(土) 08:43:38.04

Rust排除のためのMozilla潰しが始まったか？

GoogleとLinux FoundationがChromiumの開発と維持を支援する基金「Supporters of Chromium-Based Browsers」を設立、MetaやMicrosoftなども参加 - GIGAZINE
https://gigazine.net/news/20250110-supporters-of-chromium-based-browsers/

**デフォルトの名無しさん** · 2025/01/11(土) 10:01:12.58

Chromium プロジェクトが Rust の利用をサポート
https://developers-jp.googleblog.com/2023/02/supporting-use-of-rust-in-chromium.html

**デフォルトの名無しさん** · 2025/01/11(土) 10:03:06.03

Rust を導入する目的は、シンプルで（IPC を使わない）安全な（全般的に C++ よりも複雑でなく、サンドボックスでメモリの安全性に関するバグは発生しない）形で 2 の法則を満たすことにより、

**デフォルトの名無しさん** · 2025/01/11(土) 10:08:09.58

Rust は、Mozilla がブラウザを書くために特別に開発したものなので、このテクノロジーが Chromium でようやく使われ始めるようになるのは、理にかなったことです。
システムソフトウェア業界に莫大な貢献をしてくださっている Mozilla に感謝いたします。
Rust は、安全性とパフォーマンスの両方を言語に期待できることを見事に証明しています。

**デフォルトの名無しさん** · 2025/01/11(土) 10:21:28.46

むむっ

**デフォルトの名無しさん** · 2025/01/11(土) 11:00:56.87

そもそもMozillaはRust開発者の大半をリストラしてしまったし
すでに単なる1ユーザ企業に過ぎなくて、Rustの発展にはあんまり関係なくなってる
どちらかというとMDNを維持できるかとかの方が重要そう

**デフォルトの名無しさん** · 2025/01/11(土) 11:44:47.56

GoogleはChromeが独占禁止法違反にならないようにFirefox支援しててMozillaは生きててもらわなきゃならん
デフォルトの検索エンジンに採用する見返りにGoogle社から受け取ってる金がMozillaの収益の90%を占めるから潰すのはその金を絞るだけでいい

**デフォルトの名無しさん** · 2025/01/11(土) 12:13:12.32

>>187
おまえ日本語不自由なら無理に書き込まなくてもいいんだよ？

**デフォルトの名無しさん** · 2025/01/11(土) 12:35:47.49

>>188
お前には難しかったか
すまんな

**デフォルトの名無しさん** · 2025/01/11(土) 12:37:03.90

添削してあげる

GoogleのChromeが独占禁止法違反にならないように対抗馬のFirefoxにある程度台頭してもらう必要がある
そのためGoogleはMozillaを投資している
投資の一例としてMozillaはデフォルトの検索エンジンに採用する見返りにGoogleからMozillaの収益の90%を占める投資を受け取ってる
仮にGoogleがMozillaを潰すのならその投資を絞るだけでいい

**デフォルトの名無しさん** · 2025/01/11(土) 12:38:54.31

訂正

誤そのためGoogleはMozillaを投資している
正そのためGoogleはMozillaに投資している

**デフォルトの名無しさん** · 2025/01/11(土) 12:49:21.17

いずれも着実にRust化

**デフォルトの名無しさん** · 2025/01/11(土) 12:57:56.78

>>190
俺より頭が良さそう
尻拭いしてもらってすまんな

**デフォルトの名無しさん** · 2025/01/11(土) 16:20:18.17

ところがMozillaに資金援助してるのが
独禁法違反ともめてるわけだ

**デフォルトの名無しさん** · 2025/01/12(日) 23:53:09.91

ChromeもMozillaも各々Rust化へ向かってるなら
今後はここでもう揉めなくて済むな

**デフォルトの名無しさん** · 2025/01/13(月) 05:20:11.26

>>189
結局添削されてるな
ガイジ乙

**デフォルトの名無しさん** · 2025/01/13(月) 13:52:02.59

>>188
あなたは頭が不自由なのですね判ります

**デフォルトの名無しさん** · 2025/01/13(月) 16:13:11.82

Rust 1.84.0でprovenance関係が安定化されてるね

**デフォルトの名無しさん** · 2025/01/18(土) 10:00:11.55

Rustで描かれてるMozillaがめっちゃ不安定なんすけど

**デフォルトの名無しさん** · 2025/01/18(土) 10:07:56.33

>>199
Mozillaのメモリ管理や中核部分はC++で書かれている