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/26(日) 23:11:50.20

そう書いていたら謎が解けた

>>235
＞ 1億/2 + 1億/3 + 1億/5 + 1億/7 + 1億/11 + … + 1億/9973 = 約2.5億の足し算で原理的には済むはず

これは1億✕(1/2 + 1/3 + 1/5 + 1/7 + 1/11 + … )だから括弧内は素数の逆数の和でlog log N
1億がNだから足し算の回数はO(N log log N)なのか

**デフォルトの名無しさん** · 2021/12/26(日) 23:46:34.73

>>239
素数かどうかを調べるのは>>236が書いているように足し算だけで可能です
必要となる足し算の数は>>241が書いているようにO(N log log N)です
足し算平均2.5回は1億まで素数を列挙した時の話であって>>240が書いているようにNに対してわずかですが増えていきます

**デフォルトの名無しさん** · 2021/12/27(月) 00:18:24.10

>>242
C言語でいいから加算で素数を求めるアルゴリズム書いてくれない？

**デフォルトの名無しさん** · 2021/12/27(月) 08:37:12.33

このスレで出てきているテレーターがよくわからんのだけど、wikipediaの定義と違うんかいな？
ttps://ja.m.wikipedia.org/wiki/%E3%82%A4%E3%83%86%E3%83%AC%E3%83%BC%E3%82%BF

**デフォルトの名無しさん** · 2021/12/27(月) 09:31:03.72

>>244
その日本語wikiは怪しいので英語のwikiを見るといい

**デフォルトの名無しさん** · 2021/12/27(月) 13:29:55.23

100回繰り返すのと1億回繰り返すのとどっちがマヌケに見えるか、億という言葉を使えば賢く見えるのか？
億回繰り返さないと理解できないのか、汚コードRust相談室と化したC vs C++ vs Rustスレに未来はあるのか

**デフォルトの名無しさん** · 2021/12/27(月) 14:18:09.83

隔離スレに未来などあるわけあるか

**デフォルトの名無しさん** · 2021/12/27(月) 18:22:06.83

>>244
実際のコード例で体験していくと理解が早い

例えばこの計算をしたいとする
>>235
> 素数でなければ1万以下の素数が約数として必ずあるから順に最大素数9973まで調べるだけでよい
> 1億/2 + 1億/3 + 1億/5 + 1億/7 + 1億/11 + … + 1億/9973 = 約2.5億の足し算で原理的には済むはず

コードは>>176の素数生成イテレータも使って以下のイテレータ4つの連鎖で求まる

let result: i32 = 素数生成::<i32>()
　.take_while(|&p| p < 10000)
　.map(|p| 100000000 / p)
　.sum();

途中のtake_while()は条件を満たす間だけ取るイテレータでこの場合は「1万未満」が条件
map()は変換するイテレータで「素数pを1億/p」へ変換している
最後にsum()で流れてきた1億/pを「全て足して」目的を達成

このように個々の単機能イテレータを複数組み合わせて連鎖させることでプログラミングできる

**デフォルトの名無しさん** · 2021/12/27(月) 21:02:50.96

まーたイテレータの定義をよくわかってないやつがヘンテコな説明しちゃう

**デフォルトの名無しさん** · 2021/12/27(月) 22:13:30.95

ヘンテコなとこに気がつけなかったんだけど、どのへん？

**デフォルトの名無しさん** · 2021/12/27(月) 23:21:22.61

今どきの言語のイテレータは>>248で合っている
しかしC++のイテレータは低レベルでポインタを抽象化したものと考えたほうがいいので注意
C++にもようやくmap()に相当するものが入ったが他言語とは異なりtransform()という名前など使いにくい
今どきのプログラミングしたいなら素直にRustを使ったほうが便利

**デフォルトの名無しさん** · 2021/12/27(月) 23:38:31.34

>>250
イテレータとは何かを分かってない
用語の使い方見れば一目瞭然でしょ

