Rust part13

**デフォルトの名無しさん** · 2021/11/07(日) 10:04:59.35

公式
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のasyncについて知りたければ「async-book」は必読
https://rust-lang.github.io/async-book/

※C++との比較は専用スレへ
C++ vs Rust
https://mevius.5ch.net/test/read.cgi/tech/1619219089/

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

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

**デフォルトの名無しさん** · 2021/12/23(木) 00:23:38.98

ここを読む
https://doc.rust-lang.org/book/ch19-05-advanced-functions-and-closures.html#returning-closures

**デフォルトの名無しさん** · 2021/12/23(木) 07:21:11.33

>>348
そりゃあcratesio に上がったものは空っぽでもゴミでも全部公認だわなｗ

**デフォルトの名無しさん** · 2021/12/23(木) 15:17:54.33

>>342
逆だ、コードは常に「正解」で動いていて「間違い」ない。

あんたの書いたバグもコンピューターにとっては一部の隙もなく正解であり、書かれたその通りに動き、無慈悲である。
同じ目的で、多数、あるいは二人の人が書いたコードで違いが出るのは「表現の違い」であり「間違い」と決めつける
のは人間の主観や嗜好でしかなく、仮にコードへ正誤を求めるなら明確に表現できていなればならず、矛盾が生じる

**デフォルトの名無しさん** · 2021/12/23(木) 15:32:21.87

コンパイルが通らないコードも正解なのかい？

**デフォルトの名無しさん** · 2021/12/23(木) 15:39:30.16

えらいポエミーやな

**デフォルトの名無しさん** · 2021/12/23(木) 18:55:13.24

”動いていて”と言っているからコンパイルは通ってる前提だろう、”コードへ正誤を求める”といっているから
仮にコンパイルが通らないコードは明確にそれ（誤り・間違い）が表現できている
ポエミーなのはその通りだろう

**デフォルトの名無しさん** · 2021/12/23(木) 21:22:53.78

>>349
Boxとはヒープを使うということです
Rustではコードで明示的に指定しない限り勝手にヒープが使われることはないです
(もちろんBox以外にもVecやStringなどヒープを使うものを使ってもそれは明示的に指定したことになります)

その Box<Fn(i32) -> i32> は今は Box<dyn Fn(i32) -> i32> と書く必要があります
では本題の impl Fn(i32) -> i32 と書いた場合はどうなるのでしょうか？
以下のように3種類のクロージャを作ってサイズや型を表示させてみると
fn main() {
　let direct_closure = |x: i32| x + 1;
　let impl_closure = make_impl_closure();
　let box_closure = make_box_closure();
　println!("{} {}", std::mem::size_of_val(&direct_closure), type_of(&direct_closure));
　println!("{} {}", std::mem::size_of_val(&impl_closure), type_of(&impl_closure));
　println!("{} {}", std::mem::size_of_val(&box_closure), type_of(&box_closure));
}
fn make_impl_closure() -> impl Fn(i32) -> i32 {
　|x| x + 1
}
fn make_box_closure() -> Box<dyn Fn(i32) -> i32> {
　Box::new(|x| x + 1)
}
fn type_of<T>(_: &T) -> &'static str {
　std::any::type_name::<T>()
}

実行結果は以下のように表示されます
0 tmp::main::{{closure}}
0 tmp::make_impl_closure::{{closure}}
16 alloc::boxed::Box<dyn core::ops::function::Fn<(i32,)>+Output = i32>
つまりimplでは直接クロージャ指定したのと全く同じです
(上記では定義した関数名だけが異なる)

**デフォルトの名無しさん** · 2021/12/23(木) 21:33:09.04

今日はポエマー多いなw

**デフォルトの名無しさん** · 2021/12/23(木) 22:34:57.88

では常に impl を使えばよいのかというと
以下のような条件によって異なるクロージャを返す時
ここで Box を使わず impl Fn(i32) -> i32 にしようとすると
2つのクロージャの型が違うとコンパイラに怒られます

fn make_closure(curry: Option<i32>) -> Box<dyn Fn(i32) -> i32> {
　if let Some(curry) = curry {
　　Box::new(move |x| x + curry)
　} else {
　　Box::new(|x| x + 1)
　}
}

結局クロージャでない場合と同じ話で
同じトレイトでも型が異なるものが同居する時にBox化します
>>349のRust bookの例はBox化が不要なケースでBox化だから混乱しますね

