C++ vs Rust

**デフォルトの名無しさん** · 2021/04/24(土) 08:04:49.48

競え

**デフォルトの名無しさん** · 2021/04/24(土) 09:03:31.43

何で？

**デフォルトの名無しさん** · 2021/04/24(土) 09:10:09.42

どちらも変なプライド拗らせたアホしかいない印象

**デフォルトの名無しさん** · 2021/04/24(土) 10:50:18.68

C++: ｶﾐｿﾘ
Rust: 安全ｶﾐｿﾘ

**デフォルトの名無しさん** · 2021/04/24(土) 11:18:00.79

別に～
裏方一緒だし

**デフォルトの名無しさん** · 2021/04/25(日) 11:37:52.88

一概にどちらが優れているとは言えないことではあるが、
代入やコンストラクタが、moveとcopyのどちらになるかについて、Rustの
方が自動化が進んでいると思いがちだが、実際は、
C++は、関数の戻り値が構造体型/クラス型になっている場合に関しては
RVO(Return Value Optimization)が働き、右辺が
クラス名(実引数列)
の形式の一時オブジェクトである場合には、moveが選ばれるが、それ以外は、
概ねcopyになるので、ある意味では「自動選択」しているのに対し、
Rustでは、x = y と書いた場合、原則的には「デフォルトmove」の規則に
従い、copyしたい場合は、右辺をy.clone()と書くことになっていて、
「手動選択」を採用している。
C++は、どう書いた場合にmoveになり、どう書いた場合にcopyになるかを全て把握するのは
難しくて、C++の仕様が勉強不足だと勘違いや見落としが発生する可能性があるのに対し、
Rust方式は、moveとcopyのどちらになるかが明確なので混乱が少ないと言えるかも知れない。
つまり、このことに関しては、児童選択より手動選択の方が安心感があるかも知れない。
意見を求む。

**デフォルトの名無しさん** · 2021/04/25(日) 11:57:11.84

Copy trait実装してたら暗黙的に実行されるわ。
とはいえc++のそれよりかは分かり易いけど。

**デフォルトの名無しさん** · 2021/04/25(日) 13:18:15.15

[C++]
xやfunc()の戻り値が CPerson というクラス型の場合、
10. x = y;　// copy代入。yの中味はxにコピーされる。yのデータも保存。
11. x = std::move(y) // move代入。yのデータは破棄される。
12. x = func(a);　// move代入または、RVOが働いてmove代入以上に速い動作になる。
　　　　　　　　　　関数の戻り値だけは特別に処理されている。

[Rust]
(CPerson がCopy traitを実装して無い場合に限定)
20. x = y;　// move。以後、y は使用できなくなる。これが故にデフォルトmoveと呼ばれる。
21. x = y.clone(); // copy。以後もyは使用できる。
22. x = func(a); // move。20.と同じ規則に従っているだけで関数の戻り値だから特別では無い。

C++の場合、12.で関数だけは特別処理されているのに対し、Rustの22では
関数でも特別処理されているわけではなく、20.のデフォルトmoveの原則に従っているだけ
のように見える。
C++の場合、11. では、std::move()で修飾すると、なぜか、10. で修飾しなかった場合
より、実行されるCPUの処理が「減る」。ソースコードで関数の様なものを
追加した方が追加しなかったときよりCPUの処理が減ってしまうのは、どことなく直感に
反する。
一方、Rustの21と20を比較すると、.clone()を書いた方が書かなかったときより、
実行されるCPUの処理が増えるので、直感的である。
この場合、.clone()を書いたことで「コピーするためにCPUの処理が追加された」という
直感に沿った感じになるから。
C++の場合、std::move()と書くと「std::move()という関数の様なものを書いたのに、
なぜか、CPUの処理が減る」という違和感を感じるようになる。

**デフォルトの名無しさん** · 2021/04/25(日) 17:13:07.94

要はRustの代入ってmemcpyで、単純なmemcpyされると困るデータ(!Copy)の場合右辺がinvalidate(move)され使えなくなる
って理解がシンプルなのかな

**デフォルトの名無しさん** · 2021/04/25(日) 18:00:12.34

>>9
x = y の時、
結果的にはほとんどmemcpy(&x,&y,サイズ)に近い動作になっているかもしれないな。
ただ、右辺yの構造体メンバの中にRc<T>のような複雑なものが入っている場合、
結果は単純コピーのようになったとしても、コンパイラはもっと丁寧に処理
しているのではなかろうか。

**デフォルトの名無しさん** · 2021/04/26(月) 01:44:08.26

>>10
move は memcpy だよ
Rc も実体はヒープへのポインタだから memcpy で問題ない
memcpy してはいけない例としては async fn みたいな自己参照構造体などがあるけど
Pin をうまく使うことで変な状態にならないようにしている

**デフォルトの名無しさん** · 2021/04/26(月) 17:23:54.42

c++に批判的な姿勢で知られるlinusがなぜrustにはwelcomeな態度取ってるのかが理解できない
rustだってメモリ安全性がなければc++みたいなもんだろ

**デフォルトの名無しさん** · 2021/04/26(月) 17:27:49.70

言うほどwelcomeか？

**デフォルトの名無しさん** · 2021/04/26(月) 17:29:26.57

>>13
貶すまではいってないじゃん

**デフォルトの名無しさん** · 2021/04/26(月) 18:48:21.42

あわしろ氏もRustは凄いって言ってましたね。
C++をあまり好きじゃないところも同じ。

**デフォルトの名無しさん** · 2021/04/26(月) 20:08:40.47

>>12
c++にもだいぶ甘くはなってるよ。
ただそれでもrustに対してもそこまで容認的ではない。
試しにドライバー書いてみれば？って言って試させてるが、まだまともには考えてないわ。
https://lkml.org/lkml/2021/4/16/901

**デフォルトの名無しさん** · 2021/04/26(月) 20:27:04.95

>>16
むしをrust側に対して例外処理の方法をカーネル内での往来の方法に変更してくれって促しているように見えるんだけど
導入したがってるやんけ

**デフォルトの名無しさん** · 2021/04/26(月) 20:51:20.12

>>17
続きを読めば？どういう流れかわかるから。