次世代言語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(土) 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は注視すべきポイントとなる

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

>>243の基本を踏まえた上で
例えば16bit環境でなければu32からusizeへのtry_into()は常に成功し安全にunwrap()できる
生成コードも以下のようにコストゼロ
https://godbolt.org/z/cEc5fKGjh

キャストasと同様にunwrapも注視ポイントとなるため
利便性も含めてinlineのto_usize()を用意してしまうのがよいかもしれない
bit環境依存性はそのメソッドに押し込めることで注視ポイントが散らばるのを防げる

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

危険のある操作は面倒にするべきなんだよ。

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

>>239
それ絶対に正しいとは言えてないよね
下のほうに書いてるんだろうけど、よくある別の言語仕様だと、a[-1]が末尾を表したりできるし、数多くの言語でインデックスループだと
これもよくある相対位置やインデックス演算でa[i-1]とか書くけど、usizeをキャストしてi32にしてもう一度、スライスにアクセスするために
as usizeとか2回キャストを行う。これがどれほど醜くなるし、めんどくさくて労力を要するか
当然、メモリアドレッシングが0x00～上に伸びていくことなんて言わなくてもわかるが、それが合理的であり、かつスライスがusizeで
支持できる理由かといえばどうだろう？少なくとも私はメンドクサイ
またもちろん、(a, b) = t がタプルのアンパッキングなどに使えるのも知ってるけど、それとまとめて変数の宣言と初期化を少ないタイプ量で
出来る話とは別だろう、上からアドバイス頂いてるようでケチをつけて申し訳ないけど、もちろん不変性はマルチスレッドでも有利だしコードの
リファクタリングなどもし易い、ファンクションの変更が良くわかる（そのくせ同じ変数名で別型再定義できたり）とか色々利点があるのは
当然分かってるけど、これもまたmutを多数宣言しなきゃならない時とは全く別の話だよ

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

>>246
Rustならばusize型そのままa[i-1]と書くことが出来ますが
2回キャスト面倒とは別の言語の話ですか？

例えば前の要素との差が指定のものを見つけてインデックスを返すRustコード例
fn find_diff(a: &[i32], diff: i32) -> Option<usize> {
　for i in 1..a.len() {
　　if a[i] - a[i-1] == diff {
　　　return Some(i);
　　}
　}
　None
}
もちろん最適化によりアクセス時のインデックス境界チェックは無くなります

**デフォルトの名無しさん** · 2022/09/05(月) 00:30:20.92

まともにプログラム書いたことなさそうだね

**デフォルトの名無しさん** · 2022/09/05(月) 00:34:33.72

>>241
Rustはletとmut指定を分離することでそのようにできるから大成功だな
mut指定が分離していない言語ではそのようにすることができずいつも困っている
方法がないからimmutableで十分な変数も含めてまとめてmutableな変数宣言にせざるをえない
初めて知ったときRustはよく考えられているなあと感動した

**デフォルトの名無しさん** · 2022/09/05(月) 00:43:43.47

>>246
・Rustは、数値リテラルに多くの言語ある固定の型がなく、文脈によりu32とかi32とか変わる（型推測）
・下のほうで境界チェックがないのも1..a.len()としているから
当然ながら、これは胸を張って一貫性があるとは言えないがa[-1]は言語仕様ではコンパイルエラーになるが
for i in 0..a.len()とすれば境界チェックが入り実行時にpanicする
君が勘違いしてるのはa[i+b]とかはbを宣言した場合、as castが必要で、色々ごっちゃになってるYO

アンダースタンド？ｗ

**デフォルトの名無しさん** · 2022/09/05(月) 00:44:27.92

C++は型の特性を調べて、ユーザーがconst性を利用したバージョンの実装を生み出すことができる。
しかも利用時には、型の特性によってコンパイラにどのバージョンを使うか選択させる事が出来る。

**デフォルトの名無しさん** · 2022/09/05(月) 00:48:14.12

RustもIndex<u32>とか実装はできるよ
標準のsliceに実装されてないというだけで

**デフォルトの名無しさん** · 2022/09/05(月) 00:55:53.18

C++は、型の計算ができるんですよ。

**デフォルトの名無しさん** · 2022/09/05(月) 01:07:57.19

すまん、誰が聖闘士星矢で例えてくれないか？

**デフォルトの名無しさん** · 2022/09/05(月) 01:12:56.84

