C vs C++ vs Rust Part.2

**デフォルトの名無しさん** · 2021/12/15(水) 12:35:50.91

競え
※前スレ
C++ vs Rust
https://mevius.5ch.net/test/read.cgi/tech/1619219089/

**デフォルトの名無しさん** · 2021/12/29(水) 13:20:17.30

javaだと
public interface Iterator<E>
ここにあるメソッドをiterator methodsと読んでる人居るね
まあ単にイテレータのメソッドってことなんだけど

**デフォルトの名無しさん** · 2021/12/29(水) 13:36:57.67

>イテレータメソッドというのは多くの言語では一般的にはイテレータを返すメソッドのこと

ググってみたがほとんど用例が見つからん。

**デフォルトの名無しさん** · 2021/12/29(水) 14:15:53.78

ばっかもーん！それがイテレータだ！定義しろ～！
みたいな

**デフォルトの名無しさん** · 2021/12/29(水) 15:32:20.47

>>284
いいわけが見つからず
必死に話題そらしを始めるに1000ペリカ

**デフォルトの名無しさん** · 2021/12/29(水) 17:12:35.25

発信イテレータ<Item=オレオレ定義>

**デフォルトの名無しさん** · 2021/12/29(水) 21:23:30.19

たしかに「イテレータメソッド」だと「イテレータ生成メソッド」を意味する用例もあり曖昧さがある
「の」を入れて「イテレータのメソッド」とした方がいいだろう

(A) イテレータ
trait Iteratorを実装するもの
コード上で「impl Iterator for 各イテレータが返す型」となって現れる
各イテレータが返す型は通常structでありimpl Iterator<Item=T>を満たす
メソッドとしてnext()を持ちこれがOption<T>を返す

(B) イテレータのメソッド
イテレータのメソッドとして機能するもの
コード上では「impl 宣言用トレイト for Iterator」の中で現れる
イテレータの各メソッドが返す型は任意でありfor_each()のように無しも可
対象イテレータのnext()を利用する側となる

**デフォルトの名無しさん** · 2021/12/29(水) 21:25:05.27

// 例: イテレータ CountUp
struct CountUp(isize);
impl Iterator for CountUp {
type Item = isize;
fn next(&mut self) -> Option<isize> {
self.0 += 1;
Some(self.0)
}
}

// 例: イテレータのメソッド average()
trait AverageMethod {
fn average(&mut self) -> isize;
}
impl<I: Iterator<Item=isize>> AverageMethod for I {
fn average(&mut self) -> isize {
let mut len = 0;
let mut sum = 0;
while let Some(n) = self.next() {
len += 1;
sum += n;
}
sum / len
}
}

fn main() {
let a = CountUp(0).take(99).average();
assert_eq!(a, 50);
}

**デフォルトの名無しさん** · 2021/12/30(木) 00:04:05.78

反応がないとうんこしたと流してない。不安に襲われるような感じ

**デフォルトの名無しさん** · 2021/12/30(木) 14:31:45.54

>>291のイテレーターとメソッドをCやC++で実装することも可能ですか？
どんな感じのコードになりますか？

**デフォルトの名無しさん** · 2021/12/30(木) 22:06:33.40

Rustを勧めるとだけ言っておく

**デフォルトの名無しさん** · 2021/12/31(金) 05:37:35.76

ここにいるRust屋はC/C++が書けないってことがはっきりしている

**デフォルトの名無しさん** · 2021/12/31(金) 06:22:24.67

単純にC++が不得手な分野が多すぎ
Rustだと楽に書けるからこのスレに書かれているコードがRustばかりになっている
プログラミング言語としての優劣の違い

**デフォルトの名無しさん** · 2021/12/31(金) 07:44:51.93

Rustだと楽にかける分野ってメモリ安全性関連以外ない気がする

**デフォルトの名無しさん** · 2021/12/31(金) 07:51:10.24

