C++ vs Rust

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

競え

**デフォルトの名無しさん** · 2021/11/22(月) 21:17:24.64

Rustの実装 (>>257) はポインタでの直接アクセスではなく配列への添え字アクセスだからオーバーヘッドが大きいとか言い出したらみんなで笑ってあげましょう

**デフォルトの名無しさん** · 2021/11/22(月) 21:26:20.75

>>257
独自のLinkedListで、実装としては配列を持っていて、
ノード間が参照でリンクされておらず、添え字番号でリンクしており、
get(), set()が添え字番号を返して配列要素を返しているので
ゼロコストではないね。

struct LinkedList<T> {
　first_idx_a: Option<usize>,
　first_idx_b: Option<usize>,
　elems: Vec<Elem<T>>,
}
struct Cursor {
　a_idx: usize,
}
fn get(&self, elem: Cursor) -> &T {
　&self.elems[elem.a_idx].data
}
fn set(&mut self, elem: Cursor, data: T) {
　self.elems[elem.a_idx].data = data;
}

**デフォルトの名無しさん** · 2021/11/22(月) 21:27:13.68

>>261
ゼロコストが謳いなのに、ゼロコストで無い。

**デフォルトの名無しさん** · 2021/11/22(月) 21:27:14.40

>>257
それで実装も動作も良いけど
_bはどちらも不要
_a.0と_a.1はそれぞれprevとnextと書いたほうが読みやすい

**デフォルトの名無しさん** · 2021/11/22(月) 21:33:11.94

>>264
_b は単一の要素が複数のリストに属するという要件に対する実装ですね
面倒だったのでメンバーだけ用意して実装はしてないですが
タプル使ってるのも構造体定義が面倒だったため
というかできるできないを実証するための例なので細かいところは適当です
お好きなように修正してください

>>263
>>245 の
> C/C++/Java/C#/JS/Ruby/Python など多くの言語では可能だが、Rust
だけが不可能
> なので、Rustだけが仲間はずれであり、他の言語でできる事ができない。

というのはほかの言語ではゼロコストで実装できることを意味していますか？
それともRustでも実装できることを認めた上でのただの負け惜しみですか？
はたまたこれを書いたのは自分とは別の人と主張されるのでしょうか

**デフォルトの名無しさん** · 2021/11/22(月) 21:34:40.04

>>262
ゼロコストを定義してください

**デフォルトの名無しさん** · 2021/11/22(月) 21:37:06.49

>>265
後半のあなたの主張、おかしくないか。
Rustの参照では無い独自の参照風の様な構造を添え字番号で実装してしまって、
C言語より速度を落としているのだから、ゼロコスト性に反してる。

**デフォルトの名無しさん** · 2021/11/22(月) 21:38:01.88

>>266
参照に関しては、参照がC言語の生ポインタと同じ速度で扱えること。

**デフォルトの名無しさん** · 2021/11/22(月) 21:38:56.97

>>267
あらゆる言語の中でRustだけが実装できないという主張は撤回されて
CにRustは劣るという主張へと変更されるのですね？

**デフォルトの名無しさん** · 2021/11/22(月) 21:49:14.11

>>257
elements_aはinto_iterにしたらあかんの？と思ったけど
2つ持った時の前半用として用意した意味なのかw

**デフォルトの名無しさん** · 2021/11/22(月) 21:56:48.89

>>269
1. データを格納している場所が配列になっているが、動的に長さを長くしようとすれば
　動的配列と同様のコピー動作が生じてしまうから、その実装は、本来のLinkedListの
　性質とはかなり異なる。リンクリストは速度的に安定である事が重要なのに、
　この性質により、動的配列と同様に、時々大規模コピーが生じて、スパイク的に
　速度が遅くなる減少を伴うことになってしまう。このようなスパイク的な
　速度低下は、twitterかFacebook のどちらか忘れたが、どっかのSNSでも問題
　になっていた。
2. アクセスするときに、番号を配列のアドレスに変換する動作を毎回行っている。