>>254
くちから　たれている　みつは　２きろ　はなれていても　はなが　まがるほど　もうれつに　くさい。

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

>>211
一昨日は言葉が過ぎました。開発現場、携わっている人には心無い発言でした。反省してます。
強調したかったのは、最適化って難しいよ、速そうな言語を選んでコンパイラにお任せって言う易しい世界じゃないよ、という事です。

むしろ叩きたいのは、定期的に現れる無意味なRust上げ
スレッドの流れをフォローしている人間にはネガティブキャンペーンと受け取られているコメントです。
うすうす気づいているとは思いますが、これSEO対策なんですよ。
Rustをほとんど知らない人が検索をした時に、
チラッとその一部だけを見せてエコーチェンバーにはめ込むと言う仕掛けです
同様に時々現れる、会話の流れを修正したい時に持ち出す極論、逆説的にRustを卑下する冗談
これはわざとRsutとタイポしてチラ見に現れないようにしている。
複製おじとは別人だと思うのですがどんなんですかね。皆さんの意見を訊きたいな

**デフォルトの名無しさん** · 2022/09/05(月) 01:22:23.34

>>246はまともにプログラミングしたことないとまでは言えないが多くの勘違いをしてるのは確かだな
usizeを上に伸びていくと書いてあるから引き算出来ないとでも勝手に思い込んでa[i-1]ができないと勘違いしたのかもしれない
もう一件

＞よくある別の言語仕様だと、a[-1]が末尾を表したりできるし

その件はa[-1]やマイナスのインデックスに意味を持たせたプログラミング言語の仕様ミス
もしくはお子様向け言語であるとの結論が大昔に出ている
プログラミングのミスでマイナスのインデックスとなり本来はエラーでミス発覚となるべきところか不可能となった
つまり言語仕様ミスなのかそんなこと気にしないお子様向け言語なのかどちらかということになる
ほとんどの言語はまともなのでa[-i]はエラーとなり正しくa[len-i]と書く

**デフォルトの名無しさん** · 2022/09/05(月) 01:34:56.96

>>257
複製おじ？usizeの議論は微笑ましいですね。盲目的ですが熱意にあふれてます。
速度、最適化に関する盲目的思い込みがなければ無害ですな
SEO対策(>>256)に加担していなければの話ですが

**デフォルトの名無しさん** · 2022/09/05(月) 01:45:29.53

実力のある者はC++を利用するべきでは？

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

>>259
同意ですな
一方で熱意にあふれ盲目的で従順に車輪の開発をしてくれるプログラマが
無料で使えるのであれば使わない手は無いとLinus辺りは策略してそう
SEO対策(>>256)もあながち...？

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

欠陥言語C++を使うメリットは何？
今はこれだけ多数の安全な言語があって色々選べるのに

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

アセンブラを使う理由はレジスタにアクセスできるから。
これはとても危険。
C/C++を使う理由はメモリーにアクセスできるから。
これはとても危険。

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

大いなる力には責任が伴う。
　　2019 - アフレシアさん

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

早くコンセプトが使いたいわー。

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

>>261 もしこの二日間程度のスレッドの流れをフォローしてもなお一つのメリットも見えないのであれば
あなたの長所は熱意だけです。周りを頼って上手に立ち振る舞ってください。

>>260 有料案件で活躍されているプログラマーを見下すものではありません

>>263 同意正に実力の世界。去れよ無責任Kids

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

C++にもメリットはありゼロじゃない
ただし世界的には>>154の結論が出ている
そして今回もC++で書かれたChromiumの穴のせいで、それを使うElectronを始め多數に影響が出て、それを使うVScodeにもセキュリティ脆弱性と連鎖
C++を使い続ける限りセキュリティの穴が量産されてしまう

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

>>266
あなたの結論素晴らしいですね。
どうぞLinusあるいはMozillaの元へ
SEO対策(>>256)の一環ですか？

＞C++を使い続ける限りセキュリティの穴が量産されてしまう
ほんと怖いです。一刻も早くRustに書き換えて欲しいですね。もう10年経ったっけ？

ところでFirefoxのthird_party directoryを除いたsource repoでのRustの使用割合ってご存知？宿題ですよ

**デフォルトの名無しさん** · 2022/09/05(月) 03:10:33.61

