次世代言語28 TypeScript Swift Go Kotlin Rust Nim

**デフォルトの名無しさん** · 2022/08/29(月) 11:22:16.48

スレタイ以外の言語もok

前スレ
次世代言語27 TypeScript Swift Go Kotlin Rust Nim
https://mevius.5ch.net/test/read.cgi/tech/1659655598/

**デフォルトの名無しさん** · 2022/08/31(水) 21:28:47.20

限られた情報から善と悪を判断できない人達が
まだ公開されていないクソどうでもいいデータを欲しがる

**デフォルトの名無しさん** · 2022/08/31(水) 22:11:23.35

オラクルに丸め込まれた会社本当にかわいそう

**デフォルトの名無しさん** · 2022/08/31(水) 22:21:51.07

今日Helidonなるものを初めて知ったわ
オラクル足掻いてるよねー

**デフォルトの名無しさん** · 2022/08/31(水) 23:06:38.28

rustは死産だったんだよ
このスレで頑張ってるのは水子供養みたいなもん

**デフォルトの名無しさん** · 2022/08/31(水) 23:15:56.00

Facebook、開発言語に「Rust」採用　Javaからも移行
https://www.itmedia.co.jp/news/articles/2107/28/news152.html

Rustを用いることで、どのような利点があるのか。
Facebookは記事の中で次の4つの項目を挙げています。

①Rustのasync/awaitシンタックスは、非同期のコードをとてもスムーズに記述できますし、
Rustは複雑な並行処理の詳細を正しく理解するのに役立ちます。
BuckのJavaの計算を一つ一つ並行処理に移行するのは数カ月に及ぶ困難な作業でしたし、
シングルスレッドの大きなボトルネックがまだ存在しています。

②Rustには、開発をより簡単で楽しいものにしてくれる多くの高レベルな言語機能があります。
それらはenum、パターンマッチング、trait、手続き型マクロなどで、
Rustの開発者の多くに愛されています。

③Rust はメモリの割り当てをより細かく制御することができます。
ガベージコレクションのある言語では、たとえジェネレーショナルコレクションであっても、
Buckが行うようなインクリメンタルな演算に対応するのは困難です。

④Rustは高性能です。
Rustに移植することで劇的な性能向上を私たちは見てきました。

**デフォルトの名無しさん** · 2022/08/31(水) 23:21:00.54

>>35
いやいやC++で書かれたプログラムは無条件にRustで置き換えられるって主張は銀の弾丸って言ってるのと同じでしょ

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

善行を勧めることと、善行が必勝法であると主張することを区別する必要がある

**デフォルトの名無しさん** · 2022/09/01(木) 07:30:51.13

>>23
「最適化によりforでのチェックだけになり・・・つまりC言語と同じになる」
はい、明確すぎる嘘、Cは普通処理系によりけりだが通常は配列境界のチェックなんてしません。あほかｗなにが、つまりだｗ
必死すぎるのがほんと痛々しい

**デフォルトの名無しさん** · 2022/09/01(木) 07:32:21.78

所有権を邪魔だと思ってる奴のC++コードは読みたくねえな
一緒に仕事したくねえ……

**デフォルトの名無しさん** · 2022/09/01(木) 07:51:48.00

>>46
インデックス値でforループを回すとあるから
C言語でもループ1回に付き必ず1回のインデックス値の境界比較が必ず入るよ
境界チェック無しでforを回したら無限ループになる

**デフォルトの名無しさん** · 2022/09/01(木) 07:57:15.00

>>48
Cって、配列のインデックスアクセスに境界チェックとか無くて、プログラマに委ねられているのかと思ってた。Cも意外に安全性を気にしているんだね。

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

>>38
javaのフレームワークって何使ってるの？

**デフォルトの名無しさん** · 2022/09/01(木) 09:37:58.04

>>44
その通り
条件を絞って
予めRustに移植することを意識して描かれたC++のソースのみ自動変換出来る
なら正しいかも知れない

**デフォルトの名無しさん** · 2022/09/01(木) 09:39:23.27