**デフォルトの名無しさん** · 2021/11/22(月) 22:00:19.83

>>271
[補足]
誤解を招いて議論に混乱を来たしそうなので捕捉しておくと、
271の2で書いた「番号」は、リンクリストの先頭からの通し番号の事ではなく、
今回示されたリンクリスト風のコードで、内部で用いられている配列の添え字番号
のことで、リンクリストの先頭からは、辿っていっても、連続した番号には成ってないもの。

**デフォルトの名無しさん** · 2021/11/22(月) 22:05:48.24

>>271
あらゆる言語で実装できないがRustでは実装できない
他の言語だと O(1) だが Rustだと O(N) になる
という主張を撤回されたと理解しました

そういうことでしたら私の方から言うことはなにもありません

またアロケーションについてはVecを実装が工夫されたコンテナ型に変えることで対応できそうですね
実装詳細のないまま議論してもしょうがないトピックなのでこれ以上こちらからレスを重ねることはやめます
ありがとうございました

**デフォルトの名無しさん** · 2021/11/22(月) 22:10:00.62

>>271
[追加]
3. そこにさらに削除メソッドを実装したとしよう。
　削除したノードに対する番号が、どこかのCursorの中にまだ生きた状態に
　なっている場合、ダングリング参照と似た現象が起きる。
　削除したノードの中を参照できてしまうのだ。

**デフォルトの名無しさん** · 2021/11/22(月) 22:15:27.68

>>273
その主張、Rustの中に超軽量のインタプリタの様なものを載せておいて、
そのインタプリタの中ではランダムアクセスがO(1)のリンクリストが
完全に実装できることを示しただけだね。
しかも、追加すると、時々、大規模なメモリーコピーが生じるし。
newやmallocではそのようなメモリーコピーは生じない。
ノードを追加しても、リンクリスト中の他のノードの本当のマシン語レベルでの
線形アドレスが固定で変化し無いし。
あなたの実装では、それが変化してしまう。相対アドレスは変化しないが。
ベースアドレスが変化している。

**デフォルトの名無しさん** · 2021/11/22(月) 22:19:00.36

>>274
generational arenaという手法を利用することでダングリングポインタ的アクセスを検知してハンドリング可能になります

**デフォルトの名無しさん** · 2021/11/22(月) 22:19:03.44

>>274
[補足]
実質的なダングリング参照が起きるということは、Rustのもう一つの柱である
ところのメモリー安全性が部分的に壊れてしまってるということだ。

**デフォルトの名無しさん** · 2021/11/22(月) 22:23:12.75

>>276
動的コストを掛けていいなら、C++でも安全性の高いものは作れるぞ。
ポインタも正しいメモリーブロックを指していることを動的に確認した後で
実際に参照するようなことは、C++でも出来るから。
Rustも配列の範囲チェックはやっているが、配列以外のアドレスでも、動的に
チェックしようと思えばいろいろなチェック法はある。
その一つの方法が、アドレスではなく、あなたが書いたような配列の中の
番号方式にしてしまうこと。
番号に対する配列要素がNULLになっていれば、動的にエラーを出力して
アプリを停止させる、などの方法が有る。

**デフォルトの名無しさん** · 2021/11/22(月) 22:25:32.33

>>278
Rustの zero-cost abstraction はあなたの期待するような物ではありませんでした
残念でしたね

**デフォルトの名無しさん** · 2021/11/22(月) 22:36:23.68

>>265
>> C/C++/Java/C#/JS/Ruby/Python など多くの言語では可能だが、Rust
だけが不可能
>> なので、Rustだけが仲間はずれであり、他の言語でできる事ができない。
>というのはほかの言語ではゼロコストで実装できることを意味していますか？
>それともRustでも実装できることを認めた上でのただの負け惜しみですか？