**デフォルトの名無しさん** · 2021/12/24(金) 11:53:17.86

コンパイル通ってれば全て正解とかバカ丸出し。
厳密な定義でも使えない定義があるってことすら理解してなさそう。

**デフォルトの名無しさん** · 2021/12/24(金) 12:05:46.49

型安全だったらコンパイル通れば実行時エラーにならないという点で全て正解っていうのは別に間違ってないと思うけど？
これにケチつけるのは流石にどうかと

**デフォルトの名無しさん** · 2021/12/24(金) 12:44:01.96

バカ丸出しにお前バカだろとわざわさ言うのもバカなんじゃなかろうか

**デフォルトの名無しさん** · 2021/12/24(金) 15:42:15.21

>>360
実行時エラーにならないなんて最低限のところだっつーの。だからバカだっていうんだよ。

**デフォルトの名無しさん** · 2021/12/24(金) 16:05:46.66

もしかしてrustはlinuxに取り込まれるわけねーだろって言い張っていた人？
予言外していたよね。お疲れ様です。

**デフォルトの名無しさん** · 2021/12/24(金) 16:08:19.93

バカをスルーできないバカっているよねー

>>364
お前の事な

**デフォルトの名無しさん** · 2021/12/24(金) 16:10:39.10

なんか草

**デフォルトの名無しさん** · 2021/12/24(金) 16:20:12.59

25 デフォルトの名無しさん sage 2021/04/27(火) 08:00:23.09 ID:/+bIFNU8
>>23
あのね。。書けばそうなるってものじゃなくてそれを実装しなきゃならんのよ。。
コンパイラにそういったコンテクストを判断させるのがめちゃくちゃ難しいっていってるでしょ？
なんでそんなに読み取れないの？

27 デフォルトの名無しさん sage 2021/04/27(火) 16:10:45.63 ID:/+bIFNU8
>>26
だからそのコードじゃpanic捉えきれねーからカーネルに入れるわけねーだろって
言ってんじゃん。。何読んでんだよ。

28 デフォルトの名無しさん sage 2021/04/27(火) 18:23:48.67 ID:n/AWrch2
まあ半年後どうなるかで誰が正しかったかは分かるわな

29 デフォルトの名無しさん sage 2021/04/27(火) 20:32:29.92 ID:/+bIFNU8
半年も経たなくてももうわかってるっつーの。。だからちゃんと英語の勉強しましょうね。

完全に同一人物だよね

**デフォルトの名無しさん** · 2021/12/24(金) 16:26:02.78

https://lkml.org/lkml/2021/12/6/461

英語読めんならこれになんて書かれているのかわかるよね？

**デフォルトの名無しさん** · 2021/12/24(金) 16:31:02.04

予想が完全に外れたID:8qqh3vKrを晒し上げ♪♪♪
ここまで簡単な予想を外すとかバカ過ぎて生きていけなさそうｗｗｗ
馬鹿丸出しですねｗｗｗｗｗｗ

**デフォルトの名無しさん** · 2021/12/24(金) 16:40:31.03

素でバカなんだな。。もうコンパイル通ったんで俺の仕事終わりとか現場で言ってろよ。。話にもならん。

**デフォルトの名無しさん** · 2021/12/24(金) 16:42:14.31

>>362
最低限の性質を満たしている⇔正解って言ってんじゃん。。何読んでんだよ。
なんでそんなに読み取れないの？
だからバカだっていうんだよ。
だからちゃんと日本語の勉強しましょうね。

**デフォルトの名無しさん** · 2021/12/24(金) 16:45:16.93

>>369
なお予言を外したことについては一貫してノータッチｗｗｗｗｗ
話をしたくないのは君だよねｗｗｗｗｗｗ

**デフォルトの名無しさん** · 2021/12/24(金) 16:46:19.44

>>369
同一人物だってことはバレバレだっつーの。バカ丸出し。ｗｗｗｗｗｗｗｗｗｗ

**デフォルトの名無しさん** · 2021/12/24(金) 17:12:05.04

どうでもええわRustの話しろ

**デフォルトの名無しさん** · 2021/12/24(金) 17:38:56.03

厳密な定義でも使えない定義？Rustに特定条件下でCのような未定義になる動作あったっけ？

**デフォルトの名無しさん** · 2021/12/24(金) 18:41:11.93

スレの文脈はしらんけど、
Rustではunsafeを使ってなければコンパイラが、未定義動作が起きないということや、データ競合がないことを保証をしてくれるよ

