結局C++とRustってどっちが良いの？ 2traits

**デフォルトの名無しさん** · 2023/04/02(日) 00:42:57.53

「C++の色々配慮してめんどくさい感じは好きだけど、実務になったらメモリ安全性とか考えて今後Rustに変わっていくんかな」
「うだうだ言ってないで仕事で必要なのをやればいいんだよ、趣味なら好きなのやればいい」

っていうスレ。

前スレ: 結局C++とRustってどっちが良いの？
https://mevius.5ch.net/test/read.cgi/tech/1677286186/

**デフォルトの名無しさん** · 2023/04/02(日) 06:53:36.16

あっちにもスレあったんだけどね、あんま流行ってなかったから
マの問題じゃない、言語がイイんだ! ってｇｄｇｄやるのがいいみたいだ

Google&MS「バグの70%はC/C++。Rustにする」
https://medaka.5ch.net/test/read.cgi/prog/1619943288/

ほんとにマの問題なら、>>1 で終わってしまうｗ

**デフォルトの名無しさん** · 2023/04/02(日) 06:54:05.31

あっ >>12 >>10

**デフォルトの名無しさん** · 2023/04/02(日) 08:05:56.68

>>11
DQNだから言語的になんら優位性のないC++に固執している
過去の遺産だけはC++の優位性があるがそれすら時間とともに置き換わっていく

**デフォルトの名無しさん** · 2023/04/02(日) 08:13:05.31

Rustは難しくない。そうだろ?
大手が本格的に移行しはじめてからでも、全然遅かねえんだよ

ま、C++を捨てられないってのは、このスレだけの内緒だけどな!

**デフォルトの名無しさん** · 2023/04/02(日) 08:16:48.61

Rustに移行ってのは、採用された程度じゃ移行じゃない
APIに、Rustの所有権・マルチスレッド関係のシグネチャが付くようになって、ようやっとだ
その日はくる

そして、Rustの独占は揺らぐ

**デフォルトの名無しさん** · 2023/04/02(日) 08:25:23.82

C++を捨てたんなら、no_mangle とか、まさか、extern "C" とかいう呪詛を唱えてないよな?

移行っていう以上、そういうの要らないんだよ
C++が、こっちから適合してやっからよ

**デフォルトの名無しさん** · 2023/04/02(日) 10:39:13.92

複おじはね、承認に飢えた構ってちゃんなのよ
この紛うことなきクソスレを隔離スレ化して構い続けてあげれば、他スレの被害を最小限にできるって寸法よ
こんなクソゴミスレを存続させる意義はここにある

君たちも>>5は知識として覚えておいて、そこらでそれっぽい書き込みを見ても一切反応しちゃいけないぞ

**デフォルトの名無しさん** · 2023/04/02(日) 10:48:26.80

ディスパッチはディスパッチだろ、くらいに思ってたのに、
Rustの優位性を説明するキーワードのひとつなのね
もうちょっと勉強してからそのへんはゆっくり読む罠ついていけん

C++を捨てろって言われると猛然と怒るけど、
じゃRust使わないのかって聞かれると、いやじゃんじゃん使うよ必要ならって答える
それがC++er

**デフォルトの名無しさん** · 2023/04/02(日) 11:14:49.29

>>5
よくまとまってる

**デフォルトの名無しさん** · 2023/04/02(日) 12:12:13.50

>>19
>Rustの優位性を説明するキーワードのひとつなのね
静的ディスパッチ/動的ディスパッチの違いは
基本としておさえておくべきポイントというだけで
Rustに明確な優位性があるわけではないよ
vtableの持ち方の違いもトレードオフだから
何に重きを置くかによってRustがやや有利な場合もあればC++が有利な場合もある

**デフォルトの名無しさん** · 2023/04/02(日) 12:30:32.66

しゃぶれよ

**デフォルトの名無しさん** · 2023/04/02(日) 13:40:35.10

>前スレ

>Rust派は、Rustなら、必ず・全部安全

doubt

**デフォルトの名無しさん** · 2023/04/02(日) 14:12:33.01

そりゃC++よりは安全だろうけど

少なくともメモリ管理において、Rustの安全性って、数学的に保証されるものなの?

**デフォルトの名無しさん** · 2023/04/02(日) 14:28:31.37

>>24
定義次第だと思うのでメモリ管理以外で「安全性が数学的に保証されてる」と思ってる例をいくつかあげてみて

**デフォルトの名無しさん** · 2023/04/02(日) 14:50:01.38

あ、わかった
Rustがsafeといっても、定義次第なんだね

**デフォルトの名無しさん** · 2023/04/02(日) 15:21:53.12

