結局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/20(木) 21:38:15.36

＞その場合でも、範囲内のインデックス値しか来ない構造ならば
この判断を誤ると結局脆弱性が埋め込まれそうだけど、
チェックを忘れることに比べれば起こりにくいのかもね

**デフォルトの名無しさん** · 2023/04/20(木) 21:40:24.96

>>301
オーバーヘッドに関してはC++もRustも最小限にすることができて同じ
安全性に関しては範囲外アクセスが生じうるC++のみ安全でない

**デフォルトの名無しさん** · 2023/04/20(木) 21:40:47.43

私は違いがサッパリ分からんぞ

**デフォルトの名無しさん** · 2023/04/20(木) 21:44:22.16

>>305
>安全性に関しては範囲外アクセスが生じうるC++のみ安全でない
範囲外チェックなしでインデックスでアクセスしたら
Rustも危険なのでは?

**デフォルトの名無しさん** · 2023/04/20(木) 21:51:17.50

>>304 >>307
その場合は、一般的にunsafeを閉じ込めてsafeなインタフェースを提供する新たな型をモジュールとして提供する
そのモジュール部分のみを人間が安全性を保証する形になり、その利用者側はRustコンパイラが安全性を保証する
したがってそれを利用する側のプログラマーのミスで範囲外アクセスなどが起きることはない

**デフォルトの名無しさん** · 2023/04/20(木) 21:56:16.00

>>308
今はそのunsafeに閉じ込める部分に
C++とRustで差があるのか無いのかを議論している
お分かりかな?

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

>>307
私はせっかちなので自分で議論を進めると（と言っても私はRustは分からんのだが）
範囲外チェックなしでインデックスでアクセスできる -> Rustも同様に危険
範囲外チェックなしでインデックスでアクセスできない -> Rustはオーバヘッドがある
ということになる

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

複オジの説明がクソだから伝わらなくても仕方ない

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

>>295
>C/C++とは異なり、Rustは範囲外メモリアクセスを絶対に起こさないことが保証される点が決定的な違い
によると後者ってことになるが

>>300
>Rustもインデックス範囲内チェックの有り無しを選べる
によると前者ってことになる

矛盾しとる
どっちや?

**デフォルトの名無しさん** · 2023/04/20(木) 22:18:01.10

C++に勝ってると主張するために普段はunsafeのことを脇に置いてメリットばっかり語ってるのに
性能で負けてるって言われて悔しいからって急にget_uncheckedの話持ち出すからややこしいことになるんじゃな

**デフォルトの名無しさん** · 2023/04/20(木) 22:26:58.01

昔LISPもそれでCと張り合ってたな
歴史は繰り返すんやな

**デフォルトの名無しさん** · 2023/04/20(木) 22:36:42.26

話は簡単
RustはVecもそこで使われるスライスのイテレータも
unsafeなコードを閉じ込めてsafeなメソッドを提供している
だからその部分の作成は人間がミスるとおしまい
逆に言えばその狭い範囲のみ人間が頑張って安全性を保証すればよい

一方でそれらVecやイテレータなどを利用する一般のプログラマーは
そのsafeなメソッドを使っている限り絶対に安全なことが保証される
もし問題があればコンパイラがエラーを出すので常に安全となる

結論
RustもC++も最小限のオーバーヘッドが可能で同じ
しかしその安全性は全く異なる
C++は常にミスったらおしまい
C++はプログラム全体に対して人間が安全性を保証しなければならない
Rustはsafe利用者がミスることは絶対になくコンパイラがエラーを出してくれる
Rustはunsafe利用部分のみ人間が安全性を保証しなければならない

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

>>315
一生懸命書いているところを申し訳ないが
>>276の話で始めたように今は
コンパイル時にチェックできない状況の話をしているんだ

**デフォルトの名無しさん** · 2023/04/20(木) 22:43:11.74

>>313
そのunsafeなget_uncheckedの件も同じ
unsafeを利用してsafeを提供する人だけがその安全性の保証できるコードを書けばよい
一方でそこで作られたsafeなものを利用する一般プログラマーはミスってもコンパイラがエラーとして止めてくれる

**デフォルトの名無しさん** · 2023/04/20(木) 22:44:27.28

>>98y/hYCF
>>312はどっちや?

**デフォルトの名無しさん** · 2023/04/20(木) 22:44:35.26

>>316
Rustではコンパイル時に安全性を必ずチェックできる

**デフォルトの名無しさん** · 2023/04/20(木) 22:48:29.32

>>319
実行時にサイズを入力するのにかい?
Rustコンパイラは未来が分かるのかw

**デフォルトの名無しさん** · 2023/04/20(木) 22:49:34.33

>>318
どちらも正しい
効率的なunsafeを使いそれを閉じ込めることで効率的なsafeを提供することがRustの基本
一般プログラマーはそのsafeのみ使えば書いたコードの安全性が保証される

**デフォルトの名無しさん** · 2023/04/20(木) 22:55:08.59

>>320
最初に出ているこのコードのことだろ
for n in v.iter().take(input_size) {
println!("{n}");
}
もちろんinput_sizeの値に関わらず静的に安全なコードだ
そしてインデックスは用いないのでインデックス範囲外チェックは無い
Cでポインタで書いたときと同じ速度になる

