次世代言語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/09/03(土) 10:06:50.84

>>142
プログラマが完璧なら危険ではないので上司のしりぬぐいをしないというのがCのスタンス
Rustはチェックするので正しいが遅い

あのー、わざとやってるのかバカなのかどっちなの？

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

>>141
Rustではもっと抽象的に捉えてプログラミングするからそこに無駄と考える発想は出てこないし
同じだから無駄だといっても生成コードは最適化で無駄は消えるからCと同じ速さが出るでしょう

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

実例と計測結果出さないと空論でしか無いわな
まあ速度差が無くて出せないんだろうけど

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

チェックが入ると遅くなるから最適化でチェック省くことがあるんだろうに何で実測しなきゃわかんないんだよ
特定のスニペットじゃなく境界チェックが入る現実のコードの話をしてるのに実測なんてできるわけないだろ
境界チェックが原因で遅くなるコード作れと言うなら作るが、それ作ったら間違いを認めるんだろうな？

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

>>144
ホントに常に消えるの？
ダメなケースは存在しないの？

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

>>143
それは君が誤解してるようにみえるなあ
Rustでは安全に範囲内のアクセスとRustコンパイラが分析できれば境界チェックをしないためCと同じ速さが出る
そうでなく危険な範囲外のアクセスになりうるとRustコンパイラが判断すれば正しく境界チェックを行なう
C言語で書いても危険な範囲外のアクセスになりうる場合は手動で境界チェックをせざるを得ないから速さは同じ

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

>>148
同じじゃなく遅くなると認めろよ

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

>>149
遅くなる具体例ありそう？それ知りたい
RustとCのアセンブリ生成コードが同等になり速さが同じとなるケースは>>92で示されてるから
同じようにして遅くなるケースを示せばよいと思う
もちろん範囲外アクセスとならない例でw

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

いつもの嘘つき複オジに必死に突っかかるアホ
どっちもどっち

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

>>148
> そうでなく危険な範囲外のアクセスになりうるとRustコンパイラが判断すれば正しく境界チェックを行なう
C言語では外部からもらったデータは仕様で配列範囲に入るのが確実だからチェックをしないとかあるんだけど、Rustコンパイラとやらは仕様書まで読み込んでくれるのかなw

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

境界チェックによるペナルティが気になる箇所なら境界チェックのないget_unchecked使えば良いのでは
デフォルトは安全側に倒されてるけどプログラマの裁量で速度を優先することもできるので、適材適所でどちらを使うか選べば良い
C++でも境界チェックありのat()があるから、デフォルトが逆なだけでできることは同じだよね

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

結局プログラマーの手に委ねていると必ずミスが起きうるから
境界チェック省略の件も含めて全てについて
コンパイラが分析して安全かどうか判定できた時にはチェックを省略し
そうでない場合は安全のために自動的にチェックをするのがベスト
という方向へ向かっているんじゃないかな

GoogleやMicrosoftがRust言語でOS開発
https://xtech.nikkei.com/atcl/nxt/column/18/00692/042700054/
【脆弱性の70％がメモリー管理バグに起因】
GoogleによればAndroidに存在した深刻なセキュリティー脆弱性の70％近くがメモリー安全に関するバグに起因するという。
同様にマMicrosoftも、同社製品に存在したセキュリティー脆弱性の70％がメモリー安全に関するバグに起因すると述べている。
C/C++を使う限りセキュリティー脆弱性を根絶するのは不可能と考えて、Rustを採用するに至ったというわけだ。

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

マジキチだった

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

>>150
じゃあCよりRustが遅くなるコードを示せばごめんなさいすんのか？しないだろ？
ここまでの説明でわからないバカがいるはずないからレスバしたいだけだよな？

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

この話題、ここ数年で最もレベル低いんじゃないか？大丈夫か？

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

Rustは安心安全でC言語と同等の速度ってことでFAだな

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

体言止めおじさん

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

最近のレベル低下には目を見張るものがあるな

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

>>142
>array[i*2]の例は危険な範囲外アクセスとなるコードだから境界チェックをするRustに軍配が上がるね