Rustはイテレータ作れる文法用意されててスゴイ言語ってことか
まあトイプログラム作るのに秀でた言語いじって喜んでるレベルじゃ
あらゆる分野のアプリケーションが書かれてきたC++の実績は理解できないだろうな
せいぜい不得意なことと言えばスクリプト言語で代用される分野くらいだろ

**デフォルトの名無しさん** · 2021/12/31(金) 08:08:48.60

>>297
パターンマッチがハマるプログラムは書きやすいと思う
言語処理系とか

**デフォルトの名無しさん** · 2021/12/31(金) 08:23:51.96

>>299
なるほど
でもそれってc/c++でもenumと構造体か共用体組み合わせればできるよね？

**デフォルトの名無しさん** · 2021/12/31(金) 08:33:21.86

>>297
マルチスレッドは楽だと思うけどな
というかC++が辛すぎる

**デフォルトの名無しさん** · 2021/12/31(金) 09:32:24.05

>>300
できるできないの話じゃなく
どちらが楽にできるかの話をしてたんじゃないの？

**デフォルトの名無しさん** · 2021/12/31(金) 10:43:31.43

C++20 からコルーチンが入ってジェネレータは割と書きやすくなったよ
とはいえイテレータのほうが従来通りのポインタ的用法に引きずられてるからなんともだけど
https://cpprefjp.github.io/lang/cpp20/coroutines.html

**デフォルトの名無しさん** · 2021/12/31(金) 11:38:15.61

>>300
c++でもできるけどenumの値とunionのvariantの組み合わせはプラグラマが意識しないといけない
rustだとmatch式のcond部分に値を書けばrust-analyzerがすべてのarmのスケルトンを作ってくれるから
穴埋めしていくだけで処理が書けて楽

**デフォルトの名無しさん** · 2021/12/31(金) 12:10:32.68

>>304
まあrustの方がc++よりパターンマッチング楽なのは認めるよ間違いない

**デフォルトの名無しさん** · 2021/12/31(金) 21:01:38.85

C++と比べてRustだとメモリ安全にできるから、スレッドセーフなコードも誰でも書けるよ
そういったメモリ安全関連の利点がなきゃ存在意義のない言語だよね

書いたコードが高速に動作するかどうか、とかはまた別の話だけど

**デフォルトの名無しさん** · 2021/12/31(金) 21:30:26.51

>>301
マルチスレッドの並列処理だけでなくシングルスレッドマルチタスクの並行処理も便利かつ安全に書けるところも

>>304
match式だけでなくletやif letでのデストラクチャリング＆マッチングがある点も
一方でC++は多重構造の分解分配もダメでif letも値付きenumもないからほとんど何も出来ない

**デフォルトの名無しさん** · 2021/12/31(金) 21:55:39.97

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p1371r3.pdf
パターンマッチング構文が提案されてる。

**デフォルトの名無しさん** · 2021/12/31(金) 21:55:45.65

>>298
C++で書けることは全てRustで書ける
C++が優位な点は過去実績しかない
これは両方やればはっきりと認識できる
そのスクリプト言語的な記述や利便性がRustにあるという認識は正しい
かゆいところにも手が届くスクリプト言語という側面もある

**デフォルトの名無しさん** · 2021/12/31(金) 22:00:54.10

Rustはスクリプト言語なのか。

**デフォルトの名無しさん** · 2021/12/31(金) 22:02:16.06

>>306
CやC++と同等の性能特性を持つ言語の選択肢は限られてるから安全性以外の理由でRustが採用されることもあると思うよ

**デフォルトの名無しさん** · 2021/12/31(金) 22:03:31.93

Rustって循環参照安全に書けないんじゃなかったけ？

**デフォルトの名無しさん** · 2021/12/31(金) 22:11:10.66

>>308
構文のアーム「=>」や後置のifガードなどRustのmatch式の後追いパクリw
それが仮に導入できても要である値付きenum(＝タグ付き共用体)を持たないC++では活用に限界