分かった。ゼロコストで無くて良いなら Rustでも実装できるということだね。
なるほど、今回の実装法のような裏技の発想は無かったよ。それは認める。
でも、ゼロコストでなくなるということは、RustがC/C++の代替になるという
説には反することになるね。

それと、C++, Java, C# では最初から標準ライブラリ的なもので最初から実装済み
なのに対して、あなたのやり方は、少なくとも標準のLinkedListではないね。
Cursorも標準のものとは別。

**デフォルトの名無しさん** · 2021/11/22(月) 22:37:35.24

結局何がしたいのよ
ノードへの参照を持ったままリストを変更したいの？

**デフォルトの名無しさん** · 2021/11/22(月) 22:44:50.09

>>281
何がしたいって、C/C++/C#/Javaでは、LinkedListへのアクセスがO(1)で
自由自在に出来るのに、標準のRust実装では出来ないことが問題なんだ。

それに、今回示された実装法では、内部では配列で実装されているから、
ノードを追加してい言って、配列の要素数を超える時には、新しい配列を
コピーして内部でコピー動作が生じる。これは、C++のnewよりも遥かに
遅い動作になってしまうし、スパイク的に時々生じるから速度的な安定性
が求められるソフトでは好ましくない現象。

また、実質的なダングリング参照的が生じることも指摘した。

結論は、このやり方で、C/C++などと同じO(1)にはなったものの、安全性も失われ、
ゼロコスト性も失われ、C/C++の実装に比べて速度的に不安定でありスパイク的に
遅くなるということだ。

**デフォルトの名無しさん** · 2021/11/22(月) 22:51:04.06

>>282
「LinkedListへのアクセスがO(1)で自由自在に出来る」
が正確にはどういう意味かと聞いているんだ

>>257の実装は忘れなさい

**デフォルトの名無しさん** · 2021/11/22(月) 22:52:27.47

>>281
>ノードへの参照を持ったままリストを変更したいの？
もちろん、それもある。

**デフォルトの名無しさん** · 2021/11/22(月) 22:56:03.63

デマを流すのはゼロコストなんだから相手にした時点で負け

**デフォルトの名無しさん** · 2021/11/22(月) 22:57:09.11

>>283
>「LinkedListへのアクセスがO(1)で自由自在に出来る」
>が正確にはどういう意味かと聞いているんだ

Cの場合、ポインタでアクセスすれば、O(1)でリンクリストの
ノードを参照できるし、削除も出来る。
削除しても、他のノードのアドレスは変化しないから、ポインタも
書き換える必要も無い。
配列だったら、削除するとそれより後ろのノードの番号が全て
変化してしまうので、書き直さなくてはならない。
リンクリストでも、先頭からの通し番号を識別番号に
している場合には、同様にそれ以後のノードの全ての番号を書き換えないといけない。

リンクリストのノードにO(1)でアクセスするというのは、ポインタでアクセスすれば
当たり前の事で、どう説明していいのか分からない。マシン語では、間接参照の
[アドレス]
だけの話だから。
コンピュータの基礎から学び直してもらわないと理解してもらえないかも知れない。
マシン語を学んで欲しい。

**デフォルトの名無しさん** · 2021/11/22(月) 22:57:21.67

コンテナと各要素の&mutと&が同時に取れない件はsplitして借用の単位を分けるべし
Vec::split_at_mutと同様の発想

**デフォルトの名無しさん** · 2021/11/22(月) 22:59:22.03

>>286
だからそれだけならCursorMutでできるんだって
でもダメなんだろ？
それはなぜ？

**デフォルトの名無しさん** · 2021/11/22(月) 23:01:06.85

>>285
どっちがデマだと思ってるのか知らんが、俺のはデマじゃないぞ。

実際に、今回の実装を示した彼は、俺の言ってることはある程度正しく理解していた。
つまり、基本的にデマじゃないということを理解した人がいるということだ。
ただし、彼は、ゼロコスト安全性である、ということを無視して独自実装したり、
参照を独自に修正したものを勝手に導入した誤魔化しがあったのが残念であった
だけだ。
つまり、俺の主張自体は、彼は本当は理解している。
理解しているが、悔し紛れに詐欺めいた独自実装をしたことだけが残念なだけだ。