>>44 追加
ちなみに漏れは
「Rustに移植することを意識して描かれたC++のソース」
ならC++のままでええやん？的な立場

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

>>48 はCを知らない素人以下

**デフォルトの名無しさん** · 2022/09/01(木) 09:48:59.81

>>49
たぶん間違って読解してる。
良くも悪くも日本語って主語省略しちゃうからね。

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

>>53
え？
>>48で合ってるだろ
インデックスforループは境界比較しないと止まらん

**デフォルトの名無しさん** · 2022/09/01(木) 09:57:04.30

>>55
配列のインデックスチェックってここではモダンな言語は配列外にアクセスすると実行時エラーになるということを言ってるんだよ
Cはエラーじゃなく未定義だから何が起こるかわからん

**デフォルトの名無しさん** · 2022/09/01(木) 09:57:34.15

実行時じゃないわ
コンパイルエラーね

**デフォルトの名無しさん** · 2022/09/01(木) 09:59:00.80

いや動的配列ならやっぱ実行時か
どっちにしてもCみたいに変更しちゃいけないところを変更して暴走しないってこと

**デフォルトの名無しさん** · 2022/09/01(木) 10:09:23.03

>>56
元の話は>>23だからインデックス値のforループ
C言語でも他でもfor文で境界チェックが必ず入る

配列アクセス時はまた別の問題
Cならばチェックしないがfor文でチェック済なので安全上の問題なし
Rustならばチェックするがfor文でチェック済なので最適化によりここでのチェックは消えて問題なし

結果としてCでもRustでも同じ生成コードとなる

**デフォルトの名無しさん** · 2022/09/01(木) 10:23:52.21

>>59
動的配列のランダムアクセス時にC言語では入らない境界チェックが入るな

**デフォルトの名無しさん** · 2022/09/01(木) 10:30:39.30

>>59
日本語で説明するよりコードと生成されるアセンブリ見せた方がわかりやすいのでは

**デフォルトの名無しさん** · 2022/09/01(木) 10:31:44.69

forループの例では同じ生成コードとなるが
範囲内かどうか不明なインデックス値がやってきてそれで配列をアクセスする場合は違いが出る

C/C++
プログラマーの自己責任で境界チェックを手動でしなければならない
忘れたときは未定義動作となりうるため危険

Rust含むその他の言語
プログラマーは気にせずとも自動的に境界チェックされるため安全

**デフォルトの名無しさん** · 2022/09/01(木) 11:17:36.46

>>43
もうRustの覇権確定だなｗ

**デフォルトの名無しさん** · 2022/09/01(木) 12:16:04.06

その技術を作られたのがこれか
https://i.imgur.com/ymYXnQr.jpg

**デフォルトの名無しさん** · 2022/09/01(木) 12:46:30.05

>>62
？？
範囲forは？

**デフォルトの名無しさん** · 2022/09/01(木) 13:36:52.33

>>59
>Cならばチェックしないがfor文でチェック済なので安全上の問題なし

doubt
マジで言ってるなら去ね

**デフォルトの名無しさん** · 2022/09/01(木) 19:55:15.23

>>66
forでインデックスの境界チェック済みとあるから
配列のアクセス時に再び境界チェックしなくても安全でしょ

**デフォルトの名無しさん** · 2022/09/01(木) 20:39:52.39

いや、for文でのループ条件とか書き間違えてバグる筆頭だろ。
人力チェックの限界が見える典型。

**デフォルトの名無しさん** · 2022/09/01(木) 21:06:01.62

Rust方式が速さと安全の両立でベストだろう
基本的には配列(スライス)アクセス時にインデックス境界チェックが行われて必ず安全
その上でインデックスforなどでループ内のアクセスがコンパイラにより安全と保証できる場合は
最適化によりループ内の配列(スライス)アクセス時にインデックス境界チェックが無くなり速さと安全を両立

**デフォルトの名無しさん** · 2022/09/01(木) 21:29:24.74

>>38
単価の中央値は？

**デフォルトの名無しさん** · 2022/09/01(木) 22:04:15.15