>>312
曖昧すぎてどういう状況で何が書けないとの主張かわからないけど
C/C++で安全に書けることはRustでも安全に書ける
つまりRustで安全に書ける範囲の方が完全に広い

**デフォルトの名無しさん** · 2021/12/31(金) 22:18:59.59

>>313
C/C++にはRustでいうところの安全(⇔unsafe)はないから "C/C++で安全に書ける物" が何を意味するかわからない

そもそも >>309 の "C++で書けること" や "Rustで書けること" ってどう定義されるの？

**デフォルトの名無しさん** · 2021/12/31(金) 22:24:28.60

>>312
循環参照は安全に書けるよ
https://doc.rust-jp.rs/book-ja/ch15-06-reference-cycles.html

**デフォルトの名無しさん** · 2022/01/01(土) 00:53:57.74

Rustのmatch式はScalaの後追いパクリw

**デフォルトの名無しさん** · 2022/01/01(土) 01:00:44.48

ML系のパクりだよ
https://doc.rust-lang.org/reference/influences.html

**デフォルトの名無しさん** · 2022/01/01(土) 01:12:03.78

プログラミング言語としての比較結果は明瞭

適用可能な範囲は同じかつ最速
いずれもGCがなく低レベル操作も可能
Rust = C++ = C

したがって勝負は他の点
コード記述が楽に簡潔に書けるか
Rust > C++ > C

安全なコードを書けるか保証できるか
Rust > C++ > C

**デフォルトの名無しさん** · 2022/01/01(土) 01:22:01.85

>>318
> いずれもGCがなく低レベル操作も可能
これはRustはnightly使うこと前提？
低レベルな機能についてはまだまだunstableなものが多いので少なくともstableなRustではC/C++でできること (処理系依存なものも含む) がすべてできるとは言えないのでは
https://doc.rust-lang.org/stable/unstable-book/

新たな(pre-)RFCも日々提案されてるし現状で十分とあぐらをかくべきではないと思う

**デフォルトの名無しさん** · 2022/01/01(土) 01:33:41.15

ということは、RustはC++よりJavaと比較する言語なのでは？

**デフォルトの名無しさん** · 2022/01/01(土) 01:41:42.07

>>309の
> C++で書けることは全てRustで書ける
を念頭に置いた話で "全て" は言い過ぎ、C++でないとできないこともあるだろうと言いたかった

CやC++の低レベル操作は Rust でも "だいたい" できて大抵のユースケースでは困らない
と言うのが正確だと思う

Java は GC あり VM 言語だから低レベル操作の観点でのRustとの類似度で言ったらCやC++の方が近い

**デフォルトの名無しさん** · 2022/01/01(土) 01:44:00.63

メモリーの安全性を強調する言語と言えばJavaが筆頭に挙げられるのでは？
Javaは実行時最適化を行うのでC++より速いと主張されます。
この点もRustと酷似している。

**デフォルトの名無しさん** · 2022/01/01(土) 01:45:59.28

JavaもRustもC++と比較した優位性を主張するのですが、JavaとRustならどちらが優れているのでしょう？

**デフォルトの名無しさん** · 2022/01/01(土) 01:46:52.68

>>319
勘違いしてないか？
それらのほとんどは既に別の手段でコードを書くことができるが更に利便性を高めようと検討されている機能だぞ
C++で言えば>>308提案のマッチングは現在できないがそれが無くとも別の手段でコードは書ける話

>>320
C++とRustは適用可能な範囲が同じ
Rustの記述性能が高いという違いしかない

>>322
Javaはガベージコレクションがあり適用可能な範囲が狭い
さらにヌルポインタ例外もありJavaはメモリ安全ではない

**デフォルトの名無しさん** · 2022/01/01(土) 01:50:45.71

Javaは組み込みにも使われ、それどころかpico javaというJavaを効率よく実行できる組み込み用プロセッサのアーキテクチャ迄あるんですよ。
完全にRustと一致するじゃないですか。
実績を考えたらRustを完全に包含しています。
なぜJavaとの比較を嫌がるのですか？

