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

>>365
Rcはジャンルも機能も動作も利用方法も全く異なりその話は誰もしていないよ
あなたが>>359で言った、
> 参照カウントが2以上ならエラーでいい
> 実行時エラーなら難しくない
> コンパイル時が難しいだけ
は、Rcとは全く異なる挙動でありRcとは無関係

あなたが言っている挙動「参照カウントが2以上ならエラー」は「sIngle reader or single writer」
そしてRefCellはその上位の「multiple readers or single writer」
つまりRefCellはもっと便利であり利用面での上位互換

**デフォルトの名無しさん** · 2023/04/22(土) 18:45:43.59

話が専門的になってきているけれども、「メモリー関連バグ」はバグの一部に
過ぎず、それが完全に防げたとしてもバグが入り込む余地はたくさんある。
例えば、JSやJava、C#、BASIC、Pythonなどの言語はメモリー関連バグは
入り込まないが、バグはいくらでも入り込む。

**デフォルトの名無しさん** · 2023/04/22(土) 18:51:49.24

Javaはぬるぽぬるぽいってたけどねえいまさらだけど、あれなんだったんだろう (nullptrは使ってます

**デフォルトの名無しさん** · 2023/04/22(土) 19:01:05.60

>>367
追加として、Ruby、PHP、Perl なども同様。
メモリー関連バグは入らないが、論理バグはいくらでも入り込む。
だから、ネットショッピングサイトをこれらの言語で作っても、
データ漏洩や、データ消失(顧客情報の間違った削除など)、
インターフェースのバグ、買いたいものが買えない、別人のアカウントで
買った事になってしまう、あるいは、セキュリティーホールなどは、
入り込む余地はいくらでもある。
15 番の人が購入しているのに、16番の人を購入したことにしてしまったりとか。
または、ボタンを一回押したのに、2回購入したことになってしまったとか。
キャンセルボタンを押しても動作しないとか。
または、キャンセルすると、14番の人の購入がキャンセルしてしまったりとか。
そういうのは基本的に論理バグであり、メモリー関連バグとは別に発生しうる。

**デフォルトの名無しさん** · 2023/04/22(土) 19:24:40.58

>>367
GC言語を含めた多くの言語で発生する普遍的なバグがデータ競合
データ競合は様々なものがあってマルチスレッドでは当然発生するだけでなく
スレッドを利用しなくても部分参照が可能な言語ではデータ競合が容易に発生してしまう

後者の例はこのスレ既出でベクター型においてその何番目かの要素の参照を持っているときに
要素追加が行われると再配置によりダングリングを引き起こしたり
要素挿入が行われると再配置がなくてもズレて意図せず異なる要素を指してしまうデータ競合が起きる

>>369の例の別の人の購入データになってしまったりするバグも様々なデータ競合により引き起こされることが多い

このように色々なデータ競合がプログラミングで発生するが
Rustではデータ競合が発生せずコンパイルエラーとなる
これは非常に大きな強み

**デフォルトの名無しさん** · 2023/04/22(土) 19:37:17.80

>>370
> 369の例の別の人の購入データになってしまったりするバグも様々なデータ競合により引き起こされることが多い
データ競合が発生しなくても、単なる論理ミスでも発生するから、Rustでも
ちゃんと正しい論理を書かなければ発生する。

**デフォルトの名無しさん** · 2023/04/22(土) 19:40:54.01

ポインタは究極の共有オブジェクトだから、同様に管理する習慣が付けば、データ競合のミスは減りそうだよね

**デフォルトの名無しさん** · 2023/04/22(土) 19:50:59.03

>>371
それはビジネスロジックの論理バグ
プログラミング言語が何であろうと関係なく生じるのでこのスレの目的である言語の比較に無関係

そしてプログラミングのデータの取り扱いで発生する論理バグがデータ競合
データ競合はバグを引き起こしうるためプログラマーが回避しなければならない
Rustはコンパイルが通ればデータ競合がないことが保証される
任意のプログラミング言語に対してRustが有利

**デフォルトの名無しさん** · 2023/04/22(土) 20:01:02.96

メモリやデータ競合に関係したバグの送りにくさRustは有利ではある。
ただ、言語に求められるのはそれだけではない。

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

>>374
他の言語では起きないまたは起こりにくいバグが
Rustだと起きるまたは起きやすい例ってある？
その例を示せないとRustが最強になってしまうよ

**デフォルトの名無しさん** · 2023/04/22(土) 20:10:28.97

Visual Studio でC++のMFCや C#のWPFのようにGUI開発がサポートされたら新規ソフトはRustになっていきそう
逆に現状のままなら開発元のMozilla以外はLinuxカーネルみたいなマニアックな用途だけで終わりそう

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

>>375
あるけど言わない。それは自分で気付かないと。
なぜ言わないかと言えば、その情報を元に論文書いたり、
国から研究費貰ったりする人がいるから。

**デフォルトの名無しさん** · 2023/04/22(土) 20:17:17.43

let mut hoge: Vec<Vec<String>> = vec![Vec::with_capacity(3); 4];
のとき
hoge.len() は 4
hoge[0].len() は 0
hoge[0].capacity() は 3 を期待していたのですが何故か常に 0 になってしまいます

Why?

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

vec![expr; n]は内部でclone使うんだけど、Vecのcloneはcapacityまでは複製しないみたい
複製はできるだけ余剰メモリをカットしたい気がするから仕様だろうな

fn main() {
let a: Vec<String> = Vec::with_capacity(10);
let b = a.clone();

println!("{}, {}", a.capacity(), b.capacity()); // 10, 0
}

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

データ競合を防ぐのは簡単で「multiple readers or single writer」を守れば防げる
どの言語でもそのような形になるようにプログラマーが解決する
ただしRust以外の言語はデータ競合があっても検出できずに競合を起こしたまま動いてしまいバグとなる

>>377
存在しない

>>378
vec!は回数分のcloneするだけ
そしてcloneはcapacityを保持しない
だからその0となる挙動は仕様通りで正しい
その3となる挙動にしたいなら例えば
Vec::from_iter((0..4).map(|_| Vec::with_capacity(3)));
あるいはrepeat_withでtake(4)

**デフォルトの名無しさん** · 2023/04/22(土) 21:09:18.75

やっぱりC++のstd::variant欲しいっすな
Refに対応したCow作ったけどなかなかだるい（というか標準で対応してくれの感が激しかった）し
こんどはRc<RefCell<T>>と&Tのenumが欲しい
わざわざ作るのもだるい

**デフォルトの名無しさん** · 2023/04/22(土) 21:09:58.95

制約は安全性を高めるためなんだろうけど率直に言ってウザいからな
他人に書かせるならRustを選ぶかもしれんがw
自分で書くものにはRustは不要かな

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

マルチスレッドの主な用途は数値計算なんだけど、数値計算だと
データ競合が起きるような場合はシミュレーション結果がおかしくなるので
テスト段階で分かることが多い。また、脆弱性とも関係無い。
脆弱性が問題になるのは、主にブラウザ。
自分のマシンのセキュリティーホールに悪さをするアホはいない。
つまり、脆弱性とはネットと関係する場合にのみおきると言っても過言ではない。
だから、シミュレーションとかは脆弱性とは関係が無いので、
データ競合が起きたら、結果がおかしくなるだけ。

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

>>377
ついに嘘つき敗北宣言『あるけど言わない。』を出したのか

**デフォルトの名無しさん** · 2023/04/22(土) 21:29:51.72

>>382
Rustでウザい制約って何かある？
必要な制約は当然あるけど不要な制約はないんじゃないか

**デフォルトの名無しさん** · 2023/04/22(土) 21:30:53.79

>>384
いや、有る。

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

ここの人達は、自分と意見が合わない人を馬鹿だと思ってる気がするけど、
それは違うぞ。
俺は貴重な意見を言っている。
まあ、日本全国探しても貴重だろう。
だけど、全部は大事なところは言わん。

**デフォルトの名無しさん** · 2023/04/22(土) 21:38:49.06

>>383
データ競合はタイミングなどで稀にしか発生しないものも多い
テストで何度か実行すれば必ず判明するわけではない
そして特定の分野でのみ発生するものではない

>>386
もし>>375の例があると主張するなら例を出しなよ

**デフォルトの名無しさん** · 2023/04/22(土) 21:39:07.62

無能である上に突っ込まれるのが怖くて意見表明すらできない
負け犬極まれりだな

**デフォルトの名無しさん** · 2023/04/22(土) 21:41:53.93

>>388
>データ競合はタイミングなどで稀にしか発生しないものも多い
数学的に考えているから、細かいミスが取れた後は大丈夫。
脳内で証明済みのアルゴリズムを使うから。
才能の無い人は誰かが考えたアルゴリズムを真似て使うのだろう。
俺はそんなことはしてない。

**デフォルトの名無しさん** · 2023/04/22(土) 21:42:53.35

>>389
自分の周りと同じにしないほうがいいぞ。
付きぬけている人をみたことがないみたいだな。

**デフォルトの名無しさん** · 2023/04/22(土) 21:46:36.12

>>377
自分がそれをネタに論文を書く予定でもないなら
別に良いのでは?

**デフォルトの名無しさん** · 2023/04/22(土) 21:49:17.49

>>392
姿を隠して情報収集ってか。

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

>>390
データ競合を引き起こしてきたプログラマーたちは皆そのように言っている
「自分はデータ競合を引き起こさないように(アルゴリズムを考えて)コードを書いた」
しかし実際にはデータ競合が起きた
データ競合はRustのようにプログラミング言語で防いだほうが好ましい

**デフォルトの名無しさん** · 2023/04/22(土) 21:51:10.61

>>394
俺とそいつらの頭脳は同じではない。

**デフォルトの名無しさん** · 2023/04/22(土) 21:54:28.66

Mozillaは、凡庸な技術者しかいないからRustが必要になった。
それだけの話。
もっとも、普通の企業はそんなもんだろうが。

**デフォルトの名無しさん** · 2023/04/22(土) 21:55:58.32

データ競合起きたら意図と異なりデタラメな結果になるので
すぐ分かると思うよ

**デフォルトの名無しさん** · 2023/04/22(土) 21:57:39.05

>>393
こんなところで姿を出す訳にいかないじゃないか!
俺はコンパイラ屋ではない

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

>>385
文字列全体（String）とその一部の参照（&str）を同じ構造体に詰めないとか
オブジェクト指向言語に慣れた人だと辛いと思う
厳密にはC++でも難しい（&strの初期値で悩む）けどこっちはまだごまかせるし

上の方でもちょっと書いたけど行ロックを意識したDBのテーブル設計に近い印象
とりあえず全項目を１つのテーブルに突っ込むみたいな方法だと途中で引っ掛かるから
大雑把な人には面倒な言語かもしれない

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

>>397
俺の経験から言ってもそう思う。
テスト時に働かないような「if 文」を入れたりしない限りは。
バグが取れない人は、変なところに if 文を入れている。
数学的な理想世界では基本的には if は存在しないことがおおい。最小と最大の
付近以外では。
だから、数学的に考えられる人は if 文は最低限しか入れないで済む。
このルールを守っていれば、滅多なことで妙なバグは入らない。

**デフォルトの名無しさん** · 2023/04/22(土) 22:11:27.43

>>396
つまりRust採用を進めているGoogleやMicrosoftやAWSなどIT各社は凡庸な技術者しかいないからRustが必要になったとの主張？？
キチガイじみてるね

**デフォルトの名無しさん** · 2023/04/22(土) 22:15:02.54

>>401
いや、Microsoftは、「凡庸な技術者」もいるが、優秀なのも居る。

**デフォルトの名無しさん** · 2023/04/22(土) 22:19:29.86

>>399
それはString内容が変わったり空になったら意味のないデータになったり無効メモリを指すから、非GC言語でその設計はよくないね
Rust本スレで話題があったようにもう少し詳細な用途毎にstring_cacheやtyped_arenaを使ったりそういう自作設計をして安全と効率を両立させるべきかと

**デフォルトの名無しさん** · 2023/04/22(土) 22:35:35.61

>>401
使ってる例が出始めたってだけで
GoogleやMicrosoftやAWSで書かれる全コードの何%なのやら...

**デフォルトの名無しさん** · 2023/04/22(土) 22:41:58.79

>>383
>マルチスレッドの主な用途は数値計算なんだけど
へぇーw

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

「数学的」な人だったかww

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

rustcがソースコードを採点してくれるのに
なぜ採点結果ではなく書いた文字の量を競っているんだ

**デフォルトの名無しさん** · 2023/04/23(日) 00:09:49.30

>>399
>文字列全体（String）とその一部の参照（&str）を同じ構造体に詰めないとか
JavaやC#でそういうことする？？

**デフォルトの名無しさん** · 2023/04/23(日) 00:35:50.04

>>408
例えばURL全体を受け取ってパースした結果の部分文字列を保持する場合とか

JavaとC#は全部Stringにするから関係ないけどRustで同じことをしようとしたときに
本体のStringと一緒に部分文字列の&strを持ちたいと考えるかもしれない

あと？を２つ重ねるとなんか頭悪そうに感じるからやめたほうが…

**デフォルトの名無しさん** · 2023/04/23(日) 00:46:01.33

>>409
完全にダメな設計だね
？？は皮肉だから

**デフォルトの名無しさん** · 2023/04/23(日) 00:52:26.01

オブジェクト指向全く関係ないな

**デフォルトの名無しさん** · 2023/04/23(日) 03:53:33.10

>>397
データ競合は実行タイミングや入力データなどによって発生したりしなかったりすることもある
だから実行してみて不具合が無ければ大丈夫というものではない

>>400
そういうお子様プログラミングしかしたことがないやつに複雑な状況でのコードは理解できないだろう

**デフォルトの名無しさん** · 2023/04/23(日) 08:58:13.51

>>380
>ただしRust以外の言語はデータ競合があっても検出できずに競合を起こしたまま動いてしまいバグとなる

Rustで実行時にデッドロックを回避する方法を教えてくれ

**デフォルトの名無しさん** · 2023/04/23(日) 09:05:15.73

デッドロックはデータ競合ではなく無関係
デッドロックはロック順序を守ることで防ぐ

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

rustコンパイラじゃ防げない

**デフォルトの名無しさん** · 2023/04/23(日) 10:01:44.66

Rust初心者だけど、シングルスレッドでしか動かさない場合にも、
マルチスレッドで起きるデータ競合を気にしてるってことよね
それはめんどくさくない？

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

気にしてるのはコンパイラ

**デフォルトの名無しさん** · 2023/04/23(日) 10:21:19.31

>>416
シングルスレッドでも起こる
データ競合が防げるというのはメモリ安全性の副産物

**デフォルトの名無しさん** · 2023/04/23(日) 10:47:08.19

ライブラリがマルチスレッドかもしれんだろ、そういうとこ油断しちゃだめだｗ

**デフォルトの名無しさん** · 2023/04/23(日) 10:59:51.10

>>418
>データ競合が防げるというのはメモリ安全性の副産物
関係ないのでは?

**デフォルトの名無しさん** · 2023/04/23(日) 11:05:41.04

>>391-392
Qi痛のネタ程度の話を論文って言っちゃう人って

>>396
それだ！

**デフォルトの名無しさん** · 2023/04/23(日) 11:26:29.64

フリーソフトで遊んでる場合にも、お金に関する問題を気にしてる奴が一番めんどくさいぞ

**デフォルトの名無しさん** · 2023/04/23(日) 11:41:38.27

各社だいたい優秀なんだろうけど、飲酒コーディングするような香具師も混じってるってことだよ
デバフだデバフｗ

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

参照のread-writeロックもどきは↓みたいなコードを防いでる

fn main() {
let mut a = vec![42];
let r = &a[0];
println!("{r}"); // 42
a.clear();
println!("{r}"); // もういないよ
}

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

a[0]をコピーまたはcloneできる場合にも&a[0]を使うのはめんどくさい
Tをコピーまたはcloneできる場合にもRefCell<T>を使うのはめんどくさい

**デフォルトの名無しさん** · 2023/04/23(日) 13:21:04.29

>>409-410
Rust の hoge()? って頭悪そうだよな

**デフォルトの名無しさん** · 2023/04/23(日) 13:43:48.93

C#は
int? hoge = null;
int fuga = hoge ?? -1;
まで進歩してるからhoge()?くらいなら余裕

**デフォルトの名無しさん** · 2023/04/23(日) 18:41:22.14

C/C++ で安全なコードを描ける人からすれば Rust なんてホント苦行でしかない
全然生産性上がらないぞω

**デフォルトの名無しさん** · 2023/04/23(日) 19:13:33.85

>>428
逆だな
C++で安全なコードを書ける人にとってRustは楽勝

**デフォルトの名無しさん** · 2023/04/23(日) 20:15:54.20

C/C++で安全なコードを描けると思ってるやつはもはやレガシープログラマー

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

つまり結局のところRustは苦しいと
そう思わないやつはC++で安全なコードを書けると思い込んでいる人であると
それか大したプログラムを書いたことがないか

**デフォルトの名無しさん** · 2023/04/23(日) 20:38:12.61

酷い目に遭ったことがないんだろう
慣れるまでに、自分が踏み抜いたり、他人が踏み抜いたとばっちりを食ったりするんだけどね

ごりごり汗が書けるやつは、たしかにレガシコーダだな
ちゃんと書けるなら、レガシにしてレジェンド

**デフォルトの名無しさん** · 2023/04/23(日) 20:42:24.61

Cは複雑なGUIを作らず、スクリプトのインタプリタを作るから結構安全だ
外見重視でインタプリタ言語嫌いなOOPが危ない

**デフォルトの名無しさん** · 2023/04/23(日) 22:43:02.30

>>425
コピーできる型でコピーが望ましいならそうすればいいだけだぞ
シーケンシャルにポインタを進めていく方が望ましい時はコピー可能か否かに関係なく参照のイテレータを使えばいい
コピーできる型で内部可変性が欲しいならばRefCellではなくCellを使え

**デフォルトの名無しさん** · 2023/04/23(日) 22:48:39.88

>>428
コンパイル時点でメモリ問題やデータ競合の無いことが保証されるRustはもちろん開発効率がよい
時間と手間の大きな節約になる

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

「C/C++ で安全なコードを描ける」=「メモリ問題やデータ競合の無」く書ける
なのでは?
経験を積むと書けるようになるよ

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

>>436
その根拠のない自信とミスが多くのバグとセキュリティホールを生んできた
一方で経験を積んだ者ならばC++でもRustでもどちらのコードも書けることも事実その通りだ
ならば客観的に各種問題のないことが保証されているRustのコードの方が選ばれる

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

経験を積むと安全なコードを書けると言ってる人は過去に書かれたコードのメンテとかも経験してるんだろうか
当然前後のコードを全て確認したうえで安全なコードを書いてきたんだろうけど
確認作業の範囲を少しでも減らしたいとか考えたことないのかな

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

俺がRustへ移った理由もそれ
開発でも保守や更新でも言語システムが自動的に確認作業をやってくれる
こちらはビジネスロジックのテストだけに専念できて非常に効率がいい

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

>>437
根拠は自分の経験だよ
お前のことは知らんよ

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

>>438,439
他人のコードについての見解は一理あると思う

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

翻って>>382だな

**デフォルトの名無しさん** · 2023/04/24(月) 00:16:29.06

経験深いC++プログラマーにとって、Rustは難しいものでもなく特にウザいものでもないよなあ。
部分的に各片方が書きやすい面もあるが、フィフティフィフティでどちらにも分はある。
結局Rustコンパイラが色々と保証してくれる信頼性と効率性だけが決定的な差異で、Rustへ進む流れだろな。

**デフォルトの名無しさん** · 2023/04/24(月) 00:17:39.52

完璧なC++のコードを書けるやつならまぁそうすればいいけど、同僚も完璧に書けるかな？って話だよな
同僚も完璧なのが書ける？　でも同僚もお前のことを「完璧に書ける奴」と認識してるとは限らない

そんで慢心の発生は自分自身を完璧と信じてるかと関係なく起こるわけで

**デフォルトの名無しさん** · 2023/04/24(月) 00:25:06.29

普通にGC付きの言語を使えばそんなウジウジしなくていいのに
システムプログラマ以外にはrustもC++も縁遠い

**デフォルトの名無しさん** · 2023/04/24(月) 00:29:33.47

速度を抜きにしてc++の利点は生ポインタを使って直感的にコードを書けたりするところにもあったと思う
それが今は捨てられたのでまあ他の言語でもいいじゃんと思う

**デフォルトの名無しさん** · 2023/04/24(月) 00:40:24.53

>>445
従来の非GC言語と比べて
Rustは以下の点でGC言語に近くなっていて書きやすいわー
・メモリや競合など色んなことをRustは安全だと保証してくれる
・メモリ解放も常に何もしなくてよくてRustは完全に自動でやってくれる
・各GC言語のモダンな機能がRustも取り入れていて便利に使える
という感じ
対象言語やコードによっては数倍Rustが速くて
エコでリソースコストも少なくて金銭的コストも数分の1になるのが魅力的

**デフォルトの名無しさん** · 2023/04/24(月) 00:40:47.69

C++にあってRustにない特徴はCを包含していること
Rust派は欠点と考えているだろうが
この特徴がなければ普及しなかっただろうね
ハゲの慧眼だよ

**デフォルトの名無しさん** · 2023/04/24(月) 01:05:01.61

>>445
そのへんC++はGC言語と比べて余分なコードレビューコストやメモリ関連のデバッグコストなどもかかっていたけど
Rustはコンパイラがやってくれるから困っていない

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

個人的には、Rustは、メモリ安全であると言う以外に魅力は無いと思ってる。
しかも、Java、C#、JS、Ruby、PHP、Perl、Python、Kotlin、Go
は全てメモリー安全。

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

それに、C++やCでずっとプログラミングしているが、メモリー関連バグが
生じる頻度は非常に低い。大部分はロジックのバグで、少しずつテストを
するのでその段階で取れることが多い。
メモリー関連バグが起きる場合でも、VisualStudioでは容易に原因箇所が
発見できることが多い。
特にC++では、デストラクタの中にポインタ型のメンバ変数の delete 文を
書いておけば、メモリー関連バグはまず起きない。
その意味では、C++は、それで賄えない特殊な場合を除いては、メモリー解放が
自動化されていると言える。

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

メモリー関連バグは、VisualStudioではコンパイル段階での静的な発見は一般的
には出来ないが、動的には、デバッガを使うことでかなり高い確率でメモリー
関連バグの原因箇所が分かる様になっている。
昔、C言語を使っていて、メモリー関連バグで困るのは、全く原因が分からないような
ことがありえることであったが、C++では、classのデストラクタの中にdelete文を
閉じ込めることによって、メモリー解放が自動化される。
だから、メモリー関連バグが起きるのは、それでまかなえない場合に限る。
同じ関数の上の方とnew文と下の方でdelete文を単純に対応させて書けば
「どう見ても安全」のような書き方ができる。
また、それで書けない場合でも、delete文を、EndXxx()のような「終了関数」
の中だけに書く様にすれば、滅多なことでメモリー関連バグは入らない。

これでも原因不明なメモリー関連バグが起きた場合でも、VisualStudioの
場合はあの手この手で、メモリー関連バグの原因を動的検査で特定し易くなっている。

**デフォルトの名無しさん** · 2023/04/24(月) 05:06:00.35

CやC++でメモリー関連バグに悩まされている人は、gccなどのフリーのコンパイラ
を使っている人ではないかと思う。
Visual StudioのIDEとデバッガを使えば、メモリー関連バグで悩むことは滅多に
なくなる。
それと、C++の場合は、正しい流儀で書けば、そもそもメモリー関連バグが
入り込む可能性が劇的に減る。

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

gccとVisual Studioのメモリー安全性に関する違いは、ヒープメモリに対しての
さまざまな工夫に有る。プログラマが明示的に初期化して無い部分には 0xcccccccc
のようなデータで初期化するコードをコンパイラが書きこむ。
それに、ヒープメモリーのリンクチェーンにも何らかの工夫がされている。
「デバッグビルド」では、そういった構造を、適切なタイミングでチェックする
コードが自動的に付加されるので、「おかしなことをやった直後に近いタイミングで」
IDEが「異常」を報告してくれる。
また、MFCの場合は、さまざまな場所にASSERT() 文で検査コードを入れてあるので、
メモリー関連バグも気付き易い。なんらかの異常は、早い段階で発覚するので、
原因がどこにあるかが特定し易くなっている。
このおかげで、多くの場合は、異常が発見された直前の処理を疑えばよくなっている。

**デフォルトの名無しさん** · 2023/04/24(月) 05:45:34.11

SNSで、「オブジェクト指向は意味が無く、むしろ駄目」というような話題が
出ることがあるが、C++のclassのデストラクタは、メモリー安全性に大きく
寄与しており、Cよりもメモリー安全になっている。
逆にclassがなければ、メモリー管理にバグが入りやすかったことであろう。
それだけでも、「オブジェクト指向」の意味がある。

**デフォルトの名無しさん** · 2023/04/24(月) 07:52:58.48

気をつければ大丈夫というのはプログラマーの考え方ではない
少なくとも向いてない

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

c++erにとってRustはウザいけど、他人にライフタイム管理を強制できるというメリットが大きい。
基本的にRustは他人にやらせるための言語。

**デフォルトの名無しさん** · 2023/04/24(月) 08:23:30.04

ツールやコンパイラがいろいろやってくれる優位性を語っておいて
Rustの利点に目をむけないって意味わからんなあ

**デフォルトの名無しさん** · 2023/04/24(月) 08:50:49.89

セキュアコーディングについて、誰かがキメてくれるというのがデカい
Rustはそれをやったんだ

欲しいのはunsafeのやり方であって、それができるんならC++でもいいんだよ
そうと決まれば、処理系も実装者もどんどん追従する

だから、採用すると言い切ったんだから、APIもとっととRust化してほしい
そうしたら速攻で、unsafeがC++にも来る

**デフォルトの名無しさん** · 2023/04/24(月) 09:49:02.72

>>459
>セキュアコーディングについて、誰かがキメてくれるというのがデカい
>Rustはそれをやったんだ
まぁある方がマシだけどもrustcが検出してくれるのは一部で
>>451に指摘されてるように頻度が少ないので有用性は俺も疑問に思ってる
（率直に言ってあんまり嬉しくない）

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

Rustを難しいとかウザいとか言ってる人は単にまだ慣れていなかったり知識が足りていないだけだ
C++できちんとコーディングできていた人にとってRustは難しくなく慣れと知識を獲得した後はC++よりも全体効率がアップする
したがってRustを難しいとかウザいとか言ってる人の発言は全て無視してよい

**デフォルトの名無しさん** · 2023/04/24(月) 10:18:34.43

>>461
覚えるの面倒くさいねん
将来性もまだちょっと...
だけど面白いので取り入れられるところはC++に取り入れてるよ
Arcパクらせて頂いた

**デフォルトの名無しさん** · 2023/04/24(月) 10:33:40.77

>>1 のとおり、職務とかでやれといわれたらやるんだけど、
Rust勢がいうとおり、デファクトスタンダードになりそうなら、C++にもほぼ間違いなく「来る」だろうしねえ
それなら、安全になったC++でいいや、Rustに限らず、新言語とかたりぃな、とかは思う
新言語覚えるかわりに、安全になったC++勉強しなきゃだし、と言ってもいい

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

C++とRustの比較は簡単

両方使いこなせるプログラマーはどちらを選んでいるか？
・多くのことをコンパイラに任せられて開発保守効率の良いRust
・その逆でそれらの開発保守効率に劣るC++

企業はどちらを選んでいくか？
・客観的に各種の安全性が保証されるRustで書かれたコード
・その逆で各プログラマーの腕により保証されるC++で書かれたコード

プログラマーと企業どちらの視点に立っても
RustもC++も選べる環境状況にあるならば
新規のプロジェクト(案件)でC++を採用する動機は完全に無くなった

**デフォルトの名無しさん** · 2023/04/24(月) 10:47:20.17

>>464
企業の視点に立つとRustはプログラマが確保できんだろw