**デフォルトの名無しさん** · 2021/11/22(月) 23:01:57.98

>>288
1つのリンクリストに対して、書き込み参照や読み込み参照を同時に複数持てない。

**デフォルトの名無しさん** · 2021/11/22(月) 23:13:17.79

>>290
デマを流すのはそろそろやめとけよ
RustはRefCellもあるし複数からポインタで指しつつ書き換えもできるぞ

**デフォルトの名無しさん** · 2021/11/22(月) 23:14:41.21

>>291
そもそも、RefCellは、動的チェックが入るからゼロコストではない。
C には存在しないコストが新たに導入される。

**デフォルトの名無しさん** · 2021/11/22(月) 23:15:37.93

unsafe で生ポインタ使えばCと同じ実装は確実にできるが

**デフォルトの名無しさん** · 2021/11/22(月) 23:15:41.59

リンクトリストな？

**デフォルトの名無しさん** · 2021/11/22(月) 23:16:05.08

>>292
何を言ってるんだ？
そういうコストかけずにどうやって排他制御するんだよ？

**デフォルトの名無しさん** · 2021/11/22(月) 23:18:27.46

>>295
そこはCだとプログラマが気をつけることで排他制御してるんだと思うよ
unsafe Rustでも同じだけど

**デフォルトの名無しさん** · 2021/11/22(月) 23:18:40.37

>>295
C++と同じ事が出来るのに「ゼロコスト」で「安全」、と謳ってるのが間違いだと
言ってる。
間違いというより、デマや誇大宣伝。

**デフォルトの名無しさん** · 2021/11/22(月) 23:21:22.25

>>290
そうだ、最初からそう言えばよかったんだ
蓋を開けてみればO(1)なんかまるで関係無いじゃないか

でそれに対して>>287という策があるわけだがどう思う？

**デフォルトの名無しさん** · 2021/11/22(月) 23:22:12.49

>>295
「排他制御」とは、マルチスレッドプログラミングで使う用語なのだが、
本当にその意味で使ってるか？

**デフォルトの名無しさん** · 2021/11/22(月) 23:22:18.49

>>292
ゼロコストって他のことでもそうだけど全くコストがかからないってことではない
必要最低限のことのみでそれ以外はゼロコストってこと
今回のRefCellならば並行プログラミングの時の書き換え競合が起きないことを保証する
RefCellはゼロコスト
ゼロコストでないと主張するならば他の対処方法を述べよ

**デフォルトの名無しさん** · 2021/11/22(月) 23:24:19.66

>>298
「策」があるっていうが、どんどん複雑化し、コストも増えているだろ。

**デフォルトの名無しさん** · 2021/11/22(月) 23:28:31.00

>>300
俺も正直言うとRefCellとか出てくると複雑すぎてよくわからなくなってくるが、
RefCellは内部可変性に対するものだから、並行プログラミングを使わない時
にも使うことがあるはずだが。

**デフォルトの名無しさん** · 2021/11/22(月) 23:28:31.66

Rustは安全性を追求した言語でC++と比較する物ではない。
比較するならRubyが妥当。

**デフォルトの名無しさん** · 2021/11/22(月) 23:30:51.55

>>303
つまり、CやC++の代替には成りえない。
アプリレベルであってもC/C++の全てをカバーすることは出来ない。

**デフォルトの名無しさん** · 2021/11/22(月) 23:33:19.88

コンパイラに安全性を保証してほしければ実行時のコストを払ってRefCellを使えばいいし、
そのコストを払いたくなければunsafe 使って自分で安全性を保証すればいいって話なんだが

**デフォルトの名無しさん** · 2021/11/22(月) 23:35:15.39

必要最低限のunsafeを使うのは大前提で、
それでもリンクリストがどうたらって話じゃなかったっけ・・・？？