もしもポインタが組み込み型ではなく外部のライブラリだったら
ライブラリを変更するだけでCはそこそこ安全になれた

C++はスマートポインタを追加することはできても
元からあるポインタ型を改善することは全然できなかった

**デフォルトの名無しさん** · 2022/09/02(金) 00:56:06.09

>>69
slice::Iterは<[] as Index>::index使わないから最適化関係なく境界チェックは一度だけになるが

**デフォルトの名無しさん** · 2022/09/02(金) 05:54:25.85

>>59
痛いRustおじさんの代表例だね、境界チェックが必ず入る処理系があったとしてそれを、C言語は！なんて表現しないぞ？
「結果としてCでもRustでも同じ生成コードとなる」絶対ならないからｗつーかアセンブラして貼り付けろよ？
それで常に100%が誰がやってもどのバージョンでもどの環境でも同じならあんたが正しい
そもそも配列ループの遅さをカバーするためにRustは速度を稼ぐために一部分ループ展開を勝手にするはずなので、gccとかなら
O2ではダメでO3でfunroll-loopsでコンパイルしないとならないよ

**デフォルトの名無しさん** · 2022/09/02(金) 07:47:28.70

>>72
もちろんRustはイテレータが強力だから
インデックスで回すよりもイテレータ利用が断然に多く
スライス(配列)アクセスに境界チェックを毎回しないのはおっしゃる通りだが
様々な理由でイテレータではなくインデックスでforで回す場合もあり
その時ですらforの終端チェックのみで最適化によりスライス(配列)アクセス時の境界チェックは消えている
という話だから両立する話

**デフォルトの名無しさん** · 2022/09/02(金) 07:51:35.38

>>73
配列ループで遅いなんて聞いたこともなく実際に遅くなっていない
何を根拠にそんなデタラメで叩いているのだろうか

**デフォルトの名無しさん** · 2022/09/02(金) 08:11:51.41

他言語の範囲forとかイテレーターを無視して「Rustのforが一番」とかいうのは無知を通り越して無能。
「C++のforループは危険」というのはさすがに引っ込めたみたいだけど、cのforループと比較してRustを褒めるのは邪悪すぎるだろ。

**デフォルトの名無しさん** · 2022/09/02(金) 08:20:26.86

>>76
みんなが話しているのは配列アクセスの安全と速さ
forはその時に出てくるだけであってfor自体の比較を誰もしていない
そこに優劣もない

**デフォルトの名無しさん** · 2022/09/02(金) 08:36:58.81

>>77
その割にはforの安全チェックとか持ち出しているやついるけど。
それに配列ならコンパイル時にサイズが決定する／しないで全然違うけど、そこをごっちゃにしているアホがいない？

**デフォルトの名無しさん** · 2022/09/02(金) 09:00:49.10

ほんとダメだねえ、どうやっても遅いんだが？顔真っ赤にして人を罵倒する前にさ
https://play.rust-lang.org/?version=stable&mode=release&edition=2021&gist=f46924c1a775bf93703ca7aead58b36c
real 0m0.111s
https://wandbox.org/permlink/iP4fPQ7bODKrg7mC
real 0m0.006s

「C言語でもループ1回に付き必ず1回のインデックス値の境界比較が必ず入る」
まず根本的に勘違いしてるのがあなたの言ってるのは境界チェックじゃなく、終了条件のチェックであり、これも、gccなどの処理系では
最適化で固定値だったりしてループ展開したら必ず入るとは限らないんですよ・・・同様のことがRustの勝手にループ展開でも言えますが
いずれもループ終了チェックであり、そんなのは比較していませんし、またあとから出てきたイテレータの話は全く違う話ですね

**デフォルトの名無しさん** · 2022/09/02(金) 09:05:50.01

>>78
批判するにはちょっと知識不足すぎじゃない？
みんなが書いているRustのスライスはコンパイル時に長さが確定しないから、確定する配列だけでなく、どちらの場合でも大丈夫ってこと