**デフォルトの名無しさん** · 2021/12/24(金) 19:10:24.57

>>369
予言外れましたよね？ｗｗｗｗｗｗｗｗ

**デフォルトの名無しさん** · 2021/12/25(土) 15:28:33.08

Rustでフロントエンドしてる奴おる？

**デフォルトの名無しさん** · 2021/12/26(日) 12:56:45.57

Rustの勉強を昨日から開始した。後は構造体とかかな。

**デフォルトの名無しさん** · 2021/12/26(日) 17:26:13.09

コード貼ったら糞だボケだゴミだと自称上級者に罵倒されるから注意しろ

**デフォルトの名無しさん** · 2021/12/26(日) 19:27:36.42

Rustはこう謳っている
>なぜRustか？
>パフォーマンス
>信頼性
>生産性
真っ向から反するコードを貼ってりゃゴミ・クソ言われて当然なんだよなぁ

**デフォルトの名無しさん** · 2021/12/26(日) 19:29:23.79

すまんが、配列に入った数値の平均ってパッと出せないもんなの？
他言語でふにゃふにゃになった俺の頭でコードを書いたら、桁の溢れとか精度とか酷えことになりそう・・・・

**デフォルトの名無しさん** · 2021/12/26(日) 20:24:04.94

コードもゴミだったがそれ以上に考え方がゴミだったからな

**デフォルトの名無しさん** · 2021/12/26(日) 20:42:21.32

>>381
これ使ったらよいのでは
https://docs.rs/streaming-stats/0.2.3/stats/fn.mean.html

**デフォルトの名無しさん** · 2021/12/26(日) 22:30:25.75

>>381
普通に平均を求めるだけではダメなのでしょうか？

fn main() {
assert_eq!(5.5, (1..=10).average());
assert_eq!(6.8, [2.3, 8.7, 9.4].average());
}

use num::ToPrimitive;
trait Average {
fn average(self) -> f64;
}
impl<I> Average for I
where I: IntoIterator, <I as IntoIterator>::Item: ToPrimitive,
{
fn average(self: I) -> f64 {
self.into_iter().fold((0.0, 1.0), |(ave, size), n| (ave + (n.to_f64().unwrap() - ave) / size, size + 1.0)).0
}
}

**デフォルトの名無しさん** · 2021/12/27(月) 00:09:24.17

カハンの加算アルゴリズムというのがある

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

汚コードｷﾀ━！

**デフォルトの名無しさん** · 2021/12/27(月) 10:50:10.93

何でもトレイト化するアホ

**デフォルトの名無しさん** · 2021/12/27(月) 12:29:15.17

ゴミをゴミだといって何が悪い！

**デフォルトの名無しさん** · 2021/12/27(月) 12:32:52.22

ここの人たちってplaygroundとかなんで完全に動かせるコードで提示しないんだろ・・・？
アドバイス貰うにも回答するにも一生懸命スペース全角置換したり、まじ両方キモイｗ
trait Averageｗｗｗｗｗ

**デフォルトの名無しさん** · 2021/12/27(月) 13:09:28.61

こう言う時って普通の関数にしちゃいかんの？

**デフォルトの名無しさん** · 2021/12/27(月) 14:19:38.18

普通の関数にすべきかどうかはメソッドチェーンにしたいかどうかで判断すればよろしい

**デフォルトの名無しさん** · 2021/12/27(月) 14:43:10.42

>>389
playgroundでは自己顕示欲が満たせないんだよw

まあplaygroundでは動かせないコードもあるけどな

**デフォルトの名無しさん** · 2021/12/27(月) 15:03:42.29

>>381
こういう子は、移動平均出したくなった時とかどうすんだろ…
愚直に毎回平均出す関数とか使っちゃうわけ？

**デフォルトの名無しさん** · 2021/12/27(月) 21:04:27.03

しょうがない、一応は専門家が書いているであろう他言語の実装を参考にしよう・・・・
https://source.dot.net/#System.Linq/System/Linq/Average.cs,2b4701af991d5425
俺様、信頼して使っていたメソッドの衝撃の事実を知る

**デフォルトの名無しさん** · 2021/12/27(月) 21:09:19.15

浮動小数点型ならそういう素直な実装で十分だよ

**デフォルトの名無しさん** · 2021/12/27(月) 21:53:06.04