array[i*2]の例は危険な範囲外アクセスとなるコードだから境界チェックをしないCに軍配が上がる
が正しい

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

いやはや、時代についていけないCオジが暴れてるようだなw
Cオジもさぁ、自分の世界に引きこもってないでもっと外の世界見ないとねw

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

Cこそ最強！
1個でもCより遅いケースあったらダメね！

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

次世代言語スレなんだから変数の境界越えたアクセスは落とす一択だろ。

もうちょっと別の話したいわ。

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

1個でもCより遅い場合あったら、他にメリットあっても意味ないから！

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

誰も>>91の突っ込み無いんかよ。
Rustが速いのは非常にキツイxor条件を満たす範囲だけで、そこを超えるのはとても面倒。そこを無視して「Rustは安全で高速」とか言うのは詐欺じゃね？

あと、次世代スレなのに何でRustとcだけの比較なんだよ。rangeの最適化なんてイマドキc++ですらやるんじゃないの？

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

このスレは何もかもをRustと比較したがる信者とそれに反応してしまうバカに乗っ取られた隔離スレです
次世代言語スレではありません
次世代言語の話がしたいかたはこちらへ↓

次世代言語27 Nim Zig Pony Carbon Gleam
https://mevius.5ch.net/test/read.cgi/tech/1659660050/

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

ていうかこいつほんとにRust使ってプログラミングできるの？って思ったんだけど
あまりにも頭が残念すぎて論理的思考の必要なプログラミングができるとは思えない

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

>>165
Cで書いた方が良い箇所はCで書けば良いのでは
アプリケーション全体を単一言語で書かなければならない理由もなかろう

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

>>167
最終レスが8月18日とか終わってんじゃねえか

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

TypeScriptは次世代なのか？
そろそろ枯れてきてるし何ならバニラが復権しかけてんだが

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

>>169
そんなこと言ったらRsutを使う場面が無くなっちゃうだろ

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

Rustはスライスに対して境界チェックをしないでアクセスする方法もunsafeで用意されている
つまり最適なプログラミング方法はC/C++を絶対に使わずに全てをRustで記述し
「コンパイラによる安全保証で最適化により安全に境界チェックを省略してくれる部分以外」かつ「人間による安全保証で境界チェックを不要としたい部分」のところのみunsafeで人間が安全保証し
その部分以外は全てコンパイラにより自動的にあらゆるメモリ安全保証させるのが最適な方法となる

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

>>137
>>109は RustがC言語より圧倒的に遅いコードです

>>166 172
＞Rustが速いのは非常にキツイxor条件を満たす範囲だけ
＞「Rustは安全で高速」とか言うのは詐欺
＞そんなこと言ったらRsutを使う場面が無くなっちゃうだろ

完全同意
Rustの最適化度合いは一貫性がなくて信頼できない
「Rustで高速化」が少しでも視野に入っている人は
Cコードも書いて常にasmとBenchmarkで比較確認するしかない

＞173
109はRust版が10倍くらい遅いんだけどunsafe使ったら早くなるの？

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

え？↓これってデマなんだよね？

https://qiita.com/shadowTanaka/items/5fb99819629dcaab3e05

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

>>174
わざわざ　w = v; 　してそんな無意味なプログラムを書く人いないよ
>>92のような実際に使われているパターンの意味のあるプログラム例が欲しいな

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

>>109
これって偶然とか意図に関係なく引数が手に負えなくなると
Rustが全く最適化をしない、というPOCじゃね?

>>92
はhello worldレベル過ぎて逆に意味なくない?

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

>>174
Cのコードを書く必要はない
Rustには一部エリアのみプログラマーに安全性の保証の義務を負わせるunsafeブロックがありCと同じことができる
ベンチも#[bench]等ですぐ比較できるから速さにシビアな場合は本件に限らずアルゴリズムの差異も含めてコストをかけるだろう
その点はどんな言語でも同じ

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

