結局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/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>`
}

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

>>960の続き

つまり返し型を具体的に StepFive と書けばその型の機能をフルに活用できる
しかし返し型を impl Iterator<Item = i64> と書けばイテレータとしての機能のみが使える

後者はコンパイル時に StepFive の実装を知る必要がなくなる
つまり後者は next() で Option<i64> が返るという「impl Iterator<Item = i64>」の一般的知識のみでコンパイルできることになる
その代わり後者は StepFive にcur_value() というイテレータとは別のメソッドがあっても使えないという違いが出てくる

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

>>956
C++20もconceptとかrequireとか言い出してるから心配しなくていいよ
そのうち追い抜く

>>959
リンク時に確定する呼び出しも「静的に決定される」扱いでいいんじゃないのか
リンク時にアドレスの書き換えとかすると思ってたけど
どこまでがコンパイルでどこからがリンクなのか分からん

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

>>958
コンパイルエラーになるよ
まずは基本的なドキュメント読んで出直してよ
今の段階ではここでやり取りしてもお互いに時間の無駄

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

>>962
>C++20もconceptとかrequireとか言い出してるから心配しなくていいよ
最近のC++に問題が多数混入したことは知られているが、
人気が絶頂だったころのC++はシンプルで分かり易かったぞ。

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

>>964
今はそれより高機能なのにシンプルなRustがベターだね
traitと(代数的データ型である)enumの二つだけ追加で覚えれば済むから

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

人気が絶頂だったころのC++っていつのC++だ
C++17あたりかな

まさかC++98とは言わんよな…（当時は言語の選択肢が少なかったと思うけど）

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

C++98位が絶頂。

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

>>956
流石にそれはRustへの知識が足らんだろ。impl, trait, whereは全てRustでは必要不可欠な概念だぞ。ここら辺がわかってないとなると構造体に関する理解も怪しいだろ。

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

>>968
でも覚えたくないから。

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

>>956
traitの概念と用法だけ覚えればよくてimplとwhererは一般的な言葉と同じ

implは単なる「実装」
「impl Trait」が型指定の位置に来れば「Traitを実装」している型の意味
「impl Trait for 型」は「その型にTraitを実装」宣言
「impl 型」は「その型を実装」宣言

whereは説明を後置する関係副詞と同じ
型に対してtraitによる境界(制約)などを指定

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

>>967
そっからは…JavaScriptなんかが本気で伸びていった時期か。

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

C++アンチの大半はC++98を嫌々使ってた世代だろ
C++0xが16進数のBになるとは思わなかった

**デフォルトの名無しさん** · 2023/07/29(土) 02:08:00.81

ポコチンファイト

**デフォルトの名無しさん** · 2023/07/29(土) 03:40:53.45

C++は、98年頃、非常に人気であった。
それが、どんどん人気を失い、現状に至っている。

**デフォルトの名無しさん** · 2023/07/29(土) 05:56:52.93

人気があったのはあくまでc とかの古い言語に対してだろ。

当時もperl5とかのスクリプト言語の方が人気だったし。

**デフォルトの名無しさん** · 2023/07/29(土) 10:55:11.31

>>965
its true👍

**デフォルトの名無しさん** · 2023/07/29(土) 12:15:13.32

>>975
C++は、C++11以後、改悪された。

**デフォルトの名無しさん** · 2023/07/29(土) 12:34:34.52

>>974
最近また順位を上げてきてるって記事見るよ

>>977
廃止された機能はほとんどないので
C++11が好きならC++11の範囲で使えば良い
その意味では改悪ってことはない

**デフォルトの名無しさん** · 2023/07/29(土) 12:37:22.94

C++以後とはC++11自体も含む。
C++11が改悪の最初。

**デフォルトの名無しさん** · 2023/07/29(土) 12:42:47.89

C++11が最良と思っている人はC++が最悪の言語に
見えることだろう。そしてそういう人がRustを礼賛
しているように見える。
ちなみに、Stackoverflow の Most Loved Language
は、実際に使用した上で好き嫌いを表明した人を分母
とした上での好きな人の比率に過ぎないので、
たとえば、
C++ : 好き=50:嫌い=50, 愛され率 50%
Rust : 好き=7:嫌い=3, 愛され率 70%
のようになっているに過ぎない。
この場合、C++好きはRust好きの7倍以上居るが、
比率的には愛され率が50%になってしまって、
Rustより愛されて無い、という結果になってしまうが
それは統計上の一応の数値に過ぎない。

**デフォルトの名無しさん** · 2023/07/29(土) 12:56:18.62

>>979
じゃC++-98使ったら?
moveなしなんて俺は考えられん

**デフォルトの名無しさん** · 2023/07/29(土) 12:56:58.78

新しいものが良いものだという固定観念は間違い。
C++は、C++98が最良で、C++11で改悪されごちゃごちゃに
なった。
C++を愛する人はC++98を愛した人。
C++11以後を見ると改悪された後なのでごちゃごちゃになった
醜態を見る事になり、C++が大嫌いになる。
そして、そういう人がC++を完全に避けるようになり、行き場所を
失い、Rustを礼賛している。

**デフォルトの名無しさん** · 2023/07/29(土) 12:58:15.78

>>982
相変わらず不勉強な人だな
適応できないとうよりおまいさんは単なる怠惰なんだよ

**デフォルトの名無しさん** · 2023/07/29(土) 12:58:56.51

>>981
moveは、std::vectorをメインコンテナに位置づけたから
必要となった概念に過ぎない。LinkedListをメインコンテナ
にすれば、不要となる。そして、ここでいうLinkedListとは
本来のLinkedListの事であり、std::listのことでない。
C++委員会は馬鹿ばっかっりなので、本来のLinkedList
を全く理解できて無い。

**デフォルトの名無しさん** · 2023/07/29(土) 12:59:13.66

>>982
moveなしのC++なんよく使う気になるね

**デフォルトの名無しさん** · 2023/07/29(土) 12:59:23.06

>>983
違う。
常識が間違っている。

**デフォルトの名無しさん** · 2023/07/29(土) 13:01:23.60

>>985
数学や右脳的IQが低い人にはLinkedListは理解が難しい
概念とされているため、LinkedListを使わない人に
とって、moveは必須となってしまうが、バグの温床と
なっている。
そのために出てきたのがRust。
何もかもが間違っている。

**デフォルトの名無しさん** · 2023/07/29(土) 13:02:06.55

>>984
>moveは、std::vectorをメインコンテナに位置づけたから
>必要となった概念に過ぎない。
違うだろwww
std::vectorの高速化にも役立つが
vectorのために作られた概念では断じてない