結局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/23(日) 11:39:51.12

>>818
CS用語って量子化とかエントロピーとか変に数学とか物理の用語借用してるのがまずいんだよな
全然関係無い概念で混乱する

**デフォルトの名無しさん** · 2023/07/23(日) 11:43:20.98

クライマックスシリーズはまだはやい

**デフォルトの名無しさん** · 2023/07/23(日) 11:48:32.16

>>832
>>832
打ち上げの動画で今のロケット責任者の頭抱えてる姿観るとあれじゃだめ感

**デフォルトの名無しさん** · 2023/07/23(日) 11:49:16.91

>>834 だった

**デフォルトの名無しさん** · 2023/07/23(日) 11:51:24.56

>>836
挿入削除だけで参照も検索もしないなら高速だね
四次元ポケット欲しいな

**デフォルトの名無しさん** · 2023/07/23(日) 12:06:43.78

>>838
ネタなのかマジなのか分からんけど高速な実装を考える前に
とりあえず(1+a)^nを展開して両辺のaに1を代入してみよう

**デフォルトの名無しさん** · 2023/07/23(日) 14:11:34.49

Rustは、コンパイル速度が遅いと言う噂があるが、
VC++(msvc、precompiled header利用時)と比べると
どうなんだ。

**デフォルトの名無しさん** · 2023/07/23(日) 14:12:51.60

コンパイル速度は、本を見てるだけでは分からない事
の一つだな。そして大規模開発には物凄く重要となる。

**デフォルトの名無しさん** · 2023/07/23(日) 15:04:02.22

さすがにそこは、clangと比べるべきでは

**デフォルトの名無しさん** · 2023/07/23(日) 15:47:54.37

>>844
それがどうかしましたか？

**デフォルトの名無しさん** · 2023/07/23(日) 15:55:24.23

let hoge = "a";
println!("{:2}後ろ",hoge);
let hoge = "あ";
println!("{:2}後ろ",hoge);
表示幅を揃えたいのですが上のやり方だと
後者の｢あ｣と｢後ろ｣の間にスペース１文字入ってしまいます
hogeに｢あ｣か｢a｣かどちらが入るか不定の時
どうするのが定石？

**デフォルトの名無しさん** · 2023/07/23(日) 16:38:44.72

traitを作る
とりあえず定石無視でimplする

**デフォルトの名無しさん** · 2023/07/23(日) 16:40:47.70

>>849
unicode_widthとかで表示幅を求めて調整する
調整したい文字列集合の最大値ベースの調整だけでいいか
1行で表示したい最大長ベースの調整も必要かは用途次第

**デフォルトの名無しさん** · 2023/07/23(日) 18:04:59.73

メモリ安全性は大規模開発時に有利に働く特徴なのだが、
コンパイル速度の遅さなど、Rustにはそれとは逆の特徴も
持っており、ややこしいぞ。

**デフォルトの名無しさん** · 2023/07/23(日) 21:22:05.78

幅曖昧問題は指定するしかない
https://www.unicode.org/reports/tr11/images/tr11.h1.jpg
https://www.unicode.org/reports/tr11/images/tr11.h2.jpg

**デフォルトの名無しさん** · 2023/07/23(日) 22:53:08.93

コストカットに取り憑かれたら
文字列cloneしてスペースを付け足して返すコストも
許可がないと支払えない人間になったりして
知らんけど

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

C++だと、ライブラリが大きくなってもコンパイル速度が
遅くなることは無い。異常に大きくなった場合には
リンク速度が遅くなることが有る程度だが、通常は
遅さを感じることが無い程度に留まる。
Rustだと、crateが大きくなったりcrateの個数が増えると
コンパイルが遅くなったりするの？

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

ブラウザにはJSがあるから
C++やRustのコード修正と再コンパイルをすることなくJSのコードを修正すればいい
これが大規模開発ではないというなら小規模で十分

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

どうやろ？
コンパイラの暗黙の了解でサイズに対して処理は線形にならなければならないというのがある
流石にその範囲ではあるんじゃないの？
ただ線形は線形でも係数がでかいんかな
それだけならコンピュータが早くなれば体感的には改善していくはず

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

Rustのcratesの依存関係でcargoが予期せぬものをいっぱいダウンロードするから
遅い回線だと(一回目の)コンパイル(というかコンパイルの準備)は超遅くなる

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

デフォルトが全部静的リンクだからそれが遅いのもある

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

>>858
その「遅い回線」って何?

**デフォルトの名無しさん** · 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型なんて限られているので全部明示的インスタンス化しておけば
ビルド時間は短縮できる