結局C++とRustってどっちが良いの？ 5traits

**デフォルトの名無しさん** · 2023/06/30(金) 21:56:35.52

「C++の色々配慮してめんどくさい感じは好きだけど、実務になったらメモリ安全性とか考えて今後Rustに変わっていくんかな」
「うだうだ言ってないで仕事で必要なのをやればいいんだよ、趣味なら好きなのやればいい」

っていう雑談スレ。

結局C++とRustってどっちが良いの？ 4traits
https://mevius.5ch.net/test/read.cgi/tech/1686046386/

関連スレ(マ板): Google&MS「バグの70%はC/C++。Rustにする」
https://medaka.5ch.net/test/read.cgi/prog/1619943288/

**デフォルトの名無しさん** · 2023/07/24(月) 13:30:21.48

>>860
時間帯によっては遅いことがある。
技術や能力の差ではなく、お金持ちかどうかで出来ることが
違ってくるのはおかしい社会。

**デフォルトの名無しさん** · 2023/07/24(月) 13:34:38.77

>>861
>技術や能力の差ではなく、お金持ちかどうかで出来ることが
>違ってくるのはおかしい社会。
お前それ左翼の発想そのものじゃねーかwww

**デフォルトの名無しさん** · 2023/07/24(月) 13:36:23.66

通信インフラってのは
ソフトウェアの複製がゼロコストなのと違って
コストが掛かるんだよ

**デフォルトの名無しさん** · 2023/07/24(月) 13:39:12.35

>>862
左翼は能力の差まで無視しようとするで。

**デフォルトの名無しさん** · 2023/07/24(月) 13:51:35.63

>>864
典型的にはいわゆる「優秀」な人を
民意を無視して登用するシステムと理解しているが?
政治家として優秀かはさておき
日本でも共産党って学歴偏重でしょ?

**デフォルトの名無しさん** · 2023/07/24(月) 13:59:42.61

自分用には、そこそこ全体がコンパクトな方が好きかなあ

仕事用には、回線も装置も会社のものだから兎も角なんだが

**デフォルトの名無しさん** · 2023/07/24(月) 14:04:31.32

「コンパイル速度が遅い」という噂が立ってるんですが、
実際は、crateのダウンロード速度が遅い、ということなんですか？

**デフォルトの名無しさん** · 2023/07/24(月) 14:05:59.45

>>865
明らかに能力の無い女性を、最も能力の高い男性しか
就けない役職に無理やり入り込ませようとするのも
左翼なんだけど。

**デフォルトの名無しさん** · 2023/07/24(月) 14:07:33.73

>>868
例えば? 煽りではなく

**デフォルトの名無しさん** · 2023/07/24(月) 15:00:19.41

イヤちゃうやろ
流石にそれはコンパイラの作業量が純粋に多いから遅いでしょ
そりゃC++と比べて早くなるわけない
チェックしてる事多いんだから

**デフォルトの名無しさん** · 2023/07/24(月) 15:30:37.55

>>861
それはプログラム板で主張することじゃないやろ

**デフォルトの名無しさん** · 2023/07/24(月) 16:03:16.33

C++派だが、C++もたいがい遅いだろ
pchとか使うのが習慣化してるけど

そういや、結構前からmoduleってのが使えるけど、きちんと使ったことないな。。

**デフォルトの名無しさん** · 2023/07/24(月) 17:44:58.93

>>869
能力が低い女性を政治的圧力で無理やり色々な場所に
押し込んできたから日本はこんなにめちゃくちゃに
なってるのに。

**デフォルトの名無しさん** · 2023/07/24(月) 18:20:23.66

10人必要っぽい場所に20人投入すればいいのに
10人投入してめちゃくちゃになってから10人追加するやつって何なの？
戦力の逐次投入なの？

**デフォルトの名無しさん** · 2023/07/24(月) 18:51:49.12

>>873
何の話だ?
ちゃんとスレを遡って文脈を把握してから書いてくれ

**デフォルトの名無しさん** · 2023/07/24(月) 21:47:00.51

>>874
20人必要そうなら最初から20人要求しろよ。

10人で合意しているのに20人にして予算倍増させた責任は誰が取るんだよ。

**デフォルトの名無しさん** · 2023/07/24(月) 22:22:14.29

自己責任ってあれほど言ったのに
自己とは誰なのか
誰も知らないんだよな