>>178
＞Cのコードを書く必要はない
＞ベンチも#[bench]等ですぐ比較できる
いやいやCコードなしにhello sliceどうしでいくら比較しても意味ない。>>174は信頼性の話でしょ

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

>>174
最適化度合いに一貫性のある言語って何？
Cだろうがasm確認しないといけないのは同じだと思うが

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

>>109のコードを見てみたが書き方が酷いな
とりあえずそれと全く同じ関数仕様に合わせるとして
Rustならもっと簡潔にこのように書く

fn max_value_slice_vw(v: &[u32], w: &[u32]) -> u32 {
　std::iter::zip(v, w)
　　.map(|(m, n)| m + n)
　　.max()
　　.unwrap_or_default()
}

C言語バージョンより遥かに分かりやすいし
通常Rustでは返り値をu32でなくOption<u32>とするから最後のunwrap_or_default()も不要となる

これでC言語バージョンと全く同じ結果を得られるし
境界チェックも行われないし
そのC言語バージョンと全く同等のアセンブリコードが生成されることも確認できる
つまり今回の>>109の件もRustとCは同じ速さで動作する

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

>>180
現行C/C++だけがダントツトップレベル
Rustは裏でLLVM使ってるのに何で >>177 で信頼性がないと証明されたんだ...

>>181
あちゃちゃhello sliceと違う書き方をしないといけないなんて、これも無信頼性のPOCだ

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

「最適化度合い」ってあれだな
「クイックソートは最悪のケースの計算量が多過ぎる」みたいな
ヒープソート最強伝説に似ている

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

>>183
ほんとだね。アルゴリズム系は数学的に最悪ケースを予期回避できるのに、Rustの一貫性の無さは最悪
>>181で突然「このように書く」って言われてもPOCの積み増し

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

>>181
RustはわかりやすくシンプルにプログラミングできてCと同じ速度なのが素晴らしいね

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

>>185もはや自虐ネタ。嫌味ですか？

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

Rustをむやみに褒めてるやつがアホすぎてRustのネガティブキャンペーンにしか見えない件

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

こういう争いは同じレベルのやつ同士でしか起きない
お互いに相手がアホだと思ってるけど両方同レベルのアホ

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

for文を使わずにメソッドチェーンで書いたことが気に入らないのならば
>>181はfor文を使って以下のように書ける

fn max_value_slice_vw2(v: &[u32], w: &[u32]) -> u32 {
　let mut max = 0;
　for (m, n) in std::iter::zip(v, w) {
　　if max < n + m {
　　　max = n + m;
　　}
　}
　max
}

これもC言語バージョンと同じ動作をし
同等のアセンブリコードが生成されることも確認できる

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

せめてID変えずにやってくれればいいのにな
何回NGさせるんだか

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

>>189
確認乙
POC(>>177,182)積み増し乙

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

Cだと速いけどRustだと遅くなるケースって存在しないの？
誰かそういう例を作ってほしい
ここまでRustがCと同じ速さで書ける例ばかりだから

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

本人はバレてないと思ってるらしいw

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

>>192
はい。Rustは一貫性がない(>>177,>>182)ので個別にCコードと比べて
書き方を変えることにより同程度にもって行ける
ケースが稀にあることが証明されました
多大な努力の結果です。感謝

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

Rustはfor文自体がイテレータを使うから、
for i in 0..s.len() {
　　println!("{}", s[i]);
}
とインデックスを使う書き方をするのは非常に稀で、
これはインデックスを使わず、
for n in s {
　　println!("{}", n);
}
と書くのがRustでは普通だから、
インデックス議論自体があまり意味のないものに思える。
そしてどちらの書き方をしてもCコードと同速度。

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

Rustがそんなに速いならなんで競プロはC++一択なの

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

>>196
それは単なる人口差・マニュアルやサンプル数差
C++に次いで多いのが言語としてはかなり遅いPythonなのを見ても分かる通り

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

まあ、型を正確に宣言しても速くならないし遅くなるというのがもし本当なら
バニラJSが復権するのもPythonが支持されるのも当然といえば当然

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

>>196
解説本がc++が多いからかな

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