**デフォルトの名無しさん** · 2022/09/02(金) 09:13:12.31

前スレでも出てたけどrustがphpより遅いってマジっぽいね

**デフォルトの名無しさん** · 2022/09/02(金) 09:17:24.54

>>79
あまりにキチガイでワロタ
その約20倍差の数値で比較しちゃってるのかよ
本気で20倍速いと思い込んでる？

**デフォルトの名無しさん** · 2022/09/02(金) 09:24:36.61

>>74
レス番つけ忘れたけど、頑にCと（速度が）同じだ。遅くないというカルト信者みたいな態度はほんと反省してほしいわ・・・
根拠を示したのにキチガイと反論するばかりで、こんな簡単なプログラムにさえどこが悪いのか言えないし

**デフォルトの名無しさん** · 2022/09/02(金) 09:32:20.12

誰も20倍速いなんて一言もいってませんが？timeごときでこの程度の差が出るのであれば、「同じ」なんて言えないと思いますが？
むしろ境界チェックが機能してる結果であり、一方でCはそのような境界チェックは通常の処理系ではありえない＝チェックがないので
安全性はlintなどやプログラマーの能力に依存する
提言：”内容に反証を提示できず、人をキチガイ呼ばわりする人がキチガイ”

**デフォルトの名無しさん** · 2022/09/02(金) 10:07:22.38

> C言語でも他でもfor文で境界チェックが必ず入る

std::vectorだと両方あるから説明しやすいけど

reference at(size_type n);
　n >= size()の場合、out_of_range例外を送出する。

reference operator[](size_type n);
　vector型のオブジェクトvに対して、v[n] と *(v.begin()+ n) は同じ結果になる
　n >= size()の場合、未定義動作となる
　この関数は、at()メンバ関数とちがって境界チェックを行うことが規定されない。

境界チェックってこれの話じゃないの？
index側のどうこうはさておき、要素アクセスのときにケアできてるかどうかの話じゃないの？

**デフォルトの名無しさん** · 2022/09/02(金) 10:13:15.80

ちなみにJavaのjava.util.Listは

https://docs.oracle.com/javase/jp/8/docs/api/java/util/List.html#get-int-
E get(int index)
　例外: IndexOutOfBoundsException - インデックスが範囲外の場合(index < 0||index>= size())

となってる。

**デフォルトの名無しさん** · 2022/09/02(金) 10:33:22.77

現代のCPUなら投機的実行で境界チェックみたいな処理は時間コストかからんけどなあ
それとRustのprintln!は非バッファでロックもするから配列性能計測に混ぜたらいかんでしょ
性能計測の初歩だと思うんだけど

**デフォルトの名無しさん** · 2022/09/02(金) 10:41:36.52

ここが応仁の乱か

**デフォルトの名無しさん** · 2022/09/02(金) 11:14:19.45

Rustのスライスsでfor i in 0..s.len()でループ回して見たら
生成コードはforの終端チェックだけになってs[i]の境界チェックは消えるんだな
確かに論理的に正しい最適化だが賢いな
結局Cでfor (i = 0; i < len; i++) とした時と同じ

**デフォルトの名無しさん** · 2022/09/02(金) 12:00:55.17

println!取り除いてもCより遅いけど？
勝手にコードを変更してs.lenとか悦にはいってるし、この人たちって絶対objdumpした結果を上げないね
同じ（＝100%一致）なんて絶対あり得ない、gccじゃなくclang/llvmにしたら分らんけど、それでも
”Ｃ言語は”なんてあんたさえも知らない処理系があるのに恥ずかし気もなくビックマウス披露出来るわけない
投機実行の境界チェックのバイパスは有名なスペクターとして脆弱性だから機能してないんちゃうか？知らんけどさ

**デフォルトの名無しさん** · 2022/09/02(金) 12:40:37.54

>>80
固定長なら範囲チェック自体消えるだろ。

Rustの話をするなら、「ひとつの読み書き参照 xor 複数の読み取り参照のきっつい制約を課すことで範囲チェックの回数を減らしている」くらいの説明はできんのかね？オレも詳しくはないが。