何でもrustでやらんで、安全性第一のとことか機能が優れてるとこ(非同期やジェネリクス、健全なマクロ、パターンマッチ等)とかからでもrustを便利に使ってったらええ。
今のrustは少しずつ実用面で採用を広げて行ってる段階だろ。Linuxでの採用とかさ。
既存のcでやってることをイキなり全部rustで置き換えようとしてる人なんて居ない。
rustにその潜在能力があったもしてもマンパワーが足りない。だから大手は少しずつ小さな分野で使いだしてる、複数の大手でね。
ただrustはもっとc言語との連携が簡単だったらと思う。

**デフォルトの名無しさん** · 2022/09/05(月) 03:31:45.52

>>268
＞何でもrustでやらんで、安全性第一のとこ
完全同意話が合いそう
安全性アピールがマーケティング上有利な暗号通貨系の動きが早かったです

＞Linuxでの採用とかさ。
早いとこ第一歩を踏み出して欲しいです。偉大な一歩となることでしょう。

＞既存のc...イキなり全部rust...
10年なんてあっという間ですね

＞複数の大手でね。
大手って何やっても凄いです
ScalaでのNetflix分岐点未満/以上の話を思い出した

＞ただrustはもっとc言語との連携が簡単だったらと思う。
完全同意話が合いそう

>>266 が宿題(>>267)をサボったら手伝ってあげてください

**デフォルトの名無しさん** · 2022/09/05(月) 03:36:29.05

>>268
どの言語からどの言語の場合でも既存システムをそのまま言語置き換えはコストだけかかり効率がよろしくない
そのためシステム改修や新規システムを中心にRust採用となっているようだ
現在ある選択肢では人間が引き起こしうるミスをコンパイラに防止させてセキュリティ含む穴を無くしていく言語候補がRustの他にない

**デフォルトの名無しさん** · 2022/09/05(月) 06:42:39.68

簡単に言えば、Pythonの代わりにRustを使うことはあっても、C/C++の代わりになることはない。
レジスタやメモリーを扱うのは大変危険だから。

**デフォルトの名無しさん** · 2022/09/05(月) 07:16:47.41

>>271
Rustはinlineアセンブラ記述をサポートしていてレジスタ操作もできることを知らないのかね
Rust叩きの人はなぜ学習せずに無知なままなのだろうか

**デフォルトの名無しさん** · 2022/09/05(月) 07:22:08.46

>>272
じゃあ安全じゃないじゃん。

**デフォルトの名無しさん** · 2022/09/05(月) 07:51:21.51

以前の言語
　・プログラムのメモリ安全性、null安全性、データ競合安全性をプログラマーの責任で保証する

Rust
　・それらの安全性を全てコンパイラが保証
　・プログラマーの責任でCと同じメモリ操作やインラインasmなどを記述できるunsafeブロックもサポート

Swift, Kotlinなど
　・null安全性をコンパイラが保証

**デフォルトの名無しさん** · 2022/09/05(月) 08:33:46.56

>>268
Rustを使うにはガッツリ勉強しないと無理だから……THE BOOK一通り勉強しないと無理だから……

**デフォルトの名無しさん** · 2022/09/05(月) 09:45:50.25

>>92
上に書いたように、当然gccでやったら同じコンパイル結果にならず全く違いますね？これを同じとは言えません
rustcの結果(-C opt-level=2)が138行あるが、x86-64 gcc 12.2(-O2)は16行です。
https://godbolt.org/z/v6TxTGGbT
max_value:
test rdi, rdi
je .L4
lea rcx, [rsi+rdi*4]
xor eax, eax
.L3:
mov edx, DWORD PTR [rsi]
cmp eax, edx
cmovb eax, edx
add rsi, 4
cmp rsi, rcx
jne .L3
ret
.L4:
xor eax, eax
ret

速度の比較はやはりrust（というかllvm)のほうが、ほんのちょっぴりから2倍以内ほど遅い結果になると思います。
今はC言語といえばclangなのかもしれませんが作られているソフトウェアはまだgccのほうが圧倒的に多いです。
gccを-O3にするとrustcと同じくSIMD拡張命令が使われますが、それでも84行と138行なので違います
それほど真剣に見ていませんが、C側はlenが引数として取るのに対して、もう一方はlen()を呼び出していますが
c/clangでほぼ同じになるのはなんでなんでしょうか？

**デフォルトの名無しさん** · 2022/09/05(月) 09:57:13.85

>>276
やっぱりおまえアホだな
16行だから速いと思っている？？
行数で速さは決まらないが
その例なら16行のコードが無展開で一番遅くなる