分かってない人が書いた説明を読むよりもある程度査読されてる英語のwikiや各言語のリファレンス見たほうがいい

**デフォルトの名無しさん** · 2021/12/27(月) 23:39:05.80

この文中に>>入れる自作自演の同一人物の基地外Rustのくせはほんと気持ち悪い。また引用で > 使う

**デフォルトの名無しさん** · 2021/12/27(月) 23:41:50.94

伝統的には値を生成するものはジェネレータと呼ぶわな

**デフォルトの名無しさん** · 2021/12/27(月) 23:46:27.40

>>253
はちみつ病だからスルーしてさしあげろ

**デフォルトの名無しさん** · 2021/12/27(月) 23:49:02.66

>>254
それは観点が違うな
値を生成するものであってもイテレータとして機能するものと機能しないものがある
つまり重要な点はイテレータとして機能するか否かのみ
Rustの1..nやこのスレの素数生成はイテレータとして機能しているから明白にイテレータ

**デフォルトの名無しさん** · 2021/12/28(火) 01:27:16.67

ジェネレータはみんなイテレータだから

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

やっぱり頭がおかしいよ、1..nはRange { start: 1, end: n }と同じ。Rust公式でもイテレータじゃなく
単にRangeと言っているだけなのに、それが機能するかという観点ならfor inが無ければ機能しないから
イテレータじゃない。collect()がイテレータをコレクションに変換するように、for inで(暗黙)変換されるだけ。
こいつ、あちこちで暴れてる

**デフォルトの名無しさん** · 2021/12/28(火) 11:06:40.72

RangeはIterator実装してるからrustの定義ではイテレータではあるのでは

**デフォルトの名無しさん** · 2021/12/28(火) 11:57:32.05

汚コード厨まだ居るのか

**デフォルトの名無しさん** · 2021/12/28(火) 12:05:42.28

>>258
君もイテレータがわかってないお仲間さんなので仲良く勉強しとけ

**デフォルトの名無しさん** · 2021/12/28(火) 12:13:02.75

プログラミング初心者でもないのにイテレータを理解してないやつがRustスレに多いのはなぜ？

**デフォルトの名無しさん** · 2021/12/28(火) 12:16:44.18

ここ本スレではなく隔離スレ
スレ民の目的はただの冷やかし

**デフォルトの名無しさん** · 2021/12/28(火) 14:55:22.51

"仲介イテレータ"
約 2 件（0.26 秒）

すげー、全世界で、このスレにしかその言葉は存在しない

**デフォルトの名無しさん** · 2021/12/28(火) 15:25:43.05

厨怪イッテレータ

**デフォルトの名無しさん** · 2021/12/28(火) 15:44:45.74

>>262
一番レスの多い自演厨が理解してないから、そう見えるだけ

**デフォルトの名無しさん** · 2021/12/28(火) 16:37:20.65

イテレータには狭義のイテレータと広義のイテレータがある
広義のイテレータは狭義のイテレータとイテレータメソッドを合わせたものである

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

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

>>195
| (1) 発信イテレータ … >>174で示しました素数生成、レンジ(0..n)、配列やVecに対するiter()などチェーンでは先頭に来るもの
| (2) 仲介イテレータ … map()、filter()、enumerate()などチェーンでは中間に来るもの
| (3) 受信イテレータ … find()、fold()、collect()などチェーンでは最後に来るもの

その分類で言えば
(1) ＝ (A) かつ not (B) ＝イテレータ(狭義)だがイテレータメソッドではない
(2) ＝ (A) かつ (B) ＝イテレータ(狭義)でありイテレータメソッドでもある
(3) ＝ not (A) かつ (B) ＝イテレータメソッドだがイテレータ(狭義)ではない

**デフォルトの名無しさん** · 2021/12/28(火) 17:20:35.84

>>267
>広義のイテレータは狭義のイテレータとイテレータメソッドを合わせたものである
この定義のソースはどこ？

**デフォルトの名無しさん** · 2021/12/28(火) 18:00:29.58