**デフォルトの名無しさん** · 2022/09/02(金) 18:35:42.02

引数で与えられた配列の中の最大要素をインデックスアクセスで探す関数をC (clang 14) と Rust (rustc 1.63.0) で書いた
使ってるレジスタこそ違うけど同じコンパイル結果になった

https://godbolt.org/z/TvdGf3dYq

Rust は他の書き方も試してみたけど生成されたコードは同じっぽい

forでsliceをイテレートした場合:
https://godbolt.org/z/38s1819hr
イテレータアダプターだけで書いた場合:
https://godbolt.org/z/cjqqYjKfE

**デフォルトの名無しさん** · 2022/09/02(金) 19:48:54.34

っつーか今さらcでの開発なんて小規模じゃないとやりたくないわ。

**デフォルトの名無しさん** · 2022/09/02(金) 20:22:00.68

遅いくせにCと同等とか言い出したのが発端じゃね？

**デフォルトの名無しさん** · 2022/09/02(金) 20:51:46.96

>>92
凄いな
CとRustは同じ生成コードになるんだな
どちらも64バイトでループ展開か

**デフォルトの名無しさん** · 2022/09/02(金) 20:58:00.60

>>94
生成コードが同じだからCとRustは速さも同等っぽい

**デフォルトの名無しさん** · 2022/09/02(金) 21:28:46.71

>>96
マジか、rustすご過ぎ

**デフォルトの名無しさん** · 2022/09/02(金) 21:41:46.84

わざわざ境界値チェックが不要になるケースで比べたらそりゃそうだろって感じ
最初のサンプルコードが酷すぎた

**デフォルトの名無しさん** · 2022/09/02(金) 21:45:38.80

>>98
境界値チェックが必要なケースをよろ

**デフォルトの名無しさん** · 2022/09/02(金) 22:15:29.02

結論が出たな
Rustを攻撃してた人が以下のようなウソをついてた

> 「結果としてCでもRustでも同じ生成コードとなる」絶対ならないからｗ
> つーかアセンブラして貼り付けろよ？

> そもそも配列ループの遅さをカバーするために
> Rustは速度を稼ぐために一部分ループ展開を勝手にするはず

生成アセンブラコード>92を見ると
CでもRustでも同じ生成コード
CもRustもループ内のインデックス境界チェックは無く同じコードとなっている
そしてCもRustも一部分ループ展開を同様にしてる
当然どちらも同じ速度となる

**デフォルトの名無しさん** · 2022/09/02(金) 22:58:49.99

>>98
早くc言語で境界値チェックするコード出してよ。

**デフォルトの名無しさん** · 2022/09/02(金) 23:27:03.89

全然読まない、勝手にコードを変更してs.lenとか悦にはいってる

**デフォルトの名無しさん** · 2022/09/02(金) 23:59:11.14

>>102
配列やベクタやスライスなどを一般的に
C言語で扱う関数ならば先頭ポインタと長さを受け取る
Rustならばその二つがペアとなったスライスsを受け取りその長さ部分がs.len()
だから常識的なプログラマーならば誰が書いても>>92のソースコードとなる
そして生成アセンブラコードがCとRustで同等と判明した

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

おじさん普通にC勉強した方が良いよ
Rust書ける人でC書けない人なんていないからズレまくった指摘してるんだよ
Rustであえてパフォーマンス出ないようなコードを書いてるとしか思えない

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

>>92のシンプルなコードをこれ以上に速くするのは無理じゃね
そしてRustもCも同等のアセンブリコードを吐いてるから実行速度も同じで勝負ついた感じだな

**デフォルトの名無しさん** · 2022/09/03(土) 03:19:04.56

バカ野郎！
Rustのおっちゃんは、日本を代表するトライアングル（楽器）奏者なんだぞ！

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

少なくとも配列範囲外アクセスするようなコードで比べなければ意味がない。
誰も勝負なんてしてないだろ
こんな事やってるからRustを嫌う人が割と増えていく、言い逃れそのものだろｗ