**デフォルトの名無しさん** · 2022/01/01(土) 01:51:16.51

もしかしてRustはJavaに負けているのですか？

**デフォルトの名無しさん** · 2022/01/01(土) 02:00:04.72

GCがあってデータ競合も起きないマルチパラダイム言語で、C,C++以上の爆速で動く処理系があるとするならそら優秀だろうと思うわ

Javaは実際にはそんなに爆速じゃないだろうし、データ競合の対策がしやすい言語とも思えんけど

**デフォルトの名無しさん** · 2022/01/01(土) 02:05:29.52

活気があったころは、C++と比較して20倍速いと主張するサイトもありましたよ。
まさに爆速です。
Rustと似ています。

**デフォルトの名無しさん** · 2022/01/01(土) 02:07:14.76

安全性という観点では、RustはHaskellと似ているように思います。
熱心なHaskellユーザーはコンパイルが終わればバグが無いことを保証されると主張します。
Rustと全く同じです。

**デフォルトの名無しさん** · 2022/01/01(土) 02:10:16.54

Javaを含めるとこうなる

安全なコードを書けるか保証できるか
Rust > Java > C++ > C

Javaはヌルポインタによる参照でエラー例外が実行時に起き得る
Rustはそれさえも起きない
したがって速さだけでなくメモリ安全の点でも Rust > Java が確定済
Javaが勝てる点がない
そのためJavaを捨ててRustへ移行するプロジェクトもある

**デフォルトの名無しさん** · 2022/01/01(土) 02:11:02.91

Haskellもまた、C++と比較して優位性が主張されることの多い言語のひとつです。
しかし、JavaやRustと比較されることは一切在りません。
Java、Rust、Haskellでは、どれが最も優れているのでしょう？

**デフォルトの名無しさん** · 2022/01/01(土) 02:13:26.08

でもRustはJavaより遅いですよね？
Javaは実行時最適化によりC++より20倍速いことがbenchmarkで判明していますよ。
10年以上も前に。

**デフォルトの名無しさん** · 2022/01/01(土) 02:15:29.86

C++を改良したD言語もあります。
DとRustならどちらが優れているのでしょう？

**デフォルトの名無しさん** · 2022/01/01(土) 02:16:49.60

出自からして、D言語もまたC++と比較して優位性が述べられる言語のひとつです。
しかし、RustやHaskellと比較されることは在りませんね。
どちらが優れているのでしょう？

**デフォルトの名無しさん** · 2022/01/01(土) 02:25:43.18

まずは決定的な違いを勉強しなさい
GCのない言語　Rust C++ C
GCのある言語　Java D C# Go Haskell Python Ruby JavaScript ...

**デフォルトの名無しさん** · 2022/01/01(土) 02:31:24.00

>>335
GCの有無で何が変わりますか？
JavaやRuby、Pythonは組み込みにも使われますし、宇宙にだって行きます。
Rustよりずっと広範囲に使われています。
Rustで作られた実用的なソフトウェアはFirefoxしかないじゃないですか。
しかも、そのFirefoxだって熱心な信者以外誰も使わない。
それと比較したら、これらの言語は実用的に使われています。
GCが在ろうとなかろうと。

**デフォルトの名無しさん** · 2022/01/01(土) 02:32:19.06

>>324
大体代替手段があるのはそうだと思います
例えばnaked functionやglobal_asmは別途asmなりCなりからオブジェクトファイル生成してリンクするという代替手段があります (これがありならC-FFIできる言語は皆同等になってしまいますが...)

もともと C++ でできることは "全て" できるというかなり強い主張をされてた人がいたのでそれは言い過ぎじゃないかと言いたかっただけです

>>332
ご参考まで
https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/java.html
他の言語との比較もありますよ

**デフォルトの名無しさん** · 2022/01/01(土) 02:33:17.91

