結局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/22(土) 18:20:17.39

京大の数学専攻に行った人知ってるけどまあひどいありさまだよ

中学の担任がまずそれで暴力教師
社会に出てあった人はうつ病で施設を行ったり来たり
もう一人は中退して地元帰ってきてギャンブルにのめりこんで今もパチプロみたいな生活してる

**デフォルトの名無しさん** · 2023/07/22(土) 18:23:18.53

確率計算がさくっとできちゃうからパチプロできるんだったりして

雀士とかいうのも聞いたことあるマンガとかでだけどｗ

**デフォルトの名無しさん** · 2023/07/22(土) 18:38:00.93

一般生活でも自然現象を見て脳内でモデル作って偏微分の境界条件とか気になる人が数学が出来る人

**デフォルトの名無しさん** · 2023/07/22(土) 18:46:30.74

その人たちの共通点は一つ

本人が理不尽だと感じることには絶対妥協しないで最後まで食い下がってくる
狂気を感じた

**デフォルトの名無しさん** · 2023/07/22(土) 20:16:03.51

>>819
わかりやすくて草
この理解でいいね

**デフォルトの名無しさん** · 2023/07/22(土) 20:38:27.64

O記法o記法に無限小は出てこない。

>>816が参照出しているんだから少しは読めよ。

**デフォルトの名無しさん** · 2023/07/22(土) 20:53:08.15

沢山数式暗記してても馬鹿は馬鹿なんだよな

**デフォルトの名無しさん** · 2023/07/22(土) 21:00:51.86

>>817
イヤ厳密に言ったらも何も全く意味が違う
完全に誤解してる

**デフォルトの名無しさん** · 2023/07/22(土) 21:06:42.21

>>818
ぼやけたjpegも圧縮率が高ければ文句言われない
不正確でも短ければ良い
長文は悪い

**デフォルトの名無しさん** · 2023/07/22(土) 21:50:16.59

>> テンプレートは通常、コピーを避けるために const& を使用しますが、これは int のような単純な型を渡すには非効率的な方法です。

な？C++20便利だろ？

**デフォルトの名無しさん** · 2023/07/22(土) 22:36:24.52

計算量でスモールoとか使う場所あるの

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

そういえばJAXAに居たとき使ってたわ

**デフォルトの名無しさん** · 2023/07/22(土) 23:43:43.06

ロケットが失敗続きな理由がなんとなくわかった

**デフォルトの名無しさん** · 2023/07/22(土) 23:47:22.27

俺が辞めたからだろ？

**デフォルトの名無しさん** · 2023/07/23(日) 08:32:47.35

マジレスすれば、いかに優秀でも一人抜けたくらいで…といったところだが、
人材流出ネタを聞くたびに、ひょっとして…と思ってしまう自分が情けない

**デフォルトの名無しさん** · 2023/07/23(日) 09:44:20.13

ロブ・パイクの「プログラミング5カ条」

ルール2：処理速度を測定すること。測定して、コードのある部分が他の部分を圧倒しない限り、速度の調整をしてはいけない。

ルール3：派手なアルゴリズムは、入力値のnが小さいと処理が遅い。そして通常、nは小さい。派手なアルゴリズムは大きな定数を持っている。nが頻繁に大きくなることがないなら、派手なアルゴリズムは使わないようにすること。(nが大きくなっても、まずルール2を適用すること)

https://gigazine.net/news/20200817-rob-pike-5-rules-programming/

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

LinkedListの挿入削除は常にO(1)！だから最強！

草
オーダ記法を最近覚えて得意げに使ってそう
Javaの入門本でもArrayListとLinkedListの使い分けはこういう用途でやりましょうって書いてあるよねｗ

**デフォルトの名無しさん** · 2023/07/23(日) 10:58:23.71

給料もらってるのに辞めるとか、課金してもサービス終了するようでは
フリーソフトに対する優位性がなくなってしまう

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

>>804 の実装で一番早いのは
パスカルの三角形で縦に足して行くやり方の気がする

**デフォルトの名無しさん** · 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にジェネリック無いだろ