そもそもforの終了条件チェックと配列境界チェックの違いすら分かってないやつだ
カルトRust信者「C言語でもループ1回に付き必ず1回のインデックス値の境界比較が必ず入る」

固定長のループがclang/llvmで同じになったとして、壺カルトRust信者曰く、「C言語は」という
デカすぎる主語と、Rustでのすべての配列境界チェックが無くなるわけではなし何が勝ちなんだか...

**デフォルトの名無しさん** · 2022/09/03(土) 05:27:05.78

>>107
コードを読めない人なの？
固定長のループではなく長さは関数の引数として与えられている
したがってC言語でもループ1回に付き必ずインデックス値の境界比較(＝インデックス値が長さを超えないこと)がfor文の条件部で行われている

**デフォルトの名無しさん** · 2022/09/03(土) 06:17:52.84

>>92
例えばinline化とかで二つの配列/スライスがエイリアスされていることがコンパイラー(とプログラマー)に見えている場合があると思うんだけれど
Rustの方は自動ベクトル化してくれないのね。Cの方は自動ベクトル化されている。

極端に書くとこんな感じ。
ttps://godbolt.org/z/sbenoGEEa

inline
ttps://godbolt.org/z/M6qz3s3f7

max_value_slice_vwをどう書いたら自動ベクトル化されるの?

**デフォルトの名無しさん** · 2022/09/03(土) 06:38:25.68

何の争いかよくわからんけどつまりRustでサイズ10の配列を作ってその11番目の要素にアクセスしたらどうなるん？
Cだと境界チェックしないから未定義になるしセグフォ出たり他の変数を書き換えたり暴走したりすることもある

**デフォルトの名無しさん** · 2022/09/03(土) 06:40:51.52

11というのをリテラルで与えるともしかしたらコンパイルエラーになるかもしれんけどたとえばそれを乱数で生成した場合はどうなんの？

**デフォルトの名無しさん** · 2022/09/03(土) 06:53:51.31

Cが境界チェックしないと言うのは境界チェックがプログラマの責任だということだよね
Rust以外のモダンな言語では大抵範囲外の要素にアクセスしようとすると実行時例外を吐く
Cはそれをせず黙って暴走したりこっそり他の変数の値を書き換えたりして気づきにくいバグになる
Rustはどっち？

**デフォルトの名無しさん** · 2022/09/03(土) 06:56:12.20

>>109
わざわざw = v; とか
架空コードすぎて気持ち悪い

**デフォルトの名無しさん** · 2022/09/03(土) 07:06:18.00

>>112
Rustは基本的には他の大多数の言語と同じで、アクセスする前に自動的にインデックスの境界チェックをする。

ただし、>>92などのように多くのプログラム利用例では、インデックスはforで指定範囲を動くため、アクセスする際のインデックス境界チェックは最適化により必要とせず行われなくなり、結果としてC言語と同じアセンブラコードが生成される。

**デフォルトの名無しさん** · 2022/09/03(土) 07:13:36.64

つまり、Rustは安全性を常に保ちつつ、不要な境界チェックは最適化で無くすことで、安全かつ高速を実現。

**デフォルトの名無しさん** · 2022/09/03(土) 07:29:39.97

>>114
普通じゃね？

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

CとRustは同じアセンブリコードを生成すると>>92で示されているから
あとは他の言語でもそうなるならそれを示せばよい

**デフォルトの名無しさん** · 2022/09/03(土) 07:37:07.45

どうでもいい内容で盛り上がってるな
for文の仕様がボトルネックになることなんかないんだからどうでもいい

**デフォルトの名無しさん** · 2022/09/03(土) 07:46:39.87

例えばfor (i=0;i<len;i++) arr[i*2]=0;
Rustはこの時もCと同じコードになるんだよね？

**デフォルトの名無しさん** · 2022/09/03(土) 07:56:47.99

gccのコミッターのものだけどそんな単純な話じゃないよ
Rustのスティーブとはよく話をするけどね

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

最後の一行で胡散臭さ出てくるの何なん

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