**デフォルトの名無しさん** · 2021/11/22(月) 23:36:31.09

だからリンクトリストな？

**デフォルトの名無しさん** · 2021/11/22(月) 23:38:22.71

>>299
シングルスレッドマルチタスクでも競合は起き得る
そのため書き込み権限がある者がある瞬間に複数存在しないことを保証する(排他制御)ためにRefCellがある
マルチスレッドの場合は並列に起き得るからもっと厳しくてRefCellではダメでMutexやRwLockを使う

**デフォルトの名無しさん** · 2021/11/22(月) 23:39:08.56

Rustは安全性を追求した言語でC++と比較する物ではない。
比較するならVBAが妥当。

**デフォルトの名無しさん** · 2021/11/22(月) 23:40:06.95

RustがC++をライバル視してきて非常にウットオシイ。
貴様のライバルはJavascriptだろ。

**デフォルトの名無しさん** · 2021/11/22(月) 23:41:22.24

>>291
LinkedListの中のノードへの参照を10個持っている状態で、
その参照を使って1個のノードを削除しようとしてコンパイルは通るか？

**デフォルトの名無しさん** · 2021/11/22(月) 23:42:38.96

>>301
safeであるためには必要なコストだと思うけどね
mutabilityが前後のノードに影響するデータ構造だから仕方がない

**デフォルトの名無しさん** · 2021/11/22(月) 23:44:32.43

>>311
それCでもC++でもダングリングポインタ発生の駄目プログラマーパターン

**デフォルトの名無しさん** · 2021/11/22(月) 23:49:43.35

>>313
そんなことないぞ。
vectorと勘違いして無いか。

**デフォルトの名無しさん** · 2021/11/22(月) 23:55:11.62

>>311
参照先自体を削除するんじゃなくて、参照先からさらにnextとかprevたどってどっかのノードを削除するってこと？
参照先自体を削除するのはRustに限らず問題でるよね

**デフォルトの名無しさん** · 2021/11/22(月) 23:58:04.28

>>315
参照先を削除するのは普通なことで、安全に行えるぞ。
参照とは、つまり、識別番号の代わりに使うものだからな。
参照はオブジェクトに付けられた名前みたいなもんだから、
逆に言えば、参照先を削除できないなら、削除する方法がほぼ無い。

**デフォルトの名無しさん** · 2021/11/23(火) 00:00:50.13

何の話についてもまずは具体的なC言語のコードを示すべきじゃないかな
そうすればRustのコードを2種類みんなが出してくれるよ
　・1つは元のC言語と同じ安全度で場合によってはunsafeを用いて実装
　・もう1つはメモリ安全性を保証してunsafeを使わずに実装
つまり「C言語で出来ることはRustで必ず出来る」＋「Rustではメモリ安全性を保証した実装も可能」
明らかにC言語よりもRustの方が能力も高く優れている

**デフォルトの名無しさん** · 2021/11/23(火) 00:00:51.12

>>314
残り9個の参照はそのノードが削除されたことを知る術がないからダングリングポインタになるってことだろ

**デフォルトの名無しさん** · 2021/11/23(火) 00:08:02.67

>>318
本来は、明らかに別のノードであれば問題ない。
C++では普通に安全にそれが行える。
リンクリストの中に、A, B, C という名前の人のデータが入っていて、
それぞれに対して1つずつそれぞれ、ポインタ pA, pB, pC が存在している時に
ポインタ pA を介してAを削除しても、B, C へのポインタ pB, pC は残っていて、
値も変更されることも絶対に無いから完全に安全。
Aさんのデータを削除する場合にはこのようなことが起きるが、その時には、
delete pA の後、pAを捨ててしまうだけで全く安全。
pB, pC は何事も無くまったく安全に残せるし、何のバグも入らない。
こんな単純なロジック、何の問題も無い。

**デフォルトの名無しさん** · 2021/11/23(火) 00:15:34.94