>>384
それだと桁溢れは防止できているが誤差蓄積の対処ができていない
もう一つパラメタを増やしてこうしたほうがいい
fn average(self: I) -> f64 {
self.into_iter().fold((0.0, 1.0, 0.0), |(ave, size, fix), n| {
let diff = (n.to_f64().unwrap() - ave) / size - fix;
let new_ave = ave + diff;
(new_ave, size + 1.0, (new_ave - ave) - diff)
}).0
}

>>387
イテレータメソッド化するにはそのためのtrait宣言が必須
もしわからないならitertoolsなどのイテレータ拡張ライブラリを見よう

>>389
標準ライブラリのsum()がtrait Sumを使っているからtrait Averageでもまあいいとは思う
ただし今回はイテレータメソッド拡張のみに用いているようだからtrait IteratorExtなどの命名がわかりやすいとは思う

**デフォルトの名無しさん** · 2021/12/27(月) 21:56:50.25

IteratorExt大草原、まじに入院してほしいｗ

**デフォルトの名無しさん** · 2021/12/27(月) 22:01:57.73

イテレータメソッドにする必要ある？

**デフォルトの名無しさん** · 2021/12/27(月) 22:15:24.91

>>398
標準ライブラリにおいてsum()やproduct()
それを一般化したfold()やreduce()
さらにmax()やmin()など当然イテレータメソッドになっている
むしろ今回のaverage()だけをイテレータメソッドにしない理由が見当たらない

**デフォルトの名無しさん** · 2021/12/27(月) 22:20:18.56

>>399
じゃあなんで標準ライブラリにないの？

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

カハンの加算使ったのか

**デフォルトの名無しさん** · 2021/12/27(月) 22:31:56.63

>>400
入力型と出力型で大量の組み合わせ(例:i32→f32)が用途に応じて要求されるのと
単純に合計をサイズで割った平均でよい用途もあれば
件数が多いと合計がオーバーフローするからその対策が欲しい用途もあれば
桁が大きく異なるデータ列の場合に浮動小数点の誤差改善が欲しい用途など多岐にわたる
だから平均を標準ライブラリで何か一つ用意は無理

**デフォルトの名無しさん** · 2021/12/27(月) 22:51:58.74

単にこれまで標準ライブラリに入れようとした人がいなかったか
そういう人はいたが必要性を説得できなかっただけでしょう
sumやproductに比べるとユースケース限られるしね

**デフォルトの名無しさん** · 2021/12/27(月) 23:21:10.48

"ave"のせいで頭に入ってこない

**デフォルトの名無しさん** · 2021/12/28(火) 00:10:56.21

「件数が多いと合計がオーバーフローするからその対策が欲しい用途」そんな考えがオカシイ
sumですらオーバーフローに言及しているだけで対策が欲しいから、だからstdじゃないという理由では無い
https://doc.rust-lang.org/std/iter/trait.Iterator.html#panics-3
When calling sum() and a primitive integer type is being returned, this method will panic if the computation overflows and debug assertions are enabled.

必要性を説得出来ないだけというのが正しい。浮動小数の加減算による誤差蓄積だって、浮動小数を扱うなら当然起こることだが
誤差改善が欲しい用途があるからstdじゃないとか嘘ばっかり言わないで？おまえさ、迷惑だからRust辞めてくれよ？
最小限、分かったふりで糞まき散らすな？

**デフォルトの名無しさん** · 2021/12/28(火) 00:45:10.69

>>405
それは君が無知
平均算出にはsumを求めずとも差分を逐次的に適用するアルゴリズムがあるoverflowを回避する対策で一般的に使われている
例えば>>383のstatsもその方法で平均を算出している
sumの例を出すのは見当違い

**デフォルトの名無しさん** · 2021/12/28(火) 00:52:41.14

>>406
アルゴリズムの話じゃなくてstdに入ってない理由の説明がおかしいという指摘だと思うよ
言葉汚いし何言ってるかわかりづらいけど

**デフォルトの名無しさん** · 2021/12/28(火) 01:20:29.34

>>407
stdに入ってない理由？
一長一短ある複数のアルゴリズムがあるから外部でいいだろう

**デフォルトの名無しさん** · 2021/12/28(火) 01:57:17.15

>>408
その理屈だとsortも該当するが
そもそも前提としてaverageをstd

**デフォルトの名無しさん** · 2021/12/28(火) 02:00:22.76

>>409
途中で書き込んでしまった

そもそもaverageか類似の関数をstdに取り込む議論が過去にあったならそれをポイントしてほしい