**デフォルトの名無しさん** · 2023/04/20(木) 22:56:41.18

議論にならんのでスルーして
彼の主張は（正しいのかは分からんが）
要するに範囲外チェックなしでインデックスでアクセスできるということだから
Rustも同様にこの点は危険ということになる

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

>>322
今はRustでも危険に書けるでしょ?って話をしている
イテレータを使えば安全なのでこう書くべしっていうのなら
それはC++となんら変わらない

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

>>323
Rustはチェックしないけど安全な型を作れるよ
例は何でもいいんだけど例えば将棋盤を表す型を9✕9＝81のインデックスを考えてみよう
その将棋盤の型に対するインデックスの型を新たに作ってメソッドとその操作を限定することでusize化した時に常に0～80の値しか取らない型を作る
あとは unsafeを使ってsafeかつ効率的な実装
impl std::ops::Index<将棋盤インデックス型> for 将棋盤 {
type Output = 将棋駒;
fn index(&self, index: 将棋盤インデックス型) {
unsafe { self.0. get_unchecked(index.to_usize()) }
}
}
これで将棋盤型のアクセス時にインデックスの範囲内チェックは行われずに効率的かつ安全
（将棋盤インデックス型の定義によりindex.to_usize()は常に0～80の値のみをとるため）

将棋の実装を実際にしたことはないが
似たようなデータ型は実際に何度か書いたことがある

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

C/C++にも、-fsanitize=address ってのが後追いながらちゃんと入ってきてる
その価値は認めていいし、しかし、差は縮まりつつある

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

Rustでも、unsafe が抜け穴になるよね、って反論はつまり、
コピペ勢に対して、「いやみんなばんばんunsafe使っちゃうからダウト」って返してるってことｗ

ここにたまるようなヤツは、必要に応じてモジュール毎にON/OFFくらいできるヤツ
熱心に張り合うまでもなく、有意義に使うよ

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

わずかなunsafe封じ込め部分だけに注力することで、効率的なsafeを作ってしまえば、safe利用者はコンパイラに安全性の保証を任せられることがRustの最大のメリット

**デフォルトの名無しさん** · 2023/04/21(金) 00:05:38.80

わずかになってくれればいいね

ああ、また釣られてしまったｗ

**デフォルトの名無しさん** · 2023/04/21(金) 00:13:14.15

>>325
安全にも書けるのは分かる（それはC++も同じこと）
9yNISOE6の主張が正しいと仮定して
Vecのアクセス範囲に関して危険にも書けるけど
Rustコンパイラは何もできないよねって話

**デフォルトの名無しさん** · 2023/04/21(金) 00:14:20.12

まちごうた
-9yNISOE6の主張が正しいと仮定して
+98y/hYCFの主張が正しいと仮定して

**デフォルトの名無しさん** · 2023/04/21(金) 00:14:28.54

最適化はunsafeというのはRustではほぼ客観的事実に近い

C++で似たような意見を言えば、最適化の足を引っ張る陰謀と見分けがつかない者もいるだろう

**デフォルトの名無しさん** · 2023/04/21(金) 00:19:35.15

範囲がconst/constexprであれば、チェックコストはゼロにしうるのでは
そこにコストをかけてでもsafeにしましょうというのがモダン(含Rust)
そこにコストがかからないように書いてナンボなのがC++(失敗時は: 安全だがコストが生じる)

**デフォルトの名無しさん** · 2023/04/21(金) 00:58:19.29

関係あると思うのできかせて

いまさら人に聞けないんだが、Intel MPXってのが早々にディスコンになったのは、
・MPXでも抜けがあることがわかった
・いまやパイプライン? が優秀すぎて、MPXでもソフトウェアサニタイザでもそんな変わらなかった
っていう理解をしてるけど合ってる?

**デフォルトの名無しさん** · 2023/04/21(金) 01:08:57.82

英語版wikiだと穴が多すぎて実用に耐えなかったって書いてるな
日本語版はなかった
https://en.wikipedia.org/wiki/Intel_MPX

**デフォルトの名無しさん** · 2023/04/21(金) 02:33:15.05

かのIntel(当時)が頑張ってもこんなもん(こんなことになる)か
難しいもんなんだな。。

俺にできないだけで、本気出せば難しくないもんかと思ってたのに

**デフォルトの名無しさん** · 2023/04/21(金) 05:31:12.23

具体的に誰が頑張ったのか全然わからない
いまさら英雄化してももう遅い

**デフォルトの名無しさん** · 2023/04/21(金) 09:34:15.68

>>330
>安全にも書けるのは分かる（それはC++も同じこと）
C++でもRustと同じレベルで安全に書けるというのはさすがにウソでしょ
複オジの説明がショボいからと言ってウソはダメだよ

**デフォルトの名無しさん** · 2023/04/21(金) 10:24:01.60

play.rust-lang.org で
use rstk::*; とか
use wx; とか
もちろん出来ない訳だが
use したときに一瞬一覧で選べるものが出て来るので
これの一覧をテキストファイルで欲しいんだが
どこで観れますか？