ちんぽこ

**デフォルトの名無しさん** · 2023/04/02(日) 16:06:16.39

キチガイの巣

**デフォルトの名無しさん** · 2023/04/02(日) 16:26:16.23

>>26
Rustに関係なく「安全かどうか」は定義次第だからね

**デフォルトの名無しさん** · 2023/04/02(日) 16:48:24.56

ていうか、こっちに定義を聞いてこられても困るんだよね
この定義において、Rustはここまで安全、って言ってもらえると、それを遵守するんだから

**デフォルトの名無しさん** · 2023/04/02(日) 16:59:55.82

>>30
数学的に安全性が保証されてるかどうかを質問してるにも関わらず
「数学的に安全性が保証されてる」とはどういう定義なのか聞かれたら困るのか
それじゃどうしようもないな

**デフォルトの名無しさん** · 2023/04/02(日) 17:13:06.13

数学的に安全性が保証されてるっぽい何かがあるんだろ? ってなことだよ
根拠もなしに、安全か? そりゃC++よりマシだろうけどさｗ

**デフォルトの名無しさん** · 2023/04/02(日) 21:00:51.01

そんな難しいことを考えなくても
Rustの所有権システムをC++で体験したければ
インスタンスを作るときに
必ず常にmake_uniqueかmake_sharedするようにすれば
だいたい同じ振る舞いになる
安全性は保証される

**デフォルトの名無しさん** · 2023/04/02(日) 23:31:24.96

C++ってstd::move(x)した後にx使うとコンパイラに怒られるの？

**デフォルトの名無しさん** · 2023/04/03(月) 00:26:35.43

コンパイラは怒らないから
静的解析ツールが必要だね

**デフォルトの名無しさん** · 2023/04/03(月) 04:38:42.03

C++はコンパイルとは別に静的解析とデバッグ解析が不可欠だからな
Rustはコンパイラがメモリ安全からデータ競合安全まで保証してくれるのでかなり楽

**デフォルトの名無しさん** · 2023/04/03(月) 09:30:27.97

デバッグ解析てなんやねん

コンパイラがやる静的解析の範囲が広いというだけでRustでも静的解析・動的解析は基本不可欠
clippy, rustfix, rust-fmt, cargo-expand辺りは静的解析ツールの一種

**デフォルトの名無しさん** · 2023/04/03(月) 09:40:57.30

まともにrustかけるやつって例外なくc++もかけるけどな。

**デフォルトの名無しさん** · 2023/04/03(月) 09:51:01.03

でも、C++よりマシな程度では?

**デフォルトの名無しさん** · 2023/04/03(月) 09:52:16.72

Rustだって、まともにって難しいだろ、たぶん
俺は簡単に使いたい

>>39 は >>36

**デフォルトの名無しさん** · 2023/04/03(月) 10:19:52.71

「安全」に描こうとするとコピーが大量に発生するのか

**デフォルトの名無しさん** · 2023/04/03(月) 10:22:17.10

