23/04/02 00:51:09.64 LXNgvG55.net
世界的にインフラはRust製になりつつある
URLﾘﾝｸ(japan.zdnet.com)
Amazon Web Services（AWS）は、同社のエンジニアたちがプログラミング言語「Rust」を
使っている大きな理由として、エネルギー効率の高さを挙げる。
AWSは早くからRustを採用し、Rust Foundationの創設にも携わった。
現在もRustの普及に熱心に取り組んでいる。
AWSのソフトウェアエンジニアで、Rustの普及に取り組む
Shane Miller氏と主任エンジニアのCarl Lerche氏の投稿によれば、
Rustはメモリー安全性を高め、セキュリティ関連の不具合を減らす役に立つだけでなく、
PythonやJavaよりもはるかに「エネルギー効率に優れている」という。
Amazonは、2025年までにデータセンターの100％を再生エネルギーでまかなうという目標を掲げ、
データセンターの環境負荷の軽減に取り組んでいる。
Rustの採用はその一翼を担うという。
Rustで構築されたAWSサービスの例としては、
3: コンテナーアプリ用のサーバーレスプラットフォーム「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などをはじめとする 複数の言語のエネルギー効率を相対的に示した研究結果を紹介している。
4:デフォルトの名無しさん
23/04/02 01:05:56.12 fga+vqS0.net
なぜ皆がC++を捨ててRustへ移行していくのか以前は不思議だったが
Rustも書くようになってようやく理由がわかった
色んな面で快適になっている
5:デフォルトの名無しさん
23/04/02 02:18:47.84 6FtsW5Qy.net
Rustは高機能に洗練されていて意外にコンパクトだね
C++では同じことを出来ないも多くて何とか出来ることもC++17やC++20の知識が必要で普及していなかったり
どちらにも新規な人ならRustの方が学習量が少なくて済むね
6:デフォルトの名無しさん
23/04/02 02:37:50.83 Xkdfgrgv.net
=== 複製おじさん（通称複おじ）について ===
Rustスレを中心に活動し、2023年4月現在で1年以上ム板に住み着くRustacean。無自覚な荒らし。
Rustスレでは、基本的に他住民の意見を聞いて糧とすることなく、自らのコードが最善であると、ID変更自演を交えいつまでも主張し続ける。
同スレで「所有権が複製される」という違和感のある表現を、「違和感がある」とする他住民の意見をすべて否定してしつこく擁護し続けたことから、「複製おじさん」というあだ名が付けられた。
それ以外のム板スレでは、基本的に他住民の意見を聞いて糧とすることなく、Rustこそが最善であると、ID変更自演を交えいつまでも主張し続ける。
その基本戦術は、「GC言語は遅い」の一声でC/C++/Rust以外の言語を否定し、残ったC/C++は安全ではないので、Rustが最善であるとするもの。
しかしながら、Rust以外の言語に関しては、正当な批判を展開するのに十分な知識を持っているとは言いがたい。
本スレPart1では、C++の問題点を指摘しようとして多数の誤り・知識不足を露呈することとなった。特にしつこく食い下がったのが「動的ディスパッチ」に関する誤解である。
ｽﾚﾘﾝｸ(tech板:786番)-799（ID:Evbafc70とID:RiLc+pIfが複製おじさんであると考えられている）
要約すると、通常「条件分岐」と呼ばれるものを「動的ディスパッチ」と呼ぶのが正しいと主張し続けたのである。
常識的にはあり得ない誤解だが、提示されたC++のコードが自らの主張（C++にはパターンマッチが無い）に不都合であると感じたためか、C++のコードを正しく読み解くことができないにもかかわらず脊髄反射的に否定してしまい、その根拠として誤った論理をこじつけてしまったものと思われる。
ちなみにこの後、同種の誤解を持って書き込むID:wHEiYRW7（これはID使用歴的に複製おじさんとは考えにくい）に対して、正しい理解に基づく指摘を行う単発IDが複数出現するが、この中にも複製おじさんが多数含まれていると考えられている。
このように自分の誤りを認識した場合、それを認める書き込みは決して行わず、別人の振りをして最初から正しく理解していた体を装うのも複製おじさんの特徴である。
7:デフォルトの名無しさん
23/04/02 02:38:05.99 Xkdfgrgv.net
テンプレに入れといていいよ
8:デフォルトの名無しさん
23/04/02 02:43:43.18 zOLTjxu5.net
C++は確実に滅びる
各種安全性が保証されているRust製と穴を多発してきたC++製
企業や国自治体がどちらを選ぶか明らか
いずれ要件にも入るだろう
9:デフォルトの名無しさん
23/04/02 03:06:04.77 WdMf4Ye5.net
>>5
おいおい！処理を切り替えること一般をディスパッチ
その実装をディスパッチャと言うんだよ
ifやmatchなどの条件分岐はやっていることはディスパッチャだよ
実行時にやっているから動的ディスパッチ
仮想関数テーブルを介した関数の呼び出しの切り替えも動的ディスパッチ
一方で関数のオーバーロードによる切り替えは
コンパイル時に決まるので静的ディスパッチと言う
10:デフォルトの名無しさん
23/04/02 03:40:43.33 IfuIFZxt.net
GoogleとMicrosoftで脆弱性の70％がメモリー管理バグに起因のためRust採用
URLﾘﾝｸ(xtech.nikkei.com)
Rustは、プログラムに必要なメモリーの確保や解放に関連するバグが生じない「メモリー安全」が保証されたプログラミング言語である。
それに対してこれまでのOS開発に使われてきたC/C++は「大規模な開発においてメモリー安全なコードを記述することがほぼ不可能」
（Microsoftのブログ「We need a safer systems programming language」出典）だという。
GoogleによればAndroidに存在した深刻なセキュリティー脆弱性の70％近くがメモリー安全に関するバグに起因するという。
同様にMicrosoftも、同社製品に存在したセキュリティー脆弱性の70％がメモリー安全に関するバグに起因すると述べている。
C/C++を使う限りセキュリティー脆弱性を根絶するのは不可能と考えて、Rustを採用するに至ったというわけだ。
11:デフォルトの名無しさん
23/04/02 06:32:11.07 kYGqyW3R.net
＞「業界談義」、愚痴はプログラマー板へどうぞ。
板ルールが読めない池沼
そしてプログラム書けずにドヤ顔で役に立たない長文書くバカ
12:デフォルトの名無しさん
23/04/02 06:39:50.05 M90rTQGQ.net
大手IT企業は揃ってC++ではダメだと判断してRustへ移行しつつあるのに
底辺は真逆でRustはダメでC++に拘るのはなぜ？
13:デフォルトの名無しさん
23/04/02 06:53:36.16 W9/nq+tL.net
あっちにもスレあったんだけどね、あんま流行ってなかったから
マの問題じゃない、言語がイイんだ! ってｇｄｇｄやるのがいいみたいだ
Google&MS「バグの70%はC/C++。Rustにする」
ｽﾚﾘﾝｸ(prog板)
ほんとにマの問題なら、>>1 で終わってしまうｗ
14:デフォルトの名無しさん
23/04/02 06:54:05.31 W9/nq+tL.net
あっ >>12 >>10
15:デフォルトの名無しさん
23/04/02 08:05:56.68 O/tjJbYW.net
>>11
DQNだから言語的になんら優位性のないC++に固執している
過去の遺産だけはC++の優位性があるがそれすら時間とともに置き換わっていく
16:デフォルトの名無しさん
23/04/02 08:13:05.31 W9/nq+tL.net
Rustは難しくない。そうだろ?
大手が本格的に移行しはじめてからでも、全然遅かねえんだよ
ま、C++を捨てられないってのは、このスレだけの内緒だけどな!
17:デフォルトの名無しさん
23/04/02 08:16:48.61 W9/nq+tL.net
Rustに移行ってのは、採用された程度じゃ移行じゃない
APIに、Rustの所有権・マルチスレッド関係のシグネチャが付くようになって、ようやっとだ
その日はくる
そして、Rustの独占は揺らぐ
18:デフォルトの名無しさん
23/04/02 08:25:23.82 W9/nq+tL.net
C++を捨てたんなら、no_mangle とか、まさか、extern "C" とかいう呪詛を唱えてないよな?
移行っていう以上、そういうの要らないんだよ
C++が、こっちから適合してやっからよ
19:デフォルトの名無しさん
23/04/02 10:39:13.92 Xkdfgrgv.net
複おじはね、承認に飢えた構ってちゃんなのよ
この紛うことなきクソスレを隔離スレ化して構い続けてあげれば、他スレの被害を最小限にできるって寸法よ
こんなクソゴミスレを存続させる意義はここにある
君たちも>>5は知識として覚えておいて、そこらでそれっぽい書き込みを見ても一切反応しちゃいけないぞ
20:デフォルトの名無しさん
23/04/02 10:48:26.80 W9/nq+tL.net
ディスパッチはディスパッチだろ、くらいに思ってたのに、
Rustの優位性を説明するキーワードのひとつなのね
もうちょっと勉強してからそのへんはゆっくり読む罠 ついていけん
C++を捨てろって言われると猛然と怒るけど、
じゃRust使わないのかって聞かれると、いやじゃんじゃん使うよ必要ならって答える
それがC++er
21:デフォルトの名無しさん
23/04/02 11:14:49.29 3BWJUO+j.net
>>5
よくまとまってる
22:デフォルトの名無しさん
23/04/02 12:12:13.50 nLGbG+/r.net
>>19
>Rustの優位性を説明するキーワードのひとつなのね
静的ディスパッチ/動的ディスパッチの違いは
基本としておさえておくべきポイントというだけで
Rustに明確な優位性があるわけではないよ
vtableの持ち方の違いもトレードオフだから
何に重きを置くかによってRustがやや有利な場合もあればC++が有利な場合もある
23:デフォルトの名無しさん
23/04/02 12:30:32.66 hC5sLbbp.net
しゃぶれよ
24:デフォルトの名無しさん
23/04/02 13:40:35.10 Ky8sq4kq.net
>前スレ
>Rust派は、Rustなら、必ず・全部安全
doubt
25:デフォルトの名無しさん
23/04/02 14:12:33.01 W9/nq+tL.net
そりゃC++よりは安全だろうけど
少なくともメモリ管理において、Rustの安全性って、数学的に保証されるものなの?
26:デフォルトの名無しさん
23/04/02 14:28:31.37 PHqZc/RR.net
>>24
定義次第だと思うのでメモリ管理以外で「安全性が数学的に保証されてる」と思ってる例をいくつかあげてみて
27:デフォルトの名無しさん
23/04/02 14:50:01.38 W9/nq+tL.net
あ、わかった
Rustがsafeといっても、定義次第なんだね
28:デフォルトの名無しさん
23/04/02 15:21:53.12 guRaVpcO.net
ちんぽこ
29:デフォルトの名無しさん
23/04/02 16:06:16.39 ZsGOmlxy.net
キチガイの巣
30:デフォルトの名無しさん
23/04/02 16:26:16.23 7EJ8Bgwe.net
>>26
Rustに関係なく「安全かどうか」は定義次第だからね
31:デフォルトの名無しさん
23/04/02 16:48:24.56 W9/nq+tL.net
ていうか、こっちに定義を聞いてこられても困るんだよね
この定義において、Rustはここまで安全、って言ってもらえると、それを遵守するんだから
32:デフォルトの名無しさん
23/04/02 16:59:55.82 asGxfFqy.net
>>30
数学的に安全性が保証されてるかどうかを質問してるにも関わらず
「数学的に安全性が保証されてる」とはどういう定義なのか聞かれたら困るのか
それじゃどうしようもないな
33:デフォルトの名無しさん
23/04/02 17:13:06.13 W9/nq+tL.net
数学的に安全性が保証されてるっぽい何かがあるんだろ? ってなことだよ
根拠もなしに、安全か? そりゃC++よりマシだろうけどさｗ
34:デフォルトの名無しさん
23/04/02 21:00:51.01 WdMf4Ye5.net
そんな難しいことを考えなくても
Rustの所有権システムをC++で体験したければ
インスタンスを作るときに
必ず常にmake_uniqueかmake_sharedするようにすれば
だいたい同じ振る舞いになる
安全性は保証される
35:デフォルトの名無しさん
23/04/02 23:31:24.96 Xbrx8QgA.net
C++ってstd::move(x)した後にx使うとコンパイラに怒られるの？
36:デフォルトの名無しさん
23/04/03 00:26:35.43 CRVbAO5a.net
コンパイラは怒らないから
静的解析ツールが必要だね
37:デフォルトの名無しさん
23/04/03 04:38:42.03 rltHNDRD.net
C++はコンパイルとは別に静的解析とデバッグ解析が不可欠だからな
Rustはコンパイラがメモリ安全からデータ競合安全まで保証してくれるのでかなり楽
38:デフォルトの名無しさん
23/04/03 09:30:27.97 sPhWZLZN.net
デバッグ解析てなんやねん
コンパイラがやる静的解析の範囲が広いというだけでRustでも静的解析・動的解析は基本不可欠
clippy, rustfix, rust-fmt, cargo-expand辺りは静的解析ツールの一種
39:デフォルトの名無しさん
23/04/03 09:40:57.30 GW2UDfFX.net
まともにrustかけるやつって例外なくc++もかけるけどな。
40:デフォルトの名無しさん
23/04/03 09:51:01.03 7c0W6U8J.net
でも、C++よりマシな程度では?
41:デフォルトの名無しさん
23/04/03 09:52:16.72 7c0W6U8J.net
Rustだって、まともにって難しいだろ、たぶん
俺は簡単に使いたい
>>39 は >>36
42:デフォルトの名無しさん
23/04/03 10:19:52.71 efbJG7yX.net
「安全」に描こうとするとコピーが大量に発生するのか
43:デフォルトの名無しさん
23/04/03 10:22:17.10 efbJG7yX.net
>>31
Rust は(限られた範囲において)常に安全ω(キリっ
44:デフォルトの名無しさん
23/04/03 10:26:17.83 ni15ogEW.net
C++er あるあるシリーズ
#![allow(unused)]
... = hoge().unwrap;
... = hoge()?;
let p: *const [u8] = &fuga;
unsafe {}
45:デフォルトの名無しさん
23/04/03 10:27:57.18 L3onvvn+.net
>>37
C++のスマポの使い方をミスっても公式支援がない話でそれらは的外れかなあ
clippyはRust公式リント
rustfixはRustコンパイラのよる提案の適用
rust-fmtは清書
cargo-expandはマクロ展開
46:デフォルトの名無しさん
23/04/03 10:39:12.43 ux7WrBep.net
>>41
Rustはムダなコピーを発生させずに参照を使って安全にメモリ管理できる言語
もしRustで不可能なケースがあったらそれはC++でも不可能で元から無理筋
47:デフォルトの名無しさん
23/04/03 10:55:27.74 GLvgK6Zq.net
なおグラフ
48:デフォルトの名無しさん
23/04/03 11:15:28.73 UoFPeH1S.net
>>44
それはRustの実装が一つしかないのを公式と言っているに過ぎない
C++でデバッガが用意されていない開発環境は無い?
もしくは使われていないのでは?
49:デフォルトの名無しさん
23/04/03 11:47:36.10 GWsnSys+.net
>>44
誰もが使ってるツールにわざわざ説明つけてるところ見ると基本の静的解析ツールも知らなかったんだな
複オジは所詮このレベルだから全く信用できない
50:デフォルトの名無しさん
23/04/03 11:50:42.61 UoFPeH1S.net
>>45
C++は選択ができる
値とポインタ（スマートポインタ）と参照（左辺値と右辺値）
冗長に書くも効率的に書くもプログラマ次第
素人にはオススメしない
51:デフォルトの名無しさん
23/04/03 12:08:48.70 NHUpObDP.net
>>49
それはどちらも同じ
所有権を持つ: C++のスマポ、Rustの変数
所有権を持たない: C++とRustの参照
ただしライフタイムが管理できるRustの参照の方が強力かつ安全
52:デフォルトの名無しさん
23/04/03 12:15:40.80 UoFPeH1S.net
>>50
「ライフタイムが管理できるRustの参照」って何?
単に参照先が死んでることをコンパイラで弾くことを「管理」って言ってるの?
53:デフォルトの名無しさん
23/04/03 12:16:08.17 GLvgK6Zq.net
the Bookを捨てよ、町へ出よう
54:デフォルトの名無しさん
23/04/03 12:24:08.54 GLvgK6Zq.net
Rustの宣伝文だけ読んで他言語を知った気になり
Rustの宣伝文を5chにコピペし続けるだけの人生
55:デフォルトの名無しさん
23/04/03 12:47:23.54 UoFPeH1S.net
>>53
言い得て妙
マジでこれw
56:デフォルトの名無しさん
23/04/03 12:54:34.40 xtNXRsCH.net
>>50
C++の参照とRustの参照はかなり違うぞ
C++の参照はちょっとミスるとダングリングになる
57:デフォルトの名無しさん
23/04/03 13:50:16.07 QA6IHCRk.net
「数学的」連呼してる割には名前に直交性が無いな
.iter
.indexed_iter
.iter_mut
.indexed_iter_mut
.outer_iter
.outer_iter_mut
not exist .indexed_iter_mut
not exist .enumerate_iter_mut
.enumerate_pixels_mut
いちいち覚えてられるか？
58:デフォルトの名無しさん
23/04/03 13:54:52.87 QA6IHCRk.net
違ったので訂正
誤 not exist .indexed_iter_mut
正 not exist .indexed_outer_iter_mut
59:デフォルトの名無しさん
23/04/03 14:01:30.74 7c0W6U8J.net
あ。「数学的」連呼してたのは、C++側の俺
そして、あんまり、数学的な安全の論拠ってのはみつからない
ありゃあC++で真似するんだよ 手本にしない手はない
60:デフォルトの名無しさん
23/04/03 14:08:12.25 rB8gWfoY.net
>>56
各ライブラリで命名方針が異なるのは、プログラミング言語の比較の話と全く無関係じゃね？
あと、enumerate_pixels_mutをその提案のenumerate_iter_mutとしてしまったら、肝心なピクセルが消えて意味不明じゃん。
61:デフォルトの名無しさん
23/04/03 14:14:18.67 7c0W6U8J.net
雑談としては、そのへんも「きれい」になってくれるとありがたいね
これはC++も同様
62:デフォルトの名無しさん
23/04/03 14:28:24.56 gdFj9/S+.net
直交性の意味がよく分からなかった
index_of（先頭から検索）とlast_index_of（末尾から検索）は直交性がないことになるのかな
標準と非標準の関係で考えると自然な命名だと思うけど
63:デフォルトの名無しさん
23/04/03 14:29:57.73 GLvgK6Zq.net
かわいそうだから答えてやるか
数学的な保証が云々ってたぶんRustBeltプロジェクトのことだよね
URLﾘﾝｸ(plv.mpi-sws.org)
64:デフォルトの名無しさん
23/04/03 15:09:57.20 dlyOKSPs.net
>>62
どの辺を指して数学的と言ってるのか謎
65:デフォルトの名無しさん
23/04/03 15:39:46.50 7c0W6U8J.net
Rust 安全 論文、で上手く引き当てられなかったんだよ
仕事サボって、ちょっと読んでみるｗ
>>63
いや、いいんだ。「それっぽいの」って俺も言った。
66:デフォルトの名無しさん
23/04/03 15:53:08.55 ZjD7pm8v.net
>>62
unsafeを使ってsafeなインタフェースを作っている部分、すなわち人間が安全性を保証しなければならなかった部分を、数学的に保証する試みがあるのか
67:デフォルトの名無しさん
23/04/03 15:56:35.02 7c0W6U8J.net
そこも気を付けて読んでみるけど、
unsafeを撲滅しようと思ったら、SoCのサポートが必要ってのが今のところの俺の考え
そう考えないと、C++も永遠にsafeに成れないことになってしまう
unsafe部分にバグが、っていう古い記事が出てきたりするんだけど、
どうせ、safeでいいものまでunsafeでいっぱい書いたんでしょ、と思ってる
これは個人の推測
68:デフォルトの名無しさん
23/04/03 16:08:23.20 sTax+JD2.net
>>65
数学的とは一言も書いてなくね？
69:デフォルトの名無しさん
23/04/03 16:11:48.88 7c0W6U8J.net
学術的とか、論理的とか、適当に読み替えてくれよ、俺がうまく言えなかったのがいけなかっただけ
70:デフォルトの名無しさん
23/04/03 17:01:07.96 dGJwzzow.net
>>61
last_index_ofはlast occurrenceのindexを示すだけで検索方向を示すものでは無いと思う
71:デフォルトの名無しさん
23/04/03 17:14:21.15 WoF7SnyS.net
>>56 >>59
.indexed_pixel_mut も欲しいです
72:デフォルトの名無しさん
23/04/03 17:34:14.59 G+jJ6S+V.net
>>70
はあ？
indexed_iter_mutがあるのはndarray crateの話
enumerate_pixels_mutがあるのはimage crateの話
pixelのイテレータとrowのイテレータがあるためiterではなくpixelsおよびrowsと名付けている
>>56が無関係な両ライブラリをごっちやに取り上げてその意味も分からず批判しているだけにすぎない
73:デフォルトの名無しさん
23/04/04 09:48:59.96 1EmRTN+L.net
前スレを読んだ感想だが
Rustのvtableは1つに合成されているのがへーだった
ちなみにC++は各基底毎にある
URLﾘﾝｸ(i.stack.imgur.com)
URLﾘﾝｸ(i.stack.imgur.com)
74:デフォルトの名無しさん
23/04/04 09:57:45.04 WkDAaTBe.net
>>72
それ読み間違えてるぞ
75:デフォルトの名無しさん
23/04/04 10:05:22.65 wMBLnZ/K.net
複オジメソッド発動
76:デフォルトの名無しさん
23/04/04 10:08:21.90 2Z9CTS/R.net
>>72
Rustは継承がなくトレイト合成なんだから当然だろ
>>73
間違ってはいないだろ
77:デフォルトの名無しさん
23/04/04 10:10:16.77 E2o8nJSl.net
まあ、ちゃんとキャストできるようにできてるというか
78:デフォルトの名無しさん
23/04/04 12:04:39.20 4IMp+S71.net
何が間違ってるかは教えてあげない
79:デフォルトの名無しさん
23/04/04 13:10:25.87 I8oGyAYF.net
プッ
80:デフォルトの名無しさん
23/04/04 13:20:50.92 E2o8nJSl.net
C++を知ってしまったことかな。。
81:デフォルトの名無しさん
23/04/04 14:47:11.16 NrMPyXSZ.net
日本人はtraitとtoiletの区別がつきにくい
82:デフォルトの名無しさん
23/04/04 17:52:01.37 N9reXox+.net
もうGPTがどの言語でも変換してくれる時代
83:デフォルトの名無しさん
23/04/04 20:58:36.08 N+qd6aMB.net
rustのcrateはdependenciesで入るのが多過ぎるし大き過ぎるわ
要らないものまで無理やり入れさせられてる気分になる
84:デフォルトの名無しさん
23/04/04 21:26:41.04 0Yk0tShF.net
依存crate問題が最大の弱点ではある
85:デフォルトの名無しさん
23/04/04 21:32:45.26 nnLBpR2L.net
node_modulesとどっちがヤバいかな？
86:デフォルトの名無しさん
23/04/05 15:18:19.83 MSpbiXL9.net
node_modules は -g で解決
87:デフォルトの名無しさん
23/04/05 15:43:59.95 lwqbYnd2.net
dependenciesに5個程度指定するだけで
依存crateが100個近くになるのも珍しくない
nodeとは比べ物にならないくらいひどいよ
88:デフォルトの名無しさん
23/04/05 15:47:38.76 lwqbYnd2.net
しかもビルドすると500～1GB超の容量使うからノートの内蔵SSDを使ってると残す必要のないのは積極的にcleanしないときつい
89:デフォルトの名無しさん
23/04/05 15:49:19.66 46QkPZge.net
そんだけファイルの読み書きするなら
IOの速度に影響されそうだね
90:デフォルトの名無しさん
23/04/05 15:55:51.93 /Rqy2YcF.net
マイコンでも大人気と聞いたんだが、どうなってるんだ
91:デフォルトの名無しさん
23/04/05 17:07:48.56 rkWYEusf.net
容量使うのはインクリメンタルビルド用の中間生成物で配置するものとは違うよ
92:デフォルトの名無しさん
23/04/05 17:26:43.23 /Rqy2YcF.net
C++もPCHファイルを生成するとアホほどでかかったりするが…世の中うまくいかんな
93:デフォルトの名無しさん
23/04/06 14:03:59.93 sb5+vAgP.net
チンチン汁出るッ
94:デフォルトの名無しさん
23/04/06 15:09:52.63 jULmAo6w.net
C++なら明示的インスタンス化を使おうよ
使っている人をほぼ見ないけども
95:デフォルトの名無しさん
23/04/06 15:52:41.86 gPnWA/2r.net
こう書いておけば、インスタンス化した関数に、こんな風に溶け込むだろうな、とか思って書いてたりはする
時間があれば、生成コードを汗で確認する
びっくりするほどスパゲッティな出力になってて、びっくりすることがある まあ実力不足を痛感する瞬間
96:デフォルトの名無しさん
23/04/06 18:12:44.37 un5AwFJZ.net
Cargo はゴミ
97:デフォルトの名無しさん
23/04/06 20:01:46.11 W1iP43mr.net
ぺたんこおっぱい
ぽっこりおなか
つるつるわれめ
98:デフォルトの名無しさん
23/04/06 23:30:16.81 ZIKOL9hh.net
>>94
クラスも構造体も使わずに書いているの？
99:デフォルトの名無しさん
23/04/06 23:35:22.20 gPnWA/2r.net
ああ、callで呼ぶようなものはなんでも関数って言っちゃうねつい
100:デフォルトの名無しさん
23/04/07 00:17:10.35 u3jMtx4p.net
URLﾘﾝｸ(www.publickey1.jp)
こちらはC++との互換性を重視しているらしい
Rustはこの先生きのこれるかな？
101:デフォルトの名無しさん
23/04/07 00:31:06.23 D4MDBVlu.net
そこにこれ載ってた
[RFC] Lifetime annotations for C++
URLﾘﾝｸ(discourse.llvm.org)
Rustは勝利した しかし、Rustはその勝利を独占できない
102:デフォルトの名無しさん
23/04/07 03:11:25.56 ZE3zxB0C.net
>>100
こう書いてあるね
提案された有効期間注釈に基づく静的分析では、C++ コード内のすべてのメモリ安全性の問題をキャッチすることはできません。
具体的には、すべての時間メモリの安全性のバグ (反復子の無効化によって引き起こされるバグなど) をキャッチすることはできず、
もちろん、有効期間注釈は空間メモリの安全性 (たとえば、C スタイルの配列の範囲外のインデックス作成) には役立ちません。
詳細な議論については、以下のRustとの比較を参照してください。
103:デフォルトの名無しさん
23/04/07 03:22:57.43 ZE3zxB0C.net
>>99
Rustを使えるならばRustを使ったほうが良いと明記されているね
ソース
Carbon公式FAQ
URLﾘﾝｸ(github.com)
Why not Rust?
If you can use Rust, ignore Carbon.
If you want to use Rust, and it is technically and economically viable for your project, you should use Rust.
In fact, if you can use Rust or any other established programming language, you should.
Carbon is for organizations and projects that heavily depend on C++
104:デフォルトの名無しさん
23/04/07 03:34:46.32 D4MDBVlu.net
>>101
-Wlifetime とかと組み合わせろってことじゃないん
スマポだけでは解けない課題にこれが要るんだろ
(勉強中なので)知らんけど
105:デフォルトの名無しさん
23/04/07 15:30:28.71 xzLK1vX9.net
動きました。ほんとうにありがとうございました。
use std::ffi::c_void;
#[link(name = "user32")]
#[no_mangle]
extern "stdcall" {
fn MessageBoxA(hWnd: *const c_void, lpMsg: *const u8, lpTitle: *const u8, flg: u64) -> u64;
}
fn main() {
let msg: &[u8] = &vec![65u8, 66u8, 67u8, 0u8];
let lpmsg: *const u8 = &msg[0];
let ttl: &[u8] = &vec![97u8, 98u8, 99u8, 0u8];
let lpttl: *const u8 = &ttl[0];
println!("{}", unsafe { MessageBoxA(0 as *const c_void, lpmsg, lpttl, 3) });
}
106:デフォルトの名無しさん
23/04/07 16:14:09.83 VHO1ouQx.net
>>103
知らないなら書くなよアホが
107:デフォルトの名無しさん
23/04/07 16:45:18.17 e9qg1mi5.net
>>104
こうしろよ
let msg: &[u8] = &vec![65u8, 66u8, 67u8, 0u8];
↓
let msg: &[u8] = b"ABC\0";
108:デフォルトの名無しさん
23/04/07 16:51:51.07 e9qg1mi5.net
さらに*constにするならこれだけでいい
let msg: &[u8] = &vec![65u8, 66u8, 67u8, 0u8];
let lpmsg: *const u8 = &msg[0];
↓
let lpmsg = b"ABC\0" as *const _;
109:デフォルトの名無しさん
23/04/07 18:04:16.50 D4MDBVlu.net
>>105
しらんがなｗ
110:デフォルトの名無しさん
23/04/08 02:42:49.64 6o1jJWCj.net
>>104
こっち使え
URLﾘﾝｸ(github.com)
URLﾘﾝｸ(www.youtube.com)
111:デフォルトの名無しさん
23/04/09 10:11:37.53 kqAFhzUx.net
Haskellでrustみたいに
型引数だけじゃなく型引数を引数に取るデータ型に対しても型制約書けたりできるんですか？
112:デフォルトの名無しさん
23/04/09 11:45:46.52 vz6m7/QT.net
逆では？
113:デフォルトの名無しさん
23/04/09 14:32:11.00 pIxjloTA.net
>>110
もちろんできる
HaskellはRustにできないHKTもサポートしてる
114:デフォルトの名無しさん
23/04/10 12:58:57.54 AInS4/OD.net
HaskellはH言語に名を改めるべきだな
そしたら興味持つ奴がたくさん出てくる
115:デフォルトの名無しさん
23/04/10 13:12:23.09 dCIkFZZ7.net
「すごいH たのしく学ぼう」 という本が出版されるのか
116:デフォルトの名無しさん
23/04/10 15:02:02.71 mDAZdp8I.net
いやん、のび太さんのHaskell
117:デフォルトの名無しさん
23/04/10 15:30:45.65 lVeX+H98.net
はじめてのH
118:デフォルトの名無しさん
23/04/12 01:19:12.28 LloefAdv.net
URLﾘﾝｸ(i.imgur.com)
119:デフォルトの名無しさん
23/04/13 18:14:06.57 HbYojT2c.net
100%検索引っ掛からねー糞がって話になるわ
120:デフォルトの名無しさん
23/04/14 11:40:41.31 UzCXU8/1.net
無能の内輪ノリで人口への膾炙が遅れただろその本の名前
キモいこと分かってないんだからそういうヤツラが使ってると思われる
日本でコケたのは本の題名のせいだ
121:デフォルトの名無しさん
23/04/15 02:05:35.34 OSkIS2HX.net
ChatGPＴでいいじゃゆ
122:デフォルトの名無しさん
23/04/15 09:46:37.00 PycfapTP.net
気が付くと unsafe {} 描きまくってるんだよなぁ orz
123:デフォルトの名無しさん
23/04/15 09:48:12.09 nVVXe4ml.net
>>118
Julia の二の舞だな
>>121
ほんそれ
124:デフォルトの名無しさん
23/04/15 10:48:22.69 8QIF2BQP.net
unsafeは甘え(自戒
C++の生ポも甘え(自戒
125:デフォルトの名無しさん
23/04/15 12:33:08.40 nVVXe4ml.net
mut 付け過ぎもあるかな
let hoge: &mut Vec<u8> = &mut vec![0u8; 256];
for i in 0..hoge.len() { hoge[i] = 255u8; }
の場合と
let mut hoge: Vec<u8> = vec![0u8; 256];
for i in 0..hoge.len() { hoge[i] = 255u8; }
の場合とか
126:デフォルトの名無しさん
23/04/15 14:12:22.83 YfadAR61.net
>>121
通常のプログラムの中にunsafeが出てくることはない
unsafeは本質的に新たな構造や仕組みをその原理部分のみ小さくライブラリ化して閉じ込めるときに用いられる
その場合も多くは再発明なので既存のライブラリを使えばよい
127:デフォルトの名無しさん
23/04/15 19:28:04.14 yvTdL9wg.net
現段階でRustを推している人は、「イノベーター」と呼ばれる人で、
『常に最新の情報をチェックしていて、新しい商品やサービスに対する興味を持ちやすいユーザーです。
「新しさ」に価値を感じているのが特徴で、商品の細かい性能や価格はそれほど気にしません。
「最先端」「革新的」などが感じられる商品を積極的に選ぶ傾向があります。』
ということで、「メリット」は余り考えなくて、最先端や革新的であれば
試す人達らしい。牽引役として重要だが、すぐ飽きると言われている。
128:デフォルトの名無しさん
23/04/15 19:33:25.66 yvTdL9wg.net
普及するには、その次に新し物好きなアーリーアダプターが重要らしい。
こちらは新しさだけでなくメリットも考慮して判断すると言われていて、
なおかつ影響力も大きいらしい。
イノベーターは恐らく説得力に乏しいから人を呼ぶ込む力が弱いかも。
129:デフォルトの名無しさん
23/04/15 19:33:29.98 8QIF2BQP.net
こんなとこ(スレ)に溜まる奴らだろ、ライブラリ内製でもしてんじゃねーの
あるいはガチ学習者。学生なら、車輪の一つや二つ、自分で磨いてみるもんだ
青春やり直してる大人も含む
130:デフォルトの名無しさん
23/04/15 19:36:01.37 yvTdL9wg.net
経験から言うと、余りよくない品物、本当は競合と比べてメリットが余りないもの
でも、一定の人は買ってくれる。そして、なぜかその人達は商品を高く評価する。
しかし、実際にはそれ以上進まない。
実
131:は商品の競争力が本当は余り無くてもそういう人達は高く評価するから。
132:デフォルトの名無しさん
23/04/15 19:36:32.22 8QIF2BQP.net
あらら >>128 >>125
まあ、ガチ勢はコード書いてるよね
今ちょっと半田ごてに逃げてる俺も耳が痛いねｗ
133:デフォルトの名無しさん
23/04/15 19:38:31.04 yvTdL9wg.net
過去の例からすると、Rustは非常に限られた分野で普及が進むのかも知れない。
ただ、言語の場合は、プロには無料である事もそんなにメリットにはならないので
どこまでいくかは見通せない。
134:デフォルトの名無しさん
23/04/15 19:40:01.02 yvTdL9wg.net
マニアは、それ自体を楽しんでいるだけで、実用的な仕事に使うことは想定して
なかったりすることが多い。
Rustもそうなのではないか。
135:デフォルトの名無しさん
23/04/15 19:42:50.40 yvTdL9wg.net
>>128
そういう人は、ライブラリ作りも、作ること自体を楽しんだり、自慢や就職に
利用するためにやってるのではないか。また、そういう人には
「沢山の人に使ってもらえれば満足」
などという人も多い傾向がある。
136:デフォルトの名無しさん
23/04/15 19:51:35.04 yvTdL9wg.net
>>125
Rustのunsafeは効率を落とさない限りはライブラリ内部に閉じ込めることが出来
無い事があることが分かってる。
数学的な才能が無い人は、想像力が無いのでそれが
137:分からない。 反論は不要。結論は出ているので。
138:デフォルトの名無しさん
23/04/15 20:02:07.05 yvTdL9wg.net
>>134
もしかしたら、マシン語を理解できないからそのことが分からないのかも知れないな。
「効率を落とさずに」
の意味がマシン語を知らないから分かって無い。
どういうことかと言えば、C言語では1クロックで書けるところが、
Rustだとunsafeをライブラリの中だけに閉じ込めるだけでは、
どうしても1クロックでは書けないことが有る。
139:デフォルトの名無しさん
23/04/15 20:24:11.46 fX0vt5Cu.net
Rustもご多分に漏れず
新しいC/C++チャレンジャーが現れて
忘れ去られるんだと思うよ
140:デフォルトの名無しさん
23/04/15 20:42:03.21 8QIF2BQP.net
Cは、広義の安全であることが実装者の責任と権限だけど、
そのために余計なステートメントを書かなくちゃいけなくて、
結局Rustのほうが全体ではステップ数がすくなくなる余地はあるぞ
なので、C/C++は、追いつき、追い越さなければならない
141:デフォルトの名無しさん
23/04/15 21:49:44.60 stEGFLky.net
クラウド世界トップシェアのAWSもRustで構築されているらしい
URLﾘﾝｸ(japan.zdnet.com)
AWD (Amazon Web Services)は、「Rust」を使っている大きな理由として、エネルギー効率の高さを挙げる。
AWSは早くからRustを採用し、Rust Foundationの創設にも携わった。
現在もRustの普及に熱心に取り組んでいる。
AWSのソフトウェアエンジニアで、Rustの普及に取り組む
Shane Miller氏と主任エンジニアのCarl Lerche氏の投稿によれば、
Rustはメモリー安全性を高め、セキュリティ関連の不具合を減らす役に立つだけでなく「エネルギー効率に優れている」。
Amazonは、2025年までにデータセンターの100％を再生エネルギーでまかなうという目標を掲げ、
データセンターの環境負荷の軽減に取り組んでいる。
Rustの採用はその一翼を担うという。
Rustで構築されたAWSサービスの例としては、
コンテナーアプリ用のサーバーレスプラットフォーム「Lamba」を支える「Firecracker」、
「Amazon Simple Storage Service（S3）」、
「Amazon Elastic Compute Cloud（EC2）」、
コンテンツ配信ネットワーク「Amazon CloudFront」、
LinuxベースのコンテナーOS「Bottlerocket」などがある。
142:デフォルトの名無しさん
23/04/15 22:30:48.74 8QIF2BQP.net
大いに主観が入るけど、もっと高級言語から来てる人も多いんじゃないかな
C++に巻き取りたいねえ、負けていられない
143:デフォルトの名無しさん
23/04/16 00:07:26.65 UgglHakI.net
イノベーターは後先考えずに新しいものを試す。しかし、ものがよくなければ、
アーリーアダプターには届かず、失速する。それがブーム。
144:デフォルトの名無しさん
23/04/16 00:17:13.72 UgglHakI.net
>>140
厳密に言うと、イノベーターは、知識が豊富で、物の「能書き」や「SPEC」をよく
見て自分に合うものを選んでいると言われている。
但し、能書きどおりのものかどうか誰にも分からないような段階で「人柱」状態
で使い始めるから、後から言われた通りになってないことに気付くこともある。
なお、他の階層の人は失敗をしたくないからその時点では試さない。
145:デフォルトの名無しさん
23/04/16 00:20:31.86 2uUp8lA9.net
8年前のRustはそんな感じだった
まだ先があるのかわからなかった
しかしMicrosoftやGoogleやAmazonなど各社でアーリーアダプターたちが実績を示していった
RustはC++より優れていて実用的だと各社が数年かけて認識を確実なものとした
そしてライバル競合IT大手各社が共同でRust Foundationを設立
安定して信頼できる今後のプログラミング言語の地位を確立した
146:デフォルトの名無しさん
23/04/16 00:30:44.93 UgglHakI.net
>>142
そんな風には思わないけどな。
そもそもRustやってる人は、現代段階でも人数からいってイノベーターの域を出て
ないし。
そんな風に語らなくても、本当に優れたものであれば噂がたって人気が出てくるはず。
147:デフォルトの名無しさん
23/04/16 01:29:25.91 ZR3Gmnwe.net
見えてる世界が違いすぎて話にならんよなw
5年前ならまだしも今はもうキャズムを超えてるかどうかなんて議論の余地無いよ
148:デフォルトの名無しさん
23/04/16 02:21:00.95 vDeFqoK0.net
C++はヘッダファイルというウンコをいつまで引き摺ってるのやら
149:デフォルトの名無しさん
23/04/16 04:33:04.30 FzlfbndA.net
そのウンコに頼らないとCFFIもできないんだから文句言わんといてください
150:デフォルトの名無しさん
23/04/16 06:41:40.93 t40wRhbK.net
cmakeとかわりといい仕事してるし、いいだろ
Rustが本格的に採用されれば、C++にもやっとsafeの波が訪れるだろう
福音だね
151:デフォルトの名無しさん
23/04/16 08:00:51.32 t40wRhbK.net
>>134
サンクがゼロコストになりえないみたいなこと?
safe/unsafe間に行き来があるとしても、うまく書ければ最適化でサンクは消失するんじゃないん
基盤がclangだし、そのうちできるようになるか、とっくにできるようになってるか
152:デフォルトの名無しさん
23/04/16 08:59:48.91 66qnCtAq.net
>>145
C++はCを包含するってのが方針なんで
そこはバッサリ互換性を切り捨てるRustとは違うのだよ
153:デフォルトの名無しさん
23/04/16 09:20:17.30 UySlLSqv.net
>>148
そいつ>>134はデタラメな主張を繰り返している基地外
数学的に自明と主張しつつその証明を示せなかったホラ吹き
154:デフォルトの名無しさん
23/04/16 10:25:57.47 9jM292fW.net
>>150
示せてるのにこの板の人が理解できないだけ。
155:デフォルトの名無しさん
23/04/16 10:28:54.24 9jM292fW.net
>>148
そうじゃない。
Rustの安全機構をライブラリ外のアプリレベルまで維持したままでは速度が
上げられないケースが存在することが分かっている。
つまり、ライブラリの中だけにunsafeを書いて、アプリコードの中ではunsafe
を使わなかった場合、安全機構と相性が悪くて必ずオーバーヘッドが生じる
場合がある事が分かっている。
156:デフォルトの名無しさん
23/04/16 10:31:26.95 J01hksTa.net
バカ同士仲良くやっとけよ
100点オジと複製オジ
157:デフォルトの名無しさん
23/04/16 10:34:06.66 9jM292fW.net
馬鹿が多すぎて学級崩壊状態。
この板は、特に数学的理解力が乏しい人が多すぎる。
158:デフォルトの名無しさん
23/04/16 10:41:45.49 FS/wFdTV.net
この板で「数学的」という言葉を使うやつは例外なく馬鹿だから
159:デフォルトの名無しさん
23/04/16 10:44:16.92 66qnCtAq.net
安全性が効率を犠牲にしているなんて
Rustに限らず分かりそうなもんだけどね
160:デフォルトの名無しさん
23/04/16 10:46:01.28 9jM292fW.net
>>155
一般人目線では、頭の良すぎる人が馬鹿に見える。
161:デフォルトの名無しさん
23/04/16 10:56:10.86 v1QbiGiU.net
数学的と言うざっくりとした使い方をしてるのは文系だろうなと言う感想です
162:デフォルトの名無しさん
23/04/16 11:04:50.54 YvJBOxcy.net
もしかして「おまえらバカにはわからないだろうが、数学的に自明。自明だから解説はしない。」という詐欺師？
163:デフォルトの名無しさん
23/04/16 11:08:16.87 v1QbiGiU.net
そうじゃないと思うよ
自分では賢いと思ってるけど実際はなにも表現出来てないし伝わってないタイプ
例え伝わっても中身自体は大したことがない
検証や考察無しにただ直観をそのまま書いてる人
自分の意見を書籍や論文にするけどその道の出来る人が見れば一瞬で捨てられる
164:デフォルトの名無しさん
23/04/16 11:15:03.16 YvJBOxcy.net
詐欺師でないなら数学的に示せばいいんじゃないかな
できなければ詐欺師確定ってことで
165:デフォルトの名無しさん
23/04/16 11:15:10.82 XjjLJq3x.net
クソスレでクソレスを重ねる板の荒らしを発酵させるスレ
>>1
責任とってしんどけ
166:デフォルトの名無しさん
23/04/16 11:19:00.37 olscUowK.net
>>155
数学的って言い出したのは俺だけど、>>68 でちゃんと謝っただろｗｗ
俺は理系だけど、バイオ系に行った人間で、情報工学とか修めてないんだ
超基礎はwebに出てるから、少しずつ勉強してるけどね
そんな人間でも使える、使ってるのがC/C++だ
だから、型安全に続いて、所有権安全がC/C++に来るのは大歓迎だぜ
167:デフォルトの名無しさん
23/04/16 11:28:57.03 v1QbiGiU.net
自分は情報系というかガチ情報
168:デフォルトの名無しさん
23/04/16 11:35:56.39 vDeFqoK0.net
Rustはコンパイル時点で安全性が担保出来るってのが強みなんだよ
GCみたいにパフォーマンスに影響与えないし、C++ほど安全に使うための予備知識が多く必要ない
169:デフォルトの名無しさん
23/04/16 11:51:39.68 66qnCtAq.net
>>165
>C++ほど安全に使うための予備知識が多く必要ない
その予備知識を覚えるコストが
所有権システムの振る舞いを覚えるコストに
吐き出されたというだけでは?
170:デフォルトの名無しさん
23/04/16 12:03:50.68 olscUowK.net
C++は安全な利用の統一的な技法が普及してない、まさにこれから
言語によっておおむね統一されてるRustはそのへんを学ぶにあたって効率はいい模様
171:デフォルトの名無しさん
23/04/16 12:13:57.81 66qnCtAq.net
>>167
>C++は安全な利用の統一的な技法が普及してない、まさにこれから
は?
（Rustの言語に含めるってアイデアはありだと思うよ）
172:デフォルトの名無しさん
23/04/16 12:14:25.91 vDeFqoK0.net
>>166
言語の標準機能で実現されてるってのが大きい
C++は調べようと思ってもレガシーな情報にぶち当たる可能性が非常に高い
173:デフォルトの名無しさん
23/04/16 12:20:48.95 66qnCtAq.net
>>169
そこは独特な所有権システムを受け入れることととのトレードオフだけども
そのぶち当たるC++のレガシーな部分って
要するにCなので難しくもないと思うのだが? そんなので挫折するかい?
俺はC++の規格のうち最近に拡張された機能を覚える方が大変だよ
174:デフォルトの名無しさん
23/04/16 12:22:56.14 olscUowK.net
普及してたら、こんだけ虫だらけになってないからさｗ
175:デフォルトの名無しさん
23/04/16 12:30:40.09 Xi5zVo2w.net
>>158
ところが「数学的」という言葉を使うのは理系が多いんだなこれが
まあちょっと考えればわかることだけど
176:デフォルトの名無しさん
23/04/16 12:33:47.71 vDeFqoK0.net
>>170
結局Ｃ++は言語としての基礎がまともじゃないから、拡張繰り返してキメラみたいになってんだよ
今更新規で薦められる言語ではない
177:デフォルトの名無しさん
23/04/16 12:42:30.71 olscUowK.net
まともな文系は、数学も勉強してるから、数学っていうだろうな
まともじゃない文系…って、こんな板来んやろ(ｗ
178:デフォルトの名無しさん
23/04/16 12:43:09.89 66qnCtAq.net
>>173
スタンダードであったCを呑み込むことが当初からのC++の戦略だからね
後方互換性ってのは大多数の人間にとっては魅力なんだよ
後方互換性を犠牲にしてディファクトスタンダードに食い込んでいくのは懐疑的だよ
PCのOSしかり携帯しかり
179:デフォルトの名無しさん
23/04/16 12:54:37.30 vDeFqoK0.net
> PCのOSしかり携帯しかり
LinusもRust導入に舵切ってるし、MSもRust採用始めてるんですがそれは
180:デフォルトの名無しさん
23/04/16 13:01:00.06 66qnCtAq.net
>>176
$ wget 'URLﾘﾝｸ(cdn.kernel.org)'
$ tar xJf linux-6.2.11.tar.xz
$ find linux-6.2.11 -name *.c -o -name *.h | wc -l
55980
$ find linux-6.2.11 -name *.rs | wc -l
37
僅かに0.07%未満だよ
最後のプロンプトから | wc -l を取ればRustが何に使われているか分かる
MSは知らん Visual Rust++は出たのかな?
181:デフォルトの名無しさん
23/04/16 13:09:54.46 vDeFqoK0.net
これから始めるのに、今の%出す意味ある？
182:デフォルトの名無しさん
23/04/16 13:13:32.51 olscUowK.net
そこで止まっちゃってないかってことじゃねえの、しらんけど
Windowsには、これが出てるけど…
URLﾘﾝｸ(github.com)
そこにあるサンプルからして、unsafe{ } じゃ、説得力ないよな
>>16-17 に書いた通りだよ Win32 APIに所有権情報が付いてなかったらなんにもならない
MS Rustチームもっと仕事しろ
183:デフォルトの名無しさん
23/04/16 13:13:34.53 66qnCtAq.net
>>178
>最後のプロンプトから | wc -l を取ればRustが何に使われているか分かる
184:デフォルトの名無しさん
23/04/16 13:33:14.21 FzlfbndA.net
Rust for Linuxは現状ドライバをRustで書けるようにしましたってだけ
Rustで置き換えて安全化！なんてわかりやすい成果は現状出ていない
何回言わせんねん
185:デフォルトの名無しさん
23/04/16 14:40:27.93 E0OdAeYg.net
Rustと違ってC++にはEditionがないからね
safe/unsafeを導入するの10年経っても無理
Clang-Tidyのような外部ツールで頑張るしかない
186:デフォルトの名無しさん
23/04/16 14:53:00.44 v/OrVFzF.net
>>182
ちゃんと調べて書けば?
Rustは規格すらないやろ?
187:デフォルトの名無しさん
23/04/16 14:56:50.63 MEMXejP0.net
>>183
Editionが何かも知らんのかw
そんなんでよく書き込みするなぁ
188:デフォルトの名無しさん
23/04/16 15:03:55.57 v/OrVFzF.net
Rustは実装がまだ1つだし仕方ないか
189:デフォルトの名無しさん
23/04/16 15:04:13.74 ztY5oQ1H.net
>>159
これまでの会話からして、この板の人は、証明しても誰一人として理解できない
から時間の無駄であることが分かった。
恐らく、10年後くらいにやっと理解できるかも知れない。
そういうものだ。
190:デフォルトの名無しさん
23/04/16 16:12:58.54 KNACwVVn.net
せっかくに日曜日をもっと有意義に過ごせばいいのに
191:デフォルトの名無しさん
23/04/16 16:21:18.43 Uuc59Yg9.net
板違いのスレで真っ赤とか人生見直した方がいいな
192:デフォルトの名無しさん
23/04/16 16:23:46.35 3uC0HhdE.net
C++はEditionがどうとか以前に、方言だらけなわけだが
なので、所有権関係が取り込まれるのも早いとこは早いかもね
193:デフォルトの名無しさん
23/04/16 18:22:08.94 Odg0MqUb.net
C,C++は1995～2000年ごろGCブームが来てて
大学の課題もGC使ってた
当たり前に使ってた
取り込まれるのかと思ったら取り込まれなかった
今は潤沢なメモリがあるからメモリリーク放置violation放置みたいだけどそもそもがc++じゃなくてpython使ってるみたい
194:デフォルトの名無しさん
23/04/16 19:23:35.61 RVWThtYJ.net
>>190
そんな素人の話をされてもね
195:デフォルトの名無しさん
23/04/16 19:35:35.63 YK5TrmOw.net
>>166
学習コストは確実にRustの方が低くて覚えやすい
所有権関係はunique_ptrすらなくシンプルなRustがわかりやすいのは言うまでもないが
あらゆる分野で整理されて高機能になるとともにわかりやすくなっている
例えばイテレータにしてもC++はC++20でようやく機能強化と大整理が行われたが普及には程遠い
196:デフォルトの名無しさん
23/04/16 20:16:07.19 66qnCtAq.net
>>192
初めて覚えるのがRustってんなら否定はしないが
所有権システムは他の全ての言語と勝手が違うからね
C++ユーザならある程度は分かるけども
>例えばイテレータにしてもC++はC++20でようやく機能強化と大整理が行われたが普及には程遠い
これなーに? ついて行けてないんだけども便利なのあるかな?
197:デフォルトの名無しさん
23/04/16 21:24:14.05 2esMCHbQ.net
言語仕様でごちゃごちゃ議論したがるのはコードまともに組めない奴
これ豆な
198:デフォルトの名無しさん
23/04/16 21:38:23.17 iwQlkKnY.net
単純な話だよな
所有権の概念の学習コストはC++もRustも同じ
所有権の実際の使い方の学習コストはunique_ptrすらないRustが易しい
学習コストでC++に勝ち目はない
199:デフォルトの名無しさん
23/04/16 21:53:57.59 66qnCtAq.net
>>195
差分としているunique_ptrの学習コストってなんやw
問題にしてるのは他の言語との変数の振る舞いにRustのみ乖離があるということ
プログラミングをRustで始めるんなら
プログラミング言語の変数ってそういうもんだと覚えるから
たぶん問題にはならん
200:デフォルトの名無しさん
23/04/16 22:01:26.81 oa9zAGJK.net
C++でも所有権くらい知らないと話にならないので、所有権があるからRustは学習コストが高いとの主張は無理があるんじゃないかな
それにプログラミングができる人にとって所有権なんて大した難しい話じゃないし、誤差でしょ
201:デフォルトの名無しさん
23/04/16 22:03:10.78 66qnCtAq.net
>>197
>>193
>C++ユーザならある程度は分かるけども
202:デフォルトの名無しさん
23/04/16 22:07:10.90 3uC0HhdE.net
まあ、「C++書けます」とか、そうそう口にできないよな
「Rust書けます」…も似たようなもんな気も
203:デフォルトの名無しさん
23/04/16 22:09:18.55 bqya4Wdu.net
総じて学習コストの高いC++が不利というかさ
拡張が建て増しになってるため無駄に覚えなければいけないことが多すぎなんだよね
学習コストはRustが少なく楽
204:デフォルトの名無しさん
23/04/16 22:47:00.00 vDeFqoK0.net
>>197
そういう知らないと話にならない、という物のを纏めた
公式のドキュメントが存在しないってのが致命的なんよ
205:デフォルトの名無しさん
23/04/16 23:07:41.26 66qnCtAq.net
>>201
C++の所有権の話ってunique_ptrの使い方だけだよ
これ以上ないくらい簡単なクラスだよ
公式ドキュメントにこだわるなら
Rustにはまだ無かろうがC++には規格書があるので
それを読むと良いよ
206:デフォルトの名無しさん
23/04/16 23:12:25.31 vDeFqoK0.net
>>202
規格書はドキュメントにならないんだけど、そんな事も理解できないん？
C++学習する人に、規格書だけ渡すの？
207:デフォルトの名無しさん
23/04/16 23:17:23.76 oa9zAGJK.net
>>202
unique_ptrは使い方を間違えると終わるので簡単な話ではないよね
コンパイルエラーにしてくれるRustの方が学習も早そう
208:デフォルトの名無しさん
23/04/16 23:34:32.39 66qnCtAq.net
>>203
規格書が難しならハゲ本でもメイヤーズでも定番読めばええがな
C++の方が文献は多いよ
209:デフォルトの名無しさん
23/04/16 23:35:44.68 66qnCtAq.net
>>204
>unique_ptrは使い方を間違えると終わるので簡単な話ではないよね
どういう間違え方ですか? コードで書いてみて
210:デフォルトの名無しさん
23/04/16 23:47:43.39 vDeFqoK0.net
C++衰退してる原因が良くわかるな
そもそも使ってる連中も普及しなくていいと思ってそうな雰囲気
211:デフォルトの名無しさん
23/04/16 23:50:43.08 bqya4Wdu.net
>>202
規格書があるから学習コストが低いという主張はバカげてるよね
公式の各種ドキュメントが学習用もリファレンス用も整備されてるRustも十分すぎることになるね
>>204
コンパイルでエラーにしてくれるだけでなくエラー指摘方法と解説の丁寧さはプログラミング言語全体で比較してもRustが最も秀逸だね
212:デフォルトの名無しさん
23/04/17 00:02:25.14 jycfg89f.net
>>208
>規格書があるから学習コストが低いという主張はバカげてるよね
誰がそんな主張をしたのかな?
勝手に自分で作成した主張にバカげてるって一体どういうことだよw
>公式の各種ドキュメントが学習用もリファレンス用も整備されてるRustも十分すぎることになるね
Rustのドキュメントは別に否定はしていないよ
ただしC++の方が歴史が長い分だけ当然のことながら多い
>>204
>unique_ptrは使い方を間違えると終わるので簡単な話ではないよね
どういう間違え方ですか? コードで書いてみて
213:デフォルトの名無しさん
23/04/17 00:26:32.06 Mc7aLKxs.net
使い方を間違えなければよいだけだ
C++11スマポで避けるべきミスTop10
URLﾘﾝｸ(www.acodersjourney.com)
ただし間違えてもエラーを出してくれるわけではないから自己責任
複雑化するとミスが入り込んでセキュリティの穴になったりもするので厳格に要注意
214:デフォルトの名無しさん
23/04/17 05:11:00.37 L5GaKQYU.net
・所有権の概念の理解はどちらでも必須
・言語仕様としての使い勝手はスマポ後付けのC++が不利
・使い方の過ちでコンパイルエラーとならず実害を出してきたC++が不利
215:デフォルトの名無しさん
23/04/17 06:25:51.67 aMavO0YU.net
耳の痛い話なんだが、「所有権の概念とかブッチでも書けちゃう」まであるからね
いいや動けば、みたいなコードが、思わず生き残ってしまうみたいなやつがまずい
自分だって、所有権なにそれおいしいの、みたいな(初学者の)時期は当然あった
気を付けるのが当たり前、みたいな時代だったんだ
なによりC++に欠いているのは、安全を担保・強制する枠組みの決定打
つまり、unsafe{ } の存在 (unsafeがあるということは、逆説的? にsafeが当然にあるという意味)
216:デフォルトの名無しさん
23/04/17 08:12:32.44 jycfg89f.net
>>211
オイオイ
C++では別に所有権の理解は必須ではないよ
make_uniqueなどせずに（普通に?）インスタンス作ることの方が圧倒的に多い
unique_ptrを使うならそれがRustでいう所有権ってだけ（Rustの拝借元?）
217:デフォルトの名無しさん
23/04/17 10:08:26.63 HKDHATFA.net
それを言うなら、スマポに頼らずとも、いや、スマポに頼るような複雑な構造をいたずらに作るなかれ、ってほうが近い
でも、めちゃくちゃ書く人とか、めちゃくちゃ書いちゃうときとか、うっかり書いちゃうときとか、あるんだよね
コンパイラにチェック任せられるのはたしかにうれしい
218:デフォルトの名無しさん
23/04/17 10:08:58.01 kmcXsww3.net
Rust の macro_rules! で
macro_rules! hoge<T> {
(略)
}
って描くと怒られるので
Trait を使って <T> 出来ないかと思ったら
Trait の中に macro_rules! ってどう描けば良いの？
219:デフォルトの名無しさん
23/04/17 10:11:13.47 kmcXsww3.net
>>125 >>134
安全に運用するための unsafe {} なのに
unsafe は上位(呼び出し側)に伝播しないのも面白仕様
220:デフォルトの名無しさん
23/04/17 10:24:16.64 kmcXsww3.net
>>159
ラマヌジャンは凄いわ
221:デフォルトの名無しさん
23/04/17 10:31:53.63 kmcXsww3.net
>>179
C++をWinAPIに適合しようとしてMFC造って失敗した頃のMSと同じ過ちを繰り返してるな
222:デフォルトの名無しさん
23/04/17 10:42:37.51 kmcXsww3.net
>>208
>エラー指摘方法と解説の丁寧さは
言いたいことは判るが
提示された修正案がぴったり嵌った時はナイスと思えるが
逆のパターンもあるよね？
223:デフォルトの名無しさん
23/04/17 10:46:09.44 L5GaKQYU.net
>>213
それもC++でメモリ安全バグそしてセキュリティホールを産んできた一因
C++でも所有権の理解とスマポ利用は避けることができない
URLﾘﾝｸ(xtech.nikkei.com)
> (途中略)
> グーグルによればAndroidに存在した深刻なセキュリティー脆弱性の70％近くがメモリー安全に関するバグに起因するという。
> 同様にマイクロソフトも、同社製品に存在したセキュリティー脆弱性の70％がメモリー安全に関するバグに起因すると述べている。
> C/C++を使う限りセキュリティー脆弱性を根絶するのは不可能と考えて、Rustを採用するに至ったというわけだ。
224:デフォルトの名無しさん
23/04/17 11:13:07.86 vkHU804p.net
>>215
それどうやって呼び出すつもり？
マクロが展開されるタイミングを考えなよ
225:デフォルトの名無しさん
23/04/17 11:17:37.21 IM/7VFpy.net
ほんと低次元
小学校低学年のけんか
226:デフォルトの名無しさん
23/04/17 11:52:45.49 kmcXsww3.net
>>221
解決しました
ほんとうにありがとうございました
227:デフォルトの名無しさん
23/04/17 12:02:11.37 Dh5lk+HW.net
いつまでたっても安定化しないBtrfsを先にRustで完全実装してみせるくらいの実績を出してみやがれってんだ
228:デフォルトの名無しさん
23/04/17 15:31:33.55 GdiItcWS.net
質問です
例えば画像データの上下反転をしたい場合
let ppix: *mut std::ffi::c_void = im.pixels;
const W: usize = 640;
const H: usize = 480;
const D: usize = 24;
let q = ppix as *mut [[u8; W * D / 8]; H];
for j in 0..h/2 {
let t: [u8; W * D / 8] = (*q)[(h - 1 - j) as usize];
(*q)[(h - 1 - j) as usize] = (*q)[j as usize];
(*q)[j as usize] = t;
}
で実際に可能だったのですが W, H, D を固定にしたくなくて(続く)
229:デフォルトの名無しさん
23/04/17 15:32:27.02 TZ1fhzdQ.net
ファイルシステムのようなクリティカルな用途で使うわけないだろ
230:デフォルトの名無しさん
23/04/17 15:36:19.73 GdiItcWS.net
let ppix: *mut std::ffi::c_void = im.pixels;
let pitch: usize = im.pitch as usize; // im.pitch: std::ffi::c_int (値はほぼ3)
for j in 0..h/2 {
let a: usize = j as usize * pitch;
let p: *mut u8 = (ppix as usize + a) as *mut u8;
let b: usize = (h - 1 - j) as usize * pitch;
let q: *mut u8 = (ppix as usize + b) as *mut u8;
let mut btm = std::slice::from_raw_parts_mut(p, pitch);
let mut top = std::slice::from_raw_parts_mut(q, pitch);
let mut t: Vec<u8> = vec![0u8; pitch];
t.copy_from_slice(top);
top.copy_from_slice(btm);
btm.copy_from_slice(&t);
}
の様に書き換えて h は可変 w と d は pitch に置き換えで
こちらも動作はするのですがコードが冗長になってしまっています
後者をもう少しすっきりさせたいのですがどんなやり方が考えられますか？
231:デフォルトの名無しさん
23/04/17 15:45:58.71 uD1jGkf7.net
なんでレスバスレで質問してんの？
232:デフォルトの名無しさん
23/04/17 15:56:57.46 jycfg89f.net
>>220
お前がC++の知識が全く無いことが分かった
批判をするなら勉強しなさい
233:デフォルトの名無しさん
23/04/17 16:18:46.99 Q4jLO7Eu.net
>>225
ちゃんと動くかは分からん
chunks_exact_mut, rchunks_exact_mutの仕様だとhが奇数でも問題ないはず
fn main() {
let mut ppix = vec![0u8; 640 * 480 * 24];
let pitch = 640 * 24;
let h = 480;
// ↓この辺から参考に
let (top, bottom) = ppix.split_at_mut(pitch * h / 2);
for (top_chunk, bottom_chunk) in top
.chunks_exact_mut(pitch)
.zip(bottom.rchunks_exact_mut(pitch))
{
top_chunk.swap_with_slice(bottom_chunk);
}
}
234:デフォルトの名無しさん
23/04/17 16:23:53.42 HKDHATFA.net
>>228
レスバはレスバしたい奴に任せてほっとこうぜ
結局Rustも使うC++erが参考になる質問なら見学しとくから
でも質問スレとかないんかな
235:デフォルトの名無しさん
23/04/17 16:28:57.08 ToGc2WrC.net
>>229
安全にするために「C++でも所有権の理解とスマポ利用は避けることができない」で合っとるやろ
まさか自分で管理してdeleteすればいいから不要と言い出すんじゃないだろうな
236:デフォルトの名無しさん
23/04/17 16:45:26.70 lV//RKk9.net
let ppix: *mut std::ffi::c_void = im.pixels;
let pitch: usize = im.pitch as usize;
for j in 0..h/2 {
let a = j * pitch;
let p: *mut u8 = (ppix as usize + a) as *mut u8;
let b = (h - 1 - j) * pitch;
let q: *mut u8 = (ppix as usize + b) as *mut u8;
let btm = std::slice::from_raw_parts_mut(p, pitch);
let top = std::slice::from_raw_parts_mut(q, pitch);
for k in 0..pitch {
std::mem::swap(&mut btm[k], &mut top[k]);
}
}
237:デフォルトの名無しさん
23/04/17 17:12:38.63 KX4+3zuW.net
>>230
let len: usize = h as usize * pitch;
let (top, bottom) = std::slice::from_raw_parts_mut(ppix, len).split_at_mut(len / 2);
で動作しましたありがとう
238:デフォルトの名無しさん
23/04/17 18:39:30.36 PUaqCjxF.net
数学とは
実験データに基づかない証明ばかりしているくせになぜか正しい
現実の影響を受けにくい
前例がなければ何もしなかったのに
実例を見るとついつい行動してしまう模倣犯みたいな感じになりにくい
239:デフォルトの名無しさん
23/04/17 19:11:10.94 RKcegE7f.net
>>208
Rustc の指示通りに修正すると余計にエラーが増えて
状況が悪化して散々振り回されて時間を無駄にする
結局指示と違う修正ですっきり治ることも多い
240:デフォルトの名無しさん
23/04/17 19:14:33.38 RKcegE7f.net
時々的外れな事言ってくるのも ChatGPT と良い勝負
241:デフォルトの名無しさん
23/04/17 19:19:30.04 rguxj2m5.net
最初に&mut [u8]スライスを作るところだけffiサイドに分離しておくのがよいね
>>236
どういう不備があるかの本質をエラーメッセージはまず示してくれている
その補助としてコンパイラが一案を示してくれているから自分の望む案でなくてもエラーの理解に助かる
時間の節約にこそなれど無駄にすることはない
もし�
242:條ﾔを無駄にしているなら本質を無視しているバカさを自白してるようなもの
243:デフォルトの名無しさん
23/04/17 20:41:01.82 DvspYu3R.net
時間を無駄にしたのが本人とは限らんだろ
244:デフォルトの名無しさん
23/04/17 21:07:11.98 jycfg89f.net
>>232
もし>>213に>>220とレスを返すのを肯定するとしたら
お前もC++の知識が文字通り皆無なのだと分かる
class Hoge {
public:
void *operator new (size_t p) = delete;
};
245:デフォルトの名無しさん
23/04/18 04:15:46.41 iA5+Rtnt.net
>>212 >>216
unsafe で隠蔽してるだけで
Java の Exception みたいに上位にも伝播する訳でもないのに
全体としては安全が確保されてるとか
夢観過ぎ自己満でしかない
問題先送りどころか隠蔽体質
246:デフォルトの名無しさん
23/04/18 04:46:00.70 hIfvNlZE.net
握り潰しの握りっ屁でも臭わないのがRustの美学
247:デフォルトの名無しさん
23/04/18 06:13:08.68 MLRxBRH/.net
>>241
全くの逆
むしろ例えば生ポインタによる読み書きアクセスがunsafeなように一番下はunsafeに行き着く
しかし例えばある条件を伴ってそのメモリ領域が確保された安全なアクセスであると保証できる状況を満たす場合は
そのアクセス関数をsafeなインタフェースとして提供できる
大雑把な違いは以下
【C++の場合】
プログラム全体にunsafeが散らばっていてプログラム全体がunsafe
つまり人間がプログラム全体に対してその安全性を保証しなければならない
【Rustの場合】
safeなインタフェースの中にunsafeが閉じ込められている
その閉じ込める部分に対してのみ人間が安全性を保証しなけれはならない
プログラム全体の安全性はコンパイラが保証できる仕組み
例えばC++の場合は生ポインタでなく参照を使っている場合でもダングリング発生の危険があるのに対して
Rustの参照はライフタイムが管理されてダングリングが発生しないとともにデータ競合防止アクセスも保証される
さらに他のスレッドと共有できるか否かも含めて型付けと静的型チェックによりコンパイル時に安全性を保証できる言語仕様となっている
248:デフォルトの名無しさん
23/04/18 07:00:27.77 DviFuO26.net
OOP的な隠蔽だろ?
まあ俺のは素人が書いてるコードだし、自己満と言われようと構わんがなｗ
そして、そういう用途・運用もあるんだ
ガチプロばっかりが、PC・マイコン使ってない
249:デフォルトの名無しさん
23/04/18 08:26:30.53 Dh7Xhf9O.net
気軽に聞かせて
unsafeが残っていながら なにが安全じゃ! っていう反駁をちょくちょく見るけど、
unsafeが要らないようなプロセッサってほんとに作れないもんかな
絵空事じゃないぞ、FPGAにオレオレ プロセッサって起こせるようになったらしいし
RustBeltに載ってるのかな(読破はできてない
250:デフォルトの名無しさん
23/04/18 09:15:43.87 NALS/zAj.net
そろそろ貼っとくか
safeでもメモリはぶっ壊せる
URLﾘﾝｸ(speakerdeck.com)
251:デフォルトの名無しさん
23/04/18 09:50:26.33 tfRpsuLy.net
相関関係ではなく因果関係を立証できる者だけが
safeでも原因になれることを立証できる
252:デフォルトの名無しさん
23/04/18 10:16:01.43 sxhvE7iU.net
>FPGAにオレオレ プロセッサって起こせる
何十年も前から可能だったよ
っていうか原理的に出来て当たり前だし
「実用的な」って意味ならまあ色んな考え方もあるだろうが
253:デフォルトの名無しさん
23/04/18 10:27:05.42 PTyVVN9Y.net
限りある脳のリソースをどこに使うかという極々当たり前のことだろ
それすらわからないようなやつがまともにプログラミングできる訳がないんだから何を言っても時間の無駄だよ
254:デフォルトの名無しさん
23/04/18 10:31:04.41 Dh7Xhf9O.net
まともじゃないヤツをプログラミングから排除するのがsafeか
こりゃこまったなｗｗ
255:デフォルトの名無しさん
23/04/18 10:43:23.90 tfRpsuLy.net
人を説き伏せる目的で言うのは時間の無駄だけど自分が言いたいことを言うのはいいんだよ
256:デフォルトの名無しさん
23/04/18 11:43:26.04 rPAFEI4Z.net
なるほど
言いたいことを言う場がない人たちだから
こんなところで承認欲求剥き出しの長文書くのか
257:デフォルトの名無しさん
23/04/18 12:02:59.09 Dh7Xhf9O.net
試金石と思ってるところはあるな 大間違いならツッコミがあるし
自分も、まあそうかな、くらいなら、いちいち「そうだそうだ」って書かないしね
258:デフォルトの名無しさん
23/04/18 12:20:54.75 NALS/zAj.net
>>236
経験的にだけど、ライフタイム関連のヒントは真に受けない方がいい気がするな
多分、構造体や関数の定義側のライフタイムが意図通りにできていない場合に、そっちを直せというヒントを出せないのだと思う
定義を正としてそこから導出されるライフタイムや境界をひたすら書けと言うだけ
そんなヒントにハイハイと従ってるとそこら中ライフタイムパラメータまみれにされた挙げ句、最終的にlifetime conflictで二進も三進もいかなくなったことがある
結局その件はある関数の引数に2個ある参照のライフタイムパラメータの省略をやめて'a,'bに分けるだけでよかった記憶
あと'aで受け取りたいのに「'staticにすることを検討してください」とかもよく見る役立たずヒント
259:デフォルトの名無しさん
23/04/18 13:25:41.34 tfRpsuLy.net
グローバル変数をやめろと指示された → ヒープを使った → メモリが壊れた
という長期的な流れもあるので
'staticを検討することは指示を信じているとも言えるし、最初の指示を全力で疑っているとも言える
260:デフォルトの名無しさん
23/04/18 19:54:50.00 +ox+01C9.net
>>254-255
ほんそれ
261:デフォルトの名無しさん
23/04/18 20:52
262::44.33 ID:qWAcGwU9.net
263:デフォルトの名無しさん
23/04/18 22:19:21.28 NALS/zAj.net
いやーすんませんねバカで
実際ライフタイム系エラーメッセージって他のエラーに比してかなり分かりづらいと思うんだけど、読み方のコツとかあったら教えてくれませんかね？
264:デフォルトの名無しさん
23/04/18 22:56:45.81 1GQDyAx6.net
OOP言語のクラスと同じ感覚で構造体のフィールド組むとライフタイムのトラブルに嵌る気がする
Rustの構造体は一緒に使うデータというより一緒に捨てるデータのイメージだから
ライフタイム無しの構造体：データベースのテーブルのレコード
ライフタイム有りの構造体：↑を参照するビューのレコード
みたいな設計を意識するといいかも（RDBほど正規化を気にする必要はない）
こうするとビューが参照するテーブルごとにライフタイムパラメータが存在する形になる
あくまで個人の考え方というか経験論だから参考程度に
265:デフォルトの名無しさん
23/04/19 00:20:32.62 s8p2Q+oA.net
教師ありでも教師なしでも遅かれ早かれ同じ道を通りそうな方向に行く
教師ありの場合にしか通らない所で過学習しない
266:デフォルトの名無しさん
23/04/19 00:45:23.08 d1nAuXLd.net
>>259
スクリプト言語から来たんだけど
これまでなんでも連想配列に突っ込んでいたのが
実はアクセス毎にハッシュ値を計算して、ハッシュテーブルの衝突比較をして、ようやくたどり着くのを実感しちゃった
基本的にVecで持っていて、テーブルを引かなければならない時だけ使うHashMapを持つのがいいのかな
267:デフォルトの名無しさん
23/04/19 09:43:31.13 4c9fSoSa.net
>>246
狙ってできるということは、ぼーっとしてると踏むかもしれないってことだよな?
ライフタイムは銀の弾丸だ! みたいに、お題目のように言ってくるコピペへの反論として、
ちゃんと書かなきゃいけない、の主戦場がライフタイムの記述に移っただけじゃんってことでおっけー?
うんでも、template<> に近い感覚を覚えた、親しみを覚えたかな
はやくC++にも来ればいいのに
268:デフォルトの名無しさん
23/04/19 10:00:52.83 oanEffOH.net
普通に使われない書き方を恣意的に作らないと起きないため
実害なしとして放置となっている
269:デフォルトの名無しさん
23/04/19 10:08:03.97 4c9fSoSa.net
別にいいよ、放置で
でもそれを、(コピペ勢がいうような)安全っては言わない
俺は正確に、どう安全か知って使いたいんだ
C++だって、「そんな書き方すんなよ」ってのを踏むヤツが後を絶たない
だから、「書きようが悪いだけ」なんて反論が出るわけだ
270:デフォルトの名無しさん
23/04/19 10:31:19.03 vWGdqQhB.net
C++は初心者が自然に間違えて踏んでしまう
慣れているプロですら複雑化したときには間違えて陥ってしまう
そして現実に何度も何度も何度もプロたちがミスってきたからMicrosoftやGoogleなどIT大手も匙を投げ始めた
そのRustの件は初心者が間違えて踏んでしまうことは決してなく
慣れているプロが複雑化したときもそんな状況に陥ることはない
強引に恣意的にそれを目指して作り出さないと生じない
271:デフォルトの名無しさん
23/04/19 10:35:26.97 4c9fSoSa.net
> 初心者が間違えて踏んでしまうことは決してなく
ここだねえ 穴があったら、落ちるもんなんだよ
そこんとこは、コピペ勢に証明してもらうとするわ
俺が気に入らないのはコピペ勢だ、あいつら俺の母語を侮辱するからね
272:デフォルトの名無しさん
23/04/19 11:03:31.64 Y2fuF+9L.net
現状追認主義ここに極まれり
もはや信者以外の何者でもない
273:デフォルトの名無しさん
23/04/19 11:04:59.07 mEvWDtbQ.net
ソースコードで示してって言うと
理解しないままの受け売りなのですぐにボロが出る
ChatGPTの流行をマジで危惧してるよ
274:デフォルトの名無しさん
23/04/19 11:57:16.55 01eJvfIU.net
>>266
初心者が誤ってunsafe宣言するかな？
275:デフォルトの名無しさん
23/04/19 12:07:36.70 4c9fSoSa.net
そうじゃないけど、それもあるな
ちゃんと規制しないと、unsafe 使いまくられたら一緒じゃんｗｗって反論もできるな
276:デフォルトの名無しさん
23/04/19 14:59:19.03 4c9fSoSa.net
思わぬところに反論しときたいんだが
>>265
> 何度も何度も何度もプロたちがミスってきた
ここはちょっと要検証じゃね たとえば、Chromium/Chromeは精鋭だけで書かれたのか
ガチプロはそんなミスしないんだよ、ガチプロはスマポを使いこなすし、静的解析に通るように綺麗に書く
だから、「馬鹿にするな、C++が悪いんじゃない、悪い奴が悪いんだ」って反論も出る
C++はプロじゃない人間も使う、例えば俺 だから、C++にもunsafe{ } が必要なんだ
些細なようだが、ちゃんとしてるプロをバカにすることはない
敬意を払うのは人の為ならず(自分のため)
277:デフォルトの名無しさん
23/04/19 16:01:07.64 mEvWDtbQ.net
>>271
>ガチプロはそんなミスしないんだよ、ガチプロはスマポを使いこなすし、
使いこなすって表現するほどスマートポインタは御大層なものではない
そもそもmake_uniquやmake_sharedするのは
俺の場合は全インスタンスの1割弱だよ（newは一切無い）
operator newを呼ばずにインスタンスを作るのが9割超
278:デフォルトの名無しさん
23/04/19 16:53:43.84 ZJsXKDj1.net
>>264
>C++だって、「そんな書き方すんなよ」ってのを踏むヤツが後を絶たない
これな
前にも誰か言ってたが vector にぶっこんだデータを参照するときに
再配置が起きると参照先が無くなって困るとか
そりゃ再配置が起きるような書き方してる方が悪いんだよ
279:デフォルトの名無しさん
23/04/19 18:49:07.48 s8p2Q+oA.net
よくわからんが、プログラマーはlifetimeのパラメーターを明示的に実体化できないんだよね
人間の代わりにコンパイラが暗黙に自動的に実体化する
なんで人間が何か踏んだとか人間が穴に落ちたみたいに言われてるんだ？
280:デフォルトの名無しさん
23/04/19 19:51:56.67 ckDmN3Ij.net
コンパイラが調整する余白部分はあるけど包含関係を明示する程度にはプログラマが指定できる
ライフタイムは
「関数内のローカル変数の参照を関数の外にreturnしても受け取った側では使えなくなってる」
みたいなC++でも一般的なルールを概念的に表してるだけだよ
関数じゃなくブロック単位でスタックを伸縮させるコード生成があるかは知らないけど
ライフタイムはスタックのどの辺にそのデータ（の根拠）が置かれているかにおよそ対応してて
スタックの先端の方ほどライフタイムは短くなるし根元に近いほどライフタイムは長くなる
参照値の場所より根元の方を参照する分にはとりあえず安全だけど参照値より先端の方を参照してると
知らないうちに処理が進んでスタックが短縮されて参照先が無効になるかもしれない
そういう参照エラーをコンパイラで排除するためにライフタイムが使われてる
参照先は参照元より根元に近い（長生きする）ことが保証されてる範囲でしか認めない感じかな
実際は参照値もデータもスタック上で引っ越したりするし
被参照中はそのデータが動かせなくなるみたいな別のルールもあるからややこしいけど
281:デフォルトの名無しさん
23/04/20 00:49:58.65 9yNISOE6.net
Rustについて教えてちょ
以下はsizeが実行時に与えられるので
vについてアクセス違反を起こしていないかコンパイル時には
チェックできないと思うのだけどRustで書くとどうなるのかな?
#include <iostream>
#include <vector>
using namespace std;
int main () {
vector <int> v {1, 2, 3};
size_t size;
cin >> size;
if (v.size () < size)
{
cerr << "The specified number must be less than or equal to " << v.size () << ".\n";
return -1;
}
for (size_t i {0}; i < size; ++ i)
cout << v [i] << '\n';
return 0;
}
282:デフォルトの名無しさん
23/04/20 00:51:46.92 iAIcEMT7.net
そ、そんなに言うんだったら、お、俺もRust始めてみるよ
283:デフォルトの名無しさん
23/04/20 01:16:01.15 GPVFd3S9.net
>>276
Rustは基本bound checkがされるからそれっぽいコードだと実行時にパニックで落ちる
bound checkも避けて落ちないようにするならイテレータをtake(size)する
284:デフォルトの名無しさん
23/04/20 01:19:28.98 GPVFd3S9.net
他言語なら0..min(v.len(), size)とかもあるだろうけどRustではあんまりやらないと思う
285:デフォルトの名無しさん
23/04/20 01:22:50.03 9yNISOE6.net
Rustにはindexでアクセスするコンテナってやっぱないのかな?
286:デフォルトの名無しさん
23/04/20 01:24:33.22 9yNISOE6.net
>>278
>Rustは基本bound checkがされるからそれっぽいコードだと実行時にパニックで落ちる
あれ!? ということはコンパイルは通るの?
287:デフォルトの名無しさん
23/04/20 01:42:12.31 px2D1mrK.net
Rustでは普通こう書く
for n in v.iter().take(input_size) {
println!("{n}");
}
どうしてもインデックスでアクセスしたいなら
他の言語と同じく小さい方まで回す
let ok_size = min(v.len(), input_size);
for i in 0..ok_size {
let n = v[i];
println!("{n}");
}
288:デフォルトの名無しさん
23/04/20 01:54:59.31 px2D1mrK.net
あとはインデックスを使いminを使わないならばこうかな
for i in (0..v.len()).take_while(|&i| i < input_size) {
let n = v[i];
println!("n={n}");
}
3つとも同じ動作となるけど
簡潔かつインデックス不要な最初の方法がRustでは普通
289:デフォルトの名無しさん
23/04/20 01:56:51.02 9yNISOE6.net
>>282
ありがとう
最初のはinput_sizeがvの要素数よりデカかったらどうなるの?
290:デフォルトの名無しさん
23/04/20 01:59:04.25 9yNISOE6.net
>>282,283
3つともunsafeで囲まなくてもコンパイルは通るのでしょうか?
291:デフォルトの名無しさん
23/04/20 02:22:14.41 px2D1mrK.net
>>284
イテレータのtake(n)は最大n個になる
その前のv.iter()からv.len()個の参照が来る
だからnがv.len()より多くてもそれ以上ポインタは進まず安全
>>285
unsafeは必要ない
自分ですぐ試せるからここで何でもやってみればいい
URLﾘﾝｸ(play.rust-lang.org)
Rustで普通に使っていてunsafeは出て来ない
unsafeが出てくるのは例えば
FFIでC言語など別言語からの変換とか
既存ライブラリにない新たな仕組みの型を作り出すときに
unsafeを使わざるを得なくてunsafeを閉じ込めて安全なインタフェースを提供する場合
292:デフォルトの名無しさん
23/04/20 02:38:45.55 9yNISOE6.net
>>283
(0..v.len())でインデックスを作ってると思うのだけど
コンパイラはfor節の中でアクセスされるvのサイズと
インデックスの最大値の比較まで行ってるってことかぁ
293:デフォルトの名無しさん
23/04/20 02:54:57.60 px2D1mrK.net
>>287
例えば 0..10 は0から10未満つまり0から9までの数値を返すイテレータ
インデックスかどうかは関係ないし配列やVecとも無関係
非負数値だからたまたまインデックスとしても使えるというだけ
いずれにせよ配列やVecのシーケンシャルアクセスにインデックスを使うのは無駄なので
インデックスは使わずに>>282の前者を使おう
294:デフォルトの名無しさん
23/04/20 03:11:11.34 9yNISOE6.net
ボローチェッカの挙動を知りたいのだよ
以下だとコンパイルは通らないんだよね?
for i in (0..100).take_while(|&i| i < input_size) {
let n = v[i];
println!("n={n}");
}
295:デフォルトの名無しさん
23/04/20 05:14:11.17 px2D1mrK.net
コンパイルも通る
そこには借用(ボロー)つまり参照がないからボローチェッカーは無関係
厳密にはtake_whieは参照を取るが対象が整数値なのでコピーして比較していて無関係
let n = v[i]; も整数値のコピーなので無関係
ちなみにC以外ほとんどの言語と同様に v[i] は安全にインデックス範囲チェックが行われる
範囲チェックの結果を受け取りたいならばget()によりOptionを得ることもできる
例えばこれで安全にアクセスできる
if let Some(n) = v.get(i) {
println!("n={n}");
}
シーケンシャルアクセスならインデックスによるアクセスの必要性がないので
v.iter()を使い安全に各要素の参照を得ることができる
したがって>>282の前者が簡潔で可読性もよく安全で高速なRustでの普通の書き方
296:デフォルトの名無しさん
23/04/20 09:48:13.23 9yNISOE6.net
>>290
なるほど
>ちなみにC以外ほとんどの言語と同様に v[i] は安全にインデックス範囲チェックが行われる
C++でいうと以下のような感じなのかな?
for (size_t i {0}; i < input_size; ++ i)
cout << v.at (i) << '\n';
Rustはメモリアクセス違反を何でもかんでもコンパイルで弾けるわけじゃないのね
297:デフォルトの名無しさん
23/04/20 11:20:58.88 ViRjvm8y.net
アクセス違反が発生しても何となく動き続けることがなければとりあえずセーフの精神
unsafe内でuncheckにするオプションも用意されてることが多いけど
298:デフォルトの名無しさん
23/04/20 11:29:56.72 vzrku2iH.net
DoSにつながるから、落ちるのはよくないみたいに言われたりするんだけど、
変に無理に動き続けるより、異常を見つけたら落としたほうがいいときってあると思うんだよな
落ちるバグはコールスタック残ってればいち早く潰すだろうし
299:デフォルトの名無しさん
23/04/20 11:44:16.22 GPVFd3S9.net
バッファオーバーフローみたいな脆弱性につながるから落とすほうが安全なんだよ
300:デフォルトの名無しさん
23/04/20 11:48:21.96 SYxH5KMK.net
C/C++とは異なり、Rustは範囲外メモリアクセスを絶対に起こさないことが保証される点が決定的な違い
シーケンシャルアクセスでは、Rustではv.iter()とイテレータを使い、結果的に終端アドレスに達するまでポインタが進むのと同じ生成コードになるので、最高速かつ安全に範囲内のみのコードになる
そのうえで、v.iter().take(input_size)など様々な条件や加工などをするイテレータメソッドを複数組み合わせて、メソッドチェーンにより簡潔な記述をするのがRustでの書き方
301:デフォルトの名無しさん
23/04/20 13:05:49.56 9yNISOE6.net
>>295
ディフェンスラインが後退したな
STLのコンテナもatでアクセスすれば範囲外アクセスで例外を投げるので同じ
オーバーヘッドが気になるならoperator[]によるアクセスも
イテレータによるアクセスも選択できる
302:デフォルトの名無しさん
23/04/20 13:34:13.29 w/28tNmU.net
C/C++はポインタと配列の区別があやふやだ
まず配列という概念がない言語でポインタの問題だけを解決し
それから配列をたんなるライブラリとして追加するほうが無駄なトラブルが少ない
配列すらない状態に一旦後退するのは正しい
その意味では、ジェネリクスがない状態に後退できるC/C++を見習うべきだったとも言える
303:デフォルトの名無しさん
23/04/20 18:25:05.04 zqUq/1wh.net
>>296
違いはここ
・安全な言語： 範囲外アクセスをすることが絶対にない
・安全でない言語： 範囲外アクセスをしてしまう
CとC++は不合格
304:デフォルトの名無しさん
23/04/20 19:53:34.14 9yNISOE6.net
>>298
範囲外かどうかチェックのオーバーヘッドがあるのではないのかな?
C++はチェックありもなしも選択できるんだよ
305:デフォルトの名無しさん
23/04/20 20:48:09.87 D1KovJeq.net
Rustもインデックス範囲内チェックの有り無しを選べる
基本的にはインデックスは使われず、安全な範囲内に動くポインタのみを、自在に各種イテレータメソッドで扱うため、オーバーヘッドはゼロ
唯一の例外が真のランダムアクセスで、範囲内のインデックス値か不明なものを扱うため、インデックス毎に範囲内チェックは絶対に不可避なためコストがかかる
その場合でも、範囲内のインデックス値しか来ない構造ならば、新たな型をunsafeなget_unchecked()を用いてそれを閉じ込めて、安全なインターフェースとして提供できるため、オーバーヘッドはゼロ
306:デフォルトの名無しさん
23/04/20 21:12:04.09 8LRk4zHW.net
>>300
それC++と何が違うのかな?
307:デフォルトの名無しさん
23/04/20 21:17:13.53 B6QJskar.net
チェックを忘れて脆弱性を埋め込むリスクが桁違い
308:デフォルトの名無しさん
23/04/20 21:33:10.92 9yNISOE6.net
>>302
すまんが何が違うかを書いてくれないかな?
あるいは>>300が何を言わんとしているか
他の人の解説でもいいんだけど
309:デフォルトの名無しさん
23/04/20 21:38:15.36 iAIcEMT7.net
＞その場合でも、範囲内のインデックス値しか来ない構造ならば
この判断を誤ると結局脆弱性が埋め込まれそうだけど、
チェックを忘れることに比べれば起こりにくいのかもね
310:デフォルトの名無しさん
23/04/20 21:40:24.96 SYxH5KMK.net
>>301
オーバーヘッドに関してはC++もRustも最小限にすることができて同じ
安全性に関しては範囲外アクセスが生じうるC++のみ安全でない
311:デフォルトの名無しさん
23/04/20 21:40:47.43 9yNISOE6.net
私は違いがサッパリ分からんぞ
312:デフォルトの名無しさん
23/04/20 21:44:22.16 9yNISOE6.net
>>305
>安全性に関しては範囲外アクセスが生じうるC++のみ安全でない
範囲外チェックなしでインデックスでアクセスしたら
Rustも危険なのでは?
313:デフォルトの名無しさん
23/04/20 21:51:17.50 D1KovJeq.net
>>304 >>307
その場合は、一般的にunsafeを閉じ込めてsafeなインタフェースを提供する新たな型をモジュールとして提供する
そのモジュール部分のみを人間が安全性を保証する形になり、その利用者側はRustコンパイラが安全性を保証する
したがってそれを利用する側のプログラマーのミスで範囲外アクセスなどが起きることはない
314:デフォルトの名無しさん
23/04/20 21:56:16.00 9yNISOE6.net
>>308
今はそのunsafeに閉じ込める部分に
C++とRustで差があるのか無いのかを議論している
お分かりかな?
315:デフォルトの名無しさん
23/04/20 22:01:05.35 9yNISOE6.net
>>307
私はせっかちなので自分で議論を進めると（と言っても私はRustは分からんのだが）
範囲外チェックなしでインデックスでアクセスできる -> Rustも同様に危険
範囲外チェックなしでインデックスでアクセスできない -> Rustはオーバヘッドがある
ということになる
316:デフォルトの名無しさん
23/04/20 22:03:11.36 cejxbewD.net
複オジの説明がクソだから伝わらなくても仕方ない
317:デフォルトの名無しさん
23/04/20 22:06:37.25 9yNISOE6.net
>>295
>C/C++とは異なり、Rustは範囲外メモリアクセスを絶対に起こさないことが保証される点が決定的な違い
によると後者ってことになるが
>>300
>Rustもインデックス範囲内チェックの有り無しを選べる
によると前者ってことになる
矛盾しとる
どっちや?
318:デフォルトの名無しさん
23/04/20 22:18:01.10 FIsyFWOj.net
C++に勝ってると主張するために普段はunsafeのことを脇に置いてメリットばっかり語ってるのに
性能で負けてるって言われて悔しいからって急にget_uncheckedの話持ち出すからややこしいことになるんじゃな
319:デフォルトの名無しさん
23/04/20 22:26:58.01 dJqrvGvM.net
昔LISPもそれでCと張り合ってたな
歴史は繰り返すんやな
320:デフォルトの名無しさん
23/04/20 22:36:42.26 98y/hYCF.net
話は簡単
RustはVecもそこで使われるスライスのイテレータも
unsafeなコードを閉じ込めてsafeなメソッドを提供している
だからその部分の作成は人間がミスるとおしまい
逆に言えばその狭い範囲のみ人間が頑張って安全性を保証すればよい
一方でそれらVecやイテレータなどを利用する一般のプログラマーは
そのsafeなメソッドを使っている限り絶対に安全なことが保証される
もし問題があればコンパイラがエラーを出すので常に安全となる
結論
RustもC++も最小限のオーバーヘッドが可能で同じ
しかしその安全性は全く異なる
C++は常にミスったらおしまい
C++はプログラム全体に対して人間が安全性を保証しなければならない
Rustはsafe利用者がミスることは絶対になくコンパイラがエラーを出してくれる
Rustはunsafe利用部分のみ人間が安全性を保証しなければならない
321:デフォルトの名無しさん
23/04/20 22:42:39.55 9yNISOE6.net
>>315
一生懸命書いているところを申し訳ないが
>>276の話で始めたように今は
コンパイル時にチェックできない状況の話をしているんだ
322:デフォルトの名無しさん
23/04/20 22:43:11.74 98y/hYCF.net
>>313
そのunsafeなget_uncheckedの件も同じ
unsafeを利用してsafeを提供する人だけがその安全性の保証できるコードを書けばよい
一方でそこで作られたsafeなものを利用する一般プログラマーはミスってもコンパイラがエラーとして止めてくれる
323:デフォルトの名無しさん
23/04/20 22:44:27.28 9yNISOE6.net
>>98y/hYCF
>>312はどっちや?
324:デフォルトの名無しさん
23/04/20 22:44:35.26 98y/hYCF.net
>>316
Rustではコンパイル時に安全性を必ずチェックできる
325:デフォルトの名無しさん
23/04/20 22:48:29.32 9yNISOE6.net
>>319
実行時にサイズを入力するのにかい?
Rustコンパイラは未来が分かるのかw
326:デフォルトの名無しさん
23/04/20 22:49:34.33 98y/hYCF.net
>>318
どちらも正しい
効率的なunsafeを使いそれを閉じ込めることで効率的なsafeを提供することがRustの基本
一般プログラマーはそのsafeのみ使えば書いたコードの安全性が保証される
327:デフォルトの名無しさん
23/04/20 22:55:08.59 98y/hYCF.net
>>320
最初に出ているこのコードのことだろ
for n in v.iter().take(input_size) {
println!("{n}");
}
もちろんinput_sizeの値に関わらず静的に安全なコードだ
そしてインデックスは用いないのでインデックス範囲外チェックは無い
Cでポインタで書いたときと同じ速度になる
328:デフォルトの名無しさん
23/04/20 22:56:41.18 9yNISOE6.net
議論にならんのでスルーして
彼の主張は（正しいのかは分からんが）
要するに範囲外チェックなしでインデックスでアクセスできるということだから
Rustも同様にこの点は危険ということになる
329:デフォルトの名無しさん
23/04/20 23:00:30.54 9yNISOE6.net
>>322
今はRustでも危険に書けるでしょ?って話をしている
イテレータを使えば安全なのでこう書くべしっていうのなら
それはC++となんら変わらない
330:デフォルトの名無しさん
23/04/20 23:23:11.63 SYxH5KMK.net
>>323
Rustはチェックしないけど安全な型を作れるよ
例は何でもいいんだけど例えば将棋盤を表す型を9✕9＝81のインデックスを考えてみよう
その将棋盤の型に対するインデックスの型を新たに作ってメソッドとその操作を限定することでusize化した時に常に0～80の値しか取らない型を作る
あとは unsafeを使ってsafeかつ効率的な実装
impl std::ops::Index<将棋盤インデックス型> for 将棋盤 {
type Output = 将棋駒;
fn index(&self, index: 将棋盤インデックス型) {
unsafe { self.0. get_unchecked(index.to_usize()) }
}
}
これで将棋盤型のアクセス時にインデックスの範囲内チェックは行われずに効率的かつ安全
（将棋盤インデックス型の定義によりindex.to_usize()は常に0～80の値のみをとるため）
将棋の実装を実際にしたことはないが
似たようなデータ型は実際に何度か書いたことがある