**デフォルトの名無しさん** · 2023/04/21(金) 10:33:13.77

>C++に勝ってると主張するために普段はunsafeのことを脇に置いてメリットばっかり語ってるのに
>性能で負けてるって言われて悔しいからって急にget_uncheckedの話持ち出す

ほんそれ

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

>>339
crates.ioのダウンロードTop100とその依存クレート
入れ替えとかどう対処してるのかは知らん
playgroundのヘルプにリスト(Cargo.toml)へのリンクがある

**デフォルトの名無しさん** · 2023/04/21(金) 15:41:39.16

>>341
thx!
自分用のCargo.tomlに置き換えたいときは？

**デフォルトの名無しさん** · 2023/04/21(金) 16:08:14.43

>>342
それは自分の環境でどうぞ

**デフォルトの名無しさん** · 2023/04/21(金) 21:37:21.45

控えめに言って Rust は超マゾ言語

**デフォルトの名無しさん** · 2023/04/21(金) 23:59:16.40

C++もRustも基本的には変わらん
C++で常に安全に書ける人にとってライフタイムなんてすぐ理解できて困らん普通のことだった
Rustでいいと思ったのはイテレータメソッドチェーンのシンプルさとか
あらゆる部分でパターンマッチングできる点とか

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

GC言語は良いと思うし使いけど可視化する気にならない
GC言語が多過ぎるから
Python並みの人気でも過半数に支持されるとは思えない

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

ライフタイム付き再帰構造体を再帰関数で回してlifetimeのvarianceで苦しむまでがボローチェッカチュートリアルです

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

Rustの弱点突きまくり

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

言語(Rust含む)がせっかく親切にしてくれてるのに、その虚を突く

…っていうか、虚を天然で踏み抜いちゃうのが、シロウトなんだよなあ俺含む(自戒

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

PythonのAI系のライブラリを
rustで作り直したら爆速になるのかな？

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

大人気のCUDA版は、CUDAでできてるから Pythonで操ってるだけ

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

C++のライフタイムが本当に簡単ならライフタイム系のバグを100%検知できるツールなんて簡単に作れるはずだよね？

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

>>352
そういう意味ではなく逆だろ
C++でもともなコードを書けているプログラマーはRustでライフタイムをすぐ習得してしまう話だろう
逆にライフタイムを難しいと言ってるプログラマーはC++で込み入ってくると正しいコードを書けない

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

>>352
いくらか指針・実装はあったんだけど、決定打に欠いた
いろいろと自由すぎたんだよ

Rustのやり方が業界標準になったら、C++がそれを取り込むのは早いと思う

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

varianceをOOPにたとえると
変数の型を宣言できないが基底クラスなら宣言できる
という理解でいいんでしょ
変数の型を宣言するツールを簡単に作れるかが問題なのでは

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

ポインタと同じでライフタイムも概念を理解するのは何も難しいことはない
バグなしで使いこなすのが難しいだけ
それだからRustは厳しめのルールにしてコンパイラでチェックする
C++が脆弱性を量産してきた負の遺産を継承しないためにね

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

>>356
所有権システムは単純に使いづらい
インスタンス作るときのデフォルトにされるのはちょっと...

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

少し前にvectorの再配置の例が出てたけど
他で参照してる間にデータを操作して参照がおかしくなる事故が後を絶たないから仕方ない
普通のイテレータで走査してる最中に要素を削除したりとか

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

>>358
参照カウントが2以上ならエラーでいい
実行時エラーなら難しくない
コンパイル時が難しいだけ

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

>>358
それはどういう状況かな?

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

RustはまだMicrosoftがVisualRust出してないしなあ…

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

Microsoft方言なRustとかはいらん

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

>>357
所有権システムはC++もRustも基本的に同じで難しいところはない
表記方法は両者で異なるがRustの方がシンプルに整理されていてわかりやすいだろう

そのインスタンスの挙動についてもRustは新たな型宣言時に特に指定しなければムーブ型になるが
コピー型にしたいならばこう宣言すれば挙動がムーブではなくコピーとなる
#[derive(Copy, Clone)]
struct Foo(i32, i32);
let mut p = Foo(123, 456);
let q = p;
p.0 = 789;
assert!(p.0 != q.0);
assert!(p.1 == q.1);

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

>>359
実行時に参照カウントが2以上ならエラーとなる型もRustでは作れるよ
でももっと便利な仕様「実行時に(可変でない)参照カウントはいくつ増えてもOKだけど、可変参照を得る時だけは独占的つまり参照カウントが0でないとエラー」がもっと便利
標準ライブラリRefCell<T>がその仕様そのままで
RefCell<T>自体の可変参照を持っていなくて(非可変)参照を持ってるだけでもTを書き換えることができちゃう
Rustの厳しい可変参照ルールを無視できるから便利だね
いわゆる内部可変性と呼ばれる型の一つ

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

>>364
Rc<T>とRefCell<T>に互換性のようなものはないから「もっと便利」というのは違和感がある

**デフォルトの名無しさん** · 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で書かれる全コードの何%なのやら...