同一のノードに10個の参照って意味ちゃうん？

**デフォルトの名無しさん** · 2021/11/23(火) 00:16:47.17

>>319
それだと>>311の条件を満たしていないのでやり直し
　・いずれにせよC/C++で書けるコードはそのままの形でそのままの安全度で必ずRustでもunsafeを用いて書ける
　・更にRustでは安全性を保証する形でunsafeを用いずに実装することもできる
C/C++よりもRustのほうが明白に能力が高い

**デフォルトの名無しさん** · 2021/11/23(火) 00:20:07.35

>>320
1つのリンクリストの異なる10個のノードに対する10個の参照。

**デフォルトの名無しさん** · 2021/11/23(火) 00:21:41.44

>>319
C++でノードへのポインタは実装依存な方法でしか取れないよ
pAその他は本当にポインタ？イテレータではなく？

**デフォルトの名無しさん** · 2021/11/23(火) 00:21:54.64

>>321
何度もしているが、それはフェイク。
Cできることのうち、Rustでは追加コストを掛けずにはsafeモードで出来ないことはたくさん有る。
unsafeモードを使いまくれば別。
しかしそれではRustを使う意味が無い。

**デフォルトの名無しさん** · 2021/11/23(火) 00:22:40.62

>>323
C++ではなく、Cのリンクリストで考えよう。C++は別の複雑さを入れ込んだから。

**デフォルトの名無しさん** · 2021/11/23(火) 00:22:46.42

>>324
なぜRustを使う意味がないのですか

**デフォルトの名無しさん** · 2021/11/23(火) 00:25:21.42

>>326
Rustの売りはゼロコスト+安全性にあるからだよ。
どちらが掛けても意味が無い。
ゼロコストで無いなら既にC#やJavaがある。
安全で無いなら既にC++がある。

**デフォルトの名無しさん** · 2021/11/23(火) 00:26:18.34

ああ、なるほど
安全性を考慮していないCのLinked Listと、安全性が保証されたRustのLinked Listを比較して、
Rustは遅い、できることが少なくて不便だ、みたいなことを述べてたわけか

Cでもメモリリークしないようにして、スレッドセーフにするとかしたら、途端に大変になりそう

**デフォルトの名無しさん** · 2021/11/23(火) 00:26:36.02

>>327
違いますよ

**デフォルトの名無しさん** · 2021/11/23(火) 00:27:06.93

>>324
リンクトリスト内のメソッドでunsafeを閉じ込めることできると思うんだけどそれではだめなのか

**デフォルトの名無しさん** · 2021/11/23(火) 00:28:01.20

なんなら>>330は「基本的な操作のメソッドは」ってしてもいいけど

**デフォルトの名無しさん** · 2021/11/23(火) 00:31:19.33

>>330
複数のノードへの読み書き自由なアクセスの速度をO(1)を保ったままで、
RustではunsafeをLinkedListのメソッド内には閉じ込めることが基本的に
出来ない。基本的に、と言ったのは、先ほど彼が示したリンク先の独自
実装の様に、ゼロコストであることを諦めてコストを掛ければできる
ようになるから。ただし、その場合、スパイク的にO(N)の時間でコピー
動作が発生してしまう。

**デフォルトの名無しさん** · 2021/11/23(火) 00:32:59.52

>>332
[補足]
スパイク的なコピーの発生だけでなく、普段からコスト増加もある。
ベースアドレス + 相対アドレスでアクセスするから。

**デフォルトの名無しさん** · 2021/11/23(火) 00:38:03.01

>>262
その人が作ったLinkedList実装がポインタではなく格納配列のインデックスを使っているだけだよ
Rustの標準ライブラリのLinkedList実装ではポインタを使っています
std::collections::LinkedList
https://doc.rust-lang.org/std/collections/struct.LinkedList.html

**デフォルトの名無しさん** · 2021/11/23(火) 00:39:30.31