例えば競プロAtCoderでABC182-E問題 i行目j列目のマス(i,j)を扱う問題
提出された各プログラミング言語別の実行時間分布
https://pbs.twimg.com/media/EmYvG8aVkAMdfFG.jpg

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

Rustはコーディングに時間がかかるから競プロでは使えない。
競プロにC++とPythonは良い選択。

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

>>200
競プロでもRustが速いね

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

>>196
そもそもC++もちゃんと書けるとは言えないでしょ
mainとグローバル変数しか使わないし

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

他言語を貶しても、Rustが使える言語にはならない。

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

>>200
Pythonを選んだ時点でPyPy3にしたとしても負け戦が確定かよ
Rustは競プロでも強いのか

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

>>200 懐かしいなあ
ttps://ビット.ly/3CS8AuV
トップのuzzyさん始めC++勢がじわじわ最適化を進めているのがカッコイイ
ちらほらいるRust勢は一発屋だけでインクリメンタルな最適化が出来ていないね。
Rustは一貫性がない(>>177,>>182)から下手に弄れなかったのかな？

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

>>204
その定型文のどこが「使える」と思ったのかがさっぱり分からないよ

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

>>207 Rustって一発作ったらそれ以上で弄れないって開発現場では使えない言語だね(>>206)

**デフォルトの名無しさん** · 2022/09/04(日) 00:08:42.58

>>206
インクリメンタルに最適化したと本気で思い込んでる？
uzzyの上位4つとも全てソース同じまま変化していない
つまり何度も同じのを提出してトライしただけ

**デフォルトの名無しさん** · 2022/09/04(日) 00:27:20.06

で、その競プロでのc言語での参加率はどれくらい？> cオジ

**デフォルトの名無しさん** · 2022/09/04(日) 00:31:23.21

4回ともC++コード同じだな
ただしその一つ前だけコードが違っていて二次元配列を一次元へと書き換えて改善してる
一方でRustの人は最初から一次元にしてるからその改善が必要なかった
つまり>>208はRustを叩きたいだけの完全に的外れ

**デフォルトの名無しさん** · 2022/09/04(日) 02:03:59.28

たぶん必要なのは
葡萄を食べるべきでない理由ではなく
食べない自由なんだな

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

>>200
プログラミング言語間の速度差が激しくて勝負にならないな
競プロで勝つためにはRustかC++を選ばざるを得ないのか

**デフォルトの名無しさん** · 2022/09/04(日) 08:07:09.64

>>213
いいや
Pythonは論外だけど他の言語で十分戦える

**デフォルトの名無しさん** · 2022/09/04(日) 08:19:18.55

>>200
Rust最速レベルやん
てかC++の分布笑えるな
ギリ合格からトップクラスまでみっちり

**デフォルトの名無しさん** · 2022/09/04(日) 10:34:00.57

本日のRustあげ会場はこちらですか？

**デフォルトの名無しさん** · 2022/09/04(日) 11:16:04.09

貶めれば誹謗中傷かも知れんけど、ほめれば気持ち悪いだけ
こんなの消去法でほめるに決まってんだろ

**デフォルトの名無しさん** · 2022/09/04(日) 11:23:49.03

参加者自体はRustも多い。
C++と同じくらい居る。
時間内に提出できる人が少ないだけ。

**デフォルトの名無しさん** · 2022/09/04(日) 11:27:19.04

つまりRustは生産性が低いor利用者の能力が低いってこと？

**デフォルトの名無しさん** · 2022/09/04(日) 11:52:32.99

普通にガチ勢は昔からC++を使ってて今さら他の言語にしないというだけだろうな

**デフォルトの名無しさん** · 2022/09/04(日) 12:28:01.29

CオジはCとC++比べてもやっぱCの方が早いからC++はダメとか言うのかな？

**デフォルトの名無しさん** · 2022/09/04(日) 12:29:11.61

ダメな香具師が描いたダメなC++コードは本当に糞
Cのがマシ

**デフォルトの名無しさん** · 2022/09/04(日) 12:57:20.84

