22/08/29 11:22:16.48 5dAad4gs.net
スレタイ以外の言語もok
前スレ
次世代言語27 TypeScript Swift Go Kotlin Rust Nim
ｽﾚﾘﾝｸ(tech板)
2:デフォルトの名無しさん
22/08/29 13:57:56.66 rGElgR/G.net
>>1 乙
>>980 次スレ立ててね
3:デフォルトの名無しさん
22/08/29 17:39:40.63 OPpJUiH3.net
文字列の変数sが与えられた時に
変数a (符号付き32bit整数)、
変数b (符号なし64bit整数)、
変数c (64bit浮動小数点数)へそれぞれ変換するコード
【Rust】
let s: &str = "12345";
let a: i32 = s.parse()?;
let b: u64 = s.parse()?;
let c: f64 = s.parse()?;
【Kotlin】
val s: String = "12345"
val a: Int = s.toInt()
val b: ULong = s.toULong()
val c: Double = s.toDouble()
【Swift】
let s: String = "12345"
let a: Int32 = Int32(s)!
let b: Uint64 = Uint64(s)!
let c: Double = Double(s)!
【Go】
var s string = "12345"
var err error
var a int32
a, err = strconv.ParseInt(s, 10, 32)
var b uint64
b, err = strconv.ParseUint(s, 10, 64)
var c float64
c, err = strconv.ParseFloat(s, 64)
4:デフォルトの名無しさん
22/08/29 18:02:10.99 99yF6EBS.net
KotlinやSwiftは型推論できるやろ
それにパースとキャストは違うぞ
5:デフォルトの名無しさん
22/08/29 18:41:59.28 bPAqKnWj.net
全然書き込みが無いけど
ypeScript Swift Go Kotlin Rust Nimって、需要も人気も無いの？
6:デフォルトの名無しさん
22/08/29 18:50:03.71 9qXoEPFV.net
>>4
今どきのプログラミング言語はいずれも型推論が賢いね
昔は型推論が無いか弱くて
変数の型宣言が不要というだけで動的型付け言語のメリットされていた時代もあった
7:デフォルトの名無しさん
22/08/29 19:09:28.15 bPAqKnWj.net
次世代言語と言われる
TypeScript も Swift も Go も Kotlin も Rust も Nim ←これらの言語を全然知らない、
昭和の時代から IT関連業で働き、稼いでいた者には、居場所が無いから別の職種に転業すべきかなぁ
8:デフォルトの名無しさん
22/08/29 19:33:16.23 iMDvJogZ.net
>>7
TS、Go、Kotlinはいたるところで使われてるから、すでに現行言語では？
9:デフォルトの名無しさん
22/08/29 19:46:28.38 vWUiNEGz.net
AWSがプログラミング言語「Rust」を使っている理由
URLﾘﾝｸ(japan.zdnet.com)
Amazon Web Services（AWS）は、同社のエンジニアたちがプログラミング言語「Rust」を
使っている大きな理由として、エネルギー効率の高さを挙げる。
AWSは早くからRustを採用し、GoogleやMicrosoftとともにRust Foundationの創設にも携わった。
現在もRustの普及に熱心に取り組んでいる。
AWSのソフトウェアエンジニアで、Rustの普及に取り組む、
Shane Miller氏と主任エンジニアのCarl Lerche氏の投稿によれば、
Rustはメモリー安全性を高め、セキュリティ関連の不具合を減らす役に立つだけでなく、
PythonやJavaよりもはるかに「エネルギー効率に優れている」という。
Amazonは、2025年までにデータセンターの100％を再生エネルギーでまかなうという目標を掲げ、
データセンターの環境負荷の軽減に取り組んでいる。
Rustの採用はその一翼を担うという。
Rustで構築されたAWSサービスの例としては、
コンテナーアプリ用のサーバーレスプラットフォーム「Lamba」を支える「Firecracker」、
「Amazon Simple Storage Service（S3）」「Amazon Elastic Compute Cloud（EC2）」、
コンテンツ配信ネットワーク「Amazon CloudFront」、
LinuxベースのコンテナーOS「Bottlerocket」がある。
「CやRustが他の言語よりもエネルギー効率に優れていることに驚きはない。
衝撃的なのは、その違いの大きさだ。CとRustを広範に採用すれば、
控えめに見積もってもコンピュートに使用されるエネルギーの量を50％削減できる可能性がある」と
Miller氏は述べ、その根拠として、C、GoogleのGo、Lua、Python、Ruby、Fortranなどをはじめとする
複数の言語のエネルギー効率を相対的に示した研究結果を紹介している。
10:デフォルトの名無しさん
22/08/29 20:29:24.84 bPAqKnWj.net
>>8
そういった系統の言語は、
業務で使用した事が無いから知りませんね。
11:デフォルトの名無しさん
22/08/29 20:37:11.19 bPAqKnWj.net
>>9
Lambdaといえば、Common Lisp だな。
LISP - Lambda Functions
12:デフォルトの名無しさん
22/08/30 08:16:39.53 6rcI0yHq.net
>>9
AWSていつのまに会社になったの？
13:デフォルトの名無しさん
22/08/30 09:39:41.83 AsY/BIgk.net
文末がセミコロンで終わらない言語は流行らない
14:デフォルトの名無しさん
22/08/30 09:45:30.28 lk52xXWB.net
>>13
それなー
15:デフォルトの名無しさん
22/08/30 09:52:15.23 hK2QX/pR.net
Pythonはセミコロン非推奨だが。
16:デフォルトの名無しさん
22/08/30 12:29:02.78 OnpgRnR2.net
matzは構文に人間が寄り添うのではなく構文解析を言語が頑張るべき的なことを言ってたけど、現実は構文は厳格にしてformatterやlnterが曖昧さのないコードに導いてやるのが正解になってきたね。
人間なんてどこまでも適当な事をやらかせるんだから、それを実行時にうまく解釈してやるのは無理筋。
17:デフォルトの名無しさん
22/08/30 12:39:56.18 BpLonSBR.net
>>16
構文の厳格さもformatterもlinterも関係ないじゃんw
頭悪過ぎる
18:デフォルトの名無しさん
22/08/31 00:25:17.21 h52EUFtB.net
Pythonは当初の頓珍漢な理想を捨ててpython2を見捨てなかったのがえらいんだよ
19:デフォルトの名無しさん
22/08/31 16:57:16.44 nshUFjI3.net
Rustを自分には向いてないと言った（恐らく本人は批判したつもりはない）一生懸命にmatzを叩くRust新興カルトが気持ちわる杉る....
CやC++でバリバリ書いてる人に所有権チェックなんて邪魔すぎるし、配列境界チェックだって速度が出ない足を引っ張る機能にしか見えないだろ
今は固定範囲の配列アクセスのチェックなんかは省略してるかもしれんが、恐らくそんな事はない（全てに係るから安全だと大口する）
20:デフォルトの名無しさん
22/08/31 18:05:12.54 0pp++Yd3.net
matzは静的型付け言語は
変数に型定義を書きまくるのが面倒くさい
というようなとこを言ってて
型推論とか知ってるくせにそれは
無いんじゃねと思ったな
21:デフォルトの名無しさん
22/08/31 18:25:03.72 Fgf/9Zy6.net
CやC++で困ってない人に無理にrustを勧めてくる人は相手しなくて良いよ
22:デフォルトの名無しさん
22/08/31 18:30:28.99 kXQrZaUS.net
matzのおかげでプログラミング文化が進化したのはのは間違いない
RustもRuby文化のいい面をかなり受け継いでいる
23:デフォルトの名無しさん
22/08/31 18:32:18.02 SRFkQuBk.net
>>19
所有権チェックって何？
そんな用語も概念も存在しない
配列境界チェックは
例えばインデックス値をforでループに回したとしても
最適化によりforでのチェックだけになり
インデックスを使った配列やスライスへのアクセス時に再びチェックすることはない
つまりC言語と同じになる
>>21
困ってる困っていないの問題ではない
回避策が確立されたのに欠陥言語を使い続けるか否かの問題
人間は必ずミスを起こしうる、との結論が出ていて
大手IT企業も挙ってRustを採用している
24:デフォルトの名無しさん
22/08/31 18:35:01.88 Fgf/9Zy6.net
>>23
Rustこそが銀の弾丸って主張かな？
25:デフォルトの名無しさん
22/08/31 18:36:59.70 Fgf/9Zy6.net
みんな所有権所有権言うけど、初学者がひっかかりがちなのって借用の方では
所有権というとRAIIの方を連想してしまうけど
C++でmove使いこなしてた人ならRustの所有権ではひっかからないだろうし、他の言語でもtry-with-resourcesとか類似の概念あるよね
26:デフォルトの名無しさん
22/08/31 18:55:37.66 hNAJwBIT.net
うちの会社にもPHPで困ってないからと言いながらゴミを作り続けるおっさんいるわ
27:デフォルトの名無しさん
22/08/31 19:25:46.59 Fgf/9Zy6.net
>>26
そういうおっさんが業務の阻害要因になってるならなんとかした方が良いけど
掲示板上でどういう問題抱えてるかすら分からない相手に闇雲に勧めるのとは全然違うよね
28:デフォルトの名無しさん
22/08/31 19:48:33.02 SRFkQuBk.net
>>26
PHPは>>9の記事の観点からはエネルギー効率の悪い劣った言語かもしれないが
C/C++が現実に大量のセキュリティの穴も含むメモリ管理バグを引き起こし続けている危険な欠陥言語である点とは大きな開きがある
29:デフォルトの名無しさん
22/08/31 19:56:05.14 D6khOQ0c.net
>>27
おっさん自身は問題を理解できてないってことを言ってるんだよ
30:デフォルトの名無しさん
22/08/31 19:56:39.74 bi3oBo/Y.net
どんなに優れたプログラマーでもミスをするしバグも作るって考え方は大事だと思うけどな
31:デフォルトの名無しさん
22/08/31 19:58:59.48 mLZrYK8Z.net
#define new old
で、全て解決では？
32:デフォルトの名無しさん
22/08/31 20:04:50.79 mLZrYK8Z.net
でもウェブサイトの9割はPHPで出来てると言うからなあ。
33:デフォルトの名無しさん
22/08/31 20:33:48.91 TBd/y3ES.net
PHPを馬鹿にするやつにその資格はない
PHPの作者を馬鹿にするやつにその資格はない
PHPよりも作者よりも糞なやつが鏡すら見ずに薄ら笑ってる
34:デフォルトの名無しさん
22/08/31 20:38:28.28 PQ5q9d58.net
>>26
ゴミって言ってもそれでお金稼いでいる訳じゃなくて？
35:デフォルトの名無しさん
22/08/31 20:55:36.71 bW00GV9W.net
>>24
んなこと言ってねーだろ。
ミスリードすんな。
36:デフォルトの名無しさん
22/08/31 21:00:04.57 mLZrYK8Z.net
Haskellが見向きもされなくなったら、Rustの宣伝が増えたな。
37:デフォルトの名無しさん
22/08/31 21:11:47.88 SRFkQuBk.net
>>36
宣伝？
例えば>>9の記事はクラウドのシェアトップであるAWSがそのサービス提供にRustを使って構築しているという現実の話
着実に様々なインフラがRustベースへと置き換わっていく現実の一つ
38:デフォルトの名無しさん
22/08/31 21:22:47.94 10xvEXEy.net
Rust(笑) 時代はJavaだから
求人倍率はなんと21.8倍 「Java」を求める企業が絶えない理由とは
URLﾘﾝｸ(atmarkit.itmedia.co.jp)
39:デフォルトの名無しさん
22/08/31 21:28:47.20 h52EUFtB.net
限られた情報から善と悪を判断できない人達が
まだ公開されていないクソどうでもいいデータを欲しがる
40:デフォルトの名無しさん
22/08/31 22:11:23.35 tQxzKhe2.net
オラクルに丸め込まれた会社本当にかわいそう
41:デフォルトの名無しさん
22/08/31 22:21:51.07 PDiBd7bz.net
今日Helidonなるものを初めて知ったわ
オラクル足掻いてるよねー
42:デフォルトの名無しさん
22/08/31 23:06:38.28 1xLvm1yy.net
rustは死産だったんだよ
このスレで頑張ってるのは水子供養みたいなもん
43:デフォルトの名無しさん
22/08/31 23:15:56.00 V71AUGNS.net
Facebook、開発言語に「Rust」採用 Javaからも移行
URLﾘﾝｸ(www.itmedia.co.jp)
Rustを用いることで、どのような利点があるのか。
Facebookは記事の中で次の4つの項目を挙げています。
①Rustのasync/awaitシンタックスは、非同期のコードをとてもスムーズに記述できますし、
Rustは複雑な並行処理の詳細を正しく理解するのに役立ちます。
BuckのJavaの計算を一つ一つ並行処理に移行するのは数カ月に及ぶ困難な作業でしたし、
シングルスレッドの大きなボトルネックがまだ存在しています。
②Rustには、開発をより簡単で楽しいものにしてくれる多くの高レベルな言語機能があります。
それらはenum、パターンマッチング、trait、手続き型マクロなどで、
Rustの開発者の多くに愛されています。
③Rust はメモリの割り当てをより細かく制御することができます。
ガベージコレクションのある言語では、たとえジェネレーショナルコレクションであっても、
Buckが行うようなインクリメンタルな演算に対応するのは困難です。
④Rustは高性能です。
Rustに移植することで劇的な性能向上を私たちは見てきました。
44:デフォルトの名無しさん
22/08/31 23:21:00.54 Fgf/9Zy6.net
>>35
いやいやC++で書かれたプログラムは無条件にRustで置き換えられるって主張は銀の弾丸って言ってるのと同じでしょ
45:デフォルトの名無しさん
22/09/01 00:44:24.52 cwSyLQRT.net
善行を勧めることと、善行が必勝法であると主張することを区別する必要がある
46:デフォルトの名無しさん
22/09/01 07:30:51.13 F4Y0rM7S.net
>>23
「最適化によりforでのチェックだけになり・・・つまりC言語と同じになる」
はい、明確すぎる嘘、Cは普通処理系によりけりだが通常は配列境界のチェックなんてしません。あほかｗなにが、つまりだｗ
必死すぎるのがほんと痛々しい
47:デフォルトの名無しさん
22/09/01 07:32:21.78 fyMKlXgD.net
所有権を邪魔だと思ってる奴のC++コードは読みたくねえな
一緒に仕事したくねえ……
48:デフォルトの名無しさん
22/09/01 07:51:48.00 TMFOnHT0.net
>>46
インデックス値でforループを回すとあるから
C言語でもループ1回に付き必ず1回のインデックス値の境界比較が必ず入るよ
境界チェック無しでforを回したら無限ループになる
49:デフォルトの名無しさん
22/09/01 07:57:15.00 F8jNf2Yy.net
>>48
Cって、配列のインデックスアクセスに境界チェックとか無くて、プログラマに委ねられているのかと思ってた。Cも意外に安全性を気にしているんだね。
50:デフォルトの名無しさん
22/09/01 08:33:34.02 5fR61KJN.net
>>38
javaのフレームワークって何使ってるの？
51:デフォルトの名無しさん
22/09/01 09:37:58.04 wgtUDrt5.net
>>44
その通り
条件を絞って
予めRustに移植することを意識して描かれたC++のソースのみ自動変換出来る
なら正しいかも知れない
52:デフォルトの名無しさん
22/09/01 09:39:23.27 wgtUDrt5.net
>>44 追加
ちなみに漏れは
「Rustに移植することを意識して描かれたC++のソース」
ならC++のままでええやん？的な立場
53:デフォルトの名無しさん
22/09/01 09:41:17.41 wgtUDrt5.net
>>48 はCを知らない素人以下
54:デフォルトの名無しさん
22/09/01 09:48:59.81 5fR61KJN.net
>>49
たぶん間違って読解してる。
良くも悪くも日本語って主語省略しちゃうからね。
55:デフォルトの名無しさん
22/09/01 09:50:52.96 NH2cx+n6.net
>>53
え？
>>48で合ってるだろ
インデックスforループは境界比較しないと止まらん
56:デフォルトの名無しさん
22/09/01 09:57:04.30 oWUbfflz.net
>>55
配列のインデックスチェックってここではモダンな言語は配列外にアクセスすると実行時エラーになるということを言ってるんだよ
Cはエラーじゃなく未定義だから何が起こる
57:かわからん
58:デフォルトの名無しさん
22/09/01 09:57:34.15 oWUbfflz.net
実行時じゃないわ
コンパイルエラーね
59:デフォルトの名無しさん
22/09/01 09:59:00.80 oWUbfflz.net
いや動的配列ならやっぱ実行時か
どっちにしてもCみたいに変更しちゃいけないところを変更して暴走しないってこと
60:デフォルトの名無しさん
22/09/01 10:09:23.03 flNKFTp5.net
>>56
元の話は>>23だからインデックス値のforループ
C言語でも他でもfor文で境界チェックが必ず入る
配列アクセス時はまた別の問題
Cならばチェックしないがfor文でチェック済なので安全上の問題なし
Rustならばチェックするがfor文でチェック済なので最適化によりここでのチェックは消えて問題なし
結果としてCでもRustでも同じ生成コードとなる
61:デフォルトの名無しさん
22/09/01 10:23:52.21 oWUbfflz.net
>>59
動的配列のランダムアクセス時にC言語では入らない境界チェックが入るな
62:デフォルトの名無しさん
22/09/01 10:30:39.30 KHPE1b9m.net
>>59
日本語で説明するよりコードと生成されるアセンブリ見せた方がわかりやすいのでは
63:デフォルトの名無しさん
22/09/01 10:31:44.69 0sJGxogX.net
forループの例では同じ生成コードとなるが
範囲内かどうか不明なインデックス値がやってきてそれで配列をアクセスする場合は違いが出る
C/C++
プログラマーの自己責任で境界チェックを手動でしなければならない
忘れたときは未定義動作となりうるため危険
Rust含むその他の言語
プログラマーは気にせずとも自動的に境界チェックされるため安全
64:デフォルトの名無しさん
22/09/01 11:17:36.46 nJgMln8j.net
>>43
もうRustの覇権確定だなｗ
65:デフォルトの名無しさん
22/09/01 12:16:04.06 tWaffXfX.net
その技術を作られたのがこれか
URLﾘﾝｸ(i.imgur.com)
66:デフォルトの名無しさん
22/09/01 12:46:30.05 GpP6p1Yr.net
>>62
？？
範囲forは？
67:デフォルトの名無しさん
22/09/01 13:36:52.33 wgtUDrt5.net
>>59
>Cならばチェックしないがfor文でチェック済なので安全上の問題なし
doubt
マジで言ってるなら去ね
68:デフォルトの名無しさん
22/09/01 19:55:15.23 K2svajoy.net
>>66
forでインデックスの境界チェック済みとあるから
配列のアクセス時に再び境界チェックしなくても安全でしょ
69:デフォルトの名無しさん
22/09/01 20:39:52.39 Wlby5VAy.net
いや、for文でのループ条件とか書き間違えてバグる筆頭だろ。
人力チェックの限界が見える典型。
70:デフォルトの名無しさん
22/09/01 21:06:01.62 ms47s476.net
Rust方式が速さと安全の両立でベストだろう
基本的には配列(スライス)アクセス時にインデックス境界チェックが行われて必ず安全
その上でインデックスforなどでループ内のアクセスがコンパイラにより安全と保証できる場合は
最適化によりループ内の配列(スライス)アクセス時にインデックス境界チェックが無くなり速さと安全を両立
71:デフォルトの名無しさん
[ここ壊れてます] .net
>>38
単価の中央値は？
72:デフォルトの名無しさん
22/09/01 22:04:15.15 cwSyLQRT.net
もしもポインタが組み込み型ではなく外部のライブラリだったら
ライブラリを変更するだけでCはそこそこ安全になれた
C++はスマートポインタを追加することはできても
元からあるポインタ型を改善することは全然できなかった
73:デフォルトの名無しさん
22/09/02 00:56:06.09 itc/vw5Y.net
>>69
slice::Iterは<[] as Index>::index使わないから最適化関係なく境界チェックは一度だけになるが
74:デフォルトの名無しさん
22/09/02 05:54:25.85 shSg4CAC.net
>>59
痛いRustおじさんの代表例だね、境界チェックが必ず入る処理系があったとしてそれを、C言語は！なんて表現しないぞ？
「結果としてCでもRustでも同じ生成コードとなる 」絶対ならないからｗつーかアセンブラして貼り付けろよ？
それで常に100%が誰がやってもどのバージョンでもどの環境でも同じならあんたが正しい
そもそも配列ループの遅さをカバーするためにRustは速度を稼ぐために一部分ループ展開を勝手にするはずなので、gccとかなら
O2ではダメでO3でfunroll-loopsでコンパイルしないとならないよ
75:デフォルトの名無しさん
22/09/02 07:47:28.70 h0CkE7tZ.net
>>72
もちろんRustはイテレータが強力だから
インデックスで回すよりもイテレータ利用が断然に多く
スライス(配列)アクセスに境界チェックを毎回しないのはおっしゃる通りだが
様々な理由でイテレータではなくインデックスでforで回す場合もあり
その時ですらforの終端チェックのみで最適化によりスライス(配列)アクセス時の境界チェックは消えている
という話だから両立する話
76:デフォルトの名無しさん
22/09/02 07:51:35.38 h0CkE7tZ.net
>>73
配列ループで遅いなんて聞いたこともなく実際に遅くなっていない
何を根拠にそんなデタラメで叩いているのだろうか
77:デフォルトの名無しさん
22/09/02 08:11:51.41 yReiMthF.net
他言語の範囲forとかイテレーターを無視して「Rustのforが一番」とかいうのは無知を通り越して無能。
「C++のforループは危険」というのはさすがに引っ込めたみたいだけど、cのforループと比較してRustを褒めるのは邪悪すぎるだろ。
78:デフォルトの名無しさん
22/09/02 08:20:26.86 xKAOCFMw.net
>>76
みんなが話しているのは配列アクセスの安全と速さ
forはその時に出てくるだけであってfor自体の比較を誰もしていない
そこに優劣もない
79:デフォルトの名無しさん
22/09/02 08:36:58.81 yReiMthF.net
>>77
その割にはforの安全チェックとか持ち出しているやついるけど。
それに配列ならコンパイル時にサイズが決定する／しないで全然違うけど、そこをごっちゃにしているアホがいない？
80:デフォルトの名無しさん
22/09/02 09:00:49.10 r2oaJ0uT.net
ほんとダメだねえ、どうやっても遅いんだが？顔真っ赤にして人を罵倒する前にさ
URLﾘﾝｸ(play.rust-lang.org)
real 0m0.111s
URLﾘﾝｸ(wandbox.org)
real 0m0.006s
「C言語でもループ1回に付き必ず1回のインデックス値の境界比較が必ず入る」
まず根本的に勘違いしてるのがあなたの言ってるのは境界チェックじゃなく、終了条件のチェックであり、これも、gccなどの処理系では
最適化で固定値だったりしてループ展開したら必ず入るとは限らないんですよ・・・同様のことがRustの勝手にループ展開でも言えますが
いずれもループ終了チェックであり、そんなのは比較していませんし、またあとから出てきたイテレータの話は全く違う話ですね
81:デフォルトの名無しさん
22/09/02 09:05:50.01 kItyetcb.net
>>78
批判するにはちょっと知識不足すぎじゃない？
みんなが書いているRustのスライスはコンパイル時に長さが確定しないから、確定する配列だけでなく、どちらの場合でも大丈夫ってこと
82:デフォルトの名無しさん
22/09/02 09:13:12.31 AlmyaYR1.net
前スレでも出てたけどrustがphpより遅いってマジっぽいね
83:デフォルトの名無しさん
22/09/02 09:17:24.54 NtJICGnn.net
>>79
あまりにキチガイでワロタ
その約20倍差の数値で比較しちゃってるのかよ
本気で20倍速いと思い込んでる？
84:デフォルトの名無しさん
22/09/02 09:24:36.61 r2oaJ0uT.net
>>74
レス番つけ忘れたけど、頑にCと（速度が）同じだ。遅くないというカルト信者みたいな態度はほんと反省してほしいわ・・・
根拠を示したのにキチガイと反論するばかりで、こんな簡単なプログラムにさえどこが悪いのか言えないし
85:デフォルトの名無しさん
22/09/02 09:32:20.12 r2oaJ0uT.net
誰も20倍速いなんて一言もいってませんが？timeごときでこの程度の差が出るのであれば、「同じ」なんて言えないと思いますが？
むしろ境界チェックが機能してる結果であり、一方でCはそのような境界チェックは通常の処理系ではありえない＝チェックがないので
安全性はlintなどやプログラマーの能力に依存する
提言：”内容に反証を提示できず、人をキチガイ呼ばわりする人がキチガイ”
86:デフォルトの名無しさん
22/09/02 10:07:22.38 3EJXZ/Ye.net
> 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側のどうこうはさておき、要素アクセスのときにケアできてるかどうかの話じゃないの？
87:デフォルトの名無しさん
[ここ壊れてます] .net
ちなみにJavaのjava.util.Listは
URLﾘﾝｸ(docs.oracle.com)
E get(int index)
例外: IndexOutOfBoundsException - インデックスが範囲外の場合(index < 0||index>= size())
となってる。
88:デフォルトの名無しさん
[ここ壊れてます] .net
現代のCPUなら投機的実行で境界チェックみたいな処理は時間コストかからんけどなあ
それとRustのprintln!は非バッファでロックもするから配列性能計測に混ぜたらいかんでしょ
性能計測の初歩だと思うんだけど
89:デフォルトの名無しさん
[ここ壊れてます] .net
ここが応仁の乱か
90:デフォルトの名無しさん
22/09/02 11:14:19.45 RkYzNFi/.net
Rustのスライスsでfor i in 0..s.len()でループ回して見たら
生成コードはforの終端チェックだけになってs[i]の境界チェックは消えるんだな
確かに論理的に正しい最適化だが賢いな
結局Cでfor (i = 0; i < len; i++) とした時と同じ
91:デフォルトの名無しさん
22/09/02 12:00:55.17 kDm3gkwV.net
println!取り除いてもCより遅いけど？
勝手にコードを変更してs.lenとか悦にはいってるし、この人たちって絶対objdumpした結果を上げないね
同じ（＝100%一致）なんて絶対あり得ない、gccじゃなくclang/llvmにしたら分らんけど、それでも
”Ｃ言語は”なんてあんたさえも知らない処理系があるのに恥ずかし気もなくビックマウス披露出来るわけない
投機実行の境界チェックのバイパスは有名なスペクターとして脆弱性だから機能してないんちゃうか？知らんけどさ
92:デフォルトの名無しさん
22/09/02 12:40:37.54 omdV4spc.net
>>80
固定長なら範囲チェック自体消えるだろ。
Rustの話をするなら、「ひとつの読み書き参照 xor 複数の読み取り参照のきっつい制約を課すことで範囲チェックの回数を減らしている」くらいの説明はできんのかね？オレも詳しくはないが。
93:デフォルトの名無しさん
22/09/02 18:35:42.02 itc/vw5Y.net
引数で与えられた配列の中の最大要素をインデックスアクセスで探す関数をC (clang 14) と Rust (rustc 1.63.0) で書いた
使ってるレジスタこそ違うけど同じコンパイル結果になった
URLﾘﾝｸ(godbolt.org)
Rust は他の書き方も試してみたけど生成されたコードは同じっぽい
forでsliceをイテレートした場合:
URLﾘﾝｸ(godbolt.org)
イテレータアダプターだけで書いた場合:
URLﾘﾝｸ(godbolt.org)
94:デフォルトの名無しさん
22/09/02 19:48:54.34 SRTIVbJR.net
っつーか今さらcでの開発なんて小規模じゃないとやりたくないわ。
95:デフォルトの名無しさん
22/09/02 20:22:00.68 AlmyaYR1.net
遅いくせにCと同等とか言い出したのが発端じゃね？
96:デフォルトの名無しさん
22/09/02 20:51:46.96 eOJxFMTK.net
>>92
凄いな
CとRustは同じ生成コードになるんだな
どちらも64バイトでループ展開か
97:デフォルトの名無しさん
22/09/02 20:58:00.60 eOJxFMTK.net
>>94
生成コードが同じだからCとRustは速さも同等っぽい
98:デフォルトの名無しさん
[ここ壊れてます] .net
>>96
マジか、rustすご過ぎ
99:デフォルトの名無しさん
22/09/02 21:41:46.84 TRifMPKk.net
わざわざ境界値チェックが不要になるケースで比べたらそりゃそうだろって感じ
最初のサンプルコードが酷すぎた
100:デフォルトの名無しさん
22/09/02 21:45:38.80 SRTIVbJR.net
>>98
境界値チェックが必要なケースをよろ
101:デフォルトの名無しさん
22/09/02 22:15:29.02 ZICl4sMk.net
結論が出たな
Rustを攻撃してた人が以下のようなウソをついてた
> 「結果としてCでもRustでも同じ生成コードとなる 」絶対ならないからｗ
> つーかアセンブラして貼り付けろよ？
> そもそも配列ループの遅さをカバーするために
> Rustは速度を稼ぐために一部分ループ展開を勝手にするはず
生成アセンブラコード>92を見ると
CでもRustでも同じ生成コード
CもRustもループ内のインデックス境界チェックは無く同じコードとなっている
そしてCもRustも一部分ループ展開を同様にしてる
当然どちらも同じ速度となる
102:デフォルトの名無しさん
22/09/02 22:58:49.99 SRTIVbJR.net
>>98
早くc言語で境界値チェックするコード出してよ。
103:デフォルトの名無しさん
22/09/02 23:27:03.89 lqMLDpPB.net
全然読まない、勝手にコードを変更してs.lenとか悦にはいってる
104:デフォルトの名無しさん
22/09/02 23:59:11.14 VC9smmde.net
>>102
配列やベクタやスライスなどを一般的に
C言語で扱う関数ならば先頭ポインタと長さを受け取る
Rustならばその二つがペアとなったスライスsを受け取りその長さ部分がs.len()
だから常識的なプログラマーならば誰が書いても>>92のソースコードとなる
そして生成アセンブラコードがCとRustで同等と判明した
105:デフォルトの名無しさん
22/09/03 01:19:34.52 txSLq0y3.net
おじさん普通にC勉強した方が良いよ
Rust書ける人でC書けない人なんていないからズレまくった指摘してるんだよ
Rustであえてパフォーマンス出ないようなコードを書いてるとしか思えない
106:デフォルトの名無しさん
22/09/03 01:46:36.01 2EHZBEma.net
>>92のシンプルなコードをこれ以上に速くするのは無理じゃね
そしてRustもCも同等のアセンブリコードを吐いてるから実行速度も同じで勝負ついた感じだな
107:デフォルトの名無しさん
22/09/03 03:19:04.56 DRQBO0l9.net
バカ野郎！
Rustのおっちゃんは、日本を代表するトライアングル（楽器）奏者なんだぞ！
108:デフォルトの名無しさん
22/09/03 04:44:36.86 22c5U/VG.net
少なくとも配列範囲外アクセスするようなコードで比べなければ意味がない。
誰も勝負なんてしてないだろ
こんな事やってるからRustを嫌う人が割と増えていく、言い逃れそのものだろｗ
そもそもforの終了条件チェックと配列境界チェックの違いすら分かってないやつだ
カルトRust信者「C言語でもループ1回に付き必ず1回のインデックス値の境界比較が必ず入る」
固定長のループがclang/llvmで同じになったとして、壺カルトRust信者曰く、「C言語は」という
デカすぎる主語と、Rustでのすべての配列境界チェックが無くなるわけではなし何が勝ちなんだか...
109:デフォルトの名無しさん
22/09/03 05:27:05.78 lg2jZ6dQ.net
>>107
コードを読めない人なの？
固定長のループではなく長さは関数の引数として与えられている
したがってC言語でもループ1回に付き必ずインデックス値の境界比較(＝インデックス値が長さを超えないこと)がfor文の条件部で行われている
110:デフォルトの名無しさん
22/09/03 06:17:52.84 Xvi3nnOL.net
>>92
例えばinline化とかで二つの配列/スライスがエイリアスされていることがコンパイラー(とプログラマー)に見えている場合があると思うんだけれど
Rustの方は自動ベクトル化してくれないのね。Cの方は自動ベクトル化されている。
極端に書くとこんな感じ。
URLﾘﾝｸ(godbolt.org)
inline
URLﾘﾝｸ(godbolt.org)
max_value_slice_vwをどう書いたら自動ベクトル化されるの?
111:デフォルトの名無しさん
22/09/03 06:38:25.68 peyYEDe5.net
何の争いかよくわからんけどつまりRustでサイズ10の配列を作ってその11番目の要素にアクセスしたらどうなるん？
Cだと境界チェックしないから未定義になるしセグフォ出たり他の変数を書き換えたり暴走したりすることもある
112:デフォルトの名無しさん
22/09/03 06:40:51.52 peyYEDe5.net
11というのをリテラルで与えるともしかしたらコンパイルエラーになるかもしれんけどたとえばそれを乱数で生成した場合はどうなんの？
113:デフォルトの名無しさん
22/09/03 06:53:51.31 peyYEDe5.net
Cが境界チェックしないと言うのは境界チェックがプログラマの責任だということだよね
Rust以外のモダンな言語では大抵範囲外の要素にアクセスしようとすると実行時例外を吐く
Cはそれをせず黙って暴走したりこっそり他の変数の値を書き換えたりして気づきにくいバグになる
Rustはどっち？
114:デフォルトの名無しさん
22/09/03 06:56:12.20 TWgTITK1.net
>>109
わざわざw = v; とか
架空コードすぎて気持ち悪い
115:デフォルトの名無しさん
22/09/03 07:06:18.00 z9CaUV9k.net
>>112
Rustは基本的には他の大多数の言語と同じで、アクセスする前に自動的にインデックスの境界チェックをする。
ただし、>>92などのように多くのプログラム利用例では、インデックスはforで指定範囲を動くため、アクセスする際のインデックス境界チェックは最適化により必要とせず行われなくなり、結果としてC言語と同じアセンブラコードが生成される。
116:デフォルトの名無しさん
22/09/03 07:13:36.64 z9CaUV9k.net
つまり、Rustは安全性を常に保ちつつ、不要な境界チェックは最適化で無くすことで、安全かつ高速を実現。
117:デフォルトの名無しさん
22/09/03 07:29:39.97 peyYEDe5.net
>>114
普通じゃね？
118:デフォルトの名無しさん
22/09/03 07:34:10.00 /y6fxgdJ.net
CとRustは同じアセンブリコードを生成すると>>92で示されているから
あとは他の言語でもそうなるならそれを示せばよい
119:デフォルトの名無しさん
22/09/03 07:37:07.45 lGqTIi1A.net
どうでもいい内容で盛り上がってるな
for文の仕様がボトルネックになることなんかないんだからどうでもいい
120:デフォルトの名無しさん
22/09/03 07:46:39.87 1xBXpDYn.net
例えばfor (i=0;i<len;i++) arr[i*2]=0;
Rustはこの時もCと同じコードになるんだよね？
121:デフォルトの名無しさん
22/09/03 07:56:47.99 mdxH418+.net
gccのコミッターのものだけどそんな単純な話じゃないよ
Rustのスティーブとはよく話をするけどね
122:デフォルトの名無しさん
22/09/03 08:03:29.06 peyYEDe5.net
最後の一行で胡散臭さ出てくるの何なん
123:デフォルトの名無しさん
22/09/03 08:04:34.15 2bPWyV3b.net
まあこんなマイクロコードの比較だのベンチだのに意味は無いわな
コンパイラも局所だけ見て処理するわけでもなし
124:デフォルトの名無しさん
22/09/03 08:23:27.57 04g55wUA.net
>>119
Rustのfor文はそういう構文ではない
あとRustではその処理関数は引数をスライスxで受けることになり
lenはx.len()となる
そしてfor i in 0..lenのループの時
x[i] = 0ならばそのアクセスには境界チェックは最適化により生じない (C言語と同じ)
x[i*2] = 0ならばそのアクセスには境界チェックが入りindex o
125:ut of boundsとなる (C言語と異なる)
126:デフォルトの名無しさん
22/09/03 08:27:29.75 1xBXpDYn.net
>>123
境界チェックがあるって言われてるのはその場合のことだよ
最適化で無くなる時の話をしてるのは君だけじゃないかな多分
127:デフォルトの名無しさん
22/09/03 08:47:00.60 pNlcpp9D.net
rust書けるやつはたいていcも書ける。
cは書けるがrust書けないなつはいる(俺とか)。
両方書けるほうがいいに決まってる。
128:デフォルトの名無しさん
22/09/03 08:47:14.13 oioC2Qy2.net
>>123
後者はC言語だと範囲外をアクセスしてしまい破綻だな
境界チェックをするRustが正しい
129:デフォルトの名無しさん
22/09/03 09:09:01.93 YIfnpCsY.net
>>124
正しい使用ならば最適化されて境界チェックが消える点も重要やで
それによりRustのコードがCとほぼ同じ速度で動いている
一方で間違った範囲外のアクセスが起きうる場合には境界チェックがなされる点も重要やで
それによりRustはCとは異なり安全となっている
130:デフォルトの名無しさん
22/09/03 09:12:44.80 qprMzk1R.net
>>123,126
> あとRustではその処理関数は引数をスライスxで受けることになり
> lenはx.len()となる
配列の一部だけを処理したいとか普通にあるだろ
131:デフォルトの名無しさん
22/09/03 09:21:53.95 YIfnpCsY.net
>>128
配列の一部分はスライス (配列全体も可)
Vecの一部分もスライス (Vec全体も可)
スライスの一部分もスライス
なのでRustで関数を書くときはスライスを対象にして記述する
そしてスライスとして扱った時点で既に境界チェック済み(＝元の範囲内)なので最適化が可能となる
132:デフォルトの名無しさん
22/09/03 09:24:37.68 bVYJbA7l.net
さすが複オジ隔離スレやで
今日もいい仕事しとるww
133:デフォルトの名無しさん
22/09/03 09:27:25.47 ezD68Vvz.net
Rustの実行速度がCと同等だと何か困ることでもあるの？
134:デフォルトの名無しさん
22/09/03 09:30:24.03 qprMzk1R.net
>>129
関数内でlenが決まる場合でもいちいちスライス作るのか？
135:デフォルトの名無しさん
22/09/03 09:32:15.16 91ZlUxrs.net
C/C++ で BITMAPINFOHEADER なんか扱うときは
意図的に範囲オーバーさせて bmp データにアクセスするよねω株 PI.3.14
136:デフォルトの名無しさん
22/09/03 09:37:13.56 hKLkDwrb.net
>>131
Rustアンチの人にとって「Rustは遅い！」が信仰の砦。
ところが世間で言われてる通り、RustはCとほぼ同じ速さだと>>92で分かり、大変なことになってしまって大騒ぎ。
137:デフォルトの名無しさん
22/09/03 09:45:26.31 peyYEDe5.net
困るとか困らないとかじゃなくCではやらない境界チェックがあるから現実に遅いよ
138:デフォルトの名無しさん
22/09/03 09:47:19.22 peyYEDe5.net
Cと同じ速度で動くコード「も」あるというならその通り
他の言語でもある
139:デフォルトの名無しさん
22/09/03 09:52:51.38 cKT2CTgA.net
>>132
Rustのスライスは抽象化された概念で扱われるけど
実体は先頭ポインタと長さのペア
だからスライスを作るって大層なことではなくC言語で処理対象の先頭ポインタと長さを用意するのと同じ
あと、Rustではforインデックス使わずにイテレータチェーンにすることも多いけどその時もスライス起点が多い
そのイテレータチェーン利用時も>>92の下でforインデックス時と同等の生成コードになることが示されてる
つまり境界チェックは起きずC言語と同じ速さで動く
>>136
C言語より遅いコードがあると主張したいならば
具体的に>92のように生成コードの比較を出せばよい
140:デフォルトの名無しさん
22/09/03 09:54:03.17 peyYEDe5.net
境界チェックが消えたコードじゃなく消えてないコードで比べてみたらすぐわかるんじゃないですかね
141:デフォルトの名無しさん
22/09/03 09:54:19.38 qprMzk1R.net
>>135
コンパイルオプションでチェック無効に出来ないの？
142:デフォルトの名無しさん
22/09/03 09:56:34.91 RRdFGJ7i.net
>>139
C#はできるね
143:デフォルトの名無しさん
22/09/03 09:59:58.21 qprMzk1R.net
>>137
> だからスライスを作るって大層なことではなくC言語で処理対象の先頭ポインタと長さを用意するのと同じ
いや、実装は想像できるからいちいち説明してもらわなくてもいいんだけどC言語だといちいちそんなもの作らないよ
先頭ポインタも長さ情報も既にあるのに同じ内容を持つスライスを作るのは（C言語脳としては）無駄に思える
144:デフォルトの名無しさん
22/09/03 10:03:47.05 v+XVsXaf.net
>>138
CよりRustが遅いコードを具体的に出してよ
array[i*2]の例は危険な範囲外アクセスとなるコードだから境界チェックをするRustに軍配が上がるね
だから安全な正しいコードなのにCよりRustが遅いコードを具体的に生成コードと共に出しましょう
145:デフォルトの名無しさん
[ここ壊れてます] .net
>>142
プログラマが完璧なら危険ではないので上司のしりぬぐいをしないというのがCのスタンス
Rustはチェックするので正しいが遅い
あのー、わざとやってるのかバカなのかどっちなの？
146:デフォルトの名無しさん
[ここ壊れてます] .net
>>141
Rustではもっと抽象的に捉えてプログラミングするからそこに無駄と考える発想は出てこないし
同じだから無駄だといっても生成コードは最適化で無駄は消えるからCと同じ速さが出るでしょう
147:デフォルトの名無しさん
[ここ壊れてます] .net
実例と計測結果出さないと空論でしか無いわな
まあ速度差が無くて出せないんだろうけど
148:デフォルトの名無しさん
[ここ壊れてます] .net
チェックが入ると遅くなるから最適化でチェック省くことがあるんだろうに何で実測しなきゃわかんないんだよ
特定のスニペットじゃなく境界チェックが入る現実のコードの話をしてるのに実測なんてできるわけないだろ
境界チェックが原因で遅くなるコード作れと言うなら作るが、それ作ったら間違いを認めるんだろうな？
149:デフォルトの名無しさん
[ここ壊れてます] .net
>>144
ホントに常に消えるの？
ダメなケースは存在しないの？
150:デフォルトの名無しさん
[ここ壊れてます] .net
>>143
それは君が誤解してるようにみえるなあ
Rustでは安全に範囲内のアクセスとRustコンパイラが分析できれば境界チェックをしないためCと同じ速さが出る
そうでなく危険な範囲外のアクセスになりうるとRustコンパイラが判断すれば正しく境界チェックを行なう
C言語で書いても危険な範囲外のアクセスになりうる場合は手動で境界チェックをせざるを得ないから速さは同じ
151:デフォルトの名無しさん
[ここ壊れてます] .net
>>148
同じじゃなく遅くなると認めろよ
152:デフォルトの名無しさん
[ここ壊れてます] .net
>>149
遅くなる具体例ありそう？それ知りたい
RustとCのアセンブリ生成コードが同等になり速さが同じとなるケースは>>92で示されてるから
同じようにして遅くなるケースを示せばよいと思う
もちろん範囲外アクセスとならない例でw
153:デフォルトの名無しさん
[ここ壊れてます] .net
いつもの嘘つき複オジに必死に突っかかるアホ
どっちもどっち
154:デフォルトの名無しさん
22/09/03 10:49:11.71 qprMzk1R.net
>>148
> そうでなく危険な範囲外のアクセスになりうるとRustコンパイラが判断すれば正しく境界チェックを行なう
C言語では外部からもらったデータは仕様で配列範囲に入るのが確実だからチェックをしないとかあるんだけど、Rustコンパイラとやらは仕様書まで読み込んでくれるのかなw
155:デフォルトの名無しさん
22/09/03 10:52:15.27 BHvUMyM5.net
境界チェックによるペナルティが気になる箇所なら境界チェックのないget_unchecked使えば良いのでは
デフォルトは安全側に倒されてるけどプログラマの裁量で速度を優先することもできるので、適材適所でどちらを使うか選べば良い
C++でも境界チェックありのat()があるから、デフォルトが逆なだけでできることは同じだよね
156:デフォルトの名無しさん
22/09/03 11:03:40.39 7pWn865H.net
結局プログラマーの手に委ねていると必ずミスが起きうるから
境界チェック省略の件も含めて全てについて
コンパイラが分析して安全かどうか判定できた時にはチェックを省略し
そうでない場合は安全のために自動的にチェックをするのがベスト
という方向へ向かっているんじゃないかな
GoogleやMicrosoftがRust言語でOS開発
URLﾘﾝｸ(xtech.nikkei.com)
【脆弱性の70％がメモリー管理バグに起因】
GoogleによればAndroidに存在した深刻なセキュリティー脆弱性の70％近くがメモリー安全に関するバグに起因するという。
同様にマMicrosoftも、同社製品に存在したセキュリティー脆弱性の70％がメモリー安全に関するバグに起因すると述べている。
C/C++を使う限りセキュリティー脆弱性を根絶するのは不可能と考えて、Rustを採用するに至ったというわけだ。
157:デフォルトの名無しさん
22/09/03 11:21:29.31 Vwpr/aZb.net
マジキチだった
158:デフォルトの名無しさん
22/09/03 11:53:26.95 MAChL+qh.net
>>150
じゃあCよりRustが遅くなるコードを示せばごめんなさいすんのか？しないだろ？
ここまでの説明でわからないバカがいるはずないからレスバしたいだけだよな？
159:デフォルトの名無しさん
22/09/03 11:55:04.03 OwwDkoRs.net
この話題、ここ数年で最もレベル低いんじゃないか？大丈夫か？
160:デフォルトの名無しさん
22/09/03 12:31:15.03 ytBZTWHu.net
Rustは安心安全でC言語と同等の速度ってことでFAだな
161:デフォルトの名無しさん
22/09/03 12:34:45.63 wLxz63Y2.net
体言止めおじさん
162:デフォルトの名無しさん
22/09/03 12:53:59.17 91ZlUxrs.net
最近のレベル低下には目を見張るものがあるな
163:デフォルトの名無しさん
22/09/03 12:58:26.77 91ZlUxrs.net
>>142
>array[i*2]の例は危険な範囲外アクセスとなるコードだから境界チェックをするRustに軍配が上がるね
array[i*2]の例は危険な範囲外アクセスとなるコードだから境界チェックをしないCに軍配が上がる
が正しい
164:デフォルトの名無しさん
[ここ壊れてます] .net
いやはや、時代についていけないCオジが暴れてるようだなw
Cオジもさぁ、自分の世界に引きこもってないでもっと外の世界見ないとねw
165:デフォルトの名無しさん
[ここ壊れてます] .net
Cこそ最強！
1個でもCより遅いケースあったらダメね！
166:デフォルトの名無しさん
[ここ壊れてます] .net
次世代言語スレなんだから変数の境界越えたアクセスは落とす一択だろ。
もうちょっと別の話したいわ。
167:デフォルトの名無しさん
[ここ壊れてます] .net
1個でもCより遅い場合あったら、他にメリットあっても意味ないから！
168:デフォルトの名無しさん
[ここ壊れてます] .net
誰も>>91の突っ込み無いんかよ。
Rustが速いのは非常にキツイxor条件を満たす範囲だけで、そこを超えるのはとても面倒。そこを無視して「Rustは安全で高速」とか言うのは詐欺じゃね？
あと、次世代スレなのに何でRustとcだけの比較なんだよ。rangeの最適化なんてイマドキc++ですらやるんじゃないの？
169:デフォルトの名無しさん
22/09/03 14:31:36.61 RWiDbqEQ.net
このスレは何もかもをRustと比較したがる信者とそれに反応してしまうバカに乗っ取られた隔離スレです
次世代言語スレではありません
次世代言語の話がしたいかたはこちらへ↓
次世代言語27 Nim Zig Pony Carbon Gleam
ｽﾚﾘﾝｸ(tech板)
170:デフォルトの名無しさん
22/09/03 14:36:16.07 peyYEDe5.net
ていうかこいつほんとにRust使ってプログラミングできるの？って思ったんだけど
あまりにも頭が残念すぎて論理的思考の必要なプログラミングができるとは思えない
171:デフォルトの名無しさん
22/09/03 14:49:28.41 BHvUMyM5.net
>>165
Cで書いた方が良い箇所はCで書けば良いのでは
アプリケーション全体を単一言語で書かなければならない理由もなかろう
172:デフォルトの名無しさん
22/09/03 17:15:49.49 jD7rh1Hd.net
>>167
最終レスが8月18日とか終わってんじゃねえか
173:デフォルトの名無しさん
22/09/03 17:17:49.88 jD7rh1Hd.net
TypeScriptは次世代なのか？
そろそろ枯れてきてるし何ならバニラが復権しかけてんだが
174:デフォルトの名無しさん
22/09/03 17:37:42.10 ytBZTWHu.net
>>169
そんなこと言ったらRsutを使う場面が無くなっちゃうだろ
175:デフォルトの名無しさん
22/09/03 18:07:45.82 k38NcUnV.net
Rustはスライスに対して境界チェックをしないでアクセスする方法もunsafeで用意されている
つまり最適なプログラミング方法はC/C++を絶対に使わずに全てをRustで記述し
「コンパイラによる安全保証で最適化により安全に境界チェックを省略してくれる部分以外」かつ「人間による安全保証で境界チェックを不要としたい部分」のところのみunsafeで人間が安全保証し
その部分以外は全てコンパイラにより自動的にあらゆるメモリ安全保証させるのが最適な方法となる
176:デフォルトの名無しさん
22/09/03 18:32:15.93 5Mn7+zh6.net
>>137
>>109は RustがC言語より圧倒的に遅いコードです
>>166 172
＞
177:Rustが速いのは非常にキツイxor条件を満たす範囲だけ ＞「Rustは安全で高速」とか言うのは詐欺 ＞そんなこと言ったらRsutを使う場面が無くなっちゃうだろ 完全同意 Rustの最適化度合いは一貫性がなくて信頼できない 「Rustで高速化」が少しでも視野に入っている人は Cコードも書いて常にasmとBenchmarkで比較確認するしかない ＞173 109はRust版が10倍くらい遅いんだけどunsafe使ったら早くなるの？
178:デフォルトの名無しさん
22/09/03 18:40:11.28 ytBZTWHu.net
え？↓これってデマなんだよね？
URLﾘﾝｸ(qiita.com)
179:デフォルトの名無しさん
22/09/03 19:00:48.70 2joIss6C.net
>>174
わざわざ w = v; してそんな無意味なプログラムを書く人いないよ
>>92のような実際に使われているパターンの意味のあるプログラム例が欲しいな
180:デフォルトの名無しさん
22/09/03 19:10:31.55 UqPpASXs.net
>>109
これって偶然とか意図に関係なく引数が手に負えなくなると
Rustが全く最適化をしない、というPOCじゃね?
>>92
はhello worldレベル過ぎて逆に意味なくない?
181:デフォルトの名無しさん
[ここ壊れてます] .net
>>174
Cのコードを書く必要はない
Rustには一部エリアのみプログラマーに安全性の保証の義務を負わせるunsafeブロックがありCと同じことができる
ベンチも#[bench]等ですぐ比較できるから速さにシビアな場合は本件に限らずアルゴリズムの差異も含めてコストをかけるだろう
その点はどんな言語でも同じ
182:デフォルトの名無しさん
[ここ壊れてます] .net
>>178
＞Cのコードを書く必要はない
＞ベンチも#[bench]等ですぐ比較できる
いやいやCコードなしにhello sliceどうしでいくら比較しても意味ない。>>174は信頼性の話でしょ
183:デフォルトの名無しさん
22/09/03 20:06:47.23 BHvUMyM5.net
>>174
最適化度合いに一貫性のある言語って何？
Cだろうがasm確認しないといけないのは同じだと思うが
184:デフォルトの名無しさん
22/09/03 20:09:49.33 amOq/bcL.net
>>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は同じ速さで動作する
185:デフォルトの名無しさん
[ここ壊れてます] .net
>>180
現行C/C++だけがダントツトップレベル
Rustは裏でLLVM使ってるのに何で >>177 で信頼性がないと証明されたんだ...
>>181
あちゃちゃhello sliceと違う書き方をしないといけないなんて、これも無信頼性のPOCだ
186:デフォルトの名無しさん
22/09/03 20:34:30.71 0512mxP9.net
「最適化度合い」ってあれだな
「クイックソートは最悪のケースの計算量が多過ぎる」みたいな
ヒープソート最強伝説に似ている
187:デフォルトの名無しさん
22/09/03 20:45:21.45 GmjcSeRW.net
>>183
ほんとだね。アルゴリズム系は数学的に最悪ケースを予期回避できるのに、Rustの一貫性の無さは最悪
>>181で突然「このように書く」って言われてもPOCの積み増し
188:デフォルトの名無しさん
22/09/03 20:48:32.94 nzn5OhxI.net
>>181
RustはわかりやすくシンプルにプログラミングできてCと同じ速度なのが素晴らしいね
189:デフォルトの名無しさん
22/09/03 20:51:48.37 bnXlFS4K.net
>>185もはや自虐ネタ。嫌味ですか？
190:デフォルトの名無しさん
22/09/03 20:52:15.80 jD7rh1Hd.net
Rustをむやみに褒めてるやつがアホすぎてRustのネガティブキャンペーンにしか見えない件
191:デフォルトの名無しさん
22/09/03 21:07:27.69 ze3FTyL9.net
こういう争いは同じレベルのやつ同士でしか起きない
お互いに相手がアホだと思ってるけど両方同レベルのアホ
192:デフォルトの名無しさん
22/09/03 21:10:15.24 amOq/bcL.net
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言語バージョンと同じ動作をし
同等のアセンブリコードが生成されることも確認できる
193:デフォルトの名無しさん
22/09/03 21:13:41.03 sVwwSPBV.net
せめてID変えずにやってくれればいいのにな
何回NGさせるんだか
194:デフォルトの名無しさん
22/09/03 21:15:53.68 jlSkT3Xm.net
>>189
確認乙
POC(>>177,182)積み増し乙
195:デフォルトの名無しさん
22/09/03 21:25:28.83 jfkeSYrB.net
Cだと速いけどRustだと遅くなるケースって存在しないの？
誰かそういう例を作ってほしい
ここまでRustがCと同じ速さで書ける例ばかりだから
196:デフォルトの名無しさん
22/09/03 21:30:23.63 fcrVCCYN.net
本人はバレてないと思ってるらしいw
197:デフォルトの名無しさん
22/09/03 21:34:03.97 hQBDJOi4.net
>>192
はい。Rustは一貫性がない(>>177,>>182)ので個別にCコードと比べて
書き方を変えることにより同程度にもって行ける
ケースが稀にあることが証明されました
多大な努力の結果です。感謝
198:デフォルトの名無しさん
22/09/03 21:55:58.00 wxRR+ldD.net
Rustはfor文自体がイテレータを使うから、
for i in 0..s.len() {
println!("{}", s[i]);
}
とインデックスを使う書き方をするのは非常に稀で、
これはインデックスを使わず、
for n in s {
println!("{}", n);
}
と書くのがRustでは普通だから、
インデックス議論自体があまり意味のないものに思える。
そしてどちらの書き方をしてもCコードと同速度。
199:デフォルトの名無しさん
22/09/03 22:05:33.75 lGqTIi1A.net
Rustがそんなに速いならなんで競プロはC++一択なの
200:デフォルトの名無しさん
22/09/03 22:19:33.41 V+KjjP+f.net
>>196
それは単なる人口差・マニュアルやサンプル数差
C++に次いで多いのが言語としてはかなり遅いPythonなのを見ても分かる通り
201:デフォルトの名無しさん
22/09/03 22:30:44.07 0512mxP9.net
まあ、型を正確に宣言しても速くならないし遅くなるというのがもし本当なら
バニラJSが復権するのもPythonが支持されるのも当然といえば当然
202:デフォルトの名無しさん
22/09/03 22:31:15.35 pNlcpp9D.net
>>196
解説本がc++が多いからかな
203:デフォルトの名無しさん
22/09/03 22:34:08.49 zAI/jpLH.net
例えば競プロAtCoderでABC182-E問題 i行目j列目のマス(i,j)を扱う問題
提出された各プログラミング言語別の実行時間分布
URLﾘﾝｸ(pbs.twimg.com)
204:デフォルトの名無しさん
22/09/03 22:38:11.41 DRQBO0l9.net
Rustはコーディングに時間がかかるから競プロでは使えない。
競プロにC++とPythonは良い選択。
205:デフォルトの名無しさん
22/09/03 22:41:39.07 nzn5OhxI.net
>>200
競プロでもRustが速いね
206:デフォルトの名無しさん
22/09/03 23:18:47.73 mp8eZIVB.net
>>196
そもそもC++もちゃんと書けるとは言えないでしょ
mainとグローバル変数しか使わないし
207:デフォルトの名無しさん
22/09/03 23:28:32.01 DRQBO0l9.net
他言語を貶しても、Rustが使える言語にはならない。
208:デフォルトの名無しさん
22/09/03 23:28:44.38 Ej5h9pmc.net
>>200
Pythonを選
209:んだ時点でPyPy3にしたとしても負け戦が確定かよ Rustは競プロでも強いのか
210:デフォルトの名無しさん
22/09/03 23:33:58.57 SEYCHGY8.net
>>200 懐かしいなあ
https://ビット.ly/3CS8AuV
トップのuzzyさん始めC++勢がじわじわ最適化を進めているのがカッコイイ
ちらほらいるRust勢は一発屋だけでインクリメンタルな最適化が出来ていないね。
Rustは一貫性がない(>>177,>>182)から下手に弄れなかったのかな？
211:デフォルトの名無しさん
22/09/03 23:43:22.86 0512mxP9.net
>>204
その定型文のどこが「使える」と思ったのかがさっぱり分からないよ
212:デフォルトの名無しさん
22/09/03 23:47:27.33 YC+HIv6p.net
>>207 Rustって一発作ったらそれ以上で弄れないって開発現場では使えない言語だね(>>206)
213:デフォルトの名無しさん
22/09/04 00:08:42.58 yt7jdRkq.net
>>206
インクリメンタルに最適化したと本気で思い込んでる？
uzzyの上位4つとも全てソース同じまま変化していない
つまり何度も同じのを提出してトライしただけ
214:デフォルトの名無しさん
22/09/04 00:27:20.06 ULs4IOBU.net
で、その競プロでのc言語での参加率はどれくらい？> cオジ
215:デフォルトの名無しさん
22/09/04 00:31:23.21 ygllKmJ5.net
4回ともC++コード同じだな
ただしその一つ前だけコードが違っていて二次元配列を一次元へと書き換えて改善してる
一方でRustの人は最初から一次元にしてるからその改善が必要なかった
つまり>>208はRustを叩きたいだけの完全に的外れ
216:デフォルトの名無しさん
22/09/04 02:03:59.28 1GJgU4m+.net
たぶん必要なのは
葡萄を食べるべきでない理由ではなく
食べない自由なんだな
217:デフォルトの名無しさん
22/09/04 08:04:17.58 IySRHUNr.net
>>200
プログラミング言語間の速度差が激しくて勝負にならないな
競プロで勝つためにはRustかC++を選ばざるを得ないのか
218:デフォルトの名無しさん
22/09/04 08:07:09.64 gz8Ny9ff.net
>>213
いいや
Pythonは論外だけど他の言語で十分戦える
219:デフォルトの名無しさん
22/09/04 08:19:18.55 ftO7cI3V.net
>>200
Rust最速レベルやん
てかC++の分布笑えるな
ギリ合格からトップクラスまでみっちり
220:デフォルトの名無しさん
22/09/04 10:34:00.57 RQxkFcRF.net
本日のRustあげ会場はこちらですか？
221:デフォルトの名無しさん
22/09/04 11:16:04.09 ubNPliW5.net
貶めれば誹謗中傷かも知れんけど、ほめれば気持ち悪いだけ
こんなの消去法でほめるに決まってんだろ
222:デフォルトの名無しさん
22/09/04 11:23:49.03 YUzYugU5.net
参加者自体はRustも多い。
C++と同じくらい居る。
時間内に提出できる人が少ないだけ。
223:デフォルトの名無しさん
[ここ壊れてます] .net
つまりRustは生産性が低いor利用者の能力が低いってこと？
224:デフォルトの名無しさん
22/09/04 11:52:32.99 r6qlMaZb.net
普通にガチ勢は昔からC++を使ってて今さら他の言語にしないというだけだろうな
225:デフォルトの名無しさん
22/09/04 12:28:01.29 1n1CTU4P.net
CオジはCとC++比べてもやっぱCの方が早いからC++はダメとか言うのかな？
226:デフォルトの名無しさん
22/09/04 12:29:11.61 RQxkFcRF.net
ダメな香具師が描いたダメなC++コードは本当に糞
Cのがマシ
227:デフォルトの名無しさん
22/09/04 12:57:20.84 r6qlMaZb.net
>>201
Pythonはよほどうまくチューニングしないとすぐ時間制限越えるんで競プロだと使い物にならないんですわ
>>200のグラフから実行時間でのランキングができそうだけどぶっちゃけ時間内に結果が出れば速かろうが遅かろうが大差無いのでPython以外なら何使ってもいい
言語よりプログラマーの能力が大事だし、それよりむしろ暇の方が大事
とにかく参加し続けてなるべく正解を出してれば上位に行ける
228:デフォルトの名無しさん
22/09/04 13:11:43.10 MfsHP/8v.net
pythonでアルゴリズム性能出ると思ってるのお前だけだよ。。
229:デフォルトの名無しさん
22/09/04 13:31:05.58 r6qlMaZb.net
お前がアルゴリズムという言葉を知らないと言うことがわかった
230:デフォルトの名無しさん
22/09/04 14:04:04.57 ubNPliW5.net
行列の和と積を英単語ではなく記号で書けるだけでC++と互角みたいになったのがPython
argv + 1000000 がnullを返したり計算中に例外を投げる実装が可能なだけでRustと互角になれる
231:デフォルトの名無しさん
22/09/04 14:42:33.66 RQxkFcRF.net
何と戦ってるのか知らんがイミフな基準
232:デフォルトの名無しさん
22/09/04 14:46:33.79 Pinnb9nG.net
>>223
うーん、いろんな言語で競プロやってる青色だからついコメントしたくなってしまう
CPythonは知らんけど、pypyは実行速度速いからマラソンでもなければ困ることないよ
再帰がしんどいと言われる問題も、コドフォではよく使われてるbootstrapデコレータを使えば簡単に解決する
Rustはusizeの扱いのために余分なコードが必要になることが多かったし、クロージャ使おうとすると引数の型とかめんどいしで、最近は専らPythonを使ってる
Pythonはクロージャを短めに書けることも競プロ的には気が楽だな
233:デフォルトの名無しさん
22/09/04 15:31:08.56 YUzYugU5.net
Rustは競プロに向いて居ないからな。
避けるのが賢明。
234:デフォルトの名無しさん
22/09/04 15:33:36.35 +XXjYupQ.net
複オジと
複オジにマジレスしちゃう人と
その両方を焚き付けて喜んでる人の三人でお送りしています
235:デフォルトの名無しさん
22/09/04 16:44:07.43 nQgfFYZJ.net
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);
文末セミコロンで複数行に分けても、理解しやすいという話はどこに行った？使いやすさを求めては
イケないんだろうけど、どうもね....
236:デフォルトの名無しさん
22/09/04 16:46:11.53 /0DHyjSi.net
ミュータブルを極力使うなということだろ
237:デフォルトの名無しさん
22/09/04 17:40:27.34 YUzYugU5.net
韓国で最も愛される言語と銘打てば流行るのでは？
238:デフォルトの名無しさん
22/09/04 17:47:06.26 rbLH55CO.net
>>231
わざと面倒臭くさせてることに意味がある
その辺りの思想は今までの言語とは違うかもしれん
239:デフォルトの名無しさん
22/09/04 17:48:26.12 qbvnu5SJ.net
>>231
＞Cが普通はintインデクスなのに
そんなルール無いよね？
仕事で他社さん作ライブラリがuint使ってたことある。
240:デフォルトの名無しさん
22/09/04 18:06:41.17 mP7WKJy6.net
普通にprintln!使うと遅いんだけど教プロ上位なんだな
241:デフォルトの名無しさん
22/09/04 18:17:28.7
242:8 ID:6TwASNhD.net
243:デフォルトの名無しさん
22/09/04 18:21:48.03 oPTKOfK9.net
安心安全最速、Rust最高じゃん
244:デフォルトの名無しさん
22/09/04 19:10:58.79 brj4MXrP.net
>>231
インデックスやその長さはusize型で絶対に正しい
まずインデックスは負の数になってはいけないからunsigned型
サイズとしてはポインタなどと同じそのCPUで使われるサイズでなければならないからusizeとなる
そして実際のほとんどの様々なプログラミングにおいてインデックスはusize型で上手く動く
ところが例外が二つある
例外の一つは自分たちで決められない外部指定APIなど規定においてインデックスや長さがusize型でない場合でas usizeにより解決
例外のもう一つは一部の数値アルゴリズムでプログラミングする上で一時的もしくは最初あるいは終端で負の数になると便利なことがある
もちろんその一時的な負の数である時ははインデックスとして使われないようにプログラマーの責任でプログラミングしてインデックスとして使う時はas usize
245:デフォルトの名無しさん
22/09/04 19:29:23.15 OkswyjL5.net
浮動小数点数から符号無し整数へキャストする命令なくね？
最近の処理系は直接キャスト出来るようなったん？
246:デフォルトの名無しさん
22/09/04 19:44:58.67 brj4MXrP.net
>>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をできる限り少なくするのがプログラミングのコツ
247:デフォルトの名無しさん
22/09/04 20:00:50.97 wyRxABNd.net
>>231
Cも配列のインデックス関連は(s)size_tが基本では
strlenやmemcpyの引数や返値はsize_tだし
単にintから暗黙的にキャストできるというだけで
暗黙の数値キャストがないのは確かにめんどくさい
asでのキャストはリリースビルドだと範囲外の値になったときにエラーにならないし、
絶対成功するキャストと失敗する可能性のあるキャストが見た目からぱっと区別がつかないのもよろしくない
かといってn.try_into().unwrap()を書くのもだるい
せめてn.into()で済ませたいが16bitアーキもサポート対象だからusizeに From<u32> が実装されていない
ターゲットを32bit以上のアーキテクチャに限定するした場合はinto()使えるようにするとか、もう少し楽にできないだろうか
248:デフォルトの名無しさん
22/09/04 22:29:03.84 rWQ8XHaT.net
>>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は注視すべきポイントとなる
249:デフォルトの名無しさん
22/09/04 23:03:51.17 rWQ8XHaT.net
>>243の基本を踏まえた上で
例えば16bit環境でなければu32からusizeへのtry_into()は常に成功し安全にunwrap()できる
生成コードも以下のようにコストゼロ
URLﾘﾝｸ(godbolt.org)
キャストasと同様にunwrapも注視ポイントとなるため
利便性も含めてinlineのto_usize()を用意してしまうのがよいかもしれない
bit環境依存性はそのメソッドに押し込めることで注視ポイントが散らばるのを防げる
250:デフォルトの名無しさん
22/09/04 23:05:01.26 ULs4IOBU.net
危険のある操作は面倒にするべきなんだよ。
251:デフォルトの名無しさん
22/09/04 23:23:22.66 nQgfFYZJ.net
>>239
それ絶対に正しいとは言えてないよね
下のほうに書いてるんだろうけど、よくある別の言語仕様だと、a[-1]が末尾を表したりできるし、数多くの言語でインデックスループだと
これもよくある相対位置やインデックス演算でa[i-1]とか書くけど、usizeをキャストしてi32にしてもう一度、スライスにアクセスするために
as usizeとか2回キャストを行う。これがどれほど醜くなるし、めんどくさくて労力を要するか
当然、メモリアドレッシングが0x00～上に伸びていくことなんて言わなくてもわかるが、それが合理的であり、かつスライスがusizeで
支持できる理由かといえばどうだろう？少なくとも私はメンドクサイ
またもちろん、(a, b) = t がタプルのアンパッキングなどに使えるのも知ってるけど、それとまとめて変数の宣言と初期化を少ないタイプ量で
出来る話とは別だろう、上からアドバイス頂いてるようでケチをつけて申し訳ないけど、もちろん不変性はマルチスレッドでも有利だしコードの
リファクタリングなどもし易い、ファンクションの変更が良くわかる（そのくせ同じ変数名で別型再定義できたり）とか色々利点があるのは
当然分かってるけど、これもまたmutを多数宣言しなきゃならない時とは全く別の話だよ
252:デフォルトの名無しさん
22/09/04 23:56:45.66 C1tkKKn6.net
>>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
}
もちろん最適化によりアクセス時のインデックス境界チェックは無くなります
253:デフォルトの名無しさん
22/09/05 00:30:20.92 +iXq2ECO.net
まともにプログラム書いたことなさそうだね
254:デフォルトの名無しさん
22/09/05 00:34:33.72 BTzrk4g4.net
>>241
Rustはletとmut指定を分離することでそのようにできるから大成功だな
mut指定が分離していない言語ではそのようにすることができずいつも困っている
方法がないからimmutableで十分な変数も含めてまとめてmutableな変数宣言にせざるをえない
初めて知っ�
255:ｽときRustはよく考えられているなあと感動した
256:デフォルトの名無しさん
22/09/05 00:43:43.47 +21R+/VD.net
>>246
・Rustは、数値リテラルに多くの言語ある固定の型がなく、文脈によりu32とかi32とか変わる（型推測）
・下のほうで境界チェックがないのも1..a.len()としているから
当然ながら、これは胸を張って一貫性があるとは言えないがa[-1]は言語仕様ではコンパイルエラーになるが
for i in 0..a.len()とすれば境界チェックが入り実行時にpanicする
君が勘違いしてるのはa[i+b]とかはbを宣言した場合、as castが必要で、色々ごっちゃになってるYO
アンダースタンド？ｗ
257:デフォルトの名無しさん
22/09/05 00:44:27.92 ARttffD1.net
C++は型の特性を調べて、ユーザーがconst性を利用したバージョンの実装を生み出すことができる。
しかも利用時には、型の特性によってコンパイラにどのバージョンを使うか選択させる事が出来る。
258:デフォルトの名無しさん
22/09/05 00:48:14.12 g3RfqaIY.net
RustもIndex<u32>とか実装はできるよ
標準のsliceに実装されてないというだけで
259:デフォルトの名無しさん
22/09/05 00:55:53.18 ARttffD1.net
C++は、型の計算ができるんですよ。
260:デフォルトの名無しさん
22/09/05 01:07:57.19 9iTWKe04.net
すまん、誰が聖闘士星矢で例えてくれないか？
261:デフォルトの名無しさん
22/09/05 01:12:56.84 ARttffD1.net
>>254
くちから たれている みつは ２きろ はなれていても はなが まがるほど もうれつに くさい。
262:デフォルトの名無しさん
22/09/05 01:19:02.56 JbiV7xYP.net
>>211
一昨日は言葉が過ぎました。開発現場、携わっている人には心無い発言でした。反省してます。
強調したかったのは、最適化って難しいよ、速そうな言語を選んでコンパイラにお任せって言う易しい世界じゃないよ、という事です。
むしろ叩きたいのは、定期的に現れる無意味なRust上げ
スレッドの流れをフォローしている人間にはネガティブキャンペーンと受け取られているコメントです。
うすうす気づいているとは思いますが、これSEO対策なんですよ。
Rustをほとんど知らない人が検索をした時に、
チラッとその一部だけを見せてエコーチェンバーにはめ込むと言う仕掛けです
同様に時々現れる、会話の流れを修正したい時に持ち出す極論、逆説的にRustを卑下する冗談
これはわざとRsutとタイポしてチラ見に現れないようにしている。
複製おじとは別人だと思うのですがどんなんですかね。皆さんの意見を訊きたいな
263:デフォルトの名無しさん
22/09/05 01:22:23.34 RaegMrzk.net
>>246はまともにプログラミングしたことないとまでは言えないが多くの勘違いをしてるのは確かだな
usizeを上に伸びていくと書いてあるから引き算出来ないとでも勝手に思い込んでa[i-1]ができないと勘違いしたのかもしれない
もう一件
＞ よくある別の言語仕様だと、a[-1]が末尾を表したりできるし
その件はa[-1]やマイナスのインデックスに意味を持たせたプログラミング言語の仕様ミス
もしくはお子様向け言語であるとの結論が大昔に出ている
プログラミングのミスでマイナスのインデックスとなり本来はエラーでミス発覚となるべきところか不可能となった
つまり言語仕様ミスなのかそんなこと気にしないお子様向け言語なのかどちらかということになる
ほとんどの言語はまともなのでa[-i]はエラーとなり正しくa[len-i]と書く
264:デフォルトの名無しさん
22/09/05 01:34:56.96 9oDekVHu.net
>>257
複製おじ？usizeの議論は微笑ましいですね。盲目的ですが熱意にあふれてます。
速度、最適化に関する盲目的思い込みがなければ無害ですな
SEO対策(>>256)に加担していなければの話ですが
265:デフォルトの名無しさん
22/09/05 01:45:29
266:.53 ID:ARttffD1.net
267:デフォルトの名無しさん
22/09/05 01:57:02.85 b0NkdPU/.net
>>259
同意ですな
一方で熱意にあふれ盲目的で従順に車輪の開発をしてくれるプログラマが
無料で使えるのであれば使わない手は無いとLinus辺りは策略してそう
SEO対策(>>256)もあながち...？
268:デフォルトの名無しさん
22/09/05 02:02:44.86 7mfke0+F.net
欠陥言語C++を使うメリットは何？
今はこれだけ多数の安全な言語があって色々選べるのに
269:デフォルトの名無しさん
22/09/05 02:05:41.16 ARttffD1.net
アセンブラを使う理由はレジスタにアクセスできるから。
これはとても危険。
C/C++を使う理由はメモリーにアクセスできるから。
これはとても危険。
270:デフォルトの名無しさん
22/09/05 02:07:30.95 ARttffD1.net
大いなる力には責任が伴う。
2019 - アフレシアさん
271:デフォルトの名無しさん
22/09/05 02:14:43.00 ARttffD1.net
早くコンセプトが使いたいわー。
272:デフォルトの名無しさん
22/09/05 02:16:22.39 E82kQidM.net
>>261 もしこの二日間程度のスレッドの流れをフォローしてもなお一つのメリットも見えないのであれば
あなたの長所は熱意だけです。周りを頼って上手に立ち振る舞ってください。
>>260 有料案件で活躍されているプログラマーを見下すものではありません
>>263 同意 正に実力の世界。去れよ無責任Kids
273:デフォルトの名無しさん
22/09/05 02:33:35.68 sgxkT6js.net
C++にもメリットはありゼロじゃない
ただし世界的には>>154の結論が出ている
そして今回もC++で書かれたChromiumの穴のせいで、それを使うElectronを始め多數に影響が出て、それを使うVScodeにもセキュリティ脆弱性と連鎖
C++を使い続ける限りセキュリティの穴が量産されてしまう
274:デフォルトの名無しさん
22/09/05 02:57:07.57 5U2utJMj.net
>>266
あなたの結論素晴らしいですね。
どうぞLinusあるいはMozillaの元へ
SEO対策(>>256)の一環ですか？
＞C++を使い続ける限りセキュリティの穴が量産されてしまう
ほんと怖いです。一刻も早くRustに書き換えて欲しいですね。もう10年経ったっけ？
ところでFirefoxのthird_party directoryを除いたsource repoでのRustの使用割合ってご存知？宿題ですよ
275:デフォルトの名無しさん
22/09/05 03:10:33.61 9iTWKe04.net
何でもrustでやらんで、安全性第一のとことか機能が優れてるとこ(非同期やジェネリクス、健全なマクロ、パターンマッチ等)とかからでもrustを便利に使ってったらええ。
今のrustは少しずつ実用面で採用を広げて行ってる段階だろ。Linuxでの採用とかさ。
既存のcでやってることをイキなり全部rustで置き換えようとしてる人なんて居ない。
rustにその潜在能力があったもしてもマンパワーが足りない。だから大手は少しずつ小さな分野で使いだしてる、複数の大手でね。
ただrustはもっとc言語との連携が簡単だったらと思う。
276:デフォルトの名無しさん
22/09/05 03:31:45.52 hQwE/dE/.net
>>268
＞何でもrustでやらんで、安全性第一のとこ
完全同意 話が合いそう
安全性アピールがマーケティング上有利な暗号通貨系の動きが早かったです
＞Linuxでの採用とかさ。
早いとこ第一歩を踏み出して欲しいです。偉大な一歩となることでしょう。
＞既存のc...イキなり全部rust...
10年なんてあっという間ですね
＞複数の大手でね。
大手って何やっても凄いです
ScalaでのNetflix分岐点 未満/以上の話を思い出した
＞ただrustはもっとc言語との連携が簡単だったらと思う。
完全同意 話が合いそう
>>266 が宿題(>>267)をサボったら手伝ってあげ
277:てください
278:デフォルトの名無しさん
22/09/05 03:36:29.05 pmwagyd7.net
>>268
どの言語からどの言語の場合でも既存システムをそのまま言語置き換えはコストだけかかり効率がよろしくない
そのためシステム改修や新規システムを中心にRust採用となっているようだ
現在ある選択肢では人間が引き起こしうるミスをコンパイラに防止させてセキュリティ含む穴を無くしていく言語候補がRustの他にない
279:デフォルトの名無しさん
22/09/05 06:42:39.68 ARttffD1.net
簡単に言えば、Pythonの代わりにRustを使うことはあっても、C/C++の代わりになることはない。
レジスタやメモリーを扱うのは大変危険だから。
280:デフォルトの名無しさん
22/09/05 07:16:47.41 yWe543y4.net
>>271
Rustはinlineアセンブラ記述をサポートしていてレジスタ操作もできることを知らないのかね
Rust叩きの人はなぜ学習せずに無知なままなのだろうか
281:デフォルトの名無しさん
22/09/05 07:22:08.46 ARttffD1.net
>>272
じゃあ安全じゃないじゃん。
282:デフォルトの名無しさん
22/09/05 07:51:21.51 928S9Xdp.net
以前の言語
・プログラムのメモリ安全性、null安全性、データ競合安全性をプログラマーの責任で保証する
Rust
・それらの安全性を全てコンパイラが保証
・プログラマーの責任でCと同じメモリ操作やインラインasmなどを記述できるunsafeブロックもサポート
Swift, Kotlinなど
・null安全性をコンパイラが保証
283:デフォルトの名無しさん
22/09/05 08:33:46.56 HWNfM8e/.net
>>268
Rustを使うにはガッツリ勉強しないと無理だから……THE BOOK一通り勉強しないと無理だから……
284:デフォルトの名無しさん
22/09/05 09:45:50.25 KpRHtzI/.net
>>92
上に書いたように、当然gccでやったら同じコンパイル結果にならず全く違いますね？これを同じとは言えません
rustcの結果(-C opt-level=2)が138行あるが、x86-64 gcc 12.2(-O2)は16行です。
URLﾘﾝｸ(godbolt.org)
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でほぼ同じになるのはなんでなんでしょうか？