>>334
それは分かってる。
で、標準の方は、ノードのアクセス速度に問題がある。

**デフォルトの名無しさん** · 2021/11/23(火) 00:43:10.08

>>335
RustはLinkedListでも問題を感じたことがないですが何を根拠に？

**デフォルトの名無しさん** · 2021/11/23(火) 00:49:14.22

>>336
1つのリンクリストの異なる10個のノードに対する10個のmut参照を同時
に持ち事は出来ないので、O(1)でアクセスできないからだ。

**デフォルトの名無しさん** · 2021/11/23(火) 01:04:38.76

>>337
意味がわからないので具体的に意味のあるCコードを書いて

**デフォルトの名無しさん** · 2021/11/23(火) 01:08:49.01

Rustだと確かに複数個所のノードへの可変参照を得るのはunsafeメソッドになるだろうね
そのノードが全部別々であることが保証できないから
でもそれは他の言語でも同じで、例えば1のノードに複数の可変参照があって、
1の参照がノード消したらまずことになる

そしてunsafeを許すのなら、内部実装でUnsafe Cell使えばコンパイラからの見た目は不変参照になるから、
オーバーヘッドなしでそういうのは実装可能（ただしstdのLinkedListはそのようにはなっていない）

んで、複数個所のノードへの可変参照を得るというのは相当レアな操作なはずなので、
それはunsafeにしてもAPIの使い勝手としては全然問題はない

**デフォルトの名無しさん** · 2021/11/23(火) 01:37:22.61

あるC/C++コードがあった時
(A) 常にRustではC/C++コードと同じ安全度で(必要時はunsafeを用いて)実装できる
(B) ほとんどのケースでRustでは安全なコードを(unsafeを用いずに)実装できる

つまりRustの能力はC/C++を上回っている

言い換えると
C/C++を捨ててRustを使えば
(B) ほとんどのケースで安全性を保証する形で実装できる
(A) 残りのレアケースでもC/C++と同じ安全度で実装できる

したがってC/C++を用いずにRustを用いたほうがよい

**デフォルトの名無しさん** · 2021/11/23(火) 05:32:01.67

安全性よりも、
とにかくパフォーマンスや使用リソースが最重要な用途がある
そういう所でC/C++が使われる

C/C++は少なくとも今後20年は使われ続ける

**デフォルトの名無しさん** · 2021/11/23(火) 05:47:19.80

>>341
RustはC/C++と同じパフォーマンスを出せます
>>340を読みましょ
C/C++からRustへ移ったほうが誰の目にも得です

**デフォルトの名無しさん** · 2021/11/23(火) 07:27:06.42

本当に良いことばかりなら
ここで宣伝しなくても自然に広まるはず

**デフォルトの名無しさん** · 2021/11/23(火) 13:48:55.03

いや、あわしろ氏もC++は窓から投げ捨てろと言ってる。

**ハノン** ◆QZaw55cn4c · 2021/11/23(火) 14:00:24.39

>>344
その、あわしろ氏とやらは、では、なにを推薦しているのでしょうか？

**デフォルトの名無しさん** · 2021/11/23(火) 14:20:23.73

ほんとRust気持ち悪いなｗ
リンクリストのような単純な構造でSTLでもboostでもそれ自体が「安全でない」ことはめったにない。
バグや脆弱性を作りこんでしまうのは多くは固定長のバッファに対するパース処理などで、確かに各種の
*nixコマンドなんかはRustで書いて貰ったほうが良い場合があるが、C/C++の数msが致命となる世界で
Rustが一般的となることはない。そんな布教をやってるから嫌われるんだよｗ
悔しかったらOpenSSLとか書き直して”安全なコード”で出してみろよ？WebkitにC/C++を排除させて
Rustだけにさせてみろｗ

**デフォルトの名無しさん** · 2021/11/23(火) 14:29:53.22

いまさらC++やってるようでは時代についていけない老害という評価しかない。

**デフォルトの名無しさん** · 2021/11/23(火) 14:45:56.12