>>201
Pythonはよほどうまくチューニングしないとすぐ時間制限越えるんで競プロだと使い物にならないんですわ
>>200のグラフから実行時間でのランキングができそうだけどぶっちゃけ時間内に結果が出れば速かろうが遅かろうが大差無いのでPython以外なら何使ってもいい
言語よりプログラマーの能力が大事だし、それよりむしろ暇の方が大事
とにかく参加し続けてなるべく正解を出してれば上位に行ける

**デフォルトの名無しさん** · 2022/09/04(日) 13:11:43.10

pythonでアルゴリズム性能出ると思ってるのお前だけだよ。。

**デフォルトの名無しさん** · 2022/09/04(日) 13:31:05.58

お前がアルゴリズムという言葉を知らないと言うことがわかった

**デフォルトの名無しさん** · 2022/09/04(日) 14:04:04.57

行列の和と積を英単語ではなく記号で書けるだけでC++と互角みたいになったのがPython

argv + 1000000 がnullを返したり計算中に例外を投げる実装が可能なだけでRustと互角になれる

**デフォルトの名無しさん** · 2022/09/04(日) 14:42:33.66

何と戦ってるのか知らんがイミフな基準

**デフォルトの名無しさん** · 2022/09/04(日) 14:46:33.79

>>223
うーん、いろんな言語で競プロやってる青色だからついコメントしたくなってしまう

CPythonは知らんけど、pypyは実行速度速いからマラソンでもなければ困ることないよ
再帰がしんどいと言われる問題も、コドフォではよく使われてるbootstrapデコレータを使えば簡単に解決する
Rustはusizeの扱いのために余分なコードが必要になることが多かったし、クロージャ使おうとすると引数の型とかめんどいしで、最近は専らPythonを使ってる
Pythonはクロージャを短めに書けることも競プロ的には気が楽だな

**デフォルトの名無しさん** · 2022/09/04(日) 15:31:08.56

Rustは競プロに向いて居ないからな。
避けるのが賢明。

**デフォルトの名無しさん** · 2022/09/04(日) 15:33:36.35

複オジと
複オジにマジレスしちゃう人と
その両方を焚き付けて喜んでる人の三人でお送りしています

**デフォルトの名無しさん** · 2022/09/04(日) 16:44:07.43

Cが普通はintインデクスなのになんで、配列というかスライスをusizeにしたか何回も疑問に上がるよね....
まあインデックスループじゃなく、イテレート操作するからとか、std::ops::Index<T>でusizeだからとか
色々な回答があるけど、どうにもスッキリしない
usize以外の型（より小さい型やsigned)を使えるようにすることは将来ありうるかという開発者への質問も
ライブラリの互換性上ではすぐに実現できないみたいだし、ま、使う人の利便性・プログラマーへの負担軽減を
優先的に考えて作られた言語じゃないからだけど、let mutと書いてる時点でそうだが、せめてこれだけでも
1キーワードに出来なかったんだろうかな
それとCだとint a = 0, b = 1, c = 2;と宣言できるけど、let (mut a, mut b, mut c) = (0, 1, 2);
文末セミコロンで複数行に分けても、理解しやすいという話はどこに行った？使いやすさを求めては
イケないんだろうけど、どうもね....

**デフォルトの名無しさん** · 2022/09/04(日) 16:46:11.53

ミュータブルを極力使うなということだろ

**デフォルトの名無しさん** · 2022/09/04(日) 17:40:27.34

韓国で最も愛される言語と銘打てば流行るのでは？

**デフォルトの名無しさん** · 2022/09/04(日) 17:47:06.26

>>231
わざと面倒臭くさせてることに意味がある
その辺りの思想は今までの言語とは違うかもしれん

**デフォルトの名無しさん** · 2022/09/04(日) 17:48:26.12

>>231
＞Cが普通はintインデクスなのに
そんなルール無いよね？
仕事で他社さん作ライブラリがuint使ってたことある。

**デフォルトの名無しさん** · 2022/09/04(日) 18:06:41.17