**デフォルトの名無しさん** · 2021/12/28(火) 02:37:31.31

多数あり外部で十分派なのでそこは興味ない
sortは2種類しかなく2種類とも標準ライブラリでサポートしている

**デフォルトの名無しさん** · 2021/12/28(火) 09:30:51.41

>>411
じゃ一番メジャーな外部ライブラリを教えてよ

**デフォルトの名無しさん** · 2021/12/28(火) 10:24:44.25

外部で十分と言えば、cratesは先着順で名前取れるからこの先優良ライブラリ程クソみたいな名前になっていくよね

**デフォルトの名無しさん** · 2021/12/28(火) 10:41:12.74

>>413
マジでこれ
いい名前取るだけ取って何年も放置とか多すぎ
なんかいい方法無いかねぇ…

**デフォルトの名無しさん** · 2021/12/28(火) 11:15:50.74

ライブラリの永続性を保つのに名前でマッチさせるのやめてUUIDかハッシュか何かでマッチさせれば良かったのにみたいな気持ちはある

**デフォルトの名無しさん** · 2021/12/28(火) 11:32:06.72

>>414
横から失礼。
個人的にはそもそもcrate.io に頼るのがあまり好きでないなと。
Rust に限らない話だけど、こういった中央集権的なリポジトリを用意すること自体が名前争奪戦の元になるのではないかなと。
それぞれのWEBサイトで勝手に配布すればいいのにってね。
バージョン管理方法の方法論なんかも関わるから簡単な事ではないんだろうけど。

**デフォルトの名無しさん** · 2021/12/28(火) 11:35:30.26

現状でもGitHubから直接落としてくることも出来るけど、GotHubのリポジトリは消せてしまうからな

**デフォルトの名無しさん** · 2021/12/28(火) 13:40:51.12

cargo updateでマイナーバージョンアップやらせるのも規約決めたり工夫ご必要だし
専用のリポジトリ用意する方がわかりやすくはあるような
crates.io以外にも複数のリポジトリを混在して使えるようにできれば良いのかな

**デフォルトの名無しさん** · 2021/12/28(火) 14:10:43.98

cargoはどこからでも落とせる
crates.ioなみに安全性、信頼性、永続性が確保できるんなら好きにすればいい

**デフォルトの名無しさん** · 2021/12/28(火) 14:45:21.34

永続性を謳うサービスで名前で管理したらそりゃあいい名前の取り合いになるよなあ

**デフォルトの名無しさん** · 2021/12/28(火) 14:48:37.23

>>419
ほんとだ、packageごとにregistry指定できるんだね
https://doc.rust-lang.org/cargo/reference/registries.html

**デフォルトの名無しさん** · 2021/12/28(火) 15:16:22.59

GoみたいにGithubがデファクトスタンダードなレジストリになっても一覧性の面で不便だし、crates.ioでいいと思うけどなあ

**デフォルトの名無しさん** · 2021/12/28(火) 21:31:42.32

セキュリティ監査付きのcrates.ioクローンが欲しい

**デフォルトの名無しさん** · 2021/12/28(火) 21:33:45.43

average()が気になってcratesだかcargoだか話逸らしに聞こえる

**デフォルトの名無しさん** · 2021/12/28(火) 22:07:01.63

ぼぼぼ、ぼくちんのために誰か優秀なaverage()をおながいします

**デフォルトの名無しさん** · 2021/12/28(火) 22:22:38.58

>>423
cargo auditでは足りない？

**デフォルトの名無しさん** · 2022/01/01(土) 09:34:17.63

>>411
「多数あり外部で十分派」なのに>>412には答えられないの？？

**デフォルトの名無しさん** · 2022/01/01(土) 19:34:25.31

Why is my Rust build so slow?

**デフォルトの名無しさん** · 2022/01/01(土) 20:01:31.38

Because your PC is poor spec.

**デフォルトの名無しさん** · 2022/01/01(土) 23:44:42.88

https://fasterthanli.me/articles/why-is-my-rust-build-so-slow
この人の場合クソデカ型のせいでコンパイルが遅かったという話

**デフォルトの名無しさん** · 2022/01/02(日) 10:42:43.84

warpがクソみたいに重いって書いてるな

**デフォルトの名無しさん** · 2022/01/02(日) 11:21:24.79

sccacheとか入れてみるか

**デフォルトの名無しさん** · 2022/01/02(日) 13:52:17.06

当日お急ぎ便でSSDを買った

