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/25(土) 23:46:56.47

試し割り法で検索しろ

**デフォルトの名無しさん** · 2021/12/26(日) 00:33:01.70

>>228
素数が足し算平均2.5回程度で求まるアルゴリズムを説明してくれないか？

**デフォルトの名無しさん** · 2021/12/26(日) 02:08:18.89

Rustという世界最高の言語があるのに、なぜRubyを使うのが正しいのか。
リーン・スタートアップという本を読めばわかるよ。

**デフォルトの名無しさん** · 2021/12/26(日) 10:42:00.41

Ruby on Railsは、GitHub, Airbnb, Disney, Hulu, SoundCloud, Shopify といった世界的に有名な企業や、
日本国内でも、note、クックパッド、freee、マネーフォワード、Progate、Qiita などで使われている

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

一方、GitHubはGo へ以降する

Railsを使う理由を端的に言えば、もうかるから

Ruby biz Grand prix 2020 大賞を受賞した、Ruby の女神・池澤あやかも言ってる。
他の言語では開発者を確保しにくいので、Railsに切り替えた

**デフォルトの名無しさん** · 2021/12/26(日) 10:47:24.01

Mediator は、空港の管制塔

**デフォルトの名無しさん** · 2021/12/26(日) 15:09:49.43

>>214
仲介手数料、信用創造、お前が同じ穴の狢、アホのRustオジサンです

**デフォルトの名無しさん** · 2021/12/26(日) 16:15:26.85

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

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

>>224
ある数がある数で割れるかどうかのテストに足し算を使っているだけ。
例えば12を3で割れるかどうか調べる場合、0 3 6 9 12と足し算していって、12が見つかったので割れる。

**デフォルトの名無しさん** · 2021/12/26(日) 21:25:21.15

エラトステネスの篩、のことなのでは？
でも1億分のバッファとか、勿体ない気がしますね…

**デフォルトの名無しさん** · 2021/12/26(日) 22:30:41.92

そこで区間篩ですよ

**デフォルトの名無しさん** · 2021/12/26(日) 22:31:44.15

発見済みの素数を使ってループして数Xが素数かどうかを調べてるだけだろ？
足し算平均2.5回って意味不明なんだが？

**デフォルトの名無しさん** · 2021/12/26(日) 22:57:15.49

>>239
1億までの素数列挙の場合が足し算平均2.5回なだけじゃね？
>>173を見る限り
100万までの素数列挙なら足し算平均2.2回
1万までの素数列挙なら足し算平均1.9回
足し算の回数はO(N log log N)とあるから多少増えていくのだろう

**デフォルトの名無しさん** · 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と似ています。