Rustのポジションに取って変わりたいなら、RustみたいにLinuxのKernelコードに取り込まれていってくれるとわかりやすいんだけどね
なぜC++を含む他の言語はLinux Kernelに採用されないのか、って考えると差が明瞭になってきそうだ

**デフォルトの名無しさん** · 2022/01/01(土) 02:34:00.98

Firefoxのバグの多さを考えても、Rustはバグを生産する言語のように思います。

**デフォルトの名無しさん** · 2022/01/01(土) 02:35:06.26

>>338
ドライバにクラスは必要ないからでは？

**デフォルトの名無しさん** · 2022/01/01(土) 02:39:59.20

>>336
RubyやPythonは遅すぎ＆メモリ食い過ぎで話にならない
例えばクックパッド社はRubyで書かれていたのをRustへ置き換えて経費節減に成功している

**デフォルトの名無しさん** · 2022/01/01(土) 02:42:24.09

そういえば Windows 10にRust使う話ってどうなったんだろうか

>>336
以下の記事にメモリ安全な既存の言語ではだめでCやC++やRustでないといけない理由
それらの中でもRustが良いとされる理由が書かれていますよ
https://msrc-blog.microsoft.com/2019/07/22/why-rust-for-safe-systems-programming/

**デフォルトの名無しさん** · 2022/01/01(土) 02:57:17.29

>>339
FirefoxについてC++コードをRustに書き換えたらセキュリティに関わる脆弱性数がどうなるか分析した記事がありました
https://hacks.mozilla.org/2019/02/rewriting-a-browser-component-in-rust/
結論としては完璧ではないけどRustの方がバグを減らせるということのようです

MS ResearchやGoogleのAndroidチームも類似の調査をやっていてRust採用は効果有りと判断しているみたいです

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

JavaやHaskellも多くの人がC++より優れていると分析しています。
速く容易で安全なのです。
全ての点でC++を上回っています。
では、それらの言語を比較した場合、どれが最も優れているのでしょう？

**デフォルトの名無しさん** · 2022/01/01(土) 04:11:14.25

ほとんどすべての言語がC++より優れていると主張します。
という事は、C++はもっとも劣った言語のひとつなのです。
Rustはもっとも劣った言語より優れていると主張しますが、優れた言語、例えばJavaやHaskellと比較したら、かなり劣っているのでは？

**デフォルトの名無しさん** · 2022/01/01(土) 07:34:43.36

多くの人がRustとC++と比較している
比較するなら優れたもの同士を突き合わせるはずだ
なのにJavaやHaskellは影も形もないつまり論外ってことだ
全ての言語がC++に対して優位性を主張するのも
C++が最も現実的で優れた言語だと認めているからであって
わざわざ劣っているものと比較する必要なんてないからだ

**デフォルトの名無しさん** · 2022/01/01(土) 09:08:27.19

>>344
JavaやHaskellがC++より常に高速というのは明確に誤りです
https://benchmarksgame-team.pages.debian.net/benchmarksgame/index.html

ではC++がこれらの言語より優れているかというとそうではありません
言語にはそれぞれ得手不得手があります
唯一絶対の尺度で優劣を決めようとするのではなく、ある特定の用途に対してどの言語が適しているかという観点で議論した方が生産的かと思います

**デフォルトの名無しさん** · 2022/01/01(土) 09:44:43.30

スレタイ読め。

**デフォルトの名無しさん** · 2022/01/01(土) 10:50:55.11

いつもの人の自作自演

**デフォルトの名無しさん** · 2022/01/01(土) 19:02:54.41

GitHub・Cookpad などは、遅いRuby on Rails から、Go・Rust などへ移行している

2021年10月には、GitHubのコピーのGitLab が上場し、時価総額は約1.9兆円！
こんな大きい時価総額でも、Railsを使い続ける宣言をしている

基本、Railsは中小ベンチャーが、高品質なサービスを作るツール。
2億レコード・取引先が2万社みたいな規模でも、問題ないと言ってた

他には、組み込みのmruby の本も出た。
Webで使えるmrubyシステムプログラミング入門、近藤宇智朗、2020/11