**デフォルトの名無しさん** · 2022/01/02(日) 14:41:20.14

>>432
bin crateのビルドに時間かかるなら sccache は効果薄いのでは

**デフォルトの名無しさん** · 2022/01/02(日) 14:53:21.62

高度IT人材、富士通は最大年収3500万円へ

「富士通年収3500万！」日本のIT企業の年収も、高額化してきました

AI人材の獲得に超本気　NECが新人事制度を9人に適用、富士通は最大年収3500万円へ

【年収３５００万円も】富士通、「ジョブ型」人事制度を導入幹部社員から高度IT人材

来年度から副業解禁　人材多様化へ―大同生命次期社長

第一生命HD、副業解禁　約1万5000人対象

第一生命ＨＤ、副業解禁　１万５０００人対象―大手生保初

IHI、国内8000人の副業解禁　重厚長大企業も転機

ＩＨＩ、社外兼業を解禁　社内副業もルール化

**デフォルトの名無しさん** · 2022/01/02(日) 21:56:13.39

効率を求め過ぎてモノリシックになりすぎると様々なコストが上昇してしまう
そこで分割
さらに内部もcrate分割で並行コンパイル

**デフォルトの名無しさん** · 2022/01/04(火) 02:27:09.98

Rustでノードが追加されたり消されたりする双方向グラフ扱いたくなったらどうするんだろ
Arenaじゃ追加削除してるうちにゴミがメモリ圧迫していくし

**デフォルトの名無しさん** · 2022/01/04(火) 09:43:25.00

>>437
Cursor使う

Arenaの場合はfree list用意して削除済み要素を再利用すればよい
Arenaが埋まったらreallocするのではなく同じサイズの新たなArenaを獲得していくようにすれば
不要になったArenaから解放できるからmalloc使う場合と同等のメモリ使用量に抑えられるかと
これでも不足するなら copy GC 的に compaction するしかなさそう

**デフォルトの名無しさん** · 2022/01/04(火) 18:15:54.62

>>438
なるほど…… 結構ガッツリ実装しなきゃいけなそうね。ありがとう。最後はGCを実装することになりそうなので、それならいい感じのGCを残しておいてくれたら良かったのにって気になるな

**デフォルトの名無しさん** · 2022/01/04(火) 18:22:33.23

Cursorってなんでしょう？

**デフォルトの名無しさん** · 2022/01/04(火) 19:44:07.16

>>440
これのこと (まだunatable)
https://doc.rust-lang.org/std/collections/linked_list/struct.CursorMut.html

**デフォルトの名無しさん** · 2022/01/04(火) 20:59:48.62

>>439
GCを必要とする用途は非常にレア
だから標準ライブラリには不要だが外部ライブラリに色々あるので大丈夫

**デフォルトの名無しさん** · 2022/01/04(火) 22:15:51.15

>>442
GCのライブラリ使ったことある？実用的だった？

**デフォルトの名無しさん** · 2022/01/04(火) 22:53:03.36

特殊な案件でしかGCを使うことはないため
その場合は汎用GCライブラリ利用よりも
データ構造とアロケーションとGCを密に設計する方がベターかも

**デフォルトの名無しさん** · 2022/01/05(水) 00:28:17.64

ちゃんとしたスマートポインタを自作する時点で結構大変だから用途特化した方が確かによさそう

**デフォルトの名無しさん** · 2022/01/05(水) 01:03:11.75

グラフみたいなデータ構造を実装するだけでも、GCが必要になったりするもんなん？

**デフォルトの名無しさん** · 2022/01/05(水) 01:37:16.98

>>441
ありがとうございます！

**デフォルトの名無しさん** · 2022/01/05(水) 01:46:20.36

グラフ構造表現するだけならArenaや、少し安全にするならGenerationalArenaで事足りるかと
copy GC的なものが必要になるのは大量にノードを作成してほとんど削除、一部残存みたいな状況でfreeできないArenaが残ってしまうケース

**デフォルトの名無しさん** · 2022/01/05(水) 04:00:13.07

ちゃんとしたGCはないのに、参照カウントだけは標準ライブラリに入っていて循環参照には気をつけましょうねーって運用でカバーなのはなんか中途半端なものを感じる
そもそも参照カウントなんてGCとしてはかなりイケてない部類なのになんで参照カウントなんだ気持ちもある

**デフォルトの名無しさん** · 2022/01/05(水) 04:09:37.27

単純にRcやArcはGCを目的としたものではないから