**デフォルトの名無しさん** · 2023/07/25(火) 01:43:34.89

多次元配列のライブラリの演算スピードがまだnumpyより倍くらい遅い。また、速くできる要素は利便性の観点から悩ましい。rayonを使えばnumpyの倍速くらいにはできるようになった。

**デフォルトの名無しさん** · 2023/07/25(火) 03:35:47.01

>>878
それはライブラリを改良すれば今後良くなっていくだろう問題
なので、余り気にすることは無い。
それより、今後も改善しにくい問題のほうが問題。
Rustにも色々な問題が有るようだ。

**デフォルトの名無しさん** · 2023/07/25(火) 08:41:35.71

スピードが必要な部分だけRustを使わないようにすれば解決

**デフォルトの名無しさん** · 2023/07/25(火) 08:54:51.87

そういえば君らのメモリ管理の会話でLinkedListの使い道思い出したわ
Rustやその他の言語側じゃなくてOS側のメモリ管理にLinkedList使われてるわ

**デフォルトの名無しさん** · 2023/07/25(火) 09:01:07.57

>>874
デスマは人数増やしても解決しない
ステマは露出増やすと賞賛される

**デフォルトの名無しさん** · 2023/07/25(火) 09:02:56.16

>>880
unsafe {} 便利ですね判ります

**デフォルトの名無しさん** · 2023/07/25(火) 09:03:45.28

まぁ調べてみると確かに行列配列系の計算は“生rust”だと難しいんやろな
でかいデータを高速に捌くには“参照”をうまく使いこなしてなるべく“コピー”の回数を減らすくらいしかアルゴリズムの改善は見込めない
しかしrustは安全性の観点からC++のそれより所有権、生存期間の抽象度、制約を一段引き上げてる
だからそれでも速度が欲しいならunsafeで囲って危ない橋を渡るしかない、実際rcとかarcのソース読むとundafeだらけやしな
逆に言うとユーザーがその“危ない橋”を渡らなくても済むようにライブラリがあるとも言える

**デフォルトの名無しさん** · 2023/07/25(火) 13:32:44.33

>>884
ArcやRcは使用はやめた。マルチスレッド化の時にだるいことが多いから。仕方ないのでreshapeメソッドとかでは配列をクローンすることにした。

**デフォルトの名無しさん** · 2023/07/25(火) 13:34:21.22

あと、行列の計算とかでループのスピードを速くするために次元はconst N: usizeを使ってる。

**デフォルトの名無しさん** · 2023/07/25(火) 13:51:24.76

海外のサイトを見ていたら、Rustは、インクリメンタル
ビルドが遅いらしい。だから、ソースを細かく分けすぎると
遅くなるのかも知れない。しかし、ビルドの高速化の
ために発明されたのがインクリメンタルビルドだった
のだから、本末転倒の厄介な問題だ。
なんでも、リンクに10秒くらいかかるのだとか。
ある人によれば一時間くらいかかったと言う。

**デフォルトの名無しさん** · 2023/07/25(火) 13:53:33.03

>>887
crateの初回使用の時にフルコンパイルされる
ので遅いのは、それはそれで困るが、ギリギリセーフ
だとしても、それ以上に厄介なのは、自分のソースを
少しいじってビルドしなおしても、リンクはどうしても
必要だから、そこで10秒もかかってしまっては
開発は非常にストレスがかかってしまうことだ。

**デフォルトの名無しさん** · 2023/07/25(火) 13:58:22.63

中くらいの大きさのプロジェクトで、
structの中の一行を変えるだけで、5分かかって
困っていると言う報告も見つけた。

**デフォルトの名無しさん** · 2023/07/25(火) 14:00:01.53

>>888
リンカーは共通だろうからC/C++と差はないと思うのだが?

**デフォルトの名無しさん** · 2023/07/25(火) 14:15:10.14

https://www.reddit.com/r/rust/comments/11vrzme/help_me_love_rust_compilation_time/

Hey all, I've been writing software for about 15 years, Started from VB, .NET (C#), Java, C++, JS (Node), Scala and Go.

I've been hearing about how Rust is great from everyone ! But when I started learning it one thing drove me nuts: compilation time.

Compared to Go (my main language today) I find myself waiting and waiting for the compilation to end.