宇宙開発などの組み込み用、MicroPython, Lua, Squirrel の代替になる。
Ubuntu 18.04, C99 対応

人工衛星イザナギ・イザナミで、使っている

**デフォルトの名無しさん** · 2022/01/01(土) 21:35:42.72

C++もJavaも実行時にnull pointerによる参照が起きる可能性があるためどちらも安全性に劣るよね
Rustではenum Option使用でnull pointerによる参照が絶対に起きないことをコンパイル時点で保証した上で
コンパイル後は最適化でOptionがNoneの時にnull pointerを使うという二段構えにより
Rustはコストをかけずに無駄なく安全性の保証を実現しているところに感動した

**デフォルトの名無しさん** · 2022/01/01(土) 21:45:09.34

null安全ぐらいはモダン言語なら当たり前の機能なので、もはやメリットとは感じないわ
例えばTypeScript、Swift、Kotlin、Haskellとか

**デフォルトの名無しさん** · 2022/01/01(土) 21:56:26.71

C++とJavaが前近代的でダメな言語なだけだよな

**デフォルトの名無しさん** · 2022/01/01(土) 21:59:01.05

Javaは速度を追求した言語だから。

**デフォルトの名無しさん** · 2022/01/01(土) 22:39:11.50

Haskellは安全性と並列化を追求した言語です。

**デフォルトの名無しさん** · 2022/01/01(土) 22:58:31.22

RustはHaskellの長所である型クラスをトレイトとトレイト境界で採り入れていたり
HaskellのMaybeモナドやEitherモナドを採り入れてRustの型の核としているところにも感動した

**デフォルトの名無しさん** · 2022/01/01(土) 23:02:32.16

システムプログラミングでCに代替となれるほどRustがイケてるのは、
null安全やメモリ安全はモダンな言語だから当然として、データ競合が起きないことも保証しつつ、実行速度もCに劣らなくて、
それでいてRustと多少のアセンブラだけ使えば、OSや組み込みソフトウェアも普通に記述できるほどフットプリントの小さい低レベルな言語だから

**デフォルトの名無しさん** · 2022/01/01(土) 23:08:54.95

システムプログラミングにはJavaのほうが向いています。
単純に速いからです。
Javaは宇宙でさえ使われる安全で実績のある言語です。
しかも速い。
実行時最適化を行わない言語では無理な速さです。

**デフォルトの名無しさん** · 2022/01/01(土) 23:23:23.09

結局RustはHaskellの真似をするだけの偽物言語にすぎません。
Haskellの並列性、安全保証を移植するには、結局Haskellになるしかないのです。
RustはいずれHaskellになるでしょう。
その時もまだRustと呼び続けるのでしょうか。

**デフォルトの名無しさん** · 2022/01/01(土) 23:45:51.79

>>358
ねー、>>347 無視しないでよー

**デフォルトの名無しさん** · 2022/01/02(日) 01:31:01.49

rustのnull安全？はクリティカルコンテキストでも保証されるんか？

**デフォルトの名無しさん** · 2022/01/02(日) 02:22:18.22

もちろんです。

**デフォルトの名無しさん** · 2022/01/02(日) 08:42:35.10

現状でRustの欠陥は指摘なしなのか
まあ優れた言語だから主流になるとも限らんけど
ここはRust礼賛が多くて参考にならんな

**デフォルトの名無しさん** · 2022/01/02(日) 08:43:38.07

>>360
キチの相手するならメールかなんかでやってくれ

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

キチの相手するスレやぞ

**デフォルトの名無しさん** · 2022/01/02(日) 14:18:19.00

良いという人だって使ったことないんだから、欠点なんか出てこないよ。

**デフォルトの名無しさん** · 2022/01/02(日) 14:52:25.82

>>361
クリティカルセクションのこと？

**デフォルトの名無しさん** · 2022/01/02(日) 19:27:00.77

