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
続きを読めば？どういう流れかわかるから。

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

>>18
続きで懐疑的な立場取ってんのlinusじゃなくね？

**デフォルトの名無しさん** · 2021/04/26(月) 22:53:32.32

>>19
話の流れは大体予想できてただろうなという受け答えだろ。
んでもって実際、発案者自らmoonshot言うとるわ。
少しは内容を読んでくれ、なんで一から十まで説明しなきゃならんのか。

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

>>20
じゃあレスすんなよカス

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

だから読めって。。文盲なんか？

**デフォルトの名無しさん** · 2021/04/27(火) 00:14:36.96

>>20
moonshotって言ってるの割り込みコンテキストでallocator呼び出すことをコンパイル時にチェックできるようにしたいという話では
現実的には関数ごとにどのコンテキストで呼び出せるものなのかタグ付けしてるとかなんとか
綺麗じゃないけど、まあ動くわなという解決策

つまみ食いしかしてないから読み違えてるかも知れないけど
これをもってlinuxカーネルにrust取り込むのを否定するような話ではないようにみえた

他にもmoonshotって言ってる箇所ある？

**デフォルトの名無しさん** · 2021/04/27(火) 01:12:51.08

一通り読んだけど他にmoonshotって言ってるとこはなかったような。

**デフォルトの名無しさん** · 2021/04/27(火) 08:00:23.09

>>23
あのね。。書けばそうなるってものじゃなくてそれを実装しなきゃならんのよ。。
コンパイラにそういったコンテクストを判断させるのがめちゃくちゃ難しいっていってるでしょ？
なんでそんなに読み取れないの？

**デフォルトの名無しさん** · 2021/04/27(火) 15:37:12.22

>>25
当面はdoc commentにannotation書いて済ませておくって言ってるやん
何はともあれ大局的にはrustをlinux kernelに取り込む方向へ進んでいくことには間違いない

**デフォルトの名無しさん** · 2021/04/27(火) 16:10:45.63

>>26
だからそのコードじゃpanic捉えきれねーからカーネルに入れるわけねーだろって
言ってんじゃん。。何読んでんだよ。

**デフォルトの名無しさん** · 2021/04/27(火) 18:23:48.67

まあ半年後どうなるかで誰が正しかったかは分かるわな

**デフォルトの名無しさん** · 2021/04/27(火) 20:32:29.92

半年も経たなくてももうわかってるっつーの。。だからちゃんと英語の勉強しましょうね。

**デフォルトの名無しさん** · 2021/04/28(水) 03:52:50.81

C++で、n要素のint型の生配列を確保するには、
int *pBuf = new int [n];
だけど、Rustの
let a:Box<i32> = Box::new<x>;
値が x である 32BIT 整数を Heap に 1 つ確保する、という意味だよね？
Heapに n 要素の i32 型の配列を確保したい場合、
let a:Vec<i32> = vec![0; n];
かな？

**デフォルトの名無しさん** · 2021/04/28(水) 03:55:12.80

>>30
あ、
let a:Box<i32> = Box::new<x>;
ではなく、
let a:Box<i32> = Box::new(x);
let a:Box<i32> = Box<i32>::new(x);
let a = Box::new(x);
let a = Box<i32>::new(x);
かな。
か

**デフォルトの名無しさん** · 2021/04/28(水) 04:01:18.27

>>31
確保した領域の中身を書き換えたい場合は「mut」を付ける必要があり、
値が x である 32BIT 整数を Heap に 1 つ確保するのは：
let mut a:Box<i32> = Box::new(x);
let mut a:Box<i32> = Box<i32>::new(x);
let mut a = Box::new(x);
let mut a = Box<i32>::new(x);
のどれかの書き方で、Heapに n 要素の i32 型の配列を確保するのが、
let mut a:Vec<i32> = vec![0; n];
let mut a = vec![0; n];
のどちらかの書き方かな？

**デフォルトの名無しさん** · 2021/04/28(水) 10:37:51.57

let mut a = Box::new([0,n]);