Linusも老害だしChromeコミッターも全部老害、気持ち悪さNo1のRustたちが敵を作りまくる自己評価で
あらゆるスレで暴れてる

**ハノン** ◆QZaw55cn4c · 2021/11/23(火) 14:49:30.08

>>348
linus を老害呼ばわりするとは…

**デフォルトの名無しさん** · 2021/11/23(火) 14:56:32.81

>>346
usじゃなくてmsなのか...

**デフォルトの名無しさん** · 2021/11/23(火) 14:57:43.30

twitterでも、RustはHaskell程度にしか発言されて無い。
一方、C 言語で検索すると一日分でも見ることが不可能なくらい大量に
発言されてることが分かる。
twitterでは「C++」というキーワードでは検索できないので推定するしかないが、
C 言語以上であろう。

**デフォルトの名無しさん** · 2021/11/23(火) 15:54:02.42

>>340
>つまりRustの能力はC/C++を上回っている
ダウト。
安全面に置いては上回っているが、効率面では下がるケースがかなりある。

**デフォルトの名無しさん** · 2021/11/23(火) 16:13:02.54

・速度を落として安全性を高めたものは、既にJavaやC#がある。
・Rustが仮に速度面ではCに比べて余り遅くならないケースが多いと
　仮定しても(この仮定には嘘があるのだが)、使いこなすのがJavaやC#
　に比べると難しい。

特に参照関連だけでも、Option, Box, Rc, Arc, Cell, RefCell, Cursor, ref, &
の理解が必要な他、mut &'a などの表記、
let mut a : mut &:T = mut& b
や
Option<Rc<RefCell<T>>> a;
new Box<T>( T {・・・} );
のような解読が難しいシンタックスも多い。
このような複雑な表記は、JavaやC#には存在しない。

また、& と * の違いもあれば、& と ref の違いも有る。
let文ですらパターンマッチング方式になっているので Cのポインタの 10倍理解が難しい。

つまり、普通IQ者には理解が難しい。
逆に高IQ者は、C++でも安全に使えるし、C++を安全面では余り問題を感じて無い人が多い。

**デフォルトの名無しさん** · 2021/11/23(火) 16:19:09.75

>>353
さらに言えば、
・「自動参照外し」は便利だとされるが、逆に勝手に参照が外れることで、
　他人の書いたコードの理解が難しいことがある。明記してるコードと
　省略してるコードが同じことを意味してるのが理解しにくいので。
・&の意味が、let文の左辺ではパターンマッチング、右辺では参照、
　の意味になっているので混乱しやすい。左辺では参照をはずす意味
　になってしまう。
・＆は、reference(参照)演算子と呼ばれるのに、ref という演算子もあるが、
　これは、意味がかなり違うため、混乱し易い。
・nullポインタを代入するポインタは、Option<Box<T>> のように長くなる。
・ライフタイム注釈が発展途上中なのか、特に構造体に関するライフタイム注釈
　のドキュメントが少なく、例で説明されるだけで、根本的な意味を書いた
　ドキュメントが存在して無い。

**ハノン** ◆QZaw55cn4c · 2021/11/23(火) 16:26:18.07

>>353
IQの定義は？

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

LinuxはRustを第二言語と位置づけ、カーネル開発に積極利用する計画です。

**デフォルトの名無しさん** · 2021/11/23(火) 18:21:55.09

C/C++/Rustをやってきた人ならRustが圧倒的にプログラミングしやすいことで一致している
調査結果でもRustが連続1位を続けていることからも客観的に明白

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

あわしろ氏もC++は終了する言語と言っています。

**デフォルトの名無しさん** · 2021/11/23(火) 19:08:31.54

>>353
例示してるシンタックス全部間違ってるし釣りだろこれ

**デフォルトの名無しさん** · 2021/11/23(火) 19:22:32.43

>Rustが圧倒的にプログラミングしやすい
うんこ嘘つき野郎