int型(32ビット)でyy/MM/dd/HH/mmの形で日時を実装しているプログラムは、2022年1月1日0時0分(2201010001)に32ビットの最大値(2147483647)を越えてしまい、エラーが発生する。そういう実装をしているMicrosoft Exchangeでは既に問題が発生中。
みんな仕事始めになって気づいて大騒ぎに

**デフォルトの名無しさん** · 2022/01/02(日) 19:33:55.23

DosDateTime爆死確認w

**デフォルトの名無しさん** · 2022/01/02(日) 20:28:27.33

>>367
ハードウェア割り込みの割り込みコンテキストのつもりで書いた
社内独自用語なんだと思う
そこは気にせんでくれ

**デフォルトの名無しさん** · 2022/01/02(日) 21:12:20.77

>>361
Rustのポインタ(参照)および実体にはnull/nil/undefined等が一切ない
そのためnull問題が起きることはなく所謂null安全が保証されている

nullになる可能性がある場合は汎用のオプション型であるenum Option<T>型を用いる
このOption<T>はenumとしてSome(T)とNoneの二値を取り型Tは任意な型
つまり所謂NullはenumのNoneで表現され型Tとは異なるためnull問題が起きようがない

これで効率やコストはどうなるのか？
null(RustではNone)が使われない時は型Tのまま扱うので従来と同じ
null(RustではNone)が使われうる時は型Option<T>として扱う
型Option<T>から型Tを使うにはNoneでない確認が必要だがこれこそ必須な確認コスト
ポインタ(参照)の場合は値がnullすなわち0になることがないためコンパイル後はNoneが0で表現される最適化となる
つまり結果的にはC/C++と同じになるのだがRustは上述のようにコンパイル時点でnull安全を保証できる点で異なる

**デフォルトの名無しさん** · 2022/01/02(日) 22:09:32.73

Javaのほうが安全。

**デフォルトの名無しさん** · 2022/01/02(日) 22:11:45.12

ぬるぽ例外が発生するから安全じゃないとか言う書き込みがあった。
これはウソ。
ないほうが良いならCはヌルポを検出できないから安全って事になる。
Javaは検出して例外を発生させるから安全なのです。
キチガイに騙されるな。

**デフォルトの名無しさん** · 2022/01/02(日) 22:18:47.48

>ないほうが良いならCはヌルポを検出できないから安全って事になる。

発生したことを検出できないことと発生しないことを意図的に混同している

**デフォルトの名無しさん** · 2022/01/02(日) 23:11:16.20

Firefoxの惨状を見れば全然安全でないことがわかるのに。
なぜ安全と言い張るのか。

**デフォルトの名無しさん** · 2022/01/02(日) 23:20:08.47

CもC++もJavaも実行時にヌルポ発生するからいずれもダメ
Rustは実行時にヌルポ発生しないことが保証されているから安全

**デフォルトの名無しさん** · 2022/01/02(日) 23:22:44.87

RustアンチがRustを称賛してるのではないか。

**デフォルトの名無しさん** · 2022/01/03(月) 05:19:23.74

その可能性高いかも

**デフォルトの名無しさん** · 2022/01/03(月) 06:00:15.35

学会が自らキチガイを演出する手口に栗卒

**デフォルトの名無しさん** · 2022/01/03(月) 16:10:29.79

RustはC++と同じ匂いがする

**デフォルトの名無しさん** · 2022/01/03(月) 17:15:54.33

このようにRustをやってる奴は性格が捻じ曲がってる

**デフォルトの名無しさん** · 2022/01/03(月) 17:22:00.01

rustってc++より難解だよな
こんな言語が流行るとは思わない

**デフォルトの名無しさん** · 2022/01/03(月) 17:25:50.42

他の言語と比べればめちゃくちゃ難解だし、Rustコミュニティでもどうすれば簡単になるのかいろいろ議論されている

**デフォルトの名無しさん** · 2022/01/03(月) 17:32:24.16

ワイじゃないけど必死に褒めてるのにアンチだとか、ウジ沸いてる