素数生成君と仲介イテレータ君は同一人物だったのか
どおりで

**デフォルトの名無しさん** · 2021/12/28(火) 22:24:23.54

>>267
> Rustで言えばtrait Iteratorを実装するもの
これは無理矢理名前をつけるとすれば Iteratee と呼ぶべきでイテレーターではないのでは

**デフォルトの名無しさん** · 2021/12/28(火) 22:25:36.06

こいつ何度間違っても全く反省しないなww
良い子は鵜呑みにしないで自分で調べようね

**デフォルトの名無しさん** · 2021/12/28(火) 22:28:28.38

あ、>>270のことじゃないからね

**デフォルトの名無しさん** · 2021/12/28(火) 22:35:42.94

>>270
詫びがてら説明しておくがイテレータは数えあげる人のこと

「次くれ」→ 「はい、どうぞ」
「次くれ」→ 「はい、どうぞ」
「次くれ」→ 「もうありません」

数えあげる対象物を数えあげる人自身が持ってる場合もあれば持ってない場合もある
impl Iteratorしてるのがイテレータなのは間違いない

**デフォルトの名無しさん** · 2021/12/28(火) 22:49:58.47

>>270
君の中ではそうなのかもしれないが
世間では>>267の(A)をイテレータと呼んでいる
そしてイテレータパターンでもnext()を持つものをイテレータと呼んでいる
したがって>>267の説明で正しい

**デフォルトの名無しさん** · 2021/12/28(火) 23:41:11.95

出典もなしに能書き垂れるのやめろ

**デフォルトの名無しさん** · 2021/12/28(火) 23:52:38.14

デザインパターンの一つであるイテレータパターンの説明図 (wikipediaより)
https://upload.wikimedia.org/wikipedia/commons/c/c5/W3sDesign_Iterator_Design_Pattern_UML.jpg
next()を持つものがイテレータ
つまり>>267の定義で合っている

**デフォルトの名無しさん** · 2021/12/28(火) 23:56:51.47

視野が狭く思い込んだら多くの人が警告しているのに完全に無視し「定義」だの仲介だの創造だの自分勝手に講釈を垂れる

**デフォルトの名無しさん** · 2021/12/28(火) 23:59:15.51

Rust公式Bookでも同じ

https://doc.rust-jp.rs/book-ja/ch13-02-iterators.html
全てのイテレータは、標準ライブラリで定義されているIteratorというトレイトを実装しています。
Iteratorトレイトを実装するには、Item型も定義する必要があり、
そして、このItem型がnextメソッドの戻り値の型に使われています。
イテレータに対して直接nextメソッドを呼び出すこともできます。

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

じゃ>>248が間違ってたんだね

素数生成イテレータ
take_while()イテレータ
map()イテレータ
sum()イテレータ
4つの単機能イテレータの連鎖で求まるだっけ？

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

>>267に照らし合わせると
上3つが狭義のイテレータ
下3つがイテレータメソッド(広義のイテレータ)
って感じかね
間違ってるとまでは言えまい

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

イテレーターの定義はIteratorを実装してる型で良いと思うがそれがどう C vs C++ vs Rust に繋がるのか

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

>>280
そりゃ間違ってた本人の言い訳定義だからな
御本人さんよ

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

イテレータメソッドというのは多くの言語では一般的にはイテレータを返すメソッドのこと
Java, C#, C++, JavaScript, Python, Ruby, Scala等々

RustではIterator Trait’s Methodsの意味で
“iterator methods”という言葉が使われるがこれは訳すなら”イテレータのメソッド”

Rustに限った話でもIterator Traitの個別メソッドを
”イテレータ”と呼んでるのはnext()を除いて聞いたことがないので
広義のイテレータを定義してるソースがあるなら提示してもらいたい

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

>>283
必死こいて言い訳のソースを調査中だから期待して待っててね

**デフォルトの名無しさん** · 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
ドライバにクラスは必要ないからでは？