If you take any medium sized OSS project and compile once, it takes ages for the first time (3,4 minutes, up to 10 !) but even if I change one character in a string it can still take around a minute.

**デフォルトの名無しさん** · 2023/07/25(火) 14:31:37.57

cargo 使ってるときに rust にリンカオプション教える方法教えて

**デフォルトの名無しさん** · 2023/07/25(火) 14:32:50.71

海外のサイトを見ていて考えられる要因の候補
・マクロの使いすぎ。Rustのマクロは乱用すると遅いらしい。
・メモリー不足で仮想記憶が働いてしまっている？

**デフォルトの名無しさん** · 2023/07/25(火) 14:37:55.45

Rustは、ファイル単位でなく crate 単位でコンパイルするらしい。
だから、あるソースファイルの1行を直してもcrate全体の
コンパイル時間が必要となる。
C++が、ファイル単位でコンパイルするのと対照的となる。

Q: Does Rust compile fast?
A: For incremental builds, Rust will take longer to compile
than C++ (i.e. C++ wins).
This is because Rust compiles one crate at a time,
rather than one file at a time like in C++,
so Rust has to look at more code after each small change.
Jan 5, 2023

**デフォルトの名無しさん** · 2023/07/25(火) 14:41:52.08

でcrateってのは複数ファイルに跨ることが多いわけ?
それとも1ファイルに複数のcrateが実装されることが多いわけ?

**デフォルトの名無しさん** · 2023/07/25(火) 14:49:22.82

>>895
前者だろう。

**デフォルトの名無しさん** · 2023/07/25(火) 14:54:39.48

>>896
なるほどー
で触ってないファイルもコンパイルし直すのでクソだって話ね
直せるのでは? 少なくともC/C++の水準には出来るはず

**デフォルトの名無しさん** · 2023/07/25(火) 14:55:34.04

create の document の comment coverage てやっぱり判りにくいな

**デフォルトの名無しさん** · 2023/07/25(火) 17:54:05.55

Rustもまだまだだなー