普通にprintln!使うと遅いんだけど教プロ上位なんだな

**デフォルトの名無しさん** · 2022/09/04(日) 18:17:28.78

競プロではRustは間違いなく最速レベルだし、proconioみたいなマクロを使えば入出力もめちゃくちゃ扱いやすい
でもまあそれ以外のとこでかなり慣れがいる

**デフォルトの名無しさん** · 2022/09/04(日) 18:21:48.03

安心安全最速、Rust最高じゃん

**デフォルトの名無しさん** · 2022/09/04(日) 19:10:58.79

>>231
インデックスやその長さはusize型で絶対に正しい
まずインデックスは負の数になってはいけないからunsigned型
サイズとしてはポインタなどと同じそのCPUで使われるサイズでなければならないからusizeとなる
そして実際のほとんどの様々なプログラミングにおいてインデックスはusize型で上手く動く

ところが例外が二つある
例外の一つは自分たちで決められない外部指定APIなど規定においてインデックスや長さがusize型でない場合でas usizeにより解決

例外のもう一つは一部の数値アルゴリズムでプログラミングする上で一時的もしくは最初あるいは終端で負の数になると便利なことがある
もちろんその一時的な負の数である時ははインデックスとして使われないようにプログラマーの責任でプログラミングしてインデックスとして使う時はas usize

**デフォルトの名無しさん** · 2022/09/04(日) 19:29:23.15

浮動小数点数から符号無し整数へキャストする命令なくね？
最近の処理系は直接キャスト出来るようなったん？

**デフォルトの名無しさん** · 2022/09/04(日) 19:44:58.67

>>231
その3-tupleはデータ型の一つでもありまとめて変数に格納できるし関数の引数や戻り値に3-tupleは使える
let foo = (1, 2, 3);

letはパターンマッチ文なので分解にも使う
let (a, mut b, c) = foo;
b += 100;
println!("{a} {b} {c}')
ここでbしかmutableを必要としていないのだから個別mut指定が自然
どの言語でも同様だがmutableをできる限り少なくするのがプログラミングのコツ

**デフォルトの名無しさん** · 2022/09/04(日) 20:00:50.97

>>231
Cも配列のインデックス関連は(s)size_tが基本では
strlenやmemcpyの引数や返値はsize_tだし
単にintから暗黙的にキャストできるというだけで

暗黙の数値キャストがないのは確かにめんどくさい

asでのキャストはリリースビルドだと範囲外の値になったときにエラーにならないし、
絶対成功するキャストと失敗する可能性のあるキャストが見た目からぱっと区別がつかないのもよろしくない
かといってn.try_into().unwrap()を書くのもだるい

せめてn.into()で済ませたいが16bitアーキもサポート対象だからusizeに From<u32> が実装されていない

ターゲットを32bit以上のアーキテクチャに限定するした場合はinto()使えるようにするとか、もう少し楽にできないだろうか

**デフォルトの名無しさん** · 2022/09/04(日) 22:29:03.84

>>242
Rustは基本としては正しい一貫した方針をとっていて
型変換が必ず成功するものはinto()つまりfrom()が定義されていて
型変換が成功しない可能性のあるものはtry_into()つまりtry_from()が定義されている
したがって基本的にはどちらかを用いればよい
新たな型に対しても同じ方針で実装していくしライブラリもそうなっている
usizeについても同様だが16bit環境もあるためbool, u8, u16からのみinto()となり一貫している
唯一の例外は浮動小数点で成功が定義されないためにinto()もtry_into()もない

上述のコンパイラが型変換を常に保証する方式に対して
プログラマーが型変換を保証する方式に利便性を兼ね備えたのがasによるキャスト
これは例えばu32を自動的に上位を切り捨ててu8に入れるといったことも含めた広義の型変換も含まれる
いずれのケースもキャストはプログラマーの責任で行なうという一貫した方針がある
わざわざ『as xxx』と記述させるのはそのためで意図的に目立つようにしている
プログラムをチェック、デバッグ、メンテする時にunsafeに準じてas xxxは注視すべきポイントとなる