>>31
Rust は(限られた範囲において)常に安全ω(キリっ

**デフォルトの名無しさん** · 2023/04/03(月) 10:26:17.83

C++er あるあるシリーズ
#![allow(unused)]
... = hoge().unwrap;
... = hoge()?;
let p: *const [u8] = &fuga;
unsafe {}

**デフォルトの名無しさん** · 2023/04/03(月) 10:27:57.18

>>37
C++のスマポの使い方をミスっても公式支援がない話でそれらは的外れかなあ

clippyはRust公式リント
rustfixはRustコンパイラのよる提案の適用
rust-fmtは清書
cargo-expandはマクロ展開

**デフォルトの名無しさん** · 2023/04/03(月) 10:39:12.43

>>41
Rustはムダなコピーを発生させずに参照を使って安全にメモリ管理できる言語
もしRustで不可能なケースがあったらそれはC++でも不可能で元から無理筋

**デフォルトの名無しさん** · 2023/04/03(月) 10:55:27.74

なおグラフ

**デフォルトの名無しさん** · 2023/04/03(月) 11:15:28.73

>>44
それはRustの実装が一つしかないのを公式と言っているに過ぎない
C++でデバッガが用意されていない開発環境は無い?
もしくは使われていないのでは?

**デフォルトの名無しさん** · 2023/04/03(月) 11:47:36.10

>>44
誰もが使ってるツールにわざわざ説明つけてるところ見ると基本の静的解析ツールも知らなかったんだな
複オジは所詮このレベルだから全く信用できない

**デフォルトの名無しさん** · 2023/04/03(月) 11:50:42.61

>>45
C++は選択ができる
値とポインタ（スマートポインタ）と参照（左辺値と右辺値）
冗長に書くも効率的に書くもプログラマ次第
素人にはオススメしない

**デフォルトの名無しさん** · 2023/04/03(月) 12:08:48.70

>>49
それはどちらも同じ
所有権を持つ: C++のスマポ、Rustの変数
所有権を持たない: C++とRustの参照
ただしライフタイムが管理できるRustの参照の方が強力かつ安全

**デフォルトの名無しさん** · 2023/04/03(月) 12:15:40.80

>>50
「ライフタイムが管理できるRustの参照」って何?
単に参照先が死んでることをコンパイラで弾くことを「管理」って言ってるの?

**デフォルトの名無しさん** · 2023/04/03(月) 12:16:08.17

the Bookを捨てよ、町へ出よう

**デフォルトの名無しさん** · 2023/04/03(月) 12:24:08.54

Rustの宣伝文だけ読んで他言語を知った気になり
Rustの宣伝文を5chにコピペし続けるだけの人生

**デフォルトの名無しさん** · 2023/04/03(月) 12:47:23.54

>>53
言い得て妙
マジでこれw

**デフォルトの名無しさん** · 2023/04/03(月) 12:54:34.40

>>50
C++の参照とRustの参照はかなり違うぞ
C++の参照はちょっとミスるとダングリングになる

**デフォルトの名無しさん** · 2023/04/03(月) 13:50:16.07

「数学的」連呼してる割には名前に直交性が無いな

.iter
.indexed_iter
.iter_mut
.indexed_iter_mut

.outer_iter
.outer_iter_mut

not exist .indexed_iter_mut
not exist .enumerate_iter_mut

.enumerate_pixels_mut

いちいち覚えてられるか？

**デフォルトの名無しさん** · 2023/04/03(月) 13:54:52.87

違ったので訂正
誤 not exist .indexed_iter_mut
正 not exist .indexed_outer_iter_mut

**デフォルトの名無しさん** · 2023/04/03(月) 14:01:30.74

あ。「数学的」連呼してたのは、C++側の俺
そして、あんまり、数学的な安全の論拠ってのはみつからない

ありゃあC++で真似するんだよ手本にしない手はない

**デフォルトの名無しさん** · 2023/04/03(月) 14:08:12.25

>>56
各ライブラリで命名方針が異なるのは、プログラミング言語の比較の話と全く無関係じゃね？
あと、enumerate_pixels_mutをその提案のenumerate_iter_mutとしてしまったら、肝心なピクセルが消えて意味不明じゃん。

**デフォルトの名無しさん** · 2023/04/03(月) 14:14:18.67

雑談としては、そのへんも「きれい」になってくれるとありがたいね
これはC++も同様

**デフォルトの名無しさん** · 2023/04/03(月) 14:28:24.56

直交性の意味がよく分からなかった
index_of（先頭から検索）とlast_index_of（末尾から検索）は直交性がないことになるのかな
標準と非標準の関係で考えると自然な命名だと思うけど

**デフォルトの名無しさん** · 2023/04/03(月) 14:29:57.73

かわいそうだから答えてやるか
数学的な保証が云々ってたぶんRustBeltプロジェクトのことだよね
https://plv.mpi-sws.org/rustbelt/

**デフォルトの名無しさん** · 2023/04/03(月) 15:09:57.20

>>62
どの辺を指して数学的と言ってるのか謎

**デフォルトの名無しさん** · 2023/04/03(月) 15:39:46.50

Rust 安全論文、で上手く引き当てられなかったんだよ
仕事サボって、ちょっと読んでみるｗ

>>63
いや、いいんだ。「それっぽいの」って俺も言った。

**デフォルトの名無しさん** · 2023/04/03(月) 15:53:08.55

>>62
unsafeを使ってsafeなインタフェースを作っている部分、すなわち人間が安全性を保証しなければならなかった部分を、数学的に保証する試みがあるのか

**デフォルトの名無しさん** · 2023/04/03(月) 15:56:35.02

そこも気を付けて読んでみるけど、
unsafeを撲滅しようと思ったら、SoCのサポートが必要ってのが今のところの俺の考え
そう考えないと、C++も永遠にsafeに成れないことになってしまう

unsafe部分にバグが、っていう古い記事が出てきたりするんだけど、
どうせ、safeでいいものまでunsafeでいっぱい書いたんでしょ、と思ってる
これは個人の推測

**デフォルトの名無しさん** · 2023/04/03(月) 16:08:23.20

>>65
数学的とは一言も書いてなくね？

**デフォルトの名無しさん** · 2023/04/03(月) 16:11:48.88

学術的とか、論理的とか、適当に読み替えてくれよ、俺がうまく言えなかったのがいけなかっただけ

**デフォルトの名無しさん** · 2023/04/03(月) 17:01:07.96

>>61
last_index_ofはlast occurrenceのindexを示すだけで検索方向を示すものでは無いと思う

**デフォルトの名無しさん** · 2023/04/03(月) 17:14:21.15

>>56 >>59
.indexed_pixel_mut も欲しいです

**デフォルトの名無しさん** · 2023/04/03(月) 17:34:14.59

>>70
はあ？
indexed_iter_mutがあるのはndarray crateの話
enumerate_pixels_mutがあるのはimage crateの話
pixelのイテレータとrowのイテレータがあるためiterではなくpixelsおよびrowsと名付けている
>>56が無関係な両ライブラリをごっちやに取り上げてその意味も分からず批判しているだけにすぎない

**デフォルトの名無しさん** · 2023/04/04(火) 09:48:59.96

前スレを読んだ感想だが
Rustのvtableは1つに合成されているのがへーだった
ちなみにC++は各基底毎にある
https://i.stack.imgur.com/rK5xx.jpg
https://i.stack.imgur.com/TJ1k6.jpg

**デフォルトの名無しさん** · 2023/04/04(火) 09:57:45.04

>>72
それ読み間違えてるぞ

**デフォルトの名無しさん** · 2023/04/04(火) 10:05:22.65

複オジメソッド発動

**デフォルトの名無しさん** · 2023/04/04(火) 10:08:21.90

>>72
Rustは継承がなくトレイト合成なんだから当然だろ

>>73
間違ってはいないだろ

**デフォルトの名無しさん** · 2023/04/04(火) 10:10:16.77

まあ、ちゃんとキャストできるようにできてるというか

**デフォルトの名無しさん** · 2023/04/04(火) 12:04:39.20

何が間違ってるかは教えてあげない

**デフォルトの名無しさん** · 2023/04/04(火) 13:10:25.87

プッ

**デフォルトの名無しさん** · 2023/04/04(火) 13:20:50.92

C++を知ってしまったことかな。。

**デフォルトの名無しさん** · 2023/04/04(火) 14:47:11.16

日本人はtraitとtoiletの区別がつきにくい

**デフォルトの名無しさん** · 2023/04/04(火) 17:52:01.37

もうGPTがどの言語でも変換してくれる時代

**デフォルトの名無しさん** · 2023/04/04(火) 20:58:36.08

rustのcrateはdependenciesで入るのが多過ぎるし大き過ぎるわ
要らないものまで無理やり入れさせられてる気分になる

**デフォルトの名無しさん** · 2023/04/04(火) 21:26:41.04

依存crate問題が最大の弱点ではある

**デフォルトの名無しさん** · 2023/04/04(火) 21:32:45.26

node_modulesとどっちがヤバいかな？

**デフォルトの名無しさん** · 2023/04/05(水) 15:18:19.83

node_modules は -g で解決

**デフォルトの名無しさん** · 2023/04/05(水) 15:43:59.95

dependenciesに5個程度指定するだけで
依存crateが100個近くになるのも珍しくない
nodeとは比べ物にならないくらいひどいよ

**デフォルトの名無しさん** · 2023/04/05(水) 15:47:38.76

しかもビルドすると500～1GB超の容量使うからノートの内蔵SSDを使ってると残す必要のないのは積極的にcleanしないときつい

**デフォルトの名無しさん** · 2023/04/05(水) 15:49:19.66

そんだけファイルの読み書きするなら
IOの速度に影響されそうだね

**デフォルトの名無しさん** · 2023/04/05(水) 15:55:51.93

マイコンでも大人気と聞いたんだが、どうなってるんだ

**デフォルトの名無しさん** · 2023/04/05(水) 17:07:48.56

容量使うのはインクリメンタルビルド用の中間生成物で配置するものとは違うよ

**デフォルトの名無しさん** · 2023/04/05(水) 17:26:43.23

C++もPCHファイルを生成するとアホほどでかかったりするが…世の中うまくいかんな

**デフォルトの名無しさん** · 2023/04/06(木) 14:03:59.93

チンチン汁出るッ

**デフォルトの名無しさん** · 2023/04/06(木) 15:09:52.63

C++なら明示的インスタンス化を使おうよ
使っている人をほぼ見ないけども

**デフォルトの名無しさん** · 2023/04/06(木) 15:52:41.86

こう書いておけば、インスタンス化した関数に、こんな風に溶け込むだろうな、とか思って書いてたりはする
時間があれば、生成コードを汗で確認する
びっくりするほどスパゲッティな出力になってて、びっくりすることがあるまあ実力不足を痛感する瞬間

**デフォルトの名無しさん** · 2023/04/06(木) 18:12:44.37

Cargo はゴミ

**デフォルトの名無しさん** · 2023/04/06(木) 20:01:46.11

ぺたんこおっぱい
ぽっこりおなか
つるつるわれめ

**デフォルトの名無しさん** · 2023/04/06(木) 23:30:16.81

>>94
クラスも構造体も使わずに書いているの？

**デフォルトの名無しさん** · 2023/04/06(木) 23:35:22.20

ああ、callで呼ぶようなものはなんでも関数って言っちゃうねつい

**デフォルトの名無しさん** · 2023/04/07(金) 00:17:10.35

https://www.publickey1.jp/blog/22/ccarbon_languagegooglec.html
こちらはC++との互換性を重視しているらしい
Rustはこの先生きのこれるかな？

**デフォルトの名無しさん** · 2023/04/07(金) 00:31:06.23

そこにこれ載ってた
[RFC] Lifetime annotations for C++
https://discourse.llvm.org/t/61377

Rustは勝利したしかし、Rustはその勝利を独占できない

**デフォルトの名無しさん** · 2023/04/07(金) 03:11:25.56

>>100
こう書いてあるね

提案された有効期間注釈に基づく静的分析では、C++ コード内のすべてのメモリ安全性の問題をキャッチすることはできません。
具体的には、すべての時間メモリの安全性のバグ (反復子の無効化によって引き起こされるバグなど) をキャッチすることはできず、
もちろん、有効期間注釈は空間メモリの安全性 (たとえば、C スタイルの配列の範囲外のインデックス作成) には役立ちません。
詳細な議論については、以下のRustとの比較を参照してください。

**デフォルトの名無しさん** · 2023/04/07(金) 03:22:57.43

>>99
Rustを使えるならばRustを使ったほうが良いと明記されているね

ソース
Carbon公式FAQ
https://github.com/carbon-language/carbon-lang/blob/trunk/docs/project/faq.md#why-not-rust

Why not Rust?
If you can use Rust, ignore Carbon.
If you want to use Rust, and it is technically and economically viable for your project, you should use Rust.
In fact, if you can use Rust or any other established programming language, you should.
Carbon is for organizations and projects that heavily depend on C++

**デフォルトの名無しさん** · 2023/04/07(金) 03:34:46.32

>>101
-Wlifetime とかと組み合わせろってことじゃないん
スマポだけでは解けない課題にこれが要るんだろ
(勉強中なので)知らんけど

**デフォルトの名無しさん** · 2023/04/07(金) 15:30:28.71

動きました。ほんとうにありがとうございました。

use std::ffi::c_void;

#[link(name = "user32")]
#[no_mangle]
extern "stdcall" {
fn MessageBoxA(hWnd: *const c_void, lpMsg: *const u8, lpTitle: *const u8, flg: u64) -> u64;
}

fn main() {
let msg: &[u8] = &vec![65u8, 66u8, 67u8, 0u8];
let lpmsg: *const u8 = &msg[0];
let ttl: &[u8] = &vec![97u8, 98u8, 99u8, 0u8];
let lpttl: *const u8 = &ttl[0];

println!("{}", unsafe { MessageBoxA(0 as *const c_void, lpmsg, lpttl, 3) });
}

**デフォルトの名無しさん** · 2023/04/07(金) 16:14:09.83

>>103
知らないなら書くなよアホが

**デフォルトの名無しさん** · 2023/04/07(金) 16:45:18.17

>>104
こうしろよ
let msg: &[u8] = &vec![65u8, 66u8, 67u8, 0u8];
↓
let msg: &[u8] = b"ABC\0";

**デフォルトの名無しさん** · 2023/04/07(金) 16:51:51.07

さらに*constにするならこれだけでいい
let msg: &[u8] = &vec![65u8, 66u8, 67u8, 0u8];
let lpmsg: *const u8 = &msg[0];
↓
let lpmsg = b"ABC\0" as *const _;

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

>>105
しらんがなｗ

**デフォルトの名無しさん** · 2023/04/08(土) 02:42:49.64

>>104
こっち使え
https://github.com/microsoft/windows-rs
https://www.youtube.com/watch?v=-oZrsCPKsn4

**デフォルトの名無しさん** · 2023/04/09(日) 10:11:37.53

Haskellでrustみたいに
型引数だけじゃなく型引数を引数に取るデータ型に対しても型制約書けたりできるんですか？

**デフォルトの名無しさん** · 2023/04/09(日) 11:45:46.52

逆では？