Rustを始めるにはまだ早いな(時期が悪いおじさん式

**デフォルトの名無しさん** · 2023/07/25(火) 18:01:39.24

incremental buildはcodegen unit単位
開発者が明示的にリビルドを指示できるのはcrate単位

incremental buildなら変更が不要なcodegen unitはリビルドされない
codegen unitは1モジュールで2つ(non-genericとgeneric)
デフォルトでは1crateにつきcodegen unitの上限は256なのでそれを超えるようならマージされる

モジュール単位なのでファイル単位よりも細かい

**デフォルトの名無しさん** · 2023/07/25(火) 19:11:44.72

難しいね。

**デフォルトの名無しさん** · 2023/07/25(火) 23:14:21.10

Cの (shared) objectファイルには型情報がない
というかアセンブラの出力と同じ形式にしないとアセンブラを使いにくい
型を無視すればリンクが速い

ヘッダファイルを厳密に管理し、なおかつヘッダを変更しまくれば
C++やRustと似たような遅さになるかもね

**デフォルトの名無しさん** · 2023/07/26(水) 03:55:53.44

ああだから良く判らないcratesが乱立してるのか
cratesに分割すればするほど効率は上がる
crates.ioは氾濫して収拾付かなくなる

**デフォルトの名無しさん** · 2023/07/26(水) 12:19:34.24

>>902
C++はRustほど遅くない

**デフォルトの名無しさん** · 2023/07/26(水) 14:36:33.56

cast するにも int x から (long long)x でコンパイルされるのと
x: i32 から x as i64 でコンパイルされるのと天と地ほどの時間差がありそう

**デフォルトの名無しさん** · 2023/07/26(水) 18:02:28.67

コンパイル時間かかるのは多相型から単相型を導出するとこじゃないの？

**デフォルトの名無しさん** · 2023/07/26(水) 18:32:17.02

rust好きだけどJS/TSエコシステム並みにcrateの粒度が小さいのはちょっと厳しいよな。
apacheみたいなのに集約するのはもう時代じゃないんだろうけどさ。

**デフォルトの名無しさん** · 2023/07/26(水) 18:57:07.57

いつのまにかWindowsでAndroidアプリが動くようになってる
これは便利

**デフォルトの名無しさん** · 2023/07/26(水) 20:27:27.27

>>906
Foo<Bar>がn回導出されたらコンパイル時間がn倍になるかどうか
Foo<Bar>とFoo<Baz>が導出されたらBar==Bazの判定にどれだけ時間がかかるか

**デフォルトの名無しさん** · 2023/07/27(木) 00:57:46.43

型パラメータの候補が複数見つかったらすぐに諦めて競合エラー吐いてる印象
cargo checkだけだと割と軽いからジェネリクスの実体化（コード生成）が重いのかもしれない
型ごとに使ってる処理を割り出して必要な分だけ生成してそうだし

**デフォルトの名無しさん** · 2023/07/27(木) 02:10:00.11

>>907
私はnumpy並みにデカいパッケージを作ろうと思ってますよ。

**デフォルトの名無しさん** · 2023/07/27(木) 08:24:40.27

>>909
ウソかホントか知らんけど上の方の話だとRustのコンパイルが遅いのはファイル跨ぎの再コンパイルをやらされるからとか
なぜファイル跨ぎの再コンパイルが多発するかといえばやはり多相性の問題じゃないの？
posix系のアーカイバは分割コンパイルを可能とするために関数呼び出しの方法を標準化してる、すなわち呼び出し引数の数と種類が与えられた時、その引数を関数側のローカルスタックに順にセットして呼び出す、そのルールがわかっていれば呼び出し側、呼び出され側は引数の種類と順番がわかっていれば分割してコンパイルできる、たとえはCだとそれを実現するために呼び出し側は関数側の内容全部をしらなくてもよいが引数の種類だけはコンパイラに教えないといけない、それがプロトタイプ宣言
ところが多相型を利用する言語では呼び出し側と呼び出され側の内容が相が多相型だとposix標準ではリンクの方法が定められてないからこのシステムを使う事ができない
なのでHaskellではファイルにまたがる最上位の多相型は明示しないと行けない、明示しない物はコンパイラが勝手に単相化すると言う単相制限(monomorphism restriction)をつけて対処する
一方でRustはその手の制限は設けない、好きにやれと言う立場で単相型決定に必要な“型方程式”に関わるものがファイルを跨いで巨大化する事を禁止しない、その代わりコンパイルが遅くなるのは我慢しろと言う立場なんでしょ？

**デフォルトの名無しさん** · 2023/07/27(木) 08:30:54.30

>>912
Rustはライブラリとかのバージョン管理を徹底しているからでない？実際、すべてのライブラリのバージョンはCargo.tomlに明記されてるし、rustのエディションもここに明記されてる。この結果コードの一部を変えただけでもまずCargo.tomlの中身に変更がないかコンパイラが見ないといけない。その後、Cargo.tomlに記載されたライブラリを使ってるすべてののファイルのライブラリ使用に関してチェックしないといけなくなり、これによって少しの変更でもクレート全体の再コンパイルに繋がっているのでは？

**デフォルトの名無しさん** · 2023/07/27(木) 08:54:12.15

>>912
Nimはもっと良いぞ

**デフォルトの名無しさん** · 2023/07/27(木) 08:54:59.21

>>913
イヤ、ライブラリのタイムスタンプが違えばとかいうのはCでもC++でも同じ、それで言語間の差はない
C,C++とRust,Monomorphism restriction外したHaskellに差があってコンパイル上の、特に分割コンパイル絡みの差がどこで出てるかの話なんだから

**デフォルトの名無しさん** · 2023/07/27(木) 08:57:49.70

GC無し最速動作のできないNimは論外でスレ対象外

**デフォルトの名無しさん** · 2023/07/27(木) 09:05:43.60

一例はお題スレで出てた答え
https://itest.5ch.net/mevius/test/read.cgi/tech/1668333636/969

このfooという関数の型はこのソースだけでは決定できない
呼び出した側がvec<i8>とかvec<i32>とか呼び出した側の要求に応じて初めて単相型が決まる、その時点で初めてスタックに何がどんな順番で積まれるのかが決まる
なのでこの場合posix標準のライブラリ管理の方式では呼び出し側と呼び出され側を別々に分割コンパイルできない

抜粋　(全角スペース使用)
fn foo(input: u32) -> impl Iterator<Item = u32> {
　let table: Vec<u32> = bits_iter(input)
　　.map(|p| 1 << p)
　　.collect();
　(0..(1 << table.len())).map(move |bits| {
　　bits_iter(bits)
　　　.map(|p| table[p as usize])
　　　.sum()
　})
}

**デフォルトの名無しさん** · 2023/07/27(木) 09:12:08.48

おっと、この例は中身はu32固定だったな
多相性はiteratorのところだった
まぁ本質同じ、呼び出され側が多相型の場合、呼び出し側の要求と折り合いをどこでつけるのか決定するには両方のソースの型情報が必要、そしてこのような多相型の標準化はposixのライブラリシステムにはない

**デフォルトの名無しさん** · 2023/07/27(木) 09:14:53.79

>>917
そのfooにジェネリック無いだろ

**デフォルトの名無しさん** · 2023/07/27(木) 09:28:11.91

>>918
そのIteratorにも多相性はない
型は確定している

**デフォルトの名無しさん** · 2023/07/27(木) 09:48:28.92

>>917-918
ωωω

**デフォルトの名無しさん** · 2023/07/27(木) 10:03:28.53

>>916
分割コンパイルの効率を考えるのにGCあるなしは関係ない
勝手に対象から外すな

**デフォルトの名無しさん** · 2023/07/27(木) 10:12:31.52

>>917
C++のtemplateだとヘッダに実装を全て書けば同じ問題が生じることになるが
明示的実体化することでこの問題は避けられる

**デフォルトの名無しさん** · 2023/07/27(木) 10:26:22.29

だからu32のとこ読み替えてって言ってるやん

**デフォルトの名無しさん** · 2023/07/27(木) 10:32:44.98

アレ？
rust の impl trait が返り値に指定されてるのは多相型じゃなかった？
Haskellの

( Num A ) -> [ A ]

とかの糖衣表現でしょ？
上のはstd::iter::Iteratorのtraitのインスタンスは全部取れるんじゃないの？

**デフォルトの名無しさん** · 2023/07/27(木) 10:40:56.55

>>923
そう、この問題を従来のposixのライブラリ管理で無理クリ実現するには関数側が提供できる可能性のある多相型をあらかじめ“全部”用意しといてlinkerが適切な関数を選んでも使うくらいしかない
まあしかしそんな事実際不可能
結局多相型が別ファイルにまたがる場合全ファイルの提供側の多相型と右辺値で現れる制限との型方程式を全部集めて解くしかない
おそらく将来的にはML型の多相型を使う言語全体で多相型の型を分割コンパイルが自由にできるようになるには言語を跨って多相型のインターフェースの規格なりなんなりが定まってこないと無理
当面それは難しいからHaskellはデフォルトで使用禁止、Rustは遅いの我慢しろにしてるんやろ

**デフォルトの名無しさん** · 2023/07/27(木) 10:58:53.97

>>925
引数のimpl traitはその関数にとってどんな具体型がやってくるかわからないから多相であり具体型ごとに単相化される
返すimpl traitはその関数にとって具体型が確定しているから多相ではない

**デフォルトの名無しさん** · 2023/07/27(木) 11:13:06.60

>>927
上の例だと返り値は確定してるんですか？
返り値はItem=u32のiterator型なら何でも取れるのでは？
vec<u32>でもLinkedList<u32>でも
呼び出し側の注釈でas vec![u32]なり何なりでいくらでも返り値変えられるのでは？

**デフォルトの名無しさん** · 2023/07/27(木) 11:18:43.07

Item = u32であるIterator traitのインスタンスね
上の例は返り値がItem=u32のiterator traitを持つ任意の型を返り値にとれる
じゃないの？

**デフォルトの名無しさん** · 2023/07/27(木) 12:01:34.76

collect correctly

**デフォルトの名無しさん** · 2023/07/27(木) 12:03:41.01

関数の戻り値が
(0..(1 << table.len()).map(...)
だから戻り値の型はMap<Range<usize>, F<Output = u32>>
（Fはラムダ式の型でコードでは表現できない）
これをimpl Iterator<Item = u32>で代替表記してる

関数の戻り値を変えれば別の型にもできるけど
関数内で分岐して複数通りのIterator実装型を返すのはimpl traitでは無理なはず

**デフォルトの名無しさん** · 2023/07/27(木) 12:04:36.92

>>929
その通り
しかし関数が返す型はその関数にジェネリックパラメータがないなら常に具体的な型が確定していて多相ではない
今回の>>917のfooならrangeに適用のmap()を返しているからstd::iter::Map型

**デフォルトの名無しさん** · 2023/07/27(木) 12:08:33.21

>>931
同じことを被った乙
関数内で分岐しても別の型を返すなら返し型を静的なimpl traitにできず動的なdyn traitになる

**デフォルトの名無しさん** · 2023/07/27(木) 12:15:53.12

でも確かに昔のweb情報見てるとできないって書いてるページあるけど

----
impl Traitは異なる型を返せない

impl Traitは静的ディスパッチなので異なる型を返すことはできません。このコードはコンパイルエラーになります。

fn foo(x: u32) -> impl Iterator<Item=u32> {
if x == 0 {
Some(0).into_iter()
} else {
0..x
}
}
----
https://qiita.com/taiki-e/items/39688f6c86b919988222より

しかし実際上の例ではコンパイル通ってるのでは？

**デフォルトの名無しさん** · 2023/07/27(木) 12:19:18.73

具体的に上の例ではIterator<item = u32>は何か単相型に決まってしまうんですか？
[u32]とかvec<u32>とか勝手にコンパイラが決めてしまうんですか？
それ以外の型で使おうとしたらコンパイルできないの？
ホント？

**デフォルトの名無しさん** · 2023/07/27(木) 12:45:27.87

Haskellの例だと下のコードは通ります

https://ideone.com/VQHxZ9

sqTo100 :: ( Enum a, Num a ) => [ a ]
sqTo100 = [ n^2 | n<-[1..10]]

main = do
print $ ( sqTo100 :: [ Int] )
print $ ( sqTo100 :: [ Float] )

5行目ではsqTo100は[Int]型を返す関数として、6行目では[Float]型を返す関数として“臨機応変に”使い分けてくれます
ただしこのような“多相型を返す関数”はPosix標準のLinkerが準拠していないのでHaskellではファイル毎という制限がありますけど
(monomorphism restriction)
rustではできないんですか？

**デフォルトの名無しさん** · 2023/07/27(木) 12:47:44.86

複おじの好きそうな話題
よかったな

**デフォルトの名無しさん** · 2023/07/27(木) 14:12:15.53

>>926
>まあしかしそんな事実際不可能
不可能でない場合も結構多いけども? C++で話をすると
templateパラメータでPOD型しか取り得ない場合は結構ある
POD型なんて限られているので全部明示的インスタンス化しておけば
ビルド時間は短縮できる

**デフォルトの名無しさん** · 2023/07/27(木) 14:38:15.87

>>935
impl Traitはargument positionの場合はgenericと同じだけど
return positionの場合は呼び出し内容によって実装が変わるわけではないのでmonomorphizeされる

>>917の例だとMap<Range<u32>, closure>
closureはFnMut(u32) -> u32に近いもの

**デフォルトの名無しさん** · 2023/07/27(木) 14:56:22.32

思いっきりガイシュツやった
なんで同じこと何回も聞いてるんだよ

**デフォルトの名無しさん** · 2023/07/27(木) 21:42:00.32

>>935
関数の戻り型は未定のgeneric parameterを含まなければその関数のコードにより型が一つに定まっている
そしてIteratorは型ではなくtraitなので具体的なtrait実装型が関数のコードにより定まっている

一方で具体的なtrait実装型の中でもparameterとして他の型が含まれると記述が長く指定も面倒になってくる
例えば型parameterに入る他の型にも型parameterが付いて多段になることもよかある
コンパイラはそれらの複雑な指定の具体型を推論で確定できるが人間が記述するのは面倒で可読性も悪い
そのため具体型ではなくimpl traitと具象型を書くことで記述性と可読性を向上できる

**デフォルトの名無しさん** · 2023/07/27(木) 21:43:40.45

クロージャは具体型を書くことができない
各クロージャは全て異なる型が自動付与されるがコード上でそれを記述する方法がないためだ
その場合を具象型としてimpl Fn/FnMut/FnOnceを指定できる

**デフォルトの名無しさん** · 2023/07/27(木) 23:16:49.96

すいません
全然わかりません
結局Rustでは>>936のような多相型の返り値を返す関数はかけないんですか？

**デフォルトの名無しさん** · 2023/07/27(木) 23:27:43.84

単にジェネリック使えばいいだけだろ
Haskellやっててここまで頭悪いやつ見たの初めてだわ

**デフォルトの名無しさん** · 2023/07/28(金) 09:03:31.47

このスレは、Rust嫌いな人も集まるスレなんだぞ。
そして、Rustの欠点を書いているのは改良してもらいたいから
ではなく、Rustに退場してもらいたいからだ。

**デフォルトの名無しさん** · 2023/07/28(金) 10:46:00.43

そ、うそだったのか

**デフォルトの名無しさん** · 2023/07/28(金) 13:34:05.05

>>944
イヤ、上の方で「Rustの返り値にimpl traitをとった場合それがジェネリックにならない理由」を述べてる人いるやん？
それが関数返り値に多相型を取れない理由になるならRustの関数返り値は常に単相型になってしまう、でもそんな事ないでしょつて言ってるんですよ
ともかくRustの説明てそういう理屈に合わない説明をする人かなりいるから困るんですよ
頭わるいのは認めますよ

頭わ悪くてすいません

**デフォルトの名無しさん** · 2023/07/28(金) 13:45:48.26

すいません
結論としてRustでは>>936のような「呼び出し側の都合に合わせて返し値を返す関数」は型変数使って書けば書けるけどimpl traitの書式だと書けない、理由は仕様、でいいんですか？

**デフォルトの名無しさん** · 2023/07/28(金) 13:57:57.50

総称型と部分型をどっちも単に多相って呼んでるから訳分からなくなってるんでは？

**デフォルトの名無しさん** · 2023/07/28(金) 14:02:06.50

>>949
それかもしれません
説明していただけますか？
Haskellの多相型にはそんな区別はないと思います
それはRustで定義された用語ですか？

**デフォルトの名無しさん** · 2023/07/28(金) 14:07:57.62

>>950
やだよ
TaPL読んでろ

**デフォルトの名無しさん** · 2023/07/28(金) 14:10:58.16

impl traitの中にgenericsの型パラメータ含めればいい
936をRustで実装すると↓みたいになる
（RustにはEnumクラスもNumクラスもないからFrom<u8>で代用してる）

fn iter_sq_to_100<T>() -> impl Iterator<Item = T>
where
T: Copy + From<u8> + std::ops::Mul<Output = T>,
{
(1u8..=10u8).map(|v| {
let t = T::from(v);
t * t
})
}

fn main() {
// 戻り値を受け取る側からTの型を指定
println!("{:?}", iter_sq_to_100().collect::<Vec<u32>>());
println!("{:?}", iter_sq_to_100().collect::<Vec<f32>>());

// 関数を呼び出す側からTの型を指定
println!("{:?}", iter_sq_to_100::<u32>().collect::<Vec<_>>());
println!("{:?}", iter_sq_to_100::<f32>().collect::<Vec<_>>());
}

ただしこれは型パラメータで戻り値が多相的になってるだけでimpl traitでそうなってるわけではない
多相型もジェネリクスも一緒だと思うけどHaskellとの対比だとクラスをBoundに置き換えればいいのかな

**デフォルトの名無しさん** · 2023/07/28(金) 14:40:11.65

>>952
すいません、やっぱりわたしの疑問とは違っています
わたしの理解では「impl traitは引数、返り値に一般型をとるが特定のtrait 境界を持つものを指定する場合の糖衣構文」だと思っていたのです
つまり先の例impl Iterator<Item = u32>であれば
①まず

　fn myF(××) -> impl T {...}

の記法でTはtypeではなくてtraitである(ここにtraitが来る事が impl trait 記法の呼び名の理由、この記法は

fn myF(××) -> impl A, where A;T{...}

の糖衣構文で「myFはtrait Tのimplementを持つ任意の型を返す関数」を意味する
と思っていて、よって先の例
fn foo1(input: u32) -> impl Iterator<Item = u32> {...
ではfooはItemがu32であるIterator traitを持つ任意の型を返り値として持てる関数だと思っていました、もちろん自分で好きなクロージャ作ってそれにIterator<Item = u32>をimplementすればそれを返り値に持てると思っているんです
しかしそれは違う、fooは単相型、型は決定しており返り値のサイズも配置も決定しているので分割コンパイルできる(そもそも分割コンパイルの話の中で出てきた話なのでここでの多層性はもちろんこの意味)というツッコミが入ったのでホントかと、もうこのソースでRustはfooの返り値の型を完全に決定してて別のファイルからfooを呼ぶ場合にも別々にコンパイルしてposixの標準のリンカが使えるのかなんてことができるのかと
少なくともHaskellではできないはずです

**デフォルトの名無しさん** · 2023/07/28(金) 15:00:21.91

少なくともfooを呼ぶ側はfooの実装とリンクされるまで
返されるimpl traitのサイズも実際の型も分からないから
完全に分割コンパイルが可能とは言えないね
型が分からないと呼ぶべき関数の実装も分からないから標準(?)のリンカは使えない
traitを実装しててその関数が存在することだけは分かるけど

ただfooの戻り値のimpl traitの型は（型パラメータがなければ）
fooの実装側で完全に決定される
「正体が分からない単相型」って感じ

**デフォルトの名無しさん** · 2023/07/28(金) 15:13:12.73

リンク時に外から型サイズを指定できるオブジェクト形式だと頑張れば分割コンパイル可能なのかな
あまりこの辺は知識がない

**デフォルトの名無しさん** · 2023/07/28(金) 15:26:38.94

なんかよう分からないけど、この数日のスレ見てても
imp,trait,whereなど知らない概念が多すぎてRustは難しすぎる。

**デフォルトの名無しさん** · 2023/07/28(金) 15:55:11.46

>>953
間違った思い込みをしてる
まずは公式ドキュメントを読みましょう
https://doc.rust-lang.org/reference/types/impl-trait.html

**デフォルトの名無しさん** · 2023/07/28(金) 16:22:37.19

>>957
間違ってますか？
結論的に
impl Iterator<Item = u32>
を返り値として持つ関数をFile Aで定義して事前コンパイル、その後File Bで独自のIterator <u32> のinstanceを持つ型を作った場合、rust compilorはcompile済みのfile Aをlinkするだけでいいんですか？

**デフォルトの名無しさん** · 2023/07/28(金) 16:33:53.87

具体的にはどうするんですか？
file AにはItemとしてどんなサイズの型を指定されるかわからないわけですけどcompilorは各引数を受け取る時スタックのどこに第××引数が格納されてると決定できるんですか？
昔のweb情報では「impl traitが静的にアクセスするアドレスを決定できるように多相な型にするには oxで囲まないとダメ」とありました
Boxedである事を要請すれば確かに事前にアドレスを決定できます
しかし先の例ではBoxedてないので呼び出し側が要求する返り値のサイズが決まっていなければ生でスタックに並べられたら呼ばれた関数は引数を読み出せないんじゃないですか？
もちろん動的に呼び出す時に引数のサイズ与えればできますけどRustはアクセスすべきアドレスをコンパイル時に静的に決定してるんじゃないんですか？

**デフォルトの名無しさん** · 2023/07/28(金) 16:45:41.21

関数の返し型を具体的に書くかimpl Traitと書くかの違いはもちろん明瞭にある
簡単な例で説明する

// まず実験用のおもちゃ(5ずつ増えるイテレータStepFive)を用意
pub struct StepFive { n: i64 }
impl StepFive {
　fn new(init: i64) -> Self { StepFive { n: init } }
　pub fn cur_value(&self) -> i64 { self.n } // 注意: イテレータには不要な追加機能
}
impl Iterator for StepFive {
　type Item = i64;
　fn next(&mut self) -> Option<Self::Item> { self.n += 5; Some(self.n) }
}

// このおもちゃイテレータを返す関数を二つ用意する
// 返し型を具体的に StepFive と書くケース
pub fn step_five_1(init: i64) -> StepFive { StepFive::new(init) }
// 返し型を impl Trait の形で書くケース
pub fn step_five_2(init: i64) -> impl Iterator<Item = i64> { StepFive::new(init) }

fn main() {
　// イテレータとしてはどちらも当然機能する
　assert_eq!(vec![5, 10, 15], step_five_1(0).take(3).collect::<Vec<_>>());
　assert_eq!(vec![5, 10, 15], step_five_2(0).take(3).collect::<Vec<_>>());

　// しかしイテレータにない機能を使うと違いが明瞭に出る
　assert_eq!(123, step_five_1(123).cur_value()); // コンパイル通る
　assert_eq!(123, step_five_2(123).cur_value()); // コンパイルエラー method not found in `impl Iterator<Item = i64>`
}