まあこんなマイクロコードの比較だのベンチだのに意味は無いわな
コンパイラも局所だけ見て処理するわけでもなし

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

>>119
Rustのfor文はそういう構文ではない
あとRustではその処理関数は引数をスライスxで受けることになり
lenはx.len()となる

そしてfor i in 0..lenのループの時
x[i] = 0ならばそのアクセスには境界チェックは最適化により生じない　(C言語と同じ)
x[i*2] = 0ならばそのアクセスには境界チェックが入りindex out of boundsとなる　(C言語と異なる)

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

>>123
境界チェックがあるって言われてるのはその場合のことだよ
最適化で無くなる時の話をしてるのは君だけじゃないかな多分

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

rust書けるやつはたいていcも書ける。
cは書けるがrust書けないなつはいる(俺とか)。
両方書けるほうがいいに決まってる。

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

>>123
後者はC言語だと範囲外をアクセスしてしまい破綻だな
境界チェックをするRustが正しい

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

>>124
正しい使用ならば最適化されて境界チェックが消える点も重要やで
それによりRustのコードがCとほぼ同じ速度で動いている

一方で間違った範囲外のアクセスが起きうる場合には境界チェックがなされる点も重要やで
それによりRustはCとは異なり安全となっている

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

>>123,126
> あとRustではその処理関数は引数をスライスxで受けることになり
> lenはx.len()となる
配列の一部だけを処理したいとか普通にあるだろ

**デフォルトの名無しさん** · 2022/09/03(土) 09:21:53.95

>>128
配列の一部分はスライス　(配列全体も可)
Vecの一部分もスライス　(Vec全体も可)
スライスの一部分もスライス
なのでRustで関数を書くときはスライスを対象にして記述する
そしてスライスとして扱った時点で既に境界チェック済み(＝元の範囲内)なので最適化が可能となる

**デフォルトの名無しさん** · 2022/09/03(土) 09:24:37.68

さすが複オジ隔離スレやで
今日もいい仕事しとるww

**デフォルトの名無しさん** · 2022/09/03(土) 09:27:25.47

Rustの実行速度がCと同等だと何か困ることでもあるの？

**デフォルトの名無しさん** · 2022/09/03(土) 09:30:24.03

>>129
関数内でlenが決まる場合でもいちいちスライス作るのか？

**デフォルトの名無しさん** · 2022/09/03(土) 09:32:15.16

C/C++ で BITMAPINFOHEADER なんか扱うときは
意図的に範囲オーバーさせて bmp データにアクセスするよねω株 PI.3.14

**デフォルトの名無しさん** · 2022/09/03(土) 09:37:13.56

>>131
Rustアンチの人にとって「Rustは遅い！」が信仰の砦。
ところが世間で言われてる通り、RustはCとほぼ同じ速さだと>>92で分かり、大変なことになってしまって大騒ぎ。

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

困るとか困らないとかじゃなくCではやらない境界チェックがあるから現実に遅いよ

**デフォルトの名無しさん** · 2022/09/03(土) 09:47:19.22

Cと同じ速度で動くコード「も」あるというならその通り
他の言語でもある

**デフォルトの名無しさん** · 2022/09/03(土) 09:52:51.38

>>132
Rustのスライスは抽象化された概念で扱われるけど
実体は先頭ポインタと長さのペア
だからスライスを作るって大層なことではなくC言語で処理対象の先頭ポインタと長さを用意するのと同じ

あと、Rustではforインデックス使わずにイテレータチェーンにすることも多いけどその時もスライス起点が多い
そのイテレータチェーン利用時も>>92の下でforインデックス時と同等の生成コードになることが示されてる
つまり境界チェックは起きずC言語と同じ速さで動く

>>136
C言語より遅いコードがあると主張したいならば
具体的に>92のように生成コードの比較を出せばよい

**デフォルトの名無しさん** · 2022/09/03(土) 09:54:03.17

境界チェックが消えたコードじゃなく消えてないコードで比べてみたらすぐわかるんじゃないですかね