Rust part12

[表示 : 全て最新50 1-99 101- 201- 301- 401- 501- 601- 701- 801- 901- 1001- 2ch.scのread.cgiへ]
Update time : 12/23 13:16 / Filesize : 283 KB / Number-of Response : 1022
[このスレッドの書き込みを削除する]
[＋板最近立ったスレ＆熱いスレ一覧 : ＋板最近立ったスレ／記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

Rust part12

1 名前：デフォルトの名無しさん mailto:sage [2021/08/24(火) 22:55:27.78 ID:972JwtmU.net]: 公式
https://www.rust-lang.org/
https://blog.rust-lang.org/
https://github.com/rust-lang/rust

Web上の実行環境
https://play.rust-lang.org

日本語の情報
https://rust-jp.rs/

※Rustを学びたい人はまず最初に公式のThe Bookを読むこと
https://doc.rust-lang.org/book/

※Rustのasyncについて知りたければ「async-book」は必読
https://rust-lang.github.io/async-book/

※C++との比較は専用スレへ
C++ vs Rust
https://mevius.5ch.net/test/read.cgi/tech/1619219089/

前スレ
Rust part11
https://mevius.5ch.net/test/read.cgi/tech/1623857052/
2 名前：デフォルトの名無しさん mailto:sage [2021/08/24(火) 22:59:11.03 ID:972JwtmU.net]: 次スレは>>980が立ててくださいな
3 名前：デフォルトの名無しさん mailto:sage [2021/08/24(火) 23:25:20.99 ID:ELplZZUg.net]: 980ですゴメンナサイお詫びに

Rust The Book (日本語版)
https://doc.rust-jp.rs/book-ja/
Rust edition guide (日本語版)
https://doc.rust-jp.rs/edition-guide/
Rust by example (日本語版)
https://doc.rust-jp.rs/rust-by-example-ja/
Rust cookbook (日本語版)
https://uma0317.github.io/rust-cookbook-ja/
Rust API guideline (日本語版)
https://sinkuu.github.io/api-guidelines/
Rust nomicon book (日本語版)
https://doc.rust-jp.rs/rust-nomicon-ja/
Rust WASM book (日本語版)
https://moshg.github.io/rustwasm-book-ja/
Rust embeded book (日本語版)
https://tomoyuki-nakabayashi.github.io/book/
Rust enbeded discovery (日本語版)
https://tomoyuki-nakabayashi.github.io/discovery/
4 名前：デフォルトの名無しさん mailto:sage [2021/08/24(火) 23:38:41.54 ID:dmSXpC2X.net]: Rust CLI (Command Line Interface) apps Book
https://rust-cli.github.io/book/
Rust async-std Book
https://book.async.rs/
Rust The Unstable Book
https://doc.rust-lang.org/nightly/unstable-book/
Rust rustc Book
https://doc.rust-lang.org/rustc/
Rust Cargo Book
https://doc.rust-lang.org/cargo/
5 名前：デフォルトの名無しさん [2021/08/25(水) 02:49:11.51 ID:NhkykFBw.net]: >>1
乙です。
6 名前：デフォルトの名無しさん mailto:sage [2021/08/25(水) 03:59:04.43 ID:4va1W6vx.net]: The Rust Reference
https://doc.rust-lang.org/reference/
The Rust Standard Library
https://doc.rust-lang.org/std/
7 名前：デフォルトの名無しさん mailto:sage [2021/08/25(水) 08:19:23.75 ID:o6V8MH2P.net]: 前スレで循環参照なんて初心者でもすぐ作れてしまうとの意見もあったけど
Rc型を使うだけの初心者には原理的に不可能
内部可変性を与えるRefCell型も併用しないと循環参照は作れない
一つの可変参照&mutか複数の不可変参照&のどちらかのみ許されるコンパイル時確認ルールを実行時確認ルールで行なうのがRefCell型
それにより明示的に可変参照を得ることで内部可変性を持てるようにしたもの
そしてRcと組み合わせてRc<RefCell<T>>を使うことで既にあるリンクを書き換え出来るようになりようやく循環参照を作れる
もちろん自分でunsafeすればやりたい放題てすがunsafeせずともメモリ安全性ルールの元に使えます
ここまで出来る人なら強参照Rcだけでなく弱参照Weakも併用できますから循環参照を避けることも出来るでしょう
8 名前：デフォルトの名無しさん mailto:sage [2021/08/25(水) 08:36:39.57 ID:cBrhi5Vz.net]: マーフィーの法則
失敗する余地があるなら、失敗する
9 名前：デフォルトの名無しさん mailto:sage [2021/08/25(水) 09:53:46.73 ID:wz3i5qam.net]: テンプレートがやたらたくさん入り乱れる言語は嫌いだわ
可読性めちゃくちゃ悪いよな
10 名前：デフォルトの名無しさん mailto:sage [2021/08/25(水) 10:40:52.46 ID:FDhW8k6p.net]: >>7
そこまでできてやっとRust初心者という見方もあるかもしれない
11 名前：デフォルトの名無しさん mailto:sage [2021/08/25(水) 11:24:43.65 ID:cB4G1Ahy.net]: 直接関係ないけど、RefCellは借用チェックが実行時段階でのチェックになって
しまうんだってな。
12 名前：デフォルトの名無しさん mailto:sage [2021/08/25(水) 11:34:25.36 ID:N5SObJek.net]: >>11
長文だから>>7をスルーしたな？
13 名前：デフォルトの名無しさん mailto:sage [2021/08/25(水) 11:41:16.58 ID:cB4G1Ahy.net]: RefCellの借用チェックが実行段階にまで持ち越されるのは、循環参照とは全く別の話。
それはつまり、「ゼロコスト」ではないということ。
14 名前：デフォルトの名無しさん mailto:sage [2021/08/25(水) 12:14:34.01 ID:CoZuOKep.net]: >>7
Rc<RefCell<T>>じゃなくてRefCell<Rc<T>>だね
気持ちはよく分かる
15 名前：デフォルトの名無しさん mailto:sage [2021/08/25(水) 12:30:44.27 ID:XsBK0uKE.net]: >>14
どっちもあるけど通常はRc<RefCell<T>>だよ
16 名前：デフォルトの名無しさん [2021/08/25(水) 13:42:20.13 ID:6n+Di1sM.net]: >>983
なるほどサンクス
リージョン理論に線形論理を上手く組み合わせて、cycloneとかの欠点を克服したrustってすげーなあ
とはいってもそもそも二重開放してエラーになるというのがピンとこない
free(a);
free(a);
は二重解放しているように見えて合法だろ？
一度目のfreeでaにNULLが代入されて、二度目のfreeでは引数がNULLの場合はそのままreturnって処理されるんだから、理論上は何度free使ってもエラーにならないじゃないか
17 名前：デフォルトの名無しさん [2021/08/25(水) 13:42:36.69 ID:6n+Di1sM.net]: これに答えろ
18 名前：デフォルトの名無しさん [2021/08/25(水) 14:22:27.47 ID:aLlQE3on.net]: >>16
なぜRustのスレに書いているのか不明だけど
当然NULLにならなかったよ

キャスト警告無視で
#include <stdlib.h>
main() {
　char *ptr = malloc(1024);
　printf("ptr(1): %x\n", ptr);
　free(ptr);
　printf("ptr(2): %x\n", ptr);
　free(ptr);
　printf("ptr(3): %x\n", ptr);
}

実行結果
ptr(1): ea8f72a0
ptr(2): ea8f72a0
free(): double free detected
core dump
19 名前：デフォルトの名無しさん mailto:sage [2021/08/25(水) 14:49:12.37 ID:FDhW8k6p.net]: >>11
静的にチェックできないような使い方を実現するためのものなんだから
実行時チェックになるのは当然では
オーバーヘッドが気になるなら UnsafeCell を使えばよい

>>16
C には参照はないので free(a) という呼び出しで a の値が書き換わることはなく malloc で獲得した領域のアドレスがそのまま残る
領域自体は free で解放済みになっているため、アクセス (free 呼び出し含む) した場合何が起きるか分からない
このような解放済みの領域へのアクセスは use-after-free と言われるもので、脆弱性の原因として有名
20 名前：デフォルトの名無しさん [2021/08/25(水) 14:50:41.52 ID:6n+Di1sM.net]: >>18
なるほど
free内で代入されるのではなく
自分で代入しないとNULLにはならないのですね。
ありがとうございました。
21 名前：デフォルトの名無しさん [2021/08/26(木) 04:09:52.45 ID:wR4WgiQO.net]: そういやNull代入派とかいうのもいたな
22 名前：デフォルトの名無しさん [2021/08/26(木) 07:18:01.38 ID:BSY6c8/C.net]: uaf防ぐのってぶっちゃけ簡単ですよね？freeしたあとにNULL代入するのを鉄則化するだけですよね？
23 名前：デフォルトの名無しさん mailto:sage [2021/08/26(木) 07:18:53.92 ID:tGDEA4MX.net]: ポインタコピーすることないの？
加減算することないの？
24 名前：デフォルトの名無しさん mailto:sage [2021/08/26(木) 07:42:26.49 ID:YoD5H0JF.net]: int* p1 = malloc(sizeof(int));
int* p2 = p1;
free(p1);
p1 = NULL;
free(p2);

極端に書くとこうかなあ？
25 名前：デフォルトの名無しさん mailto:sage [2021/08/26(木) 08:58:05.69 ID:yCq+tuyV.net]: >>22
1つのオブジェクトを複数のポインタで挿している場合にそういうわけにはいかない。
26 名前：デフォルトの名無しさん mailto:sage [2021/08/26(木) 09:21:56.64 ID:yCq+tuyV.net]: >>25
誤字訂正: 挿して ---> 指して
27 名前：デフォルトの名無しさん [2021/08/26(木) 14:46:24.90 ID:BSY6c8/C.net]: >>25
複数のポインタにそれぞれNULL代入したらいいだけの話ですよね？
難しい話ですか？
28 名前：デフォルトの名無しさん [2021/08/26(木) 14:52:56.47 ID:BSY6c8/C.net]: >>23
加減算考慮するとなんかやばいんですか？
本当に素人なので教えてください！！
29 名前：デフォルトの名無しさん [2021/08/26(木) 14:53:33.93 ID:BSY6c8/C.net]: >>24
p2=NULL;すればいいだけの話ですよね？
30 名前：デフォルトの名無しさん mailto:sage [2021/08/26(木) 14:54:04.18 ID:ILFADcfC.net]: Cスレでやれよ
31 名前：デフォルトの名無しさん mailto:sage [2021/08/26(木) 14:55:34.47 ID:s9ncfwmd.net]: >>27
効率が落ちる。
32 名前：デフォルトの名無しさん mailto:sage [2021/08/26(木) 15:01:32.05 ID:jqKFKJA4.net]: >>27
プログラミングをしたことがなく
頭の中での思考実験もできないのか
プログラマーに向いていない
33 名前：デフォルトの名無しさん mailto:sage [2021/08/26(木) 15:04:39.60 ID:s9ncfwmd.net]: 手で書くと効率は落ちないが、実行段階で自動的に NULL を入れようとすると
効率が落ちるという意味ね。時間とメモリーの両方で。
NULLが入っているか判定して error にするなどの処理も必要となったりする。
34 名前：デフォルトの名無しさん mailto:sage [2021/08/26(木) 15:06:19.25 ID:VJ7dcvV2.net]: >>27
難しいです…
35 名前：デフォルトの名無しさん [2021/08/26(木) 15:11:05.26 ID:BSY6c8/C.net]: >>32
すみません。
おっしゃるとおりかも知れないです。。
36 名前：デフォルトの名無しさん [2021/08/26(木) 15:12:24.56 ID:BSY6c8/C.net]: >>31
>>33
そんなに効率が落ちますか？
37 名前：デフォルトの名無しさん mailto:sage [2021/08/26(木) 15:18:41.61 ID:s9ncfwmd.net]: >>36
凄く落ちるわけではないが。
38 名前：デフォルトの名無しさん mailto:sage [2021/08/26(木) 15:21:09.64 ID:s9ncfwmd.net]: >>36
参照カウンタ方式は、自動的に関連するポインタを巡ってNULLを入れるよりは
効率が良いのでプログラマーの裁量で選択できるようになっている。
しかし、それでも僅かに効率が落ちるのでなるべく使わないでプログラムする
方が良いと思うプログラマーが多いということだよ。
39 名前：デフォルトの名無しさん mailto:sage [2021/08/26(木) 15:24:37.81 ID:bKmDdfbf.net]: プログラマーならば、まず思考実験、それで解決しなければコーディング
その上で問題点を尋ねる
それをしない人はプログラマーではないから、このスレの邪魔
40 名前：デフォルトの名無しさん [2021/08/26(木) 15:24:45.61 ID:BSY6c8/C.net]: >>38
そんな僅かな効率の低下でも忌避されるんですね！！
わかりました！！
41 名前：デフォルトの名無しさん [2021/08/26(木) 15:25:39.02 ID:BSY6c8/C.net]: >>39
こわい。。
42 名前：デフォルトの名無しさん mailto:sage [2021/08/26(木) 15:25:45.57 ID:s9ncfwmd.net]: 手作業で書く場合は、1つのオブジェクトを削除する場合、それを参照する
全てのポインタに NULL を入れるのは効率が良い。だから、多くのC/C++
プログラマはかつてそうしてきたし、今でもそうすることも多い。
ところが自動でそれをやるには静的解析は難しいので実行段階でも
余計なメモリーを追加で消費して行うことになる。それが効率が悪い。
そして、NULLが入っているかどうか分からないのでその参照を
使う場合には、いつも最初にNULLが入ってないことを確認してから
作業をする必要があり、その判定に 2 クロックくらいかかる。
この2クロックが忌避される。
43 名前：デフォルトの名無しさん [2021/08/26(木) 15:26:04.39 ID:pXAeL9Oq.net]: >>7
言ってる事はかねがね同意ですが、プログラムが共同作業の為にRefCell<Rc<List>>とA氏が定義してあるものに
違う人B氏が何も考えずにRc::clone(&a)で循環を入れてしまう事は十分あり得るでしょう。
状況次第ですが循環参照を考慮してないA氏が悪いのか、Rc::clone(&a)でぶち込んだ人が悪いのかは要件次第ですが
これを簡単と言わずに（あなたは言っていませんが）難しいと表現するのは違和感がありますよ
44 名前：デフォルトの名無しさん [2021/08/26(木) 15:28:09.24 ID:BSY6c8/C.net]: >>42
詳しい解説ありがとうございますm(_ _)m
メモさせていただきます。
45 名前：デフォルトの名無しさん mailto:sage [2021/08/26(木) 15:28:30.66 ID:uyKM6LSq.net]: >>37
嘘を教えたらあかんやろ
N人の人が自分を指しているとして
まずそのN人をどうやって知る？
46 名前：デフォルトの名無しさん [2021/08/26(木) 15:29:12.92 ID:BSY6c8/C.net]: >>45
自力で数えればいいんではないでしょうか？
47 名前：デフォルトの名無しさん mailto:sage [2021/08/26(木) 15:30:36.47 ID:s9ncfwmd.net]: >>40
まあ、そういうこと。
というのは、参照カウンタも、1つのヒープノードに対して必ず1つ必要になるので、
ノード数が多いときには膨大なメモリーの無駄になるから。
それとノード数が多いときに参照カウンタを 0 クリアしたり、1足したり
する作業も馬鹿にならないと考えるプログラマが多い。

なぜかというと、そういう自動化を行わなくても、人が頭で考えて手作業で
NULLを入れても十分に安全にプログラムできるプログラマが多かったからだよ、
少なくとも昔のCプログラマには。
手作業でやってもとくに危険を感じないので、効率を落としてまで自動化する
必要が無いと思われている。
手作業でNULLを入れるのは難しくない。
ところが、コンパイラが自動で効率を落とさずにそれをやるのはめちゃくちゃ難しい。
それは人間の脳がそれだけ優秀だということだよ。
48 名前：デフォルトの名無しさん mailto:sage [2021/08/26(木) 15:31:47.17 ID:s9ncfwmd.net]: >>45
手作業で人間が頭で考えたら、難しく感じないプログラマが多かった、という
ことだよ。
難しく感じるプログラマも居る。
数学の才能だと思う。
49 名前：デフォルトの名無しさん mailto:sage [2021/08/26(木) 15:32:40.17 ID:GoG5gW1P.net]: コピーしたポインタを別スレッドに転送とかしてたら、いつNULL代入すべきかすら分からんしなぁ
50 名前：デフォルトの名無しさん mailto:sage [2021/08/26(木) 15:32:44.57 ID:s9ncfwmd.net]: >>48
ああ、自動化の効率面の話か。
凄く効率が落ちるわけではないよ。
リンクで辿るだけだから。
51 名前：デフォルトの名無しさん mailto:sage [2021/08/26(木) 15:42:17.45 ID:Nkfv2brF.net]: >>47
違うだろ
ある時点でNヶ所から指されているとして
そのNヶ所をどうやって知る？誰がどのようにNヶ所を管理する？
52 名前：デフォルトの名無しさん [2021/08/26(木) 15:43:01.48 ID:BSY6c8/C.net]: >>51
僕がです。
53 名前：デフォルトの名無しさん mailto:sage [2021/08/26(木) 15:46:08.68 ID:s9ncfwmd.net]: >>51
静的解析はコンパイラには難しいが、動的なら簡単。
人間にも、「一般性を持って」は分かる方法は無い。
54 名前：デフォルトの名無しさん mailto:sage [2021/08/26(木) 15:47:35.53 ID:s9ncfwmd.net]: 言っておくが現実世界では俺は天才だと言われているから、俺が簡単だと
思うことは、大部分のプログラマには難しいと思うかもしれないがな。
55 名前：デフォルトの名無しさん mailto:sage [2021/08/26(木) 15:48:12.84 ID:fifffju2.net]: >>52
データ構造は入出力の変化に伴いどんどん変化していく可能性がありますから人間は覚え追いきれないよね
さらに一つのmalloc毎にそれぞれそこをポイントしている利用者の数も利用者数も異なりますよね
それらのデータをどこでどうやって管理するつもりですか？
56 名前：デフォルトの名無しさん [2021/08/26(木) 15:54:12.28 ID:BSY6c8/C.net]: まず前提が誤りです
変化を追えば覚えられます
思考実験できないんですか？
57 名前：デフォルトの名無しさん mailto:sage [2021/08/26(木) 16:04:38.88 ID:xjpSGKrK.net]: >>56
利用者リストを覚えておくためにメモリが必要やね
それもmallocするか
mallocで取ってきたメモリ管理のために更にmallocが必要となってしまったぞ
利用者が増えてきたら利用者リストの領域が足りなくなる
またmallocするか
全てにNULLを入れるためだけに大がかりになってきたな
この方法は本当に大丈夫なのか？
58 名前：デフォルトの名無しさん [2021/08/26(木) 16:08:02.62 ID:BSY6c8/C.net]: >>57
静的に確認すればすむ話です
59 名前：デフォルトの名無しさん mailto:sage [2021/08/26(木) 16:17:15.72 ID:5iULk00o.net]: データが育っていったら100か所からリンクされるとか普通によくあるわけだが
その100か所にNULLを代入しにいくために100か所の場所をリストで持つのか
しかもmallocした各データ毎にリストを持つのか
全てにNULL代入はあきらめた方がいいんじゃね？
60 名前：デフォルトの名無しさん mailto:sage [2021/08/26(木) 16:20:01.23 ID:4xBLfuks.net]: アクセスするとたちまち例外発生するぬるぽにはどんなデータが格納されているのだろうか
61 名前：デフォルトの名無しさん mailto:sage [2021/08/26(木) 16:23:55.37 ID:YoD5H0JF.net]: int* p1 = malloc(sizeof(int));
int* p2 = malloc(sizeof(int));
int* p3;
if (なんかの条件) p3 = p1; else p3 = p2;
free(p1);
p1 = NULL;
// p2はまだまだ使う

こういうときp3はどうするのかっていう
62 名前：デフォルトの名無しさん mailto:sage [2021/08/26(木) 16:28:43.55 ID:HI0uJlB9.net]: すべてのヒープを**ptrで管理すればできなくもない気がする
参照するたびに有効かチェックしないといけないから激しく面倒だけど
63 名前：デフォルトの名無しさん [2021/08/26(木) 16:29:37.04 ID:BSY6c8/C.net]: >>61
なるほど
参考になります
回答してくださってありがとうございました。
64 名前：デフォルトの名無しさん mailto:sage [2021/08/26(木) 16:32:51.02 ID:+fzqgCTs.net]: >>62
その**ptrの格納領域の確保がデータ事に発生
しかも伸長してしまいますね
65 名前：デフォルトの名無しさん mailto:sage [2021/08/26(木) 16:33:25.33 ID:W3uKoL9G.net]: 何の参考だよ
66 名前：デフォルトの名無しさん mailto:sage [2021/08/26(木) 16:36:08.26 ID:YoD5H0JF.net]: https://twitter.com/cpp_akira/status/1430779310885859330
最近はC++の発表資料を公開すると「Rustでいいじゃん」というコメントがたくさんつくのか…。Rustへの言及とか一文字も書いてないのに。
普及活動だと思うけど、さすがに嫌がらせチックに見える。

↓の資料公開した時の話っぽいんだけど、Rustでいいじゃんって言われてるソースが見つからない・・・
https://speakerdeck.com/faithandbrave/opunhua-gajin-muc-plus-plus-falsexian-zhuang-tozhan-wang

言われててもおかしくないとは思うけど、実際のところどうなんすかねえ
アロケータ回りがまだ弱いから少なくともゲームは10年後もC++のが強そう
(deleted an unsolicited ad)
67 名前：デフォルトの名無しさん mailto:sage [2021/08/26(木) 16:38:42.43 ID:n3k5ztC+.net]: >>27
まだ利用者がいるのに全てへNULL代入しにいく時点で破綻
つまりまだ自分以外の誰かが利用中かどうかを知らないといけない
つまり利用者リストを管理する必要がある
68 名前：デフォルトの名無しさん mailto:sage [2021/08/26(木) 16:39:16.76 ID:6RYxqPIE.net]: おまえらスレチがすぎるぞ
まとめてどっかいってくれ
69 名前：デフォルトの名無しさん mailto:sage [2021/08/26(木) 16:43:10.20 ID:xwYftXVU.net]: >>66
Rust はメモリ安全性を保証することが論文で示されているので
どうしてもC++でないと出来ないこと(＝まだRustが対応してないこと)であることを示さないと
「Rustでいいじゃん」となってしまうのは仕方ないかも
70 名前：デフォルトの名無しさん mailto:sage [2021/08/26(木) 17:32:35.75 ID:guyKB2RO.net]: Rustは言語仕様が未確定なのが懸念事項かな
実用上は大して困らないからどうでもいいんだけど
期待してたRust Foundationは何故かディレクター探し始めてるしｗ
71 名前：デフォルトの名無しさん mailto:sage [2021/08/26(木) 17:40:08.48 ID:ek8X72OL.net]: >>70
2018editionに2019のasync/awaitゼロコストサポートで言語としては完成でしょ？
72 名前：デフォルトの名無しさん mailto:sage [2021/08/26(木) 17:48:35.66 ID:TtF6fD9w.net]: >>70
それを期待するならFoundationよりこっちかな
https://ferrous-systems.com/ferrocene/
2022年末にASIL-B認証が目標
73 名前：デフォルトの名無しさん [2021/08/26(木) 18:01:26.94 ID:BSY6c8/C.net]: >>69
どの論文だよ
74 名前：デフォルトの名無しさん mailto:sage [2021/08/26(木) 22:38:09.77 ID:57cnJJ44.net]: >>71
まだOpenなRFCいくつあると思ってるんだ
75 名前：デフォルトの名無しさん mailto:sage [2021/08/26(木) 23:09:41.27 ID:6XyucKpc.net]: そんなこと言い出したら他の言語も未完成
永久にね
76 名前：デフォルトの名無しさん mailto:sage [2021/08/26(木) 23:45:46.81 ID:3VQCq3O/.net]: でもSchemeとか言語仕様も形式意味論も定まってるし
77 名前：デフォルトの名無しさん mailto:sage [2021/08/26(木) 23:50:11.85 ID:guyKB2RO.net]: とりあえず
https://doc.rust-lang.org/stable/reference/
のWarningを消してくれるだけでいいんだ
2018版だけでも確定できないのかな
78 名前：デフォルトの名無しさん mailto:sage [2021/08/26(木) 23:57:00.95 ID:yl47Ujhv.net]: 確定できないというよりメンテする人がいないんじゃないかな
言語仕様に詳しいけどコード書くよりドキュメント書きたいっていう奇特な人が要求されるわけで
79 名前：デフォルトの名無しさん mailto:sage [2021/08/27(金) 00:00:45.70 ID:cm2Md9qJ.net]: ferroceneみたいに具体的な目標があって企業が投資してるなら進むだろうけど
リファレンスの更新とかあまり需要もないじゃない？
80 名前：デフォルトの名無しさん mailto:sage [2021/08/27(金) 00:16:19.30 ID:i+fGpSJz.net]: 完全な仕様書は間違いなく必要ではあるよな。
81 名前：デフォルトの名無しさん mailto:sage [2021/08/27(金) 00:25:02.14 ID:LvLZjQiD.net]: 完全な仕様書www
どんだけ素人なんw
82 名前：デフォルトの名無しさん mailto:sage [2021/08/27(金) 00:25:46.96 ID:vEj4Ie0t.net]: 第三者が処理系を作れるレベルで言語仕様が固まれば普及が進むと思うんだけどね
Rust Foundationにはそういう方向性を期待してたけど想像以上に何もしなかった
83 名前：デフォルトの名無しさん mailto:sage [2021/08/27(金) 00:39:02.98 ID:cm2Md9qJ.net]: Foundationはもともと裏方に徹する組織だと言ってたし
その通りに動いているのでは
最近だとgccrsのライセンス絡みの知財チェックとかやってたかと
84 名前：デフォルトの名無しさん mailto:sage [2021/08/27(金) 00:45:32.58 ID:foV8RWB5.net]: 言語仕様が固まるってのは新機能の追加をやめるということ？
85 名前：デフォルトの名無しさん mailto:sage [2021/08/27(金) 00:49:06.81 ID:21t4GoG3.net]: 言語仕様とコンパイラのバージョンが一体化しているようではミッションクリティカルな領域で採用されない
86 名前：デフォルトの名無しさん mailto:sage [2021/08/27(金) 01:13:55.67 ID:vEj4Ie0t.net]: >>84
厳密に運用するなら機能を追加するときは言語仕様のバージョンも上げる
固めるのは言語仕様の１つのバージョンってだけで言語の進化をとめるわけじゃないよ
87 名前：デフォルトの名無しさん mailto:sage [2021/08/27(金) 01:28:41.09 ID:i+fGpSJz.net]: >>84
現状では「今そのように動いている処理系」と「処理系の (不十分な) ドキュメント」がある状態で、
それのどこからどこまでが言語仕様として満たすべき要件なのか保証されている動作なのかがわからない。
追加するも何も今の時点でどうなっているのかわからん。

どこかにはあったりもするんだろうけど、開発者向けの議論の中などに分散していて「仕様書」としてまとまってないんだ。
88 名前：デフォルトの名無しさん mailto:sage [2021/08/27(金) 02:31:48.28 ID:RPPiA5lc.net]: 安全性は型システムによるところが大きいから、仕様書が無いと使えないというのは無いと思うがね
89 名前：デフォルトの名無しさん mailto:sage [2021/08/27(金) 02:39:18.77 ID:8/O2Ek7n.net]: コンパイラだってバグがない保証なんてないんだから
テストするしかないね
90 名前：デフォルトの名無しさん mailto:sage [2021/08/27(金) 02:39:45.83 ID:xRe29h0Q.net]: ISO 26262のコンパイラ認証とか無理そう
91 名前：デフォルトの名無しさん mailto:sage [2021/08/27(金) 07:59:32.64 ID:ebhntqkF.net]: LLVMの中間表現に依存してる時点で、言語仕様をまともに設定するのは無理。
だから他のコンパイラが作られることもない。
92 名前：デフォルトの名無しさん mailto:sage [2021/08/27(金) 08:07:16.05 ID:PnoFi7iU.net]: 仕様書、仕様書言っている人はOSやライブラリのAPIとかシステムコールとかはどう考えているんだろうね
MSDNだって盲信できるほどの信頼性はないし、OSS系なんてソースコードが仕様書状態だろ
もっと言えば処理系だってオプティマイザの仕様などは文書化されていなく、実際に調査しないと判らない事も多いよな
93 名前：デフォルトの名無しさん mailto:sage [2021/08/27(金) 08:07:24.55 ID:/EVH9JcP.net]: こんな状態じゃc++の置き替えなんて夢のまた夢だな。
94 名前：デフォルトの名無しさん mailto:sage [2021/08/27(金) 08:43:05.29 ID:8HMvxqPN.net]: 完全な仕様書wがないのが問題だ思うなら使わなければいいだけ
クッソ無駄なやりとりでスレ消費すんな
95 名前：デフォルトの名無しさん mailto:sage [2021/08/27(金) 08:54:32.00 ID:ZVb7iGYH.net]: 少なくともC++はもっとずっと細かな仕様が書いてある。
例で説明する時でも、変な例で説明せずに数学の教科書の様な粒度の細かい例で
説明されているで、数学の教科書の様な雰囲気を持っている。
Rustの場合、ライフタイムの説明をとってみても、ちゃんとした数学的説明になってない。
96 名前：デフォルトの名無しさん mailto:sage [2021/08/27(金) 08:57:07.99 ID:ZVb7iGYH.net]: 時々プログラミングは文系でも出来るという人が居るが、そういう人には、
数学的な説明とは何かがぴんと来ないかもしれないので、良い仕様書も
書けないかもしれない。Rustのbookの著者ももしかしたらそうなのかも。
本人は頑張って書いているつもりでも数学的な論法になってない。
97 名前：デフォルトの名無しさん mailto:sage [2021/08/27(金) 09:04:15.77 ID:ZVb7iGYH.net]: 高校数学レベルで言えば、ベクトルの和の定義は図で例を使って説明されるが、
3つの矢印で、c = a + b が説明される。
これは最も粒度が細かい説明で、これ以上簡単に説明できない。
ところがRustのライフタイム注釈の説明は、説明に使われている例が不適切で
とても長いが本質が説明し切れてない。
本来は、「ライフタイム注釈とは何か」を数式や擬似命令などを使ってせいぜい2ページ以内で
説明できるはずだ。
ところが実際の説明は、変な例を使って長々と説明されている。
数学的な説明になっていないので応用が効かない。
数学的説明とはほとんどの場合「パターン」だ。パターンになっているから応用が効く。
パターンとして説明されてないと応用が効かない。
98 名前：デフォルトの名無しさん mailto:sage [2021/08/27(金) 09:06:37.74 ID:pCZxoLJn.net]: コンパイラが一つしかない状況は現状メリットでしかない

C++のようなレガシー言語の轍を踏まない賢い選択
99 名前：デフォルトの名無しさん mailto:sage [2021/08/27(金) 09:11:46.45 ID:ZVb7iGYH.net]: 数学的説明にしたいなら、
「仮定」を置く。
「入力」と「出力」を明確にする。
「最も粒度の小さい例を書き、パターン」にする。
集合論や論理学の「かつ」「または」「積集合」「和集合」「背反集合」「区間の積」
などの言葉を使って書く。
ところが、Rustのbookはこのようなことが全く出来てない。
100 名前：デフォルトの名無しさん mailto:sage [2021/08/27(金) 09:15:12.91 ID:ZVb7iGYH.net]: >>98
仕様書が数学的(パターン的、自動機械的)に書いてないので、厳密な
仕組みや仕様が分からず、他の人がコンパイラが作りにく。
だから、「Rustは実験してみないと分からない」。
ところが、CやC++やRuby,Java,C#,Pythonなどは実験しなくても分かる
ようになっている。それはなぜかというと、仕様が粒度が細かく説明されて
いるから、パターンになっており「パターンの一部への代入」や「当てはめ」
が出来るので頭の中だけで全てプログラミングできてしまうから。
101 名前：デフォルトの名無しさん mailto:sage [2021/08/27(金) 09:17:17.15 ID:X7Hfy4km.net]: 今日のNGIDがすぐ分かって助かった
感謝感謝
102 名前：デフォルトの名無しさん mailto:sage [2021/08/27(金) 09:20:43.18 ID:ZVb7iGYH.net]: ちょっと難解だが高速なスクリプト言語としては使えるとは思う。
でもC++の置き換えは難しいな。
なぜならC++で出来ていたことがRustには移植できないから。
103 名前：デフォルトの名無しさん [2021/08/27(金) 09:47:25.61 ID:nKzWHFHq.net]: 算数がクラスで一番君がきてますね
104 名前：デフォルトの名無しさん mailto:sage [2021/08/27(金) 10:21:55.10 ID:EkQRESx5.net]: なんやいつぞやのパターンマッチングの規格についてゴネてた子か
105 名前：デフォルトの名無しさん mailto:sage [2021/08/27(金) 11:04:36.95 ID:VpJ5g/uH.net]: ・Fortran/BASICからCへの移植は容易。単純なパターンが存在する。
　アルゴリズムの変更は不要。

・C++からJavaやC#への移植は容易。単純なパターンが存在する。
　アルゴリズムの変更は不要。

・C++からRustへの移植は困難。単純なパターンは存在せず。
　アルゴリズムを根本的に変える必要がある場合がある。
106 名前：デフォルトの名無しさん mailto:sage [2021/08/27(金) 11:10:56.79 ID:ANmCg7EV.net]: Rustアンチスレでやればいいのに
107 名前：デフォルトの名無しさん mailto:sage [2021/08/27(金) 16:15:37.78 ID:Ogrd1P9P.net]: 嫌なら使うなでおわり
現状嫌でも使うしかないくらいまでのシェア獲得してないし
108 名前：デフォルトの名無しさん mailto:sage [2021/08/27(金) 16:28:39.42 ID:i+fGpSJz.net]: 個人とし
109 名前：ては使いたいけど組織として導入するには仕様の確実さというのは必要なんだわ。 []: [ここ壊れてます]
110 名前：デフォルトの名無しさん mailto:sage [2021/08/27(金) 16:36:16.05 ID:+7PBhugx.net]: C++ドロップアウターがOOPを学び直すには良いんでないの
111 名前：デフォルトの名無しさん mailto:sage [2021/08/27(金) 16:44:56.69 ID:2IayjhUe.net]: 大手IT企業たちの方針

プログラミング言語「Rust」のための「Rust Foundation」設立 -- AWS(Amazon)、Microsoft、Google、Mozilla、Huaweiが創設
https://japan.zdnet.com/article/35166267/

Facebookが「Rust Foundation」に参加
https://japan.zdnet.com/article/35170192/
112 名前：デフォルトの名無しさん mailto:sage [2021/08/27(金) 16:56:21.47 ID:e9EjTnUc.net]: >>108
仕様の確実さってどういうの言ってる？
Rustでの具体例を1～2個あげてみて？
113 名前：デフォルトの名無しさん [2021/08/27(金) 17:09:08.75 ID:dNdDj0y1.net]: >>111
lifetime関連
114 名前：デフォルトの名無しさん mailto:sage [2021/08/27(金) 17:14:05.77 ID:CxV5dN8D.net]: >>112
関連じゃわかんねーわ
Lifetime Elisionとかは分かりやすく仕様定義されてるっしょ
115 名前：デフォルトの名無しさん mailto:sage [2021/08/27(金) 17:44:50.51 ID:i+fGpSJz.net]: で、それはどこにあるっていうんだ。
これについての仕様はこっちに有ってあれについての仕様はあっちに有って
詳細はブログのここにあって……でもこれは議論のための暫定的なまとめで……
みたいなのじゃ組織の中で話を通せんのよ。

「Rust の仕様はこれです」「これを満たした処理系は (少なくとも今のところは) Rust と呼べます」
というのが仕様書であって、そういうのが欲しいわけよ。
116 名前：デフォルトの名無しさん mailto:sage [2021/08/27(金) 17:53:04.46 ID:n5KpIChT.net]: その論法は流石に違和感が強い

GAFA級の組織（のどこか）では採択されるのにその組織では通らないというなら、その組織か説得者が外れ値なだけでは？
117 名前：デフォルトの名無しさん mailto:sage [2021/08/27(金) 17:58:34.36 ID:VUXc1RWG.net]: 老害さん今日も公式読まずに愚痴たれる
118 名前：デフォルトの名無しさん mailto:sage [2021/08/27(金) 18:02:52.05 ID:i+fGpSJz.net]: >>115
そのレベルの大企業というのは策定側で関与しうるし
投機的な技術的投資にも貪欲だから
「大企業は動きが遅い」「稟議が厳密」という感覚ではない。

グーグルが大規模なサービスを開始からそれほど間を置かずに畳んだことなんて何度もあるだろう。
ぽんっとやって駄目だったらポイッと捨てられるんだよ。
119 名前：デフォルトの名無しさん mailto:sage [2021/08/27(金) 18:09:32.26 ID:34BhyfmP.net]: そういう考え方ならISO標準でもできてから検討すればいいよ
時期尚早で時間の無駄
120 名前：デフォルトの名無しさん mailto:sage [2021/08/27(金) 18:10:07.62 ID:EkQRESx5.net]: 実際のところC++みたいに委員会とかが仕様がっちり決める言語ってどんくらいあるの？

そもそもC++だって仕様は決まってもコンパイラが微妙に準拠しきれてない気がするんだが
gccとclangは実用上困らんレベルだとは思うが
121 名前：デフォルトの名無しさん mailto:sage [2021/08/27(金) 18:16:18.84 ID:V38ET8xt.net]: ISO標準のある言語で一番新しいのがRubyくらいか
もっと新しいのあったっけ？
やはりリリースから10年以上はかかる感じかね
122 名前：デフォルトの名無しさん mailto:sage [2021/08/27(金) 18:18:18.61 ID:i+fGpSJz.net]: 今の時点ではアーリーアダプタが使う言語なんだという立場でやってるならそれでもいいんだけど、
個別には割と (どこかには) まとまってるっぽいからもったいねーなという感覚がある。
123 名前：デフォルトの名無しさん mailto:sage [2021/08/27(金) 18:27:08.06 ID:zNEUYlcQ.net]: お前が標準化委員会になるんだよ！
124 名前：デフォルトの名無しさん mailto:sage [2021/08/27(金) 18:31:21.32 ID:6epxU4jC.net]: GAFAMだけでなく
日本でもNTTやTOYOTAなどもRustを採用しているわけで
まともな企業ならば支障なくRust採用を決定していってるでしょう
125 名前：デフォルトの名無しさん [2021/08/27(金) 18:52:17.41 ID:nKzWHFHq.net]: 特定の組織の土着信仰を一般論のように入れてもね
126 名前：デフォルトの名無しさん mailto:sage [2021/08/27(金) 18:54:13.62 ID:+wfLaYar.net]: 権威でものを判断したり
権威を借りて発言したり

頭ワリーわ
正気になれ
127 名前：デフォルトの名無しさん mailto:sage [2021/08/27(金) 19:30:34.42 ID:wbifwX7a.net]: >>125
「権威に訴える論証」という人間の性質なんだよ。

けっこう効果あるから詐欺師とかマスゴミが良く使う。
128 名前：デフォルトの名無しさん mailto:sage [2021/08/27(金) 19:32:40.90 ID:+7PBhugx.net]: あの松下もわが社の製品を採用しているんですよ～
情弱「ほほう、じゃうちも採用率するわ！」
129 名前：デフォルトの名無しさん mailto:sage [2021/08/27(金) 19:33:38.34 ID:ul1V6iOZ.net]: メモリ開放の意味が解らない馬鹿に合わせるための言語なんだよな
馬鹿に合わせるとロクなことがない気がするんだけど
130 名前：デフォルトの名無しさん mailto:sage [2021/08/27(金) 19:36:05.44 ID:i+fGpSJz.net]: わかってても間違えるのが人間なんだよ。
ヒューマンエラーを防止するのに「注意する」とかで対策を済ませちゃうわけ？
131 名前：デフォルトの名無しさん mailto:sage [2021/08/27(金) 19:43:24.40 ID:6epxU4jC.net]: ＞グーグルによればAndroidに存在した深刻なセキュリティー脆弱性の70％近くがメモリー安全に関するバグに起因するという。
＞同様にマイクロソフトも、同社製品に存在したセキュリティー脆弱性の70％がメモリー安全に関するバグに起因すると述べている。
＞C/C++を使う限りセキュリティー脆弱性を根絶するのは不可能と考えて、Rustを採用するに至ったというわけだ。

https://xtech.nikkei.com/atcl/nxt/column/18/00692/042700054/
132 名前：デフォルトの名無しさん mailto:sage [2021/08/27(金) 19:45:18.24 ID:+7PBhugx.net]: あの会社もあそこもRust採用しているんだから絶対ヨシ！
https://i.imgur.com/aLxQE0R.jpg
https://i.imgur.com/NXcjrJA.jpg
133 名前：デフォルトの名無しさん mailto:sage [2021/08/27(金) 19:48:14.38 ID:+wfLaYar.net]: C++で苦しんできた連中は
Rustのやろうとしたことは分かるし
例え失敗に終わっても責める気にはならん
どうころんでもしょせん死屍累々
Rustは人類の明日への尊い礎になるだけ
134 名前：デフォルトの名無しさん mailto:sage [2021/08/27(金) 19:57:25.52 ID:2e6D9xTm.net]: >>125
そいつが権威主義的思考なのは確かなんだが
新興言語は大手の技術力ある会社がスポンサーにいて
継続的な投資が行われることが確実視されてるかどうかはすごく重要なこと
135 名前：デフォルトの名無しさん mailto:sage [2021/08/27(金) 21:00:14.71 ID:lzIWzz0k.net]: >>123
二つともわけの分からん企業だな。
自動車と電話会社。
136 名前：デフォルトの名無しさん mailto:sage [2021/08/27(金) 21:03:28.03 ID:lzIWzz0k.net]: 人々の関心の高さは感じるけどな。twitterとか見てると。
137 名前：デフォルトの名無しさん mailto:sage [2021/08/27(金) 21:07:48.98 ID:lzIWzz0k.net]: でもtwitterでは、Pythonも活況だし、KotlinもRustと似たり寄ったりの数、検索される。
なぜかQtやRailsは検索されにくい。Djangoは沢山検索される。
cplusplusは僅かに検索される。C++やC#は直接的にはそもそもtwitterでは検索できない。
Rustの話題性がPythonやKotlinやDjangoと比べて取り立てて多いということではないようだ。
138 名前：デフォルトの名無しさん mailto:sage [2021/08/27(金) 21:44:01.80 ID:pUsRfODL.net]: The Bookは読まないくせにどうでもいいTwitter検索ばっかりしやがって

あーあのTwitterで独り言つぶやき続けてるひとだっけ？
忘れてた
139 名前：デフォルトの名無しさん mailto:sage [2021/08/27(金) 21:51:00.96 ID:6al70LN5.net]: とにかく仕様が必要ならC++使えばよいのでは。主要メンバーがC++標準理解しているようなすごい人ばかりなんだろう
140 名前：デフォルトの名無しさん mailto:sage [2021/08/27(金) 21:58:56.53 ID:LFxFkvSL.net]: >>138
自分達が「完全な仕様」と思えるものが存在することが重要視なんであって理解している必要はないんでしょ
ある種の宗教上の理由だよ
141 名前：デフォルトの名無しさん mailto:sage [2021/08/27(金) 22:04:01.75 ID:cMIVTei2.net]: 実際は、Rails : Laravel = 8:2。
Django は、0

どこの学校・サロンもほぼ、Ruby on Rails
142 名前：デフォルトの名無しさん mailto:sage [2021/08/27(金) 23:00:14.26 ID:n5qLAlq9.net]: 確実にinline展開する方法ってある？
手動で書く？
マクロだとどうにかなる？
143 名前：デフォルトの名無しさん mailto:sage [2021/08/27(金) 23:01:33.75 ID:81/NfoJ7.net]: >>134
自動車の制御はわからんでもない
即応性と安全性の両立を図らなければならないのだから []; [ここ壊れてます]
145 名前：デフォルトの名無しさん mailto:sage [2021/08/27(金) 23:13:16.52 ID:EkQRESx5.net]: #[inline(always)]でも100%ではないんだっけ？
146 名前：デフォルトの名無しさん mailto:sage [2021/08/27(金) 23:22:31.27 ID:i+fGpSJz.net]: >>138
把握してないから必要なときにそれを調べればいいというようなまとまったものが必要なんだよ。
147 名前：デフォルトの名無しさん mailto:sage [2021/08/27(金) 23:40:58.77 ID:Q0/jYufH.net]: Rust以外で高信頼性指向だとAdaとかMISRA Cとか？
148 名前：デフォルトの名無しさん mailto:sage [2021/08/27(金) 23:45:38.03 ID:8/O2Ek7n.net]: >>143
実装はわからんけど、スペック的にはalwaysも飽くまでヒントらしい
149 名前：デフォルトの名無しさん mailto:sage [2021/08/27(金) 23:52:40.05 ID:8/O2Ek7n.net]: >>145
MISRA Cは言語じゃなくてコーディング規約みたいなもん
組み込み以外では厳しくて準拠してられないと思う
150 名前：デフォルトの名無しさん mailto:sage [2021/08/28(土) 00:02:42.33 ID:sJf3n258.net]: ファッション感覚のバカしかアピールしてない言語だわ。
c++理解してない奴がライフタイムをまともに理解できるとも思わん。
それもわからんバカがcをバインディングなんかしたら事故しか起きんわ。
安全性もクソもない。
151 名前：デフォルトの名無しさん mailto:sage [2021/08/28(土) 00:03:44.74 ID:7QeSIxjF.net]: 組み込み向けRustって1冊本が出たみたいだけど
実際のとこ、見込みありそうなの？
ただのホビー？
152 名前：デフォルトの名無しさん mailto:sage [2021/08/28(土) 00:05:05.86 ID:V8MBAFoh.net]: >>148
C++ はわかっててもミスるんだってば。
153 名前：デフォルトの名無しさん mailto:sage [2021/08/28(土) 01:13:09.37 ID:d8vtmqNS.net]: C/C++知らないと～と言う人には型理論知ってる？って聞きたくなる
コンパイルが通れば大体ちゃんと動くようになってるって感覚はhaskellとかOCaml寄りだと思う
154 名前：デフォルトの名無しさん mailto:sage [2021/08/28(土) 01:30:02.36 ID:V8MBAFoh.net]: Haskell の型システムは好きなんだけど
さすがに副作用 (Haskell 的にはアクションだが……) の扱いがしんどすぎるし
元から C++ には慣れてるので C++ (というか C) 風な文法や意味論と
組み合わせた言語があったらいいなぁと思ってたので
Rust の台頭にはばんじゃーい ∩( ・ω・)∩
155 名前：デフォルトの名無しさん mailto:sage [2021/08/28(土) 01:31:18.92 ID:RscIlgzn.net]: おまえらスルー力低すぎやろw
156 名前：デフォルトの名無しさん mailto:sage [2021/08/28(土) 07:36:29.05 ID:sJf3n258.net]: >>151
お前こそ型理論知らんだろ。。
型理論てのは結局どれだけ簡易な計算でエラーチェックするかってだけの話なんだよ。
正しく示すだけならただ単に全実行するのが一番良い。
157 名前：デフォルトの名無しさん [2021/08/28(土) 08:21:08.61 ID:t8+wI51G.net]: ガファムがファッションでプログラミングしてるとは知らなかった
158 名前：デフォルトの名無しさん mailto:sage [2021/08/28(土) 08:46:20.33 ID:YWpKrN9v.net]: twitterでRustは話題性があるように見えるが、ためしにLISPやSchemeや
Clojure(言語)を検索してみてもRustと似たり寄ったりの書き込みがあった。
Haskelが次代を担う言語だ、的な書き込みすらある。
159 名前：デフォルトの名無しさん mailto:sage [2021/08/28(土) 09:10:33.46 ID:sJf3n258.net]: 今のgoogleじゃまともなc++プログラマもだいぶ減ってるわな。。
kumagiとかイキってるだけでまともに理解してねーじゃん。
160 名前：デフォルトの名無しさん mailto:sage [2021/08/28(土) 10:14:03.36 ID:M1lC0AeK.net]: >>156
Haskellの型システムをRustは受け継ぎつつCG無しでメモリ安全性を達成しているので
Rustが実用的なプログラミング言語として現実に機能していますね
161 名前：デフォルトの名無しさん mailto:sage [2021/08/28(土) 11:32:23.88 ID:70jgR/1l.net]: CG無し
162 名前：デフォルトの名無しさん mailto:sage [2021/08/28(土) 11:39:53.86 ID:mx2u+dFv.net]: 特撮オンリーでいくわけですねわかります
163 名前：デフォルトの名無しさん mailto:sage [2021/08/28(土) 11:48:49.70 ID:H94428G1.net]: >>145
MISRAに従ってコーディングするの辛いぞ。
164 名前：デフォルトの名無しさん mailto:sage [2021/08/28(土) 12:14:36.47 ID:UcVwcAtV.net]: >>160
特撮にはCG有るぞ
165 名前：デフォルトの名無しさん mailto:sage [2021/08/28(土) 12:24:36.28 ID:WeXzUgff.net]: 次のようなloop文のプログラ�
166 名前：(可動)を while文やfor文に書き換えてわかりやすくしたいのですが 上手く値をbreakできないので助けてください fn main() { let a = [3, 5, 1, 6, 9, 4]; print_first_even_else_zero(&a); } fn print_first_even_else_zero(a: &[i32]) { let mut i = a.iter(); let even = loop { if let Some(&n) = i.next() { if n % 2 == 0 { break n; } } else { break 0; // not found } }; println!("{}", even); } 例えばwhile文なら　let even = while let Some(&n) = i.next() { となりそうで さらに可能ならfor文で　let even = for &n in a { となるかと思うのですが []: [ここ壊れてます]
167 名前：デフォルトの名無しさん [2021/08/28(土) 12:44:34.41 ID:t8+wI51G.net]: let even = a.iter().find(|n| *n % 2 == 0).unwrap_or(&0);
168 名前：デフォルトの名無しさん mailto:sage [2021/08/28(土) 13:03:12.27 ID:WeXzUgff.net]: >>164
当然それはわかりますが、for式やwhile式ではどうなるのか、という質問です
169 名前：デフォルトの名無しさん mailto:sage [2021/08/28(土) 13:07:44.67 ID:lHkfX/Au.net]: 前スレより

625 デフォルトの名無しさん 2021/08/16(月) 09:44:36.63 ID:MZWGbmHz
loop式はbreakで指定した値を返せるのに
なぜwhile式やfor式は値を返せないの？
Option型にしてbreakで値を指定した時だけSome(値)としてそれ以外はNoneとすれば便利なのに

630 デフォルトの名無しさん sage 2021/08/16(月) 14:32:54.40 ID:ebJKRLr3
手間かけて機能拡張するほどのメリットがないってことだろうね
https://github.com/rust-lang/rfcs/issues/1767#issuecomment-292678002
170 名前：デフォルトの名無しさん [2021/08/28(土) 13:08:21.57 ID:t8+wI51G.net]: そうでしたかすみません
forとwhileは値を返さないのでご想像のようにはなりません
171 名前：デフォルトの名無しさん mailto:sage [2021/08/28(土) 14:07:01.17 ID:WeXzUgff.net]: >>166
なるほど
そこでの議論を読むと一番の肝が、
「for式が()を返さないと、最後がfor式で終わる関数の返り値で互換性が無くなる」
というところにあるようですが
「break;」が()を返すことにすれば特に問題ないように見えます
実際にloop式で値なしのbreakだと()を返しています

つまり
・「for/while/loop式が返す型」は「break式の型」とする
・「値指定のない『break;』の型」は()とする
・「break式がない場合の型」も()とする
ここまでは現状と同じになりますね

問題はfor/while式はbreakせずともループを抜けるので、値を返すには、
・「『break 値;』があるfor/while式」は「else節を取ってbreak式と同じ型を返す」
という単純ルールだけで済むように見えます
何か見落としがあるでしょうか？
172 名前：デフォルトの名無しさん mailto:sage [2021/08/28(土) 14:41:22.43 ID:AMsYRDZ6.net]: 8日前にちょうどその内容で開かれたRFCあるじゃん
イテレータで思考停止してたわ
https://github.com/rust-lang/rfcs/pull/3163
173 名前：デフォルトの名無しさん mailto:sage [2021/08/28(土) 15:14:25.46 ID:WeXzUgff.net]: >>169
なるほどありがとうございます

ところで現状のRustで>>163の例のloop式をfor式で行おうとすると
即時関数を使ってbreakをreturnに置き換えることで
let even = (|| {
　for &n in a {
　　if n % 2 == 0 {
　　　return n;
　　}
　}
　0
})();
と実現できることを思いつきましたが
この方法は表記コストはともかく実行コストもかかってしまいますか？

ちなみにこの「最初の偶数を見つけるコード」はあくまでも例として単純化したものを出しているだけで
実際には様々な例でこのパターン(＝forやwhileで値を返せると便利)が出てくるので簡略な例題として話をしています
174 名前：デフォルトの名無しさん mailto:sage [2021/08/28(土) 15:30:38.48 ID:TLYe8gOd.net]: >>168
イテレータのコードのほうが遥かにわかりやすい上に簡潔なので
新しく文法を拡張する価値がないと開発陣は考えてる点を見落としてる。る？
特にPythonの失敗例を鑑みれば機能追加される可能性は限りなくゼロ
175 名前：デフォルトの名無しさん mailto:sage [2021/08/28(土) 15:43:20.61 ID:M1lC0AeK.net]: >>171
現実にはfindより複雑なことでも使うだろうし
async関数呼び出して判断もあるだろうし
イテレータでは無理なことも多いのでは？
176 名前：デフォルトの名無しさん mailto:sage [2021/08/28(土) 16:01:24.35 ID:Zz3t2OiP.net]: Rustに限った話じゃないけど新しめの言語だとイテレータで記述可能な
ループは、出来るだけイテレータで記述するのが主流じゃね
forだのwhileはループ条件の誤りから簡単にバグが生まれるし
使わないで済むならそれに越したことはない
CやCの派生系言語がメインの人には理解しがたいかもしれないが
177 名前：デフォルトの名無しさん mailto:sage [2021/08/28(土) 16:07:59.88 ID:V8MBAFoh.net]: C++ だとテンプレートの組み合わせで回すのも一般的だけど
Go だと凝ったことするよりなんでも愚直にループを回したほうがいいというのは
基本的なスタンスになってるよね。
178 名前：デフォルトの名無しさん mailto:sage [2021/08/28(土) 16:18:39.14 ID:TLYe8gOd.net]: >>172
説得力のある実例を出せば今みたいにRFCが即closeされることはないんじゃない？

状況によってはイテレータを拡張したほうがいいという判断も有り得るし
今のforやwhileループみたいにmutで定義した変数を更新するのでも十分かもしれない
179 名前：デフォルトの名無しさん mailto:sage [2021/08/28(土) 17:39:28.92 ID:WeXzUgff.net]: >>173
なるほど
出来るだけイテレータで記述する質問です
コマンドライン引数の数字の和をイテレータでpanicさせずに求める場合
これよりもっと短く出来ないでしょうか？
fn main() -> Result<(), std::num::ParseIntError> {
　println!("Sum: {}", std::env::args().skip(1).map(|s| s.parse::<i32>()).collect::<Result<Vec<i32>,_>>()?.iter().sum::<i32>());
　Ok(())
}
以下のように正しく実行できているのですがコードが長いのが気になっています
$ cargo run 10 20 30 40 50
Sum: 150
$ cargo run 10 20 XX 40 50
Error: ParseIntError { kind: InvalidDigit }
180 名前：デフォルトの名無しさん mailto:sage [2021/08/28(土) 17:58:47.12 ID:pl5LALbI.net]: そんなに長い？
181 名前：デフォルトの名無しさん mailto:sage [2021/08/28(土) 18:59:50.15 ID:78cNf6mY.net]: twitterで「Rust過激派がルール違反と判断された」
「CやC++のこと書いてた人にRustの話吹っかけて迷惑かけてた怖い人たち」
という話を見たが、誰の事？
どういうことなんだ？
182 名前：デフォルトの名無しさん [2021/08/28(土) 19:21:11.03 ID:0ROz2KLh.net]: >>178
c++テンプレートテクニックの著者のことか？
183 名前：デフォルトの名無しさん [2021/08/28(土) 19:24:41.12 ID:0ROz2KLh.net]: >>61
int* p1 = malloc(sizeof(int));
int* p2 = malloc(sizeof(int));
int* p3;
if (なんかの条件) p3 = p1; else p3 = p2;
free(p1);
p1 = NULL;
if (なんかの条件) p3 = NULL;
// p2はまだまだ使う
こうすればいいだけの話だろ？ガイジか？
このコードの後 p2またはp3どちらかをfreeしても二重開放にならんよ
このぐらいも考えられないのかガイジは(笑)
184 名前：デフォルトの名無しさん mailto:sage [2021/08/28(土) 19:28:28.84 ID:LR/RwLxP.net]: いちいち差別的な用語を使わないとレスもできないのか
プログラマとしては一流なのかもしれないが、人間としては最低だな
185 名前：デフォルトの名無しさん mailto:sage [2021/08/28(土) 20:41:09.02 ID:WeXzUgff.net]: >>177
このcollectしてから再びiterするところを何とか出来ないものかなと
println!("Sum: {}", std::env::args().skip(1).map(|s| s.parse::<i32>()).collect::<Result<Vec<i32>,_>>()?.iter().sum::<i32>());
イテレータだけを使う限界？

同じことをfor文を使うと短くなってわかりやすくなります
let mut total = 0;
for s in std::env::args().skip(1) {
　total += s.parse::<i32>()?;
}
println!("Sum: {}", total);
186 名前：デフォルトの名無しさん [2021/08/28(土) 21:00:48.99 ID:t8+wI51G.net]: std::env::args().skip(1).map(|s| s.parse::<i32>()).sum::<Result<i32, _>>()?
187 名前：デフォルトの名無しさん mailto:sage [2021/08/28(土) 21:02:35.90 ID:TLYe8gOd.net]: ParseIntError返しても処理しないんだから
unwrap_or(0)みたいなので十分じゃないの？

fn main() {
let args = std::env::args().skip(1);
let sum: i32 = args.map(|s| s.parse().unwrap_or(0)).sum();
println!("Sum: {}", sum);
}

入力、計算、出力で分けてる
188 名前：デフォルトの名無しさん mailto:sage [2021/08/28(土) 21:14:51.79 ID:M1lC0AeK.net]: >>184
非整数は飛ばす仕様になってる
エラーはエラーだと示すべきかな
あとエラー処理コードがないのは質問の本質じゃないからかと
189 名前：デフォルトの名無しさん mailto:sage [2021/08/28(土) 21:23:19.42 ID:AMsYRDZ6.net]: println!("{}", std::env::args().skip().try_fold(|sum, s| Ok(sum + s.parse::<i32>()?))?);

try_fold使うと?演算子の入る場所が変わらずに済むっぽいな
190 名前：デフォルトの名無しさん mailto:sage [2021/08/28(土) 21:24:03.32 ID:WeXzUgff.net]: >>183
なるほど!
sum()もcollect()のように様々な形の集積方法が指定できるのですね
i32整数一覧が入力に来るのにsum::<i32>()とi32型指定をしないと怒られた理由がようやくわかりました
sumとcollect以外にもそういう仕様のメソッドはありますか？
191 名前：デフォルトの名無しさん mailto:sage [2021/08/28(土) 21:34:12.61 ID:iw2Y3ERl.net]: いちいち固有のiterator使うとか可読性悪くなるだけって場合も多い
192 名前：デフォルトの名無しさん mailto:sage [2021/08/28(土) 21:54:20.22 ID:WeXzUgff.net]: >>186
素晴らしい!
少し修正して以下で上手く行きました
std::env::args().skip(1).try_fold(0, |sum, s| Ok(sum + s.parse::<i32>()?))?
fold()は知っていたのですがtry_fold()でOptionやResultの形でfold()できるとは便利ですね

ここまでまとめると
sum計算はResult型を返せるsum()があるので>>183でも行けて
このtry_fold()ならばsum計算以外にも汎用的に使えますね
193 名前：デフォルトの名無しさん mailto:sage [2021/08/28(土) 22:01:27.46 ID:TLYe8gOd.net]: >>185
エラーだと示したいなら結果をハンドリングすればいいんじゃないの？

type Result<T> = std::result::Result<T, std::num::ParseIntError>;

fn main() {
let args = std::env::args().skip(1);
let sum: Result<i32> = args.map(|s| s.parse::<i32>()).sum();
match sum {
Ok(sum) => println!("Sum: {}", sum),
Err(e) => println!("Error: {}", e),
};
}

引数ゼロ個とかエラーは1種類じゃまかなえない
ハンドリングしたいならエラー設計がもう少し必要になるだろうね
194 名前：デフォルトの名無しさん mailto:sage [2021/08/28(土) 22:12:53.29 ID:M1lC0AeK.net]: >>190
もちろんそんなことは皆わかっていて、最後のResultのErr処理は枝葉末節だから略して議論してるのだと思う
あとmain()でResult返してErrなら勝手にエラー表示してくれるみたいで便利
で、>>185で指摘したことは、>>184のunwrap_or(0)使用はエラーが消えるからマズいよね、ということでした
195 名前：デフォルトの名無しさん mailto:sage [2021/08/28(土) 22:34:29.66 ID:TLYe8gOd.net]: >>191
何をそんなにカリカリしてるんだ？
main()でResult返したいなら別にそれでもいいんじゃない？

fn main() -> Result<()> {
let args = std::env::args().skip(1);
let sum: Result<i32> = args.map(|s| s.parse::<i32>()).sum();
println!("{}", sum?);
Ok(())
}
196 名前：デフォルトの名無しさん mailto:sage [2021/08/28(土) 22:53:59.26 ID:M1lC0AeK.net]: >>192
皆がわかりきったことしか書いていなくて何をしたいのかわからないけど
Resultはエラー型も示さないとそのコードでは動かないよ
197 名前：デフォルトの名無しさん mailto:sage [2021/08/28(土) 23:36:35.98 ID:WeXzUgff.net]: 今回はargs部分も枝葉末節なので外してまとめ直すと
『数値と思われる文字列の配列が与えられた時に非数値があればエラーを返すとして』
let a = ["1", "3", "5", "7", "9"];
和の場合はmap()でResultのままsum()に渡してResultを返せる
let sum = a.iter().map(|s| s.parse::<i32>()).sum::<Result<i32, _>>()?;
和だけでなく積などもtry_fold()を使えばResultを返せる
let sum = a.iter().try_fold(0, |sum, s| Ok(sum + s.parse::<i32>()?))?;
let mul = a.iter().try_fold(1, |mul, s| Ok(mul * s.parse::<i32>()?))?;
今回はparse()で文字列→数値のResultだけど一般的にResultを返す関数なら応用可能
皆さんありがとうございました
198 名前：デフォルトの名無しさん mailto:sage [2021/08/29(日) 09:06:24.35 ID:CQyaTqyh.net]: >>179
指摘している人も、加害者もエピステーメー氏とは全く関係ない人だと思う。
199 名前：デフォルトの名無しさん mailto:sage [2021/08/29(日) 12:05:26.47 ID:ehQ9raC/.net]: >>195
えぴすめーてーじゃないほうの共著者のほうでしょ
200 名前：デフォルトの名無しさん mailto:sage [2021/08/29(日) 13:31:13.01 ID:pAl4bTqC.net]: ローマ字で takaha... の人のことか。
Ukic...の人も何か言ってるんだけどどういう相関関係なのか。。
201 名前：デフォルトの名無しさん mailto:sage [2021/08/29(日) 17:50:42.33 ID:rRIESWs9.net]: 対立煽りに乗らないように
202 名前：デフォルトの名無しさん [2021/08/29(日) 20:28:38.19 ID:TMfqiUgQ.net]: >>174
Goは確かにその方針だけど、イテレータというか高階関数を受ける型が総称では無いから.collectや.mapなんて
型ごとに定義しないと使えないから。Go2になってくれば違ってくると思う
一方でPythonだとfunctools.reduceなんかより、リスト内包表記が使われるのは局所性で速度が速いからだけど
ループで書かずにかなり長い表現をこれで書かれると保守しずらい。
Rustでもイテレータを何回も取り出してcollectしたり、foldしたりをドットで繋げられるのはあまり読み易いとは
言えないと思う。普通にiter()を何度も呼ぶのなら、let it = a.iter();して欲しい
203 名前：デフォルトの名無しさん [2021/08/29(日) 21:26:36.38 ID:FKMKprYN.net]: そのitは一度しか使えないのでわ
204 名前：デフォルトの名無しさん mailto:sage [2021/08/29(日) 21:37:15.37 ID:3sJ97RgW.net]: collect()したやつに.iter()は確かにやめてほしい
終端操作するなら何か変数に入れた上でやってほしい
205 名前：デフォルトの名無しさん mailto:sage [2021/08/29(日) 21:56:31.67 ID:Y4MENvlF.net]: AdapterとConsumerは必ず分けろってこと？
もちろん分けたほうがいい場合もあるだろうけど
別に一緒でもいいと思うんだけどな
206 名前：デフォルトの名無しさん mailto:sage [2021/08/29(日) 22:06:52.56 ID:4xE/eKOX.net]: >>201
中間変数を使うか否かだけの問題だからどうでもいい話
言語自体やその利用方法に本質的な問題があるわけではない

一方で>>199のGoの問題は深刻
Rustがトレイトで解決している分野だ
207 名前：デフォルトの名無しさん mailto:sage [2021/08/29(日) 22:08:51.10 ID:Y4MENvlF.net]: 上にあるコードでcollect()した後にiter()してるやつのことか
それなら分かる
208 名前：デフォルトの名無しさん [2021/08/29(日) 22:19:15.00 ID:FKMKprYN.net]: あぁそういうこと
俺は別に繋がってていいかな
209 名前：デフォルトの名無しさん mailto:sage [2021/08/29(日) 22:49:50.89 ID:4xE/eKOX.net]: >>204
それコードを改善したいという相談やんけ
しかも最終的には>>194のコードへと短くわかりやすくなったのだからRustはよく考えられてるなあとしか
210 名前：デフォルトの名無しさん mailto:sage [2021/08/29(日) 23:12:51.30 ID:Y4MENvlF.net]: >>206
だからこそcollect()した後にiter()してるコードは改善したほうがいいよって話だろ？
211 名前：デフォルトの名無しさん mailto:sage [2021/08/29(日) 23:54:47.37 ID:6tO3Pyjl.net]: 和も積も求めたい時はどうすればいいかな?
文字列から数値への変換を二度するのを避けるとして
一つの方法はこのように一旦collectとして数値のVecを作ってしまう
fn main() -> Result<(), std::num::ParseIntError> {
　let input_numbers: Vec<i32> = std::env::args().skip(1).map(|s| s.parse::<i32>()).collect::<Result<_,_>>()?;
　println!("和: {}", input_numbers.iter().sum::<i32>());
　println!("積: {}", input_numbers.iter().fold(1, |mul, n| mul * n));
　Ok(())
}
それともcollectせずにイテレータのままで止めておいて使う?
212 名前：デフォルトの名無しさん mailto:sage [2021/08/29(日) 23:59:56.40 ID:53Xl0cl7.net]: 質問者とイライラ君が同一人物のパターン?
213 名前：デフォルトの名無しさん mailto:sage [2021/08/30(月) 00:06:07.90 ID:gpHI1J3P.net]: product()使わないの？
214 名前：デフォルトの名無しさん mailto:sage [2021/08/30(月) 00:06:33.11 ID:kOjyqHoG.net]: >>208
foldで和と差の2要素のタプルをとりまわせば良いだけ
215 名前：デフォルトの名無しさん mailto:sage [2021/08/30(月) 00:56:00.83 ID:5WtxtfY9.net]: こうかな
println!("和: {}", std::env::args().skip(1).map(|s| s.parse::<i32>()).sum::<Result<i32,_>>()?
216 名前：); println!("積: {}", std::env::args().skip(1).map(|s| s.parse::<i32>()).product::<Result<i32,_>>()?); println!("(和,積): {:?}", std::env::args().skip(1).try_fold((0, 1), |(sum, mul), s| { let n = s.parse::<i32>()?; Ok((sum + n, mul * n))})?); []: [ここ壊れてます]
217 名前：デフォルトの名無しさん mailto:sage [2021/08/30(月) 01:17:16.84 ID:XeeK64dt.net]: >>209
っぽい
218 名前：デフォルトの名無しさん mailto:sage [2021/08/30(月) 01:45:40.23 ID:Fg1XXjYH.net]: C++君も
219 名前：デフォルトの名無しさん mailto:sage [2021/08/30(月) 05:11:39.37 ID:1N5t7Emb.net]: この前はNim連呼してた
220 名前：デフォルトの名無しさん mailto:sage [2021/08/30(月) 05:23:26.66 ID:YLwuWBBL.net]: 二重解放NULL荒らしもな
221 名前：デフォルトの名無しさん mailto:sage [2021/08/30(月) 08:14:19.28 ID:Bz8fsAkW.net]: >>209
確かにこんな特徴的な勘違いをするやつが同時に二人出現するわけないわな
222 名前：デフォルトの名無しさん mailto:sage [2021/08/30(月) 08:46:37.85 ID:nNe2AEIB.net]: じゃあワイはガリガリ君で
223 名前：デフォルトの名無しさん mailto:sage [2021/08/30(月) 09:38:42.61 ID:j0aQcfY/.net]: >>214
C++ vs Rustスレでやれと何度言っても聞かずにここでイライラしてるよな
224 名前：デフォルトの名無しさん mailto:sage [2021/08/30(月) 10:38:26.28 ID:iy37Frot.net]: 上のイテレータ関連の質問に便乗ですが、
二次元vecの各要素をv[i][j]としたときに、
jごとの総和を計算するやつをイテレータできれいに書く方法ありますか？

例えばこういうやつです

let v = vec![vec![0; n]; m];
// (vの各要素を設定）
let mut result = vec![0; n];
for i in 0..m {
for j in 0..n {
result[j] += v[i][j];
}
}
225 名前：デフォルトの名無しさん mailto:sage [2021/08/30(月) 10:46:23.34 ID:qTeljjrO.net]: >中間変数を使うか否かだけの問題だからどうでもいい話

Rustの場合、ライフタイムとオーナーシップの関係で
中間変数を使うか否かは結構重要な問題だったりする
226 名前：デフォルトの名無しさん mailto:sage [2021/08/30(月) 10:56:01.57 ID:b2fdtQYv.net]: >>220
mapしてsumすればいいだけでは？
きれいかどうかは知らんけど
227 名前：デフォルトの名無しさん mailto:sage [2021/08/30(月) 12:15:23.57 ID:OrMFDzce.net]: >>212
これ競プロ用でしょ
一般的なプログラミングとは観点が違うから最初に競プロ用だと書いておいたほうがいいぞ
228 名前：デフォルトの名無しさん mailto:sage [2021/08/30(月) 12:35:22.36 ID:iy37Frot.net]: >>222
mapとsumで書けます？
iごとの総和なら単純に
v.into_iter().map(|v| v.into_iter().sum()).collect()
みたいな感じでいけるとおもうのですが、jごとだとちょっとわからないです

>>223
そうですね（実はもともとの発端は競プロではなかったりするのですが
229 名前：デフォルトの名無しさん mailto:sage [2021/08/30(月) 13:18:46.38 ID:cyaLRDjw.net]: (0..n).map(|j| (0..m).map(|i| v[i][j]).sum()).collect()

2重forをの親子を逆転してイテレータメソッドチェーンに変換しただけという感じ
こんなことよりもっと意味のあることに頭使ったほうがいい
イテレータでとあったから上を書いたが現実にはndarray入れてsum_axis使うのがいいだろう
https://docs.rs/ndarray/0.15.3/ndarray/struct.ArrayBase.html#method.sum_axis
230 名前：デフォルトの名無しさん [2021/08/30(月) 13:30:16.69 ID:w/2FJku9.net]: こんなかんじかな

https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=e302c841c8dd709418f923ea1ad07868
231 名前：デフォルトの名無しさん [2021/08/30(月) 13:33:43.06 ID:w/2FJku9.net]: ほぼかぶってたごめん
232 名前：デフォルトの名無しさん mailto:sage [2021/08/30(月) 13:38:15.69 ID:iy37Frot.net]: >>225-226 インデックス自体のイテレータを作るって発想がありませんでした、ありがとうございます
競プロ用ではないしndarray使うのも考えてみます
233 名前：デフォルトの名無しさん mailto:sage [2021/08/30(月) 14:45:34.31 ID:07yK3Bti.net]: 汎用的には縦横入れ替えのtransposeを作っておけば色んな操作が楽かもね
イテレータ作成はサボってとりあえず関数版
fn transpose<T>(v: &Vec<Vec<T>>) -> Vec<Vec<T>> where T: Copy {
　(0..v[0].len()).map(|j| v.into_iter().map(|vv| (*vv)[j]).collect::<Vec<T>>()).collect()
}
fn main() {
　let v = vec![vec![1,2,3], vec![4,5,6], vec![7,8,9], vec![10,11,12]];
　let w = transpose(&v);
　println!("{:?}", v); // [[1, 2, 3], [4, 5, 6], [7, 8, 9], [10, 11, 12]]
　println!("{:?}", w); // [[1, 4, 7, 10], [2, 5, 8, 11], [3, 6, 9, 12]]
}
234 名前：デフォルトの名無しさん mailto:sage [2021/08/30(月) 20:06:03.21 ID:kOjyqHoG.net]: transposeみたいな関数用意すべきかは配列の要素数次第かなあ
たかだか1度しか読まないデータのためだけに配列全体をコピーするのはもったいないケースはありそう
235 名前：デフォルトの名無しさん mailto:sage [2021/08/30(月) 20:10:57.31 ID:kOjyqHoG.net]: 性能気にするなら Vec<Vec<_>> の形で数値格納するのではなく
Vec<_> に格納して (i, j) -> j*n+i みたいにインデックスを変換してくれるラッパーを被せた方がよさそう
236 名前：デフォルトの名無しさん mailto:sage [2021/08/30(月) 20:40:55.84 ID:W4wNS06G.net]: >>231
それがndarrayなのでは?
237 名前：デフォルトの名無しさん mailto:sage [2021/08/30(月) 20:50:30.90 ID:k7vUdD10.net]: これ匙投げたな
https://lkml.org/lkml/2021/7/4/171
238 名前：デフォルトの名無しさん mailto:sage [2021/08/30(月) 21:09:01.34 ID:bfTdIfIK.net]: C++ドロップアウターの吹き溜まりスレ
239 名前：デフォルトの名無しさん mailto:sage [2021/08/30(月) 21:16:46.70 ID:Xk6FdWtE.net]: >>223
競プロではむしろ回答時間や処理速度のほうが重要なので、
あえてこういうのをイテレータで実装しようとしないよ
おれなら間違いなくforで回す。わざわざイテレータで回そうと考える時間が無駄

だけど、後から振り返って、これをイテレータで1行で簡単に表示できるんじゃないかな？と思うことはよくあるんよ。
そして、ドキュメントを見返したり、他人のソースを見て、ああこういうやり方もあるんだなと学習する

競プロは実際のコーディングに役立たないという人もいるけど、
普段、自分が利用しないメソッドや方法を発見すること、実務で役立ちそうなアルゴリズムがあることを知る
という意味では意味があると思う
240 名前：デフォルトの名無しさん mailto:sage [2021/08/30(月) 21:24:57.91 ID:zvivEi6g.net]: >>235
競プロに対する君の考えを急に述べられましても・・・
誰も興味ないよ
241 名前：デフォルトの名無しさん mailto:sage [2021/08/31(火) 00:14:29.47 ID:NYCNDL8F.net]: >>236
逆にいうと、君が競プロはこういうものだろうという勝手な解釈で意見を言うことにも意味がないということよ
それこそ誰も興味がない
242 名前：デフォルトの名無しさん mailto:sage [2021/08/31(火) 01:03:24.14 ID:P5Wfb+Ix.net]: 今日もまたこのパターンw
ヤバいやつっすね
243 名前：デフォルトの名無しさん mailto:sage [2021/08/31(火) 01:24:07.51 ID:uga9Wpe3.net]: たまにLKMLのURL貼られるけどURLだけ貼られてもなんもわからん
244 名前：デフォルトの名無しさん [2021/08/31(火) 09:11:07.02 ID:7zPv8PJ6.net]: >>235
最適化まで考えるならforなんだろうけど、iterやcollectなんかが最適化が効かないのは今昔で、いずれは
最適化されるんじゃないだろうかと希望的観測を述べてみたり。実際gccなんかだとリンク時の最適化なんて
オプションあるし、あんまり凝ったiter/map/collect/foldだと理解に時間が掛かることはいなめない
245 名前：デフォルトの名無しさん mailto:sage [2021/08/31(火) 09:16:05.39 ID:uIcWKBVk.net]: ぼくのかんがえた最強のコードが見下されたと思って悔しかったんだろうな
図星だったからこそ競プロでは逆にこんな書き方しないとか競プロは役に立つとか自己正当化に必死になる

追い越されたらバカにされたと思って煽り運転をする人と心理と同じなのでどちらの側も少し気を付けたほうがいい
246 名前：デフォルトの名無しさん mailto:sage [2021/08/31(火) 10:02:54.76 ID:Mir3UPzo.net]: forよりイテレータのメソッドチェーンのほうが処理速度速かった気がするんだが
247 名前：デフォルトの名無しさん mailto:sage [2021/08/31(火) 10:51:36.61 ID:ajUm3fTo.net]: やっていることが同じなら (最適化などによって) 結果のコードもおおよそ同じところに着地するよ。
248 名前：デフォルトの名無しさん mailto:sage [2021/08/31(火) 12:44:14.75 ID:Iv8lyMCD.net]: C/C++でポインタを使うと速い(プラシーボ)
249 名前：デフォルトの名無しさん mailto:sage [2021/08/31(火) 13:28:16.71 ID:ajUm3fTo.net]: せやな。素朴なコンパイラならともかく
いまどきの最適化能力を期待できるなら
ポインタはエイリアス解析を困難にするから
むしろ足を引っ張る要素になる。
250 名前：デフォルトの名無しさん mailto:sage [2021/08/31(火) 14:25:42.76 ID:SlncBcTV.net]: >>244
ポインタは適切に使えばデータ構造やアルゴリズム自体が根本的に変えることが
できるので使わない時と比べて計算オーダー自体が劇的に変化することがあり、
プラシーボではない。
Rustはその点でC/C++に勝てない事がある。
251 名前：デフォルトの名無しさん mailto:sage [2021/08/31(火) 14:28:10.16 ID:SlncBcTV.net]: 例えば、動的配列であるところのVectorはポインタでアクセスしても余り
効率は良くならないが、LinkedListは構造的にポインタで連結されており、
首尾一貫して添え字アクセスを使わずに必ずポインタでノードを識別する
ようにすれば、Vectorに比べて劇的に効率アップできることがある。
それはRustではほぼ不可能。ベンチマークはこの点が反映されてない。
252 名前：デフォルトの名無しさん mailto:sage [2021/08/31(火) 15:24:34.70 ID:8qO1h2Cp.net]: 続きはこちらで
https://mevius.5ch.net/test/read.cgi/tech/1619219089/
253 名前：デフォルトの名無しさん mailto:sage [2021/08/31(火) 21:08:01.25 ID:NYCNDL8F.net]: >>240
最適化ではなくて、forを利用してindexで回さないとできないことが山ほどあるんだよね
例えば、二分探索や三分探索とか

foreach（a in vec）で順繰りに回せる処理ならいいけど、
そういう処理ではできないこともあるので、
forで回す前提で考えたほうが、あとから修正する余地があるので、どうしてもforでindexで回すことになる
これは、イテレータのほうがループが速いというのと、また別の問題
254 名前：デフォルトの名無しさん mailto:sage [2021/08/31(火) 21:25:16.59 ID:RnSwjxg3.net]: rustのforは他言語でいうforeach(a in vec)やろ
255 名前：デフォルトの名無しさん mailto:sage [2021/08/31(火) 21:26:56.02 ID:RnSwjxg3.net]: そもそも二分探索を普通forで実装しないだろ
256 名前：デフォルトの名無しさん mailto:sage [2021/08/31(火) 21:39:55.47 ID:KWeLtswn.net]: for each 的なループで書いたものを二分探索に直す時点でプログラムとしては別物になりそうなんだけど
元のコードを iter じゃなく index アクセスするコードにしておくことでこの書き換えがどれほど楽になるのかね

まあここまでくると個人の好みの話なのでお好きにどうぞとしか言えないが
257 名前：デフォルトの名無しさん mailto:sage [2021/08/31(火) 21:59:30.62 ID:Gkdn/HXs.net]: Rustのfor式を理解してなかったんかーいっ！！！
258 名前：デフォルトの名無しさん mailto:sage [2021/08/31(火) 22:43:09.54 ID:JHqwYLi1.net]: >>250
それは違う

まず1点目
リスト対するfor文をforeachと書かずforと書く言語の方が非常に多く一般的
C++もJavaもJavaScriptもPythonもRubyもAwkもshもリストに対してfor文

次に2点目
Rustのfor文はIterator loopと明確に書かれてるようにリストや配列に対してではなくイテレータ正確にはIntoIteratorを実装するものに対して
259 名前：デフォルトの名無しさん mailto:sage [2021/08/31(火) 23:30:53.76 ID:lNvHqkvm.net]: もうコイツどうにかしてくれwww
260 名前：デフォルトの名無しさん mailto:sage [2021/08/31(火) 23:44:40.84 ID:Gy6+Rq7 ]: [ここ壊れてます]
261 名前：L.net mailto: >>254
恥かいたので頑張って調べましたってレスなんだろうけど何一つ理解できてないぞ
もう一回調べ直してこい []: [ここ壊れてます]
262 名前：デフォルトの名無しさん mailto:sage [2021/08/31(火) 23:52:15.67 ID:3ENBWRwS.net]: 調べたのにfor式を理解できんかったんかーいっ！！！
263 名前：デフォルトの名無しさん mailto:sage [2021/08/31(火) 23:54:52.53 ID:uga9Wpe3.net]: Rustのforで二分探索ってどうやるのか気になる
264 名前：デフォルトの名無しさん mailto:sage [2021/08/31(火) 23:56:09.61 ID:cANa6qyq.net]: どうせ自分で二分探索なんか実装しないだろ
気にするな
標準ライブラリ使え
265 名前：デフォルトの名無しさん mailto:sage [2021/09/01(水) 01:38:57.54 ID:iOouKnxp.net]: >>258
for _ in 0..log2(n) as usize 的に回せばいいんでは?

まずやらないけど
266 名前：デフォルトの名無しさん mailto:sage [2021/09/01(水) 01:59:11.36 ID:p49DyIKy.net]: >>260 それでどうやるかわかんねーんすけど
少なくとも>>249が言ってるforでindex回すってのとは違うような
267 名前：デフォルトの名無しさん mailto:sage [2021/09/01(水) 03:29:00.40 ID:MtyAaHfZ.net]: >>254
もちろんRustのforはVecや配列に適用じゃなくてイテレータに適用
だからリスト処理しかできない言語のfor/foreachよりはRustのforは適用範囲が広い
しかし

>>258
for以前に確定しているデータしかイテレータ内で使えなくて
これはforの中で算出されたデータを借用規則によりイテレータに反映させられないためで
forの中でif分岐などする形で二分探索は無理と思う
しかし

元々の>>249が言う
「forを利用してindexで回さないとできないことが山ほどある。例えば二分探索とか」も間違い
このforはC言語などのfor (index初期値; index条件判定; index更新)を指しているが
二分探索はindex更新が状況により増減変化するためfor(;;)文を使えない
無理やりにforを使っても更新項がないため最初からwhile文を使うのが正解
つまりCでもRustでも同じでforではなくwhileが使われる
268 名前：デフォルトの名無しさん mailto:sage [2021/09/01(水) 05:05:49.84 ID:W5DSGMZK.net]: こんな感じ？
fn binary_search<T>(array: &[T], target: T) -> Option<usize> where T: std::cmp::PartialOrd {
　let mut left = 0;
　let mut right = array.len() as i32 - 1;
　while left <= right {
　　let mid = (left + right) / 2;
　　if array[mid as usize] == target {
　　　return Some(mid as usize);
　　} else if array[mid as usize] < target {
　　　left = mid + 1;
　　} else {
　　　right = mid - 1;
　　}
　}
　return None;
}
Cで書いてもほぼ同じコードになるね
同じコードで任意の型に楽に対応できるRustの方が有利かな
269 名前：デフォルトの名無しさん mailto:sage [2021/09/01(水) 08:56:44.94 ID:wrwogreT.net]: >>262
常識的なことを盛大に勘違いしてるので
>>254と同一人物なのモロバレだぞ

自分の書いたレスに他人のフリして間違いを指摘しようとするのは控えめに言っても病気
270 名前：デフォルトの名無しさん mailto:sage [2021/09/01(水) 19:34:58.07 ID:8EcW0Jj4.net]: >>249
お、249は俺だ。
言われてみれば確かに二分探索でforはないなｗｗ
while max-min > 0 とかそんな感じだった。飲んで書いてたからすまんすまん

でも、イテレータでなくてindexでやるほうが便利なことのほうが多いのは事実なのよ
動的計画法で現在の参照している配列の前後の内容を参照する時とか
271 名前：デフォルトの名無しさん mailto:sage [2021/09/01(水) 20:35:07.40 ID:+RqlKI+M.net]: indexが便利なことの "方が" 多いの？
indexが便利なこと "も" 多いならわかる
272 名前：デフォルトの名無しさん mailto:sage [2021/09/01(水) 21:13:02.22 ID:8EcW0Jj4.net]: 自分は競プロでRustを使ってるけど、その範囲では圧倒的にindex
273 名前：デフォルトの名無しさん mailto:sage [2021/09/01(水) 21:38:57.15 ID:8EcW0Jj4.net]: うーん、こういうのはイテレータだけでもいけるね
ttps://atcoder.jp/contests/abc138/tasks/abc138_d

static mut tree_list: Vec<(i64, i64)> = Vec::new();
static mut job_list: Vec<(i64, i64)> = Vec::new();
static mut res_list: Vec<i64> = Vec::new();

fn main() {
　unsafe {
　　input! {
　　　edge: i64, job: i64,
　　　tree_list0: [(i64, i64); edge-1],
　　　job_list0: [(i64, i64); job],
　　}

　　tree_list = tree_list0;
　　job_list = job_list0;
　　res_list = vec![0_i64; edge as usize + 1];

　　unsafe fn calc(index: i64, count: i64) {
　　　res_list[index as usize] += count;
　　　for &(a, b) in &tree_list { if a == index { calc(b, count); } }
　　}

　　for &(a, b) in &job_list { calc(a, b); }

　　for i in 1..res_list.len() { print!("{} ", res_list[i]); }
　　println!();
　}
}
274 名前：デフォルトの名無しさん [2021/09/02(木) 00:21:53.48 ID:nqohbFGX.net]: ところで非同期ライブラリはどれが標準になるの？
275 名前：デフォルトの名無しさん mailto:sage [2021/09/02(木) 01:42:02.99 ID:S2XiqXH4.net]: そりゃあれでしょ
276 名前：デフォルトの名無しさん mailto:sage [2021/09/02(木) 11:37:50.37 ID:UEpMLVw4.net]: 名前がダセェあれか
277 名前：デフォルトの名無しさん mailto:sage [2021/09/02(木) 14:15:51.06 ID:AObLO14s.net]: お江戸
278 名前：デフォルトの名無しさん mailto:sage [2021/09/02(木) 14:55:26.38 ID:2FuyxSW6.net]: >>269
futuresで行ける
279 名前：デフォルトの名無しさん mailto:sage [2021/09/02(木) 15:18:41.35 ID:l4XbE5cZ.net]: Rustは、Tiobe index で、少し前に始めて20位に入ったが、今見たら
24位に下がってる。
このランキングの信憑性にも議論の余地はあろうが。
でも、日経の調査ではプロが使っている言語のTOPは、C/C++ということなので、
その調査とも整合はしている。
他の調査でも、CとC++を合算するとTOPか、2位になる。
280 名前：デフォルトの名無しさん mailto:sage [2021/09/02(木) 15:28:38.88 ID:l4XbE5cZ.net]: https://www.rust-lang.org/ja/production/users
には、Rust公式サイト(?)で製品に使っている企業名が書いてあるが、
聞いたことが無い企業が多い。それはそういうものなのかもしれないが。
281 名前：デフォルトの名無しさん [2021/09/02(木) 17:24:27.18 ID:oZlwZEWk.net]: >>254
お前の負けやでｗ
282 名前：デフォルトの名無しさん mailto:sage [2021/09/02(木) 17:50:16.02 ID:5ahReTWB.net]: >>256
そらそろ宿題できたかい？
283 名前：デフォルトの名無しさん [2021/09/02(木) 18:51:20.53 ID:oZlwZEWk.net]: >>277
お前の負けやでｗ
284 名前：デフォルトの名無しさん mailto:sage [2021/09/02(木) 19:10:59.17 ID:2FuyxSW6.net]: また荒らしが来てるな
ところで非同期関数を呼ぶとfuture/promiseを返すだけでそのタイミングては実行開始しない怠惰タイプのプログラミング言語はRust以外に何があります？
285 名前：デフォルトの名無しさん mailto:sage [2021/09/02(木) 19:14:26.82 ID:rwq3+G7G.net]: >>275
それはそう。
C++ を使ってる企業を並べてもほとんどは知らん企業になるはずだわ。
286 名前：デフォルトの名無しさん mailto:sage [2021/09/02(木) 20:17:55.99 ID:cdb/p6kF.net]: >>279
イテレータも理解してないのに他スレでRustをバカ推しすんなよな
287 名前：デフォルトの名無しさん mailto:sage [2021/09/02(木) 21:18:33.70 ID:5ahReTWB.net]: イテレータも理解してないアホがいるのか
288 名前：デフォルトの名無しさん [2021/09/02(木) 21:26:15.36 ID:+7Q9WvZy.net]: >>282
ほぅ(for)（　＾ω＾）・・・
289 名前：デフォルトの名無しさん mailto:sage [2021/09/02(木) 22:29:04.14 ID:2FuyxSW6.net]: >>269
せめてfutures::io::AsyncRead,AsyncWriteトレイトあたりで中立に互換性問題なんとかしてほしい
290 名前：デフォルトの名無しさん mailto:sage [2021/09/02(木) 23:41:15.18 ID:Ubg4tWaQ.net]: >>268
これじゃナイーブ過ぎて通らないでしょ
291 名前：デフォルトの名無しさん mailto:sage [2021/09/03(金) 00:54:23.74 ID:2xSRfF9g.net]: >>283
いちゃラブ ((っ´ω`)♡(´ω`⊂ )) すればすぐわかるのにね
292 名前：デフォルトの名無しさん [2021/09/03(金) 13:54:25.02 ID:j8ut1qUg.net]: let a = [10, 20, 130, 40];
let v = vec!a;//←これってなんでダメなんですか？
293 名前：デフォルトの名無しさん mailto:sage [2021/09/03(金) 14:17:04.75 ID:9y+1HwQb.net]: >>287
そういう構文規則(syntax)だから。
二行目は、vec! はマクロ名で、直後からはマクロの
294 名前：引数列が続く。 そして、その引数列は決まった形式で書く必要があり、 vec!a という形式はそれに当てはまってない。 []: [ここ壊れてます]
295 名前：デフォルトの名無しさん mailto:sage [2021/09/03(金) 14:20:52.38 ID:12Im1YVo.net]: >>287
vec![]の[]は配列リテラルではなくて、一般的にマクロ呼び出しは[]か()か{}で引数を渡す
なので実はvec!(1)やvec!{1}も通るのだが、配列リテラルの見た目と合わせるために普通[]が使われる
296 名前：デフォルトの名無しさん [2021/09/03(金) 14:26:18.39 ID:j8ut1qUg.net]: >>288
>>289
ありがとう
コンパイラの言い分もよくわかんなかったし、助かったぜ
297 名前：デフォルトの名無しさん mailto:sage [2021/09/03(金) 15:36:22.40 ID:eAcQJHwr.net]: Cのvolatileって低レイヤで多用されるにもかかわらず実装依存なんだな
処理系依存の属性値的なのと同じようなもんか
Rustはcoreの中にvolatileアクセス用のメソッドが用意されている分進んでいる
298 名前：デフォルトの名無しさん mailto:sage [2021/09/03(金) 15:55:22.52 ID:4g+/rgm+.net]: >>287
これは視点が斬新
いい質問だな
299 名前：デフォルトの名無しさん [2021/09/03(金) 18:49:30.86 ID:XJw5Azdc.net]: 何らか単純なmacroリライトとは異なるproprocessorが必要になりそうね
cとかlisp(cより遥かにまし)みたいなエラー挟み込むだけのマクロよりかは
rustのマクロはマシよね殆ど利便性は特になくcompile前にregex雑魚ver replace導入してるだけだけど
まぁ、素直なアプローチというか何というか(´・ω・｀)
300 名前：デフォルトの名無しさん [2021/09/03(金) 23:47:36.72 ID:g/jq2Cau.net]: rustの勉強のため自作のbashコマンドを、rustで書き直してるんですが、
コマンド置換（　$(echo )　）はどうやればいいでしょうか？

Command::new('hoge').args......は調べたのですが、コマンド置換の方法が
どうしてもわかりません。
301 名前：デフォルトの名無しさん mailto:sage [2021/09/04(土) 01:53:11.04 ID:HZGHSQTb.net]: >>294
Command::outputでstdout取得してきてそれをコマンド列に埋め込むとか？
302 名前：デフォルトの名無しさん mailto:sage [2021/09/04(土) 05:20:01.42 ID:iqtSb51S.net]: インタプリタを作るのでなければ置換の必要性ある？
例えばこういうことが出来ればいいんだよね？
let s = format!("今日は{}曜日です", String::from_utf8(std::process::Command::new("date").arg("+%a").env("LANG", "ja_JP.utf8").output()?.stdout)?.trim_end());
303 名前：デフォルトの名無しさん mailto:sage [2021/09/04(土) 09:57:53.03 ID:KxfCnNFO.net]: 汚いコードだなぁ
304 名前：デフォルトの名無しさん mailto:sage [2021/09/04(土) 12:45:59.97 ID:mADKIhQi.net]: >>294
rustで書き直すのにCommandは違くないか？
bashのランタイムでevalしてるだけじゃん
305 名前：デフォルトの名無しさん mailto:sage [2021/09/04(土) 14:38:37.40 ID:1i5Z4ndW.net]: >>298
Command は system 関数相当じゃなくて fork/exec だから shell は関与しないと思ってたんだけど違うの？
306 名前：デフォルトの名無しさん mailto:sage [2021/09/04(土) 17:05:10.13 ID:iqtSb51S.net]: >>297
美しいコードをご教示して下さい
307 名前：デフォルトの名無しさん mailto:sage [2021/09/04(土) 17:33:46.64 ID:mADKIhQi.net]: >>299
fork/execだからとかそういう問題じゃなくて、
外部コマンド使うんだったら、それは単なるラッパーだろうと

要求する機能を満たすだけなら別にそれでも良いと思うが、
勉強のためにrustで書き直すというなら違和感がある
自作コマンドの内容にもよるけど
308 名前：デフォルトの名無しさん mailto:sage [2021/09/04(土) 19:48:22.92 ID:FwiYtexa.net]: >>299
もちろんshellは関与していない。
環境変数PATHに従い直接起動。
>>301
どのプログラミング言語で書いていようが、外部コマンドの呼び出しは普通にある。
それをゼロにするかどうかは様々なコストの問題。
例えば、そこがボトルネックになったら内部化など。
309 名前：デフォルトの名無しさん mailto:sage [2021/09/04(土) 20:41:42.28 ID:HZGHSQTb.net]: >>301
shell を作ってるんだから外部コマンド呼び出してなんぼだと思うんだが
310 名前：デフォルトの名無しさん [2021/09/04(土) 21:53:33.09 ID:CUdge0sZ.net]: >>303
>>294 はシェルを自作してるの？
311 名前：デフォルトの名無しさん mailto:sage [2021/09/04(土) 22:09:11.34 ID:HZGHSQTb.net]: >>304
自作のbashコマンドを自作の bash 互換シェルと読んでコマンド置換の仕組みを作ろうとしてるのかと思ったけど
もしかして bash スクリプトで書いたコマンドのことだったりする？
それにしたって外部コマンド含めて自作する必要はないと思うが
312 名前：デフォルトの名無しさん mailto:sage [2021/09/04(土) 23:54:37.12 ID:iqtSb51S.net]: なるほど
>>296と書くのではRustで書き直したことになっていないとはそういう意味か
これでいいのかな
use locale::Time;
use chrono::{Local, Datelike};
let s = format!("今日は{}曜日です", Time::load_user_locale().unwrap().short_day_name(Local::now().date().weekday().num_days_from_sunday() as usize));
313 名前：デフォルトの名無しさん mailto:sage [2021/09/05(日) 01:20:41.47 ID:lJqHVJAL.net]: $ foo=$(bar $(baz))
↓
let foo = bar(baz())
314 名前：デフォルトの名無しさん [2021/09/05(日) 14:42:42.92 ID:5vCe2TIK.net]: >>294
>rustの勉強のため自作のbashコマンドを、rustで書き直し
https://github.com/uutils/coreutils/blob/master/src/uu/echo/src/echo.rs

> コマンド置換（　$(echo )　）はどうやればいいでしょうか？
https://www.joshmcguigan.com/blog/build-your-own-shell-rust/
https://zenn.dev/garebare/articles/a463257c447fa9

独自shellスクリプトをbashやzshのように実行する際は標準入力を逐次読むインタラクティブシェルの
動作モードの他に第一引数のスクリプトパスを受け取り連続的に動作するようにしなければなりません。
上記のサンプルのように変数やコマンド置換を展開（子プロを作って実行結果を保持する）パーサーが
必要になります。（上の例ではリダイレクトやパイプなどしか処理していませんが）またファイル先頭の
#!/bin/shと同じようにshebangを認識するのはOSが行います。
そのほかにもifに使われるや"["もしくはtestなどは大昔はコマンドでしたが、現在は多くのシェルでは
組み込みのビルトインコマンドになっています。
また現在でもbashなどでクラッシュさせる脆弱性が発見されていますが、GNU bashの場合はパーサーは
手書きではなく、parse.yなどのyaccです
315 名前：デフォルトの名無しさん mailto:sage [2021/09/05(日) 19:37:48.09 ID:vqQF7q4/.net]: シェル自体をRustで実装する話なん？
316 名前：デフォルトの名無しさん mailto:sage [2021/09/05(日) 20:23:09.21 ID:qXYO1Gcj.net]: 想定外。
シェルスクリプトで書かれてる日常ツール類を、高速化＆練習ついでにRust化、ってのはよくある話なので、今回もそういうことかと想定してた。
317 名前：デフォルトの名無しさん [2021/09/05(日) 20:31:50.21 ID:Mq9n6pyZ.net]: grepの書き換えとか入門用テキストあるあるだしな俺もそれかと思ってたw

インタープリターみたいの作りたいなら単純に考えて$(.+)みたいの発見し次第rustで書かれたプログラムに書き換え
この際$(.+)の.+の部分にもrust書き換えプログラムを同様に適用のrecursiveな奴考えるな
match等でregex構文が扱いやすい分rust native interpreterみたいの造りやすそう
あとそうゆうのredos
318 名前：だかなんだかのrust os projectみたいのあるから見たら面白いんじゃね(´・ω・｀) []: [ここ壊れてます]
319 名前：デフォルトの名無しさん mailto:sage [2021/09/07(火) 12:42:27.81 ID:O1QkM6d3.net]: nullの可能性がある複数の参照を作りたい場合って
OptionとかRcを組み合わせるの？
縦によも横にもコードが長くなりそう
320 名前：デフォルトの名無しさん mailto:sage [2021/09/07(火) 13:22:01.93 ID:J2y4//gF.net]: Option<&T> や &Option<T>でも良いかも知れないけど状況次第
可変参照にしたいなら Rc<RefCell<Option<T>>> とかになるかも
321 名前：デフォルトの名無しさん mailto:sage [2021/09/07(火) 14:39:19.62 ID:vfOWvkqv.net]: Rustの文化詳しくないけど、null objectは使わないの？
せっかく静的安全性にこだわっているのに、型無しのnullを使うのはこだわりが足りない気がするなぁ。
322 名前：デフォルトの名無しさん mailto:sage [2021/09/07(火) 15:00:30.72 ID:gb4OeP+0.net]: OptionがあるのにNullObjectいらなくないです？
323 名前：デフォルトの名無しさん mailto:sage [2021/09/07(火) 15:16:47.38 ID:yn0D/zff.net]: >>314
見当違い。 >>312 はどこも指さない参照を便宜的に null と言ってるだけで、
実際には代数的データ型を活用して区別しようとしている。
324 名前：デフォルトの名無しさん mailto:sage [2021/09/07(火) 15:20:59.00 ID:oZHnA/lF.net]: NullObjectは時代遅れ過ぎる
325 名前：312 mailto:sage [2021/09/07(火) 15:36:48.61 ID:O1QkM6d3.net]: >>316
正解

ただし、Rc<RefCell<Option<T>>>とか見ちゃうと
生ポインタにしたくなってくる……
326 名前：デフォルトの名無しさん mailto:sage [2021/09/07(火) 15:42:12.42 ID:gb4OeP+0.net]: 参照をRcするような場面てあんまりないような気がする

ところでRc<RefCell<Option<T>>>は、
参照じゃなくてヒープにある（かもしれない）Tの共有になりませんか
327 名前：デフォルトの名無しさん mailto:sage [2021/09/07(火) 15:58:38.34 ID:X4ha4H+D.net]: >>319
実体は必ずヒープ上
実体の構造は(強,弱,(借,(Some,T))
そしてそのヒープ上にある実体を指してるポインタはどこにあっても複数あってもよい
328 名前：デフォルトの名無しさん mailto:sage [2021/09/07(火) 18:22:59.95 ID:J2y4//gF.net]: >>319
ヒープ上にある RefCell<Option<T>> を共有することになるね
参照 (&T) ではないというのはそう
329 名前：デフォルトの名無しさん mailto:sage [2021/09/07(火) 19:09:15.95 ID:/9ekKyA5.net]: >>316 >>318
サンクス。JavaのOptionalみたいなものね。

>>317
nullobjectと比較したときのメリットは？
条件分岐を強制させることができることくらいかしらん？
330 名前：デフォルトの名無しさん mailto:sage [2021/09/07(火) 20:06:06.42 ID:Z/GuZfd2.net]: >>322
impl<T> SomeTrait for Option<T> where T: SomeTrait { ... }
ってやれば条件分岐すら自分で書かなくていいよ
331 名前：デフォルトの名無しさん mailto:sage [2021/09/07(火) 21:28:45.74 ID:GNL8Ud6q.net]: >>323
それはTraitのメソッドで分岐相当のコードを書くか
chainさせるだけで分岐処理を遅延するかのどちらかなので
分岐すら自分で書かなくていいというのはちょっと違う気がする
332 名前：デフォルトの名無しさん [2021/09/07(火) 22:29:28.46 ID:KSe0arFM.net]: 本来はOption/Result/(Either)はRust言語的な仕組みでは無く、ライブラリの作法に過ぎないが、ランタイムが
無いはずなのに、Resultなどで宣言しているところで原則として捕捉しないpanicがあるのは納得できない人は
結構いると思う。言語の構文でmatchや?など、まさにそれのサポート構文があるのに、unwrapしたらpanicで
この話は嫌がる人が結構いるけど、OptionもResultもPanicも取っ払った最小の標準ライブラリが欲しい
333 名前：デフォルトの名無しさん mailto:sage [2021/09/07(火) 22:45:10.91 ID:rBwLSogt.net]: >>325
何が言いたいのか分からん
334 名前：デフォルトの名無しさん mailto:sage [2021/09/07(火) 23:03:38.48 ID:2A/XDTjQ.net]: >>325
そこは使い分け。
エラーな時にそのままエラー吐かせても構わない場合は、main()をResult型にしてしまうし、
きちんとエラー処理する必要あるものな場合は、少なくともmain()やそれより下でmatchでResultを必ず受け止める。
335 名前：デフォルトの名無しさん mailto:sage [2021/09/07(火) 23:11:59.18 ID:oZHnA/lF.net]: >>322
比較すべきものではない
ヌルオブジェクトはインターフェースで型を隠蔽する手法
一方Optionは型をラップすることでエラーを明示する手法
似てるようで根本が違う
336 名前：デフォルトの名無しさん mailto:sage [2021/09/07(火) 23:18:49.53 ID:2A/XDTjQ.net]: あと後者の場合、unwrap()も基本的には使わない。
例外的に使うのはフィルタし終えて必ずSome(T)となっているものを剥がす時だけ。
つまりpanicはさせないので、その>>325の懸念事項は発生しない。
337 名前：デフォルトの名無しさん mailto:sage [2021/09/08(水) 07:19:42.43 ID:yXT40j/x.net]: 素人です、質問させてください
Rustでスマホアプリやwebアプリは作れますか？
作れるとしたら
java/kotlinやswiftやjavascriptより作りやすいですか？
アプリ制作でこれらの言語よりRustは優れてますか？
338 名前：デフォルトの名無しさん mailto:sage [2021/09/08(水) 07:34:28.50 ID:bql1CtjZ.net]: Rust＋JavaScriptでウェブアプリとそのためのサーバーサイドは作れる
ウェブブラウザ上ではJavaScriptが必須なのでRustだけにはできない
ただしウェブブラウザ上ではJavaScriptに加えてWebAssembly(Wasm)も動いてこれはRustで書いたプログラムが動く
なのでJavaScript部分を最小限にしてRustで書いたWasmがメインというケースもないわけではない
サーバーサイドはRustだけで全て構築できる
339 名前：デフォルトの名無しさん mailto:sage [2021/09/08(水) 07:48:35.45 ID:yXT40j/x.net]: ありがとうございました
スマホアプリを作るならKotlinやswiftってことなんですね
大変に参考になりました。ありがとうございました。
340 名前：デフォルトの名無しさん mailto:sage [2021/09/08(水) 08:09:19.60 ID:nCYYHiA4.net]: オマケみたいなもんやな
341 名前：デフォルトの名無しさん mailto:sage [2021/09/08(水) 08:14:48.98 ID:bql1CtjZ.net]: >>332
そんなことはない
スマホアプリならKotlinとSwiftの2種類を無駄に覚えずともJavaScriptだけで両OS向けスマホアプリ作成が可能
もちろんスマホでもウェブアプリが動きアプリの種類によってはウェブアプリで十分なためスマホアプリを作らないケースも出ている

一方でRustで書いてAndroid上でツワモノもいるがそれはおいとくとして
Rustをこの件で使うケースはウェブブラウザで動くWasmのプログラミングする時かサーバーサイド側
あとはGoogleがAndroid OS開発にRustを使い始めた
342 名前：デフォルトの名無しさん mailto:sage [2021/09/08(水) 14:35:34.40 ID:kw5H9VGz.net]: めっちゃWasm使ってるわ、使い心地としてはgoのが良いのだが
てか絶対JS書きたくない勢以外は勧められないけどな
エントリーポイントで4～5行JS書かざるを得ないが、そこはコピペだから俺は1行も書いてない
343 名前：デフォルトの名無しさん [2021/09/08(水) 19:04:28.13 ID:beXhRlkk.net]: >>335
javascriptからwasmにディスパッチする際のオーバーヘッドってどう？
344 名前：デフォルトの名無しさん mailto:sage [2021/09/08(水) 19:45:38.33 ID:tR72XlKG.net]: getopt()みたいなのでRust標準はどのクレイト？
345 名前：デフォルトの名無しさん mailto:sage [2021/09/08(水) 20:27:20.45 ID:aH1RnViv.net]: clapだけど、それを使ったさらに便利なstructoptのほうがおすすめかも
346 名前：デフォルトの名無しさん mailto:sage [2021/09/08(水) 21:24:09.27 ID:Ug8WkgwI.net]: clapはv3でstructoptの機能を取り込むから、今ならclapの3.0.0-beta4を使うのでもいいかも
347 名前：デフォルトの名無しさん mailto:sage [2021/09/08(水) 21:44:07.80 ID:XbOUeFJA.net]: >>339
その後、structoptはどうなるの？
348 名前：デフォルトの名無しさん mailto:sage [2021/09/08(水) 23:46:53.75 ID:tR72XlKG.net]: >>339
なるほど
v2のビルダー方式に加えて
v3でマクロ多用で見やすく書きやすくすっきりしたという感じ？
349 名前：デフォルトの名無しさん mailto:sage [2021/09/09(木) 00:04:52.59 ID:fa/WJTRs.net]: マクロは見やすさだけじゃなくてコンパイル時に諸々チェックされるのが嬉しい
350 名前：デフォルトの名無しさん mailto:sage [2021/09/09(木) 20:16:33.24 ID:Rwhy6P/q.net]: 数値の並びがある時に
その中の一番大きなものがある場所(index)が欲しいのですが
Rustではどう書くとよいでしょうか？
351 名前：デフォルトの名無しさん mailto:sage [2021/09/09(木) 20:38:00.34 ID:fa/WJTRs.net]: >>343
たとえばこう
https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=c7a0d0459c540d7b373b124d7faf239a
352 名前：デフォルトの名無しさん mailto:sage [2021/09/09(木) 21:09:46.20 ID:18O2MBOf.net]: >>344
copied()っているっけ？
353 名前：デフォルトの名無しさん mailto:sage [2021/09/09(木) 21:32:28.08 ID:Rwhy6P/q.net]: ありがとうございます
無しでもいけました

別の質問です
Vecにスライス(の各値のコピー)をappendしたいのですが
append()メソッドはVecしか引数に取れず困っています
どうすればいいでしょうか？
354 名前：デフォルトの名無しさん mailto:sage [2021/09/09(木) 21:36:39.36 ID:dEhWYfPh.net]: ちったあググれよ
教えて君は嫌われるよ
355 名前：デフォルトの名無しさん mailto:sage [2021/09/09(木) 21:55:23.66 ID:aKI9+8DZ.net]: >>346
https://doc.rust-lang.org/std/vec/struct.Vec.html
356 名前：デフォルトの名無しさん mailto:sage [2021/09/09(木) 22:34:44.73 ID:18O2MBOf.net]: >>346
append()はその名前から想像しにくい実はムーブで引数側のVecは空になるｗ
じゃあappendはどうすればいいかというと
1つだけappendするpush()の複数版のpush_all()が元々あって
それは名前変更で今はextend_from_slice()になった
がその中身はより一般化したExtendトレイトのextend()を呼んでるだけになったので
結論としてはv.extend(&a)が正解
357 名前：デフォルトの名無しさん mailto:sage [2021/09/09(木) 23:25:03.49 ID:12Nq5czF.net]: Rust 1.55.0 リリース
358 名前：デフォルトの名無しさん mailto:sage [2021/09/10(金) 01:12:44.66 ID:t0Gbnfvj.net]: faqのような気がするんだが、以下のようなコードって
どうすればコンパイル通る？

#[derive (Copy)]
struct St{
s: String
}

fn main(){
let ar = [St{s: String::from("str")}; 10];
}
359 名前：デフォルトの名無しさん mailto:sage [2021/09/10(金) 01:34:46.88 ID:Dnq/g++J.net]: 参照を配列に格納するか
let st = St{s: String::from("str")};
let array = [&st; 10];

Stringじゃなく&strにするか
#[derive (Debug, Clone, Copy)]
struct St{
s: &'static str
}

かな？
360 名前：デフォルトの名無しさん mailto:sage [2021/09/10(金) 01:38:58.21 ID:t0Gbnfvj.net]: >>352
なるほど
勉強になりました
ありがとん
361 名前：デフォルトの名無しさん mailto:sage [2021/09/10(金) 01:44:26.77 ID:59f2QwjZ.net]: >>351
Stringはヒープ上なのでstructの中でCopyは無理

>>352
そのStringも使わずにこれでいけますね
#[derive(Clone,Copy,Debug)]
struct St {
s: &'static str,
}
fn main() {
let ar = [St {s: &"str"}; 10];
println!("{:?}", ar);
}
362 名前：デフォルトの名無しさん mailto:sage [2021/09/10(金) 05:44:54.18 ID:XIGB6bHM.net]: もはやご希望のものかどうかはわからんが

#[derive(Clone)]
struct St{
s: String
}

fn main(){
let ar = vec![St {s: String::from("str")}; 10];
}

CopyをCloneして配列をvecにしただけ
363 名前：デフォルトの名無しさん mailto:sage [2021/09/10(金) 06:59:27.65 ID:59f2QwjZ.net]: >>355
vec!は単なるマクロでVec作ってるだけなので
それだと動的にヒープにString作って
そのVecを動的にヒープに作ってる
一方で>>354はヒープを全く使わないという差ですね
364 名前：デフォルトの名無しさん mailto:sage [2021/09/10(金) 07:55:51.69 ID:tPSWyt2L.net]: >>354
>そのStringも使わずにこれでいけますね
それ>>352に書いてるのと同じじゃんw
365 名前：デフォルトの名無しさん mailto:sage [2021/09/10(金) 13:58:45.81 ID:iOAXb/4V.net]: >>351
その後の用途によって7通りのやり方がある

let st = St {s: &"str"}; の場合は
let ar = [st; 10];
let ar = [&st; 10];
let ar = vec![st; 10];
let ar = vec![&st; 10]; の4通りが使い分け可能で
1番目はまとめて let ar = [St {s: &"str"}; 10];
3番目はまとめて let ar = vec![St {s: &"str"}; 10]; と省略可能
2番めと4番目が省略できない理由は参照なのに実体が変数にバインドされていないため

let st = St {s: String::from("str")}; の場合は
let ar = [st; 10]; の1番目だけは出来なくて
let ar = [&st; 10];
let ar = vec![st; 10];
let ar = vec![&st; 10]; の3通りが可能
3番目はまとめて let ar3 = vec![St {s: String::from("str")}; 10]; と省略可能
1番目が出来ない理由はヒープ上に作られるStringを暗黙的にコピーできないため
366 名前：デフォルトの名無しさん mailto:sage [2021/09/10(金) 15:18:43.49 ID:ylBsVH1G.net]: 無駄な長文乙
367 名前：デフォルトの名無しさん [2021/09/11(土) 02:12:58.97 ID:xfwty4qw.net]: 数百行程度で、Rustらしいコードの例ってありませんか？
368 名前：デフォルトの名無しさん mailto:sage [2021/09/11(土) 02:31:10.17 ID:PFLibieQ.net]: >>360
何に使うん？
紹介プレゼンとか？
369 名前：デフォルトの名無しさん [2021/09/11(土) 02:47:02.21 ID:xfwty4qw.net]: >>361
学習のために自分で読むだけです
370 名前：デフォルトの名無しさん mailto:sage [2021/09/11(土) 02:58:05.44 ID:s9euJTi1.net]: 現状はどのレベル？
とりあえず入門書は読み終わったって感じ？
371 名前：デフォルトの名無しさん mailto:sage [2021/09/11(土) 03:10:01.40 ID:w5S7rLqj.net]: >>362
例えば>>3と>>4にあるRust各book十数個のうちどれくらい読んでみましたか？
372 名前：デフォルトの名無しさん mailto:sage [2021/09/11(土) 04:59:53.97 ID:7r8uHUGr.net]: ただのコード例ってのとは違うけどこれ読み進めるとかどうだろう
https://rust-unofficial.github.io/too-many-lists/index.html

Linked Listを色々頑張るやつ
373 名前：デフォルトの名無しさん mailto:sage [2021/09/11(土) 05:21:08.84 ID:w5S7rLqj.net]: >>365
それはあまりにも偏った特殊ケースであることと
初心者向けではないということと
その件だとむしろ標準ライブラリとして提供されているリンクリストや双方向キューを覚えた方が実用的かなーhttps://doc.rust-lang.org/std/collections/
374 名前：デフォルトの名無しさん [2021/09/11(土) 17:59:37.96 ID:iQv7wiiS.net]: >>349
なるほど
375 名前：デフォルトの名無しさん mailto:sage [2021/09/11(土) 21:06:20.65 ID:KPnRgCeh.net]: Rustは可読性をもう少し良くできなかったのかな
後発なのにJavaより読みにくいってのは問題だろ
376 名前：デフォルトの名無しさん mailto:sage [2021/09/11(土) 21:16:46.98 ID:PRM8i6LA.net]: >>368
どのあたりが？
377 名前：デフォルトの名無しさん mailto:sage [2021/09/11(土) 22:08:56.74 ID:UoP9tTBS.net]: >>368
どうすれば良くなると思う？
378 名前：デフォルトの名無しさん mailto:sage [2021/09/11(土) 22:10:09.25 ID:HMdcT5ar.net]: >>370
専用フォントを開発
379 名前：デフォルトの名無しさん mailto:sage [2021/09/11(土) 23:22:27.41 ID:7r8uHUGr.net]: Javaより読みにくいとはさすがに思わんけど、
ジェネリクスが<>囲いなところとか、
そもそも中かっこ＋セミコロンってのもどうなんだ、とか
Haskell並にとは言わんがもうちょっとかっこ少なくかけないのか、とか
思うところはいろいろとある
380 名前：デフォルトの名無しさん mailto:sage [2021/09/11(土) 23:44:46.13 ID:zUj2TAiQ.net]: >>372
ジェネリクスが<>囲いなところ、ってメジャーなプログラミング言語のほとんどがそうだよね？
381 名前：デフォルトの名無しさん mailto:sage [2021/09/11(土) 23:48:51.34 ID:7r8uHUGr.net]: >>373
その通りだけどあんまり筋がよくないことでもちらほらごく一部の界隈で話題になってるような
382 名前：デフォルトの名無しさん mailto:sage [2021/09/12(日) 00:05:19.01 ID:2NCRgpdh.net]: 変にRubyの影響受けてる部分は変えて欲しいなあ
383 名前：デフォルトの名無しさん mailto:sage [2021/09/12(日) 00:20:02.96 ID:Q5FBinyU.net]: >>374
コンパイラ実装の問題なら承知した上で敢えて <> 採用してる
曖昧性の問題は turbofish で解決するなどコンパイラ実装を複雑にしない範囲で慣例的な記法に近づけている

>>375
Rubyの影響ってクロージャの記法のことかな？
384 名前：デフォルトの名無しさん mailto:sage [2021/09/12(日) 00:39:47.78 ID:qC6wZUfs.net]: それはSmalltalkじゃないの？
385 名前：デフォルトの名無しさん mailto:sage [2021/09/12(日) 00:49:53.96 ID:Q5FBinyU.net]: https://doc.rust-lang.org/reference/influences.html
ここによるとクロージャの記法はRuby由来
386 名前：デフォルトの名無しさん mailto:sage [2021/09/12(日) 01:31:54.94 ID:q/A4LK0H.net]: クロージャの記法は各言語で様々だから大して気にならないけど
こう書きたいのに書けないのが悲しい

fn make_counter_closure(init: i32) -> impl FnMut() -> i32 {
　let mut counter = init;
　move || counter--
}

この件はRustやRubyだけでなくPythonやScalaやSwiftなどでも同じで
Swiftでは昔は出来たのに後から削除されたようだから最近はそういう傾向なの？
387 名前：デフォルトの名無しさん mailto:sage [2021/09/12(日) 01:35:25.37 ID:x/LB5mED.net]: >>378
RubyのクロージャがSmalltalk由来だからどうなんだろ
388 名前：デフォルトの名無しさん mailto:sage [2021/09/12(日) 07:25:17.64 ID:+2JnoCR+.net]: >>379
++と―はバグの温床だからそういう傾向
Swiftから削除されたのもRustでrejectされてるのも同じ理由
389 名前：デフォルトの名無しさん mailto:sage [2021/09/12(日) 08:11:23.50 ID:s09Gb+ph.net]: だッさw
390 名前：デフォルトの名無しさん mailto:sage [2021/09/12(日) 10:53:10.17 ID:Q5FBinyU.net]: >>380
起源をたどればそうかもしれないけどRustが直接的に影響を受けたのはRuby
391 名前：デフォルトの名無しさん mailto:sage [2021/09/12(日) 12:43:40.70 ID:7NdeG55C.net]: ベストなジェネリクスの書き方ってなんだよ
Scalaみたいなのがいいの？
392 名前：デフォルトの名無しさん mailto:sage [2021/09/12(日) 14:11:08.78 ID:aiqNVBie.net]: Scalaみたいに[]にするのもアリだけど配列がちょっとアレになるからさすがに避けたい気がする
D言語みたいに、例えば定義時には
struct(T) Foo { foo: T }
impl(T) Foo {
fn(T) new(foo: T) { Self { foo } }
}
みたいな感じにして、使用時には
let bar = Foo!i64::new(42);
って感じにするとか・・・？
実際に書いてみるとこれはこれで微妙な気もするが
393 名前：デフォルトの名無しさん mailto:sage [2021/09/12(日) 14:19:29.99 ID:UrK9UNLE.net]: >>379
そこは
{ let result = counter; counter -= 1; result }
または
{ counter -= 1; counter + 1 }
になるの？
394 名前：デフォルトの名無しさん mailto:sage [2021/09/12(日) 15:54:09.04 ID:aiqNVBie.net]: move || { counter-=1; counter }では？？？
395 名前：デフォルトの名無しさん mailto:sage [2021/09/12(日) 15:59:39.60 ID:lBuMyCBZ.net]: >>387
それは後置デクリメントになっていない
396 名前：デフォルトの名無しさん mailto:sage [2021/09/12(日) 16:29:00.55 ID:aiqNVBie.net]: 後置であるということをそもそも認識できていなかった、やっべえ
397 名前：デフォルトの名無しさん mailto:sage [2021/09/12(日) 16:37:25.63 ID:458u6HPV.net]: まさにバグの温床となりうることが示されたな
398 名前：デフォルトの名無しさん mailto:sage [2021/09/12(日) 16:48:32.00 ID:Q5FBinyU.net]: >>385
初期Rustは [] だったけどまさに配列と被るからと言う理由で <> にした
C++と親和性のある構文を目指しているので <> 以外は採用されにくいと思う
399 名前：デフォルトの名無しさん mailto:sage [2021/09/12(日) 22:21:50.69 ID:s09Gb+ph.net]: >>387
見ろ！Rustがゴミのようだ！
400 名前：デフォルトの名無しさん mailto:sage [2021/09/13(月) 00:58:36.15 ID:1X9d0oCW.net]: 型変数を明示しなきゃならないのは汎用プログラミング言語の欠点だよな
401 名前：デフォルトの名無しさん mailto:sage [2021/09/13(月) 01:54:16.68 ID:+ZZ666OR.net]: 何言ってんだこのバカ
402 名前：デフォルトの名無しさん mailto:sage [2021/09/13(月) 11:03:41.66 ID:HWJQ0k95.net]: let mut counter = init + 1;
move || { counter -= 1; counter }

これが普通だと思うのは俺だけか？
403 名前：デフォルトの名無しさん mailto:sage [2021/09/13(月) 16:07:27.15 ID:1X9d0oCW.net]: >>395
Rubyだと普通にそういう書き方するから特に違和感はないな
404 名前：デフォルトの名無しさん mailto:sage [2021/09/14(火) 21:41:07.14 ID:qEUG/jlq.net]: 配列がusizeだけなのを何とかして欲しい
i32 as usizeとかいちいち面倒
405 名前：デフォルトの名無しさん mailto:sage [2021/09/14(火) 21:52:21.64 ID:yDfeC3hP.net]: >>397
普通に開発していればむしろusizeという別の型になってるおかげでミスなどに気付けて助かったことある人多いと思う
i32と別になっていることは非常に重要
406 名前：デフォルトの名無しさん mailto:sage [2021/09/14(火) 23:13:54.76 ID:/xeH/JpQ.net]: usizeだとうっかりマイナスにしちゃって死ぬことがある
デバッグビルドならぱにくって気づくけど、
テストすり抜けちゃうとやばい
407 名前：デフォルトの名無しさん mailto:sage [2021/09/14(火) 23:25:50.44 ID:G8gCvJ5V.net]: i32は流石にどうかと思うけど
グリッドの4-隣接とか8-隣接をforで回すときに中心からの差分で表現したくて、
isizeとusize�
408 名前：ﾅガチャガチャ変換したときはちょっとウザいなーとは思った []: [ここ壊れてます]
409 名前：デフォルトの名無しさん mailto:sage [2021/09/14(火) 23:35:48.81 ID:9cp1Eg6y.net]: impl From<u16> for usize はあるのに u32 はないのが面倒
usize のサイズがプラットフォーム依存なのは分かるけど毎回 trt_from().unwap() したくない
410 名前：デフォルトの名無しさん mailto:sage [2021/09/15(水) 06:35:42.54 ID:21ZYJzvz.net]: Rustの難しさってある程度マスターしたあとは納得の難しさなんですか？

面倒だなー。でも（メモリ安全のためには）しょうがないか～、みたいな
411 名前：デフォルトの名無しさん mailto:sage [2021/09/15(水) 07:06:01.76 ID:WxLXvftP.net]: バカ矯正用補助輪付言語の難しさ
412 名前：デフォルトの名無しさん mailto:sage [2021/09/15(水) 07:55:49.68 ID:nFHSO/L2.net]: 補助輪なし言語でバグなしプログラム作れたらどこに行っても採用されると思うよ
413 名前：デフォルトの名無しさん mailto:sage [2021/09/15(水) 08:36:21.78 ID:P0HV9c3B.net]: >>401
asでいけないっけ
414 名前：デフォルトの名無しさん mailto:sage [2021/09/15(水) 09:04:47.19 ID:77IP/X5S.net]: >>405
asでも良いけどreleaseだとオーバーフローチェックしてくれないから心許ない
constの文脈だとunwrap使えないからas使わざるを得ないけど
415 名前：デフォルトの名無しさん mailto:sage [2021/09/15(水) 09:15:01.47 ID:P0HV9c3B.net]: オーバーフローの懸念がある文脈ならtry_fromはしょうがないのでは
usizeがu32以上のプラットフォームだけ想定するならasでいいように思えちゃうんだけど
416 名前：デフォルトの名無しさん mailto:sage [2021/09/15(水) 09:44:19.90 ID:77IP/X5S.net]: asを使うとu32から別の型に変更したときに修正漏れのリスクがあるのが気になってしまう
まあfrom相当のユーティリティ関数自分で用意すれば良いか
417 名前：デフォルトの名無しさん mailto:sage [2021/09/15(水) 15:12:38.68 ID:6EsPXkcj.net]: >>398
じゃあunsafe時には許可して欲しい
418 名前：デフォルトの名無しさん mailto:sage [2021/09/15(水) 15:24:13.77 ID:a6LjJ0wO.net]: 暗黙の型変換が増えるのはやだよ
419 名前：デフォルトの名無しさん mailto:sage [2021/09/15(水) 20:24:30.93 ID:77IP/X5S.net]: 緩く簡単に書きたい人向けの言語じゃないよね全体的に
420 名前：デフォルトの名無しさん mailto:sage [2021/09/15(水) 21:01:30.58 ID:AIQN4pXi.net]: それはそう
緩く簡単に書けるせいで起きていた全てのバグを撲滅したい、的な執念を感じる
421 名前：デフォルトの名無しさん mailto:sage [2021/09/15(水) 21:30:37.23 ID:rqQTOJGj.net]: IntelliJ Rust pluginの新バージョン、関数とかの補完を機械学習でやるんだってさ
すごいね
試してないけど
422 名前：デフォルトの名無しさん mailto:sage [2021/09/16(木) 00:03:22.08 ID:5v2yv6GZ.net]: 誰も見ていなければ海や川でも裸で泳ぐCちゃんと
温泉の女湯でも深夜一人で水着で入るRustちゃん
423 名前：デフォルトの名無しさん mailto:sage [2021/09/16(木) 00:56:52.16 ID:sz29YBQA.net]: エラーハンドリング可能な形ですっきりしたルールを定義できるならやればいいんだけど
現実にそういう上手い方法がないなら煩雑でも変換の手順を書くしかない。
424 名前：デフォルトの名無しさん mailto:sage [2021/09/16(木) 01:12:36.12 ID:Efcezeu+.net]: 低レイヤーいじる言語のエラー処理内容の粒度はそれこそプログラムごとに違うとしか言いようがない。
だから仕方ない。
425 名前：デフォルトの名無しさん mailto:sage [2021/09/16(木) 05:10:39.16 ID:7K5k42SQ.net]: >>414
泳いでるのをDQNに見つかって乱暴されるCちゃん
そもそもDQNに覗かれるような温泉には入らないRustちゃん
426 名前：デフォルトの名無しさん mailto:sage [2021/09/16(木) 05:50:12.68 ID:P9SoBPvJ.net]: おっきしてきた
427 名前：デフォルトの名無しさん mailto:sage [2021/09/16(木) 06:27:10.25 ID:s4mLRLKS.net]: 椎ちゃんの方逝くわw
428 名前：デフォルトの名無しさん mailto:sage [2021/09/16(木) 18:55:26.69 ID:cHl8Y0Er.net]: as usize祭り絶賛開催中

unsafe fn calc(a_index: isize, b_index: isize) -> isize {
　if a_index == a.len() as isize { return 0; };
　let mut res: isize = 0;
　for i in b_index..b.len() as isize {
　　if a[a_index as usize] == b[b_index as usize] {
　　　res = res.max(calc(a_index + 1, b_index + 1) + 1);
　　}
　}
　res
}
429 名前：デフォルトの名無しさん mailto:sage [2021/09/16(木) 19:34:21.47 ID:vxj0ze2Y.net]: >>420
関数に定義されていない変数が使われまくり
forループの中に変動変数がなく毎回同じ実行
キチガイのコードを読むべきでなかった
430 名前：デフォルトの名無しさん mailto:sage [2021/09/16(木) 19:36:15.88 ID:cHl8Y0Er.net]: unsafeだしな

そして、その指摘にas usizeを擁護（容認）する意見は皆無だっていう
431 名前：デフォルトの名無しさん mailto:sage [2021/09/16(木) 19:38:22.07 ID:cHl8Y0Er.net]: あと祭り発生中の実況だったので稼働するコードではなく、

if a[a_index as usize] == b[i as usize] {
}

と修正した
432 名前：デフォルトの名無しさん mailto:sage [2021/09/16(木) 20:03:32.03 ID:Y8GNLhYC.net]: なんでunsafeなのかもわからないしなんでusizeじゃなくてisizeを受け取るのかもわからん
433 名前：デフォルトの名無しさん mailto:sage [2021/09/16(木) 20:06:54.23 ID:Y8GNLhYC.net]: ああ、aとbグローバル変数なんかこれ？
434 名前：デフォルトの名無しさん mailto:sage [2021/09/16(木) 20:47:15.02 ID:cHl8Y0Er.net]: 引数がマイナスになることもあるので条件判断の必要からisizeなんだよね
もしusizeを引数にするとしても、引数に渡すところでisize as usizeになるので、やっぱりusize祭りが大発生

お祭りワッショイワッショイ
435 名前：デフォルトの名無しさん mailto:sage [2021/09/16(木) 21:30:12.52 ID:+FxVjnil.net]: 引数がマイナスになるならチェックしないと範囲外アクセスするだろ馬鹿か？
436 名前：デフォルトの名無しさん mailto:sage [2021/09/16(木) 22:25:53.04 ID:XSar1IoX.net]: 今どきIndex使って回すとか化石脳かよ
437 名前：デフォルトの名無しさん mailto:sage [2021/09/16(木) 22:48:14.07 ID:VRkuCUuZ.net]: ボロクソワロタ
438 名前：デフォルトの名無しさん mailto:sage [2021/09/16(木) 23:11:45.54 ID:C/6oeybD.net]: >>425
グローバル変数を使うのはありえないな
staticは使ってもモジュール内に閉じ込める
どの言語でも常識
439 名前：デフォルトの名無しさん mailto:sage [2021/09/17(金) 01:14:24.53 ID:+px3FZ+H.net]: グローバル変数小文字にしたら警告出なかったっけ
440 名前：デフォルトの名無しさん mailto:sage [2021/09/17(金) 03:56:57.86 ID:L8yNiQtv.net]: そもそもusizeで受け取って呼び出し側でケアすべきやろ
441 名前：デフォルトの名無しさん mailto:sage [2021/09/17(金) 13:27:45.55 ID:5NPaLNkl.net]: >>412
経験的に、縛れば縛るほど最終的にはラクできるようなのを皆知ってると思う
ラクに書けるような言語は一見いいのだが
人間が生まれ持って自堕落であるのを伴って
最終的には苦しみをもたらすことになるコードを書いてしまう
442 名前：デフォルトの名無しさん mailto:sage [2021/09/17(金) 15:13:45.88 ID:dr0oo8mV.net]: >>420も煽りのつもりで普段書いてないrustを
イキって書いたんだろうけど
煽り返された上にクソコードが掲示板に一生残るのは辛いよなあ
443 名前：デフォルトの名無しさん mailto:sage [2021/09/17(金) 15:20:07.79 ID:0JdlCgnp.net]: 3歩あるけば忘れるからヘーキヘーキ
444 名前：デフォルトの名無しさん mailto:sage [2021/09/17(金) 16:32:00.60 ID:5ZlSq2T+.net]: いきなり unsafe fn とか書いてるあたり普段からrust書いるが競プロとかでついた変な癖を引きずってる人だと思う
余計悪いが
445 名前：デフォルトの名無しさん mailto:sage [2021/09/17(金) 17:02:49.25 ID:+63qaQLV.net]: >>420
これって何するコードなの？
446 名前：デフォルトの名無しさん mailto:sage [2021/09/17(金) 18:51:16.87 ID:s3DmK0IG.net]: >>437
ゴミカスコード力を披露するコードだよ
Rustどうこう言うやつはこのレベルが多い
447 名前：デフォルトの名無しさん mailto:sage [2021/09/17(金) 20:36:20.90 ID:B1Ewzio/.net]: usize祭り絶賛発生中

while !next_pos.is_empty() {
　let mut tmp_next_pos: Vec<(i32, i32)> = Vec::new();
　for &(n_yr, n_xc) in &next_pos {
　　map[n_yr as usize][n_xc as usize] = 2;

　　for (a_yr, a_xc) in around(n_yr, n_xc) {
　　　if a_yr >= 0 && a_yr < m_yr + 2 && a_xc >= 0 && a_xc < m_xc + 2 {
　　　　if map[a_yr as usize][a_xc as usize] == 0 {
　　　　　map[a_yr as usize][a_xc as usize] = 2;
　　　　　tmp_next_pos.
448 名前：push((a_yr, a_xc)) } if map[a_yr as usize][a_xc as usize] == 1 { total += 1; } } } } next_pos = tmp_next_pos; } []: [ここ壊れてます]
449 名前：デフォルトの名無しさん mailto:sage [2021/09/17(金) 21:04:31.14 ID:dr0oo8mV.net]: >>439
しつこいなw
450 名前：デフォルトの名無しさん mailto:sage [2021/09/17(金) 21:09:35.15 ID:j5AVpFMs.net]: isize ってどういう時に使います？
添字は基本的に usize しか使いませんし符号付き整数が欲しくなったらi32かi64で大体事足りるのでいまいち使い所が分かってません
451 名前：デフォルトの名無しさん mailto:sage [2021/09/17(金) 21:43:47.45 ID:hv2MZm4l.net]: 添え字に使う値を算出する途中計算で負数が必要になったら isize が妥当という場合もある。
452 名前：デフォルトの名無しさん [2021/09/17(金) 21:44:59.72 ID:NEgFw8y9.net]: can isize and usize be different in rust?
Can isize and usize be different? Both of them can be used for memory size, index, offset.
Since usize is used for arrays why don't we just have usize
I am new to Rust so this might be a basic question.

・usize cannot be negative and is generally used for memory addresses, positions, indices, lengths (or sizes!).
・isize can be negative, and is generally used for offsets to addresses, positions, indices, or lengths.

https://stackoverflow.com/questions/55506647/can-isize-and-usize-be-different-in-rust
意識高い系がウンコードを量産し罵倒するクソスレ
453 名前：デフォルトの名無しさん mailto:sage [2021/09/17(金) 21:45:51.61 ID:B1Ewzio/.net]: そして、その結果、as usize祭りにもなる場合もある
454 名前：デフォルトの名無しさん mailto:sage [2021/09/17(金) 21:51:17.48 ID:2U7psvzf.net]: >>432
経験的に縛れば縛るほど脱法行為が横行する。
455 名前：デフォルトの名無しさん [2021/09/17(金) 22:20:51.81 ID:so2YCyjR.net]: RustlingsをReplitで動かして学習したいのですが、これってrustlingsコマンドはどうやって動かすのですか？
https://github.com/rust-lang/rustlings
公式サイトが用意しているReplitの環境で学習をやりたいのです

よろしくお願いします
456 名前：デフォルトの名無しさん mailto:sage [2021/09/17(金) 23:24:24.54 ID:L8yNiQtv.net]: >>446
ReplitのRustのバージョンが古くて(1.44）ビルド失敗するっぽい
見た感じローカルでやるのとそんな変わらん気がするから、
こだわりないならローカルでやるのが吉
この環境ビルドむっちゃくちゃ遅いし
457 名前：デフォルトの名無しさん mailto:sage [2021/09/17(金) 23:26:48.18 ID:qc9SKwMT.net]: >>439
なぜそんなに下手なの？
配列のインデックスを取り出して配列をアクセスしてるだけなら
そのインデックスは最初からusize型にしておくだけてしょ
458 名前：デフォルトの名無しさん mailto:sage [2021/09/17(金) 23:34:57.92 ID:L8yNiQtv.net]: >>445
脱法行為もなにも>>420のコードで負のindex渡されたらおかしくなるやんけ
459 名前：デフォルトの名無しさん mailto:sage [2021/09/17(金) 23:57:58.10 ID:L8yNiQtv.net]: とはいえasﾅﾝﾄｶが一部のシチュエーションでめんどくさくなることはある（主に競プロ）

let (h, w) = (100usize, 100usize); // 多くの箇所ではusizeとして扱っている
let grid = vec![vec![0; w]; h]; // 横幅w 縦幅h 左上のマスの座標(0,0)のgrid

// 省略（なんかいろいろやる）

let (x, y) = some_func(); // 着目対象となるgridのマスの位置を(usize, usize)で取得

// (x, y)の上下左右のマスを対象になにかやる
for &(dx, dy) = &[(1i32, 0i32), (-1, 0), (0, 1), (0, -1)] {
let (x2, y2) = (x as i32 + dx, y as i32 + dy);
if x2 < 0 || x2 >= w as i32 || y2 < 0 || y2 >= h as i32 {
continue; // x2,y2がgridからはみ出してたら処理飛ばす
}
let (x2, y2) = (x2 as usize, y2 as usize); // できるだけusizeで処理したいので
// 省略（x2, y2を使っていろいろやる）
}

上下左右調べたいときに負の値が出てくるのがめんどくさい

一応workaroundはあって、for以下をこうする手がある
!0が2の補数的には-1として扱えるのでオーバーフローOKな足し算をする

for &(dx, dy) = &[(1usize, 0usize), (!0, 0), (0, 1), (0, !0)] {
let (x2, y2) = (x.wrapping_add(dx), y.wrapping_add(dy));
if x2 >= w || y2 >= h {
continue; // x2,y2がgridからはみ出してたら処理飛ばす
}
// 省略（x2, y2を使っていろいろやる）
}
460 名前：デフォルトの名無しさん mailto:sage [2021/09/18(土) 00:02:40.07 ID:WtcFUHdh.net]: 競技プログラミングは
正しいプログラミングスタイルから離れていく悪です
競技プログラミングスタイルな人と一緒に開発したい人は存在しないでしょう
461 名前：デフォルトの名無しさん mailto:sage [2021/09/18(土) 00:04:38.74 ID:JD4YYnZP.net]: 正当なスタイルが分かった上で競技としての割り切り方も分かっているなら問題ないんだけど、
競技から学ぶと変な癖が付きやすいというのは私も感じるなぁ。
462 名前：デフォルトの名無しさん mailto:sage [2021/09/18(土) 00:15:51.96 ID:NeCiGTRe.net]: >>441
off_tとかptrdiff_tの代わり
例えば <*const T>::offset なんかはisizeを引数に取る
463 名前：デフォルトの名無しさん mailto:sage [2021/09/18(土) 00:21:57.18 ID:NeCiGTRe.net]: >>450
自分はだいたい座標やwidth/heightはi32で扱って
indexへの変換処理を関数に抽出してそこでusizeに変えてる
一次元配列に二次元データ入れるときも自然に書ける
464 名前：デフォルトの名無しさん [2021/09/18(土) 01:57:08.86 ID:T/YDtroe.net]: type off_t = i64;(64bitOS)だからisizeを使うという発想は分かる。
でも厳密にはRustにNonZeroなどがある以上は、"本来は"実装されたfnが正常に動作する数値範囲があり
プリミティブ型で数値範囲を再定義し型定義出来ると便利だけど…、Type Aliasがあるのに無いのが辛い。
別言語の例
type Natural = range[0 .. high(int)]
type RegisteredPort = range[1024..49151, int]
type SomeSignedInt = int | int8 | int16 | int32 | int64
反対だ、コンパイルが遅くなるだけだという意見も絶対に認めない！もあるが、上記のNonZeroなどを見ると
将来的には実装されるのではなかろうか、いやヌルポインタ最適化のためのNonZeroだから入らないのでは？
という意見も分かるが…
またas演算子でキャストは安全だという話だが、符号付きから符号無しへの変換は、当然、どういう結果に
なるかを知っているべきだが、基本的な事をすっ飛ばす人も多いし、負を許容するoffsetが明確かどうかは
コードをすべて追わないと分からない場合が多い。なおこれが出来ると、コード中のキャスト変換が減るので
動作も早くなると思われるし、fnにした時の引数チェックも行わなくても良い状況が期待できる。
現実的に今のバージョンならindexもoffsetもisizeで作り、負を許容できない所にチェックを入れるだけで
as usizeは使わなくて良い箇所なら使わない。
465 名前：デフォルトの名無しさん mailto:sage [2021/09/18(土) 09:35:47.96 ID:z3n3Kv/4.net]: >>450
let mut test = 100_usize;
アンダースコア使うと読みやすいぞ。おぬぬめ
466 名前：デフォルトの名無しさん mailto:sage [2021/09/18(土) 11:21:13.85 ID:I+biH5jK.net]: winitのmasterでstdwebのサポートが切られてweb_sysに一本化されていた
stdwebってオワコンになりつつあるのかな？
467 名前：デフォルトの名無しさん mailto:sage [2021/09/18(土) 17:05:43.72 ID:NeCiGTRe.net]: >>455
NonZeroはOptionとかのサイズ最適化やポインタの値がnullでないことを示すのが主目的なので
汎用的な範囲を組み込み型で示すのはちょっと違うかと
必要ならnewtypeパターンで自分で作ればよい
468 名前：デフォルトの名無しさん [2021/09/18(土) 17:29:18.29 ID:1LwUu6qJ.net]: 配列がusizeなのはpythonなんかのa[-1]の最後尾アクセスを見てると、なぜそんな言語仕様にしたのかと
off_tなんかを見ると不思議に思う。いずれも Index bounds checkが掛るのに。符号無し64bitの巨大な
配列が欲しかったから？でもi128とかあるし
469 名前：デフォルトの名無しさん [2021/09/18(土) 17:47:44.01 ID:2OOJm5Lf.net]: インデックスiが実行時に決まるとき
配列のアクセスを内部的には *(p + i) にしたかったからじゃないかな
マイナスのとき～っていう分岐をそこに入れずに最速でアクセスしたかったと
470 名前：デフォルトの名無しさん mailto:sage [2021/09/18(土) 18:02:33.71 ID:z3n3Kv/4.net]: >>459
>符号無し64bitの巨大な配列が欲しかったから？
配列にマイナスの値は使わないんだから、そのぶんMAXの数を増やしたほうが
オーバーフローしにくいから安全だろってことらしい

でもどうせi32 as usizeとかi64 as usizeするから意味ないんですけどね！
471 名前：デフォルトの名無しさん [2021/09/19(日) 12:46:43.77 ID:/yxUr6Cy.net]: >>451
ほんそれ
めっちゃ判る
472 名前：デフォルトの名無しさん mailto:sage [2021/09/19(日) 12:55:45.99 ID:HwX1dH8g.net]: >>459
32bit環境だとisizeにするとbyte配列が2GBくらいしか扱えないからじゃないのかね
ついでに一応16bit環境もサポートしてるみたいだし
473 名前：デフォルトの名無しさん mailto:sage [2021/09/19(日) 15:08:42.28 ID:i7fTqS33.net]: 競プロの書き方を仕事でするわけないだろ
何言ってるんだ
474 名前：デフォルトの名無しさん mailto:sage [2021/09/19(日) 22:06:10.71 ID:0p9m0gya.net]: してるバカがいるから言ってんだよバカ。
475 名前：デフォルトの名無しさん mailto:sage [2021/09/19(日) 22:13:07.84 ID:xwERW7V5.net]: 矯正してやれ
476 名前：デフォルトの名無しさん mailto:sage [2021/09/19(日) 22:58:17.41 ID:i7fTqS33.net]: アホか
競プロと仕事、書いてる時間がどっちが長いと思ってる
競プロは趣味　仕事で書いてるほうが圧倒的に長い
競プロでの書き方が仕事に引きずられることがあっても逆はない

そういうヤツがいるとか嘘をついてまで、
競プロに難癖つける理由がまったく理解できんわ
477 名前：デフォルトの名無しさん mailto:sage [2021/09/19(日) 23:07:40.22 ID:k8GedCcQ.net]: お前が競プロスタイルで仕事するかどうかの話じゃないし、競プロに難癖つけてもいない
478 名前：デフォルトの名無しさん mailto:sage [2021/09/19(日) 23:52:05.14 ID:2t5v/hEZ.net]: 競プロRustスレを専用に立てて分離するのがベストな解決かな。
大多数を占める普通のRustプログラミングをする人たちにとっては役に立たない、特殊な競プロのコーティング方法が書かれても、批判議論に陥りがちでお互いにメリットないと思うのです。
479 名前：デフォルトの名無しさん mailto:sage [2021/09/19(日) 23:53:50.32 ID:i7fTqS33.net]: 難癖つけてるだろ

> 競技プログラミングは
> 正しいプログラミングスタイルから離れていく悪です

からの流れだからな
480 名前：デフォルトの名無しさん mailto:sage [2021/09/19(日) 23:59:33.71 ID:2t5v/hEZ.net]: >>470
それ自体は合ってますよ。
もちろん各々を使い分けられる人もいるでしょう。
でもそれはその人個人の内部の話。
競プロなプログラミングスタイル自体は、正しいプログラミングスタイルから乖離しています。
481 名前：デフォルトの名無しさん mailto:sage [2021/09/20(月) 00:04:36.59 ID:9haXUQHR.net]: なんで競プロの話になってるんですか？
usizeをasしまくるのが競プロってこと？
482 名前：デフォルトの名無しさん mailto:sage [2021/09/20(月) 00:14:27.54 ID:LELesARs.net]: >>472
グローバル変数を用いたりunsafeを闇雲に利用している点
483 名前：デフォルトの名無しさん mailto:sage [2021/09/20(月) 00:28:27.43 ID:sE5U575H.net]: >>462
>>465
その一緒に仕事してるという競プロの人は、どんな困った記述してるんですか？
参考までにコードを晒してくれると助かる

まさか仕事でグローバル変数やunsafeを闇雲に使ってるわけじゃないですよね？
484 名前：デフォルトの名無しさん mailto:sage [2021/09/20(月) 00:32:13.16 ID:zcJdfkjB.net]: 仕事でRust書けるなんていい職場だな
485 名前：デフォルトの名無しさん mailto:sage [2021/09/20(月) 01:04:41.94 ID:eNefvRk4.net]: 闇雲にunsafeを使うどころか脳死で全部の関数unsafeにする勢いだからな
486 名前：デフォルトの名無しさん mailto:sage [2021/09/20(月) 01:34:24.92 ID:9haXUQHR.net]: asはみるけどunsafeは競プロじゃめったにお目にかかれないような
487 名前：デフォルトの名無しさん mailto:sage [2021/09/20(月) 11:13:37.01 ID:rFqIM+Ck.net]: これ初めて知ったんだけど
Webブラウザサイド(フロントエンド)もRustで書けるのね
html!マクロでRustソースの中にHTMLもそのまま書けて更にその中にRustコードが書けてReact.jsのJSXみたいな感じね

https://yew.rs/ja/
Yew は WebAssembly によってマルチスレッドなWebアプリのフロントエンドを作ることができる、モダンな Rust のフレームワークです。
488 名前：デフォルトの名無しさん mailto:sage [2021/09/20(月) 13:47:36.24 ID:DPax/7qN.net]: そこまでする？
489 名前：デフォルトの名無しさん mailto:sage [2021/09/20(月) 15:13:17.24 ID:xK2QDi8C.net]: alert使うだけでunwrap使うwebsysは使いたくない
490 名前：デフォルトの名無しさん [2021/09/20(月) 21:41:35.24 ID:EyFwfCvn.net]: unwrapはそこらじゅうのサンプルで見かけるが、Rustクックブックでは、unwrapを許可していません。
こういう事も敷居が高い理由です
491 名前：デフォルトの名無しさん mailto:sage [2021/09/20(月) 22:06:55.37 ID:LO5PkHvF.net]: crates.ioのライブラリを読んでて見つけたんですが、
traitを実装するのに、まず構造体に直接同名のメソッドをimplして、
traitの実装ではそれを呼び出すだけ、みたいな方式でやられていました
Sがstruct、Tがtraitだとしてこんな感じです

impl S {
pub fn f(&self) {...}
}

impl T for S {
pub fn f(&self) { self.f(); }
}

これってimpl T for Sのほうに直接実装するのに比べて何かメリットがあるんでしょうか？
492 名前：デフォルトの名無しさん mailto:sage [2021/09/20(月) 23:56:14.72 ID:5wFYkRVK.net]: >>480
alert()って簡易テストくらいでしか使わないような

>>481
意味が不明です

>>482
例えば今適当に作った例だけど

struct S { x: i32, y: i32, }

impl S {
　fn fmt(&self) -> String {
　　format!("({}, {})", self.x, self.y)
　}
}

impl std::fmt::Display for S {
　fn fmt(&self, f: &mut std::fmt::Formatter) -> std::fmt::Result {
　　write!(f, "S{}", self.fmt())
　}
}

fn main() {
　let s = S { x: 123, y: 456 };
　println!("{}", s.fmt()); // (123, 456)
　println!("{}", s); // S(123, 456)
}
493 名前：デフォルトの名無しさん mailto:sage [2021/09/21(火) 03:25:03.00 ID:kmDESzsF.net]: >>482
内部用の非公開関数は
impl S { }
の方にしか書けないから実装は全部そっちに書いて
impl T for S { }
からは呼び出すだけにした方がすっきりする場合がある
494 名前：デフォルトの名無しさん mailto:sage [2021/09/21(火) 09:21:03.28 ID:asWFySWg.net]: >>483
これ見て思ったんだけど、
メソッド名と引数全く同じだった場合で、
構造体のメソッドがpubで、
トレイトのほう優先的に呼び出したい場合ってどうするの？
そもそもメソッド名被らせるなって話ではあるんだけど
495 名前：482 mailto:sage [2021/09/21(火) 10:01:30.32 ID:aEoN/PBD.net]: すみません、impl Sもimpl T for Sもpubは付いていませんでした……
Tがpubなので、外部にはTの実装としてのfだけが見える状態ですね

>>483
振る舞いを変えたいなら分ける意味も分かるんですけど、完全に同じなんですよね

>>484
すっきりするというのは確かに読んでて思いました
実際非公開の関数が他にもありました
結局これが最大の理由なんですかね？

>>485
こんな感じでいけますね
https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=10cdbd17798b14faa5fb6619ceb0739d
496 名前：デフォルトの名無しさん [2021/09/21(火) 14:10:55.34 ID:QKlGGi7s.net]: 気持ち悪い
497 名前：デフォルトの名無しさん mailto:sage [2021/09/21(火) 20:13:53.65 ID:jzXJ8gRI.net]: >>473
match お前の職場にはコーディング規約がないの？ {
　規約でunsafeが許されている => { ならunsafe使うの自由だろ。問題があるなら規約を改正しろ }
　規約でunsafeは禁止されているが使ってるヤツがいる => { ならなんでunsafeを利用してコーディングしてるヤツがいるんだよ。そいつをなんとかしろ }
}

結論　別に許可されてるなら自由だろ
それが問題だと思うなら上司にいって禁止させるのが先
498 名前：デフォルトの名無しさん mailto:sage [2021/09/21(火) 20:16:09.40 ID:jzXJ8gRI.net]: おっと最後にこれが必要か

_ => { コーディング規約ぐらい決めとけ。決められてないぐらいの組織にいるなら文句いうな。諦めるか転職しろ }
499 名前：デフォルトの名無しさん mailto:sage [2021/09/21(火) 20:37:04.07 ID:KTLm+LXj.net]: キモ
500 名前：デフォルトの名無しさん mailto:sage [2021/09/21(火) 20:43:04.95 ID:aEoN/PBD.net]: 規約で禁止されていてみんな守ってる場合にコーディング規約決めろと怒られるバグ
501 名前：デフォルトの名無しさん mailto:sage [2021/09/21(火) 20:53:30.60 ID:jzXJ8gRI.net]: >>491
規約で禁止されてるなら単純にそいつの問題だろ
それがなんで競プロの影響になるのかまったくわからんぞ
502 名前：デフォルトの名無しさん mailto:sage [2021/09/21(火) 20:54:04.75 ID:YS0x7nOl.net]: 動かないコーディング規約を作られても困るわ
どのタイミングでもいいから自動で弾く仕組みまで作らないと

…誰かgit hookの練習で作ってみない？
503 名前：デフォルトの名無しさん mailto:sage [2021/09/21(火) 21:04:02.40 ID:j1Ojj5Hg.net]: こういうキチガイがいて邪魔だから
競プロは専用スレを立ててそこへ隔離すること
504 名前：デフォルトの名無しさん mailto:sage [2021/09/21(火) 21:09:08.77 ID:asWFySWg.net]: なんで競プロの話に規約が出てくるんすか
505 名前：デフォルトの名無しさん mailto:sage [2021/09/21(火) 21:32:11.36 ID:4JalLCnu.net]: rust書いたことない障がい者が騒いでるな
ゴミコード晒して叩かれたのが相当悔しかったのか
なら自分の腕を磨けよ
やってることが数人しかいない過疎スレを荒らすって
どうやったらそう言う思考になるわけ
506 名前：デフォルトの名無しさん mailto:sage [2021/09/21(火) 23:20:56.90 ID:qogxB4xv.net]: そら競プロの解答コードが規約破りまくりなの見れば関係はあるわな
507 名前：デフォルトの名無しさん mailto:sage [2021/09/22(水) 02:11:22.59 ID:U1/YCban.net]: そもそもunsafeの利用の明確な基準って決められるのか？
利用を完全に禁止することはできるかもしないが、使ってOKな条件を担当者の最良が入り込む余地がないレベルで厳密に決めるのは難しそう
508 名前：デフォルトの名無しさん [2021/09/22(水) 03:25:11.12 ID:+50nKS9n.net]: >>498
例えばVecの実装にも一部unsafeが使われておりunsafeは忌避すべきものではなく有用なものであるがその使用には厳しい条件がある
①unsafeが極狭い範囲に閉じ込められており抽象化されたインターフェースによりその存在を意識せずに使えること
②unsafeを使用することで明白にその操作の効率が良くなるもしくは低レベル操作によりその使用が避けられないこと
③unsafeの使用部分がその関係する範囲全体の一貫性において完全に安全な操作であると確認できること
以上3点が関係者により合意確認できている場合のみunsafeの使用が認められそして上位ではその存在を気にせず安全に使うことができる
509 名前：デフォルトの名無しさん mailto:sage [2021/09/22(水) 04:21:37.31 ID:HMywcfFm.net]: >>498
unsafeのコードにはレビュアーを最低5人指定すること
とすればok
510 名前：デフォルトの名無しさん mailto:sage [2021/09/22(水) 07:58:09.34 ID:5QejlQFf.net]: 使わざるを得ないパターンを提示(この時点で滅多に無い事が分かる)、当てはまらない物は原則禁止
本来要らない箇所で使おうとする輩が湧いて出ないようにするのが目的
511 名前：デフォルトの名無しさん mailto:sage [2021/09/22(水) 10:40:17.54 ID:88WbS542.net]: ノーコメントunsafeは問答無用で禁止くらいのことはしてもいいと思う
そのくらいunsafeはやばい
512 名前：デフォルトの名無しさん mailto:sage [2021/09/22(水) 11:36:51.20 ID:Gy06LVHu.net]: stdのunsafe APIに関してはそうだと思うけど
crates.ioのライブラリ群にまでそういうの持ち出されると面倒だなあ
513 名前：デフォルトの名無しさん mailto:sage [2021/09/22(水) 12:19:04.62 ID:U1/YCban.net]: clippyもpubなunsafe fnにはドキュメントコメントに # Safety のセクションがないとデフォルトで警告出すので
コメントつけるのは最低限やっておくべきラインだと思う
https://rust-lang.github.io/rust-clippy/master/#missing_safety_doc
514 名前：デフォルトの名無しさん mailto:sage [2021/09/22(水) 12:31:35.55 ID:aOvfflz7.net]: 競プロの人ってレギュレーション守れば何してもいいって考え方の人が多いよね。
規約次第ってのが正にそれ。

unsafe みたいに取り扱いが繊細な機能は基本使わない、使う時には議論した上で限定的に使うみたいな感じに取り扱うのがほとんどだろ。
規約で機械的には決められないと思うよ。
515 名前：デフォルトの名無しさん mailto:sage [2021/09/22(水) 13:23:06.09 ID:88WbS542.net]: 競プロでunsafeなんて使わないよ
グローバル変数おじさんなら知らんけど
516 名前：デフォルトの名無しさん mailto:sage [2021/09/22(水) 13:53:44.01 ID:HlHaH6ql.net]: 久々にusize祭りｷﾀ━━━━(ﾟ∀ﾟ)━━━━!!

unsafe fn calc(bit: i32) -> i32 {
　if bit == 0 { return 0; };
　if DP[bit as usize] != -1 { return DP[bit as usize]; };

　let mut start_id: i32 = 0;
　for i in 1..=K_NUM { if bit & 1 << i == 0 { start_id += C_NUM[i]; }; }

　let mut res: i32 = i32::MAX;
　for i in 1..=K_NUM as i32 {
　　if bit & 1 << i > 0 {
　　　let mut end_id: i32 = start_id + C_NUM[i as usize];
　　　let mut num: i32 = end_id - start_id - (SUM[end_id as usize][i as usize] - SUM[start_id as usize][i as usize]);
　　　res = res.min(calc(bit ^ 1 << i) + num);
　　}
　}
　DP[bit as usize] = res;
　res
}
517 名前：デフォルトの名無しさん mailto:sage [2021/09/22(水) 13:54:58.06 ID:88WbS542.net]: なんで来るんだよおじさんー
518 名前：デフォルトの名無しさん mailto:sage [2021/09/22(水) 13:57:46.22 ID:88WbS542.net]: Rust競プロでグローバル変数（static mut）はマジでおすすめしないぞ、ほんまに
意味わからんWAの原因になりうる

https://qiita.com/qnighy/items/46dbf8d2aff7c2531f4e
519 名前：デフォルトの名無しさん mailto:sage [2021/09/22(水) 15:00:43.19 ID:xw08ZBoX.net]: そんなに生配列使いたいならCで書けよ
520 名前：デフォルトの名無しさん mailto:sage [2021/09/22(水) 19:10:57.50 ID:xKA5BBWf.net]: 結局規約頼りならrust使う意味は薄いわな。
521 名前：デフォルトの名無しさん mailto:sage [2021/09/22(水) 20:53:41.87 ID:HlHaH6ql.net]: >>509
それはRustだけでなくcやc++でも起こることなので、注意すれば大丈夫ヽ(´ー｀)ノ
Rustだから駄目、c++ならokという根拠にはならないから
522 名前：デフォルトの名無しさん mailto:sage [2021/09/22(水) 23:41:24.94 ID:U1/YCban.net]: >>511
1%でもダメな箇所があったら全部ダメって考える人？
523 名前：デフォルトの名無しさん mailto:sage [2021/09/22(水) 23:53:53.16 ID:rujUi/9T.net]: 理想的な言語には無駄など一切無いのだ
524 名前：デフォルトの名無しさん mailto:sage [2021/09/23(木) 00:15:25.31 ID:r4yNqkwu.net]: 規約になんもないからってunsafeまみれだとぶっ叩かれるぞ
そう、actix-webの作者のように
525 名前：デフォルトの名無しさん mailto:sage [2021/09/23(木) 00:24:58.81 ID:Pncl1K/q.net]: >>507 添削しました。お収めくださいまし。

1. 安易にグローバル変数を使うな。状態を引数で持つくらいやれ
2. 引数bitが負になるのかくらい考えろ。脳死でi32とusizeをコピペしてるだろテメー
　暗黙のキャストが無い==明示的にキャストすればいい、じゃねえぞ
　パッと見て汚いなら設計が汚えんだ。動的プログラミングだから汚えんじゃねえ、テメーが汚えんだ
　…負数になる可能性がある場所はたったの1行じゃねえか！どうした？頭使ってる？
4. unsafe外す努力もしねえの
526 名前：か、どうした？5回deleteキー押せば外れるぞ？ 5. 値とインデックスが混ざるような書き方、どうして怖がらない？ロボトミー手術でも受けたのか？ 6. C/C++には無い機能も使わず、warningもlinterも無視して、一体どうしてrustで書いてるんだ？ 勉強中とすら言えねえじゃねえか。 まさか、VBAスクリプトを.javaファイルにコピペして「動きません！javaはクソ！」とか言っちゃう伝説のコーダーなのか？ []: [ここ壊れてます]
527 名前：デフォルトの名無しさん mailto:sage [2021/09/23(木) 01:13:45.47 ID:X5xfUo6W.net]: 質問です
デフォルト値を与えるトレイトDefaultについて例えば
#[derive(Default)]
struct S { a: i32, b: i32, c: i32 } の時に
let s = S::default(); と書いても同じ結果で短いのに
let s: S = Default::default(); と書くのはDefaultトレイトのdefault()だと明示するためでしょうか？
結局deriveすると
impl Default for S {
　fn default() -> Self {
　　S { a: 0, b: 0, c: 0 }
　}
} を自動的に定義してくれるという理解であっていますか？
驚いたのは
let s = S { b: 123, ..Default:default() };
とすると残りフィールドをデフォルト値展開してくれて S { a: 0, b: 123, c: 0 } が得られることでした
そこでderiveを使わずに自分で
impl Default for S {
　fn default() -> Self {
　　S { ..Default::default() }
　}
}
と手動かつ内部をDefault::default()に任せてみたところ
再帰しているとコンパイルで警告が出て実行するとコアダンプでしたw
なぜ？
528 名前：デフォルトの名無しさん mailto:sage [2021/09/23(木) 01:38:10.01 ID:pkzlOfob.net]: >>517
Default::defaultはどこでも使えるから癖で使ってる人が多いんだと思う

S { b:123, ..Default::default() }は残りのフィールドを展開するというより、
S::default()の所有権を奪ってbだけ書き換えたものを返すという理解が正しい
, ..に続くのは構築しようとしているものと同じ型の値
例えばS { a: 123, ..s }のようにも書ける
, ..Default::default()と書けばSが期待される箇所なので, ..S::default()と同様になる

以上を踏まえれば最後のコアダンプの原因はS::defaultの無限再帰によるstack overflowだと容易に理解いただけよう
529 名前：デフォルトの名無しさん mailto:sage [2021/09/23(木) 02:02:07.87 ID:X5xfUo6W.net]: >>518
なるほど！よく考えれば
let base = S { a: 0, b: 0, c: 0 };
let s = S { b: 123, ..base }; の時と同じstruct base式の構文だったのですね
結局、以下のように自分で展開したところ(当たり前ですが)上手く行きました
impl Default for S {
　fn default() -> Self {
　　Self {
　　　a: Default::default(),
　　　b: Default::default(),
　　　c: Default::default(),
　　}
　}
}
530 名前：デフォルトの名無しさん [2021/09/23(木) 07:42:33.86 ID:WWdZV+h/.net]: Defaultトレイトのdefaultと明示するため、で合ってるよ
Arc::cloneにもそのような文化がある
531 名前：デフォルトの名無しさん mailto:sage [2021/09/23(木) 11:37:02.58 ID:AZNHMrAu.net]: >>513
1%のダメな箇所で他の言語の文句言ってるのはrust信者の方ですけどね。
532 名前：デフォルトの名無しさん mailto:sage [2021/09/23(木) 13:01:19.66 ID:4xQQttIg.net]: まあ、100%良いものなんてないんだし、子供達がせっかく作ったものを評価し、使ってやるというのも、年長者の優しさってものだろう。

今までどれだけ色々な言語が作られ、流行る、主流になると言われては下火になっていったことかと思えば、Rustもまたいずれ他のものにとってかわられるのが世の流れではあるだろうが、それならそれで良いじゃないか。

諸行無常
533 名前：デフォルトの名無しさん mailto:sage [2021/09/23(木) 13:12:55.93 ID:+msTn ]: [ここ壊れてます]
534 名前：Wug.net mailto: >>522
Rustを置き換えるにはコンパイル時点でのメモリ安全性保証を実現しないといけない
Rustは諸問題を解決してしまったので代わりの言語は数十年出てきそうにない
もし出てきたときには手続き型ではなくなってるだろう []: [ここ壊れてます]
535 名前：デフォルトの名無しさん mailto:sage [2021/09/23(木) 15:20:08.54 ID:xxtNZLaL.net]: みずほのシステムを全部Rustで
536 名前：デフォルトの名無しさん mailto:sage [2021/09/23(木) 15:55:02.56 ID:Ru7FlOs1.net]: >>524
ボンクラPGは排除できるから意外と良い選択かもw
537 名前：デフォルトの名無しさん mailto:sage [2021/09/23(木) 16:44:35.84 ID:kF5NpOzj.net]: みずほはもっとマクロなレベルでの設計の問題じゃないの知らんけど
538 名前：デフォルトの名無しさん mailto:sage [2021/09/23(木) 17:01:36.77 ID:Sp5Iyysf.net]: つかCOBOLならもともとメモリ安全性は高いだろ
539 名前：デフォルトの名無しさん mailto:sage [2021/09/23(木) 17:14:42.14 ID:pKS1sRJG.net]: 昔の 1% は (注意を払うという対処法で) なんとかなったが現代のコード規模の 1% は深刻だという話なんだよ。
540 名前：デフォルトの名無しさん mailto:sage [2021/09/23(木) 17:44:30.23 ID:NjDt/riq.net]: 静的チェックでその１％が埋まると思ってるのがお気楽だなと思うわ。
541 名前：デフォルトの名無しさん mailto:sage [2021/09/23(木) 18:01:26.98 ID:j+XImBaS.net]: usize祭りｺﾈ━━━━(ﾟдﾟ；)━━━━!!

let mut dp = vec![i32::MAX; n_list.len() + 1];
for &i in &n_list {
　for j in 0..dp.len() {
　　if dp[j] > i {
　　　dp[j] = i;
　　　break;
　　}
　}
}
let mut cnt = n - dp.iter().filter(|&x| x != &i32::MAX).count();
542 名前：デフォルトの名無しさん [2021/09/23(木) 18:27:08.03 ID:3ZM+sTU9.net]: vscodeでセーブした時に、ifに付けちゃった括弧を外して欲しいんだけど、何をどう設定すればいいの？
543 名前：デフォルトの名無しさん mailto:sage [2021/09/23(木) 18:28:49.30 ID:l8duufjf.net]: 処理系の勉強をかねてRustで
ttps://www.sigbus.info/compilerbook
これをやってみようと思う
序盤で二分木＆再帰・・・うへー
544 名前：ハノン mailto:sage [2021/09/23(木) 18:32:58.93 ID:HaJtCNmP.net]: >>532
二分木はむしろ非再帰で組めといわれたら罰ゲームなんですよ‥‥
545 名前：デフォルトの名無しさん mailto:sage [2021/09/23(木) 19:12:11.01 ID:+qAUZiId.net]: なんかこのスレ競プロの厄介な人に乗っ取られた？
クソコードを延々と貼り付けてるあたり開き直ったか
546 名前：デフォルトの名無しさん mailto:sage [2021/09/23(木) 19:15:36.83 ID:+msTnWug.net]: 競プロは別スレ建てて分離しましょう
競プロの件はいずれもRustを利用＆学習する人々にとって役に立たない有害なものばかりでこのスレと別件ですから
547 名前：デフォルトの名無しさん mailto:sage [2021/09/23(木) 19:22:24.57 ID:pkzlOfob.net]: 競技プログラミング総合スレ 63
https://mevius.5ch.net/test/read.cgi/tech/1627477128/
548 名前：デフォルトの名無しさん mailto:sage [2021/09/23(木) 19:48:26.70 ID:j+XImBaS.net]: >>535
いやRustで競プロをする人もいるじゃんね
Rustを使用している人は、仕事だけの人、競プロだけの人、仕事でも競プロで使う人、のそれぞれの合計

ということは、そこから競プロを排除するってことは、より少ない人数だけを対象にするスレを立てるってことだから、
競プロの話題を禁止したい人が、「Rust原理主義者スレ」とでもして、自分たちが別スレをたてて
原理主義者たちだけで移動するのが論理的かつ合理的ヽ(´ー｀)ノ
549 名前：デフォルトの名無しさん mailto:sage [2021/09/23(木) 20:01:59.63 ID:jGNo4sQ0.net]: とキチガイが申しております
550 名前：デフォルトの名無しさん mailto:sage [2021/09/23(木) 20:06:06.82 ID:pkzlOfob.net]: >>537
あなたはまず何の説明も無しにコード貼り散らかして祭りだとか言うことの目的を教えなさいよ
551 名前：デフォルトの名無しさん mailto:sage [2021/09/23(木) 20:19:26.28 ID:O5HtXMYP.net]: ブログトップにキモい自撮り写真貼ってるやつを見てから
競プロ臭のくっさいコードはスルーすることに決めてる
552 名前：デフォルトの名無しさん mailto:sage [2021/09/23(木) 20:34:50.85 ID:j+XImBaS.net]: >>538-540
スレッドは知識の集合知である場所だと思うから、
B木を考えても、情報が細分化される場合には、
携わる人数（情報）が少ないほうを葉にするのが妥当だと思うけど

>>539
Rustにはメリットもあるし、デメリットもある
様々な側面から、こういうことがあり得るとか、こういうこともできるとか
そういう情報がプラスになるんじゃないかと思っている

仕事のみの人にとっては競プロの書き方は我流だと思うだろうし、
競プロでも書いている人は、別に仕事で競プロの書き方はしてないが
直感的にやりたいことができないこともあるという思いもある

そのあたりの折り合いを付けるのが正しいRustスレなんだと思うんだよね。個人的に。
だから競プロ以外の話をしたいなら、原理主義スレを立てればいいし、
競プロだけの話をしたいなら、競プロスレを立てればいい。

ただし、ここはRustのrootだと解釈している
553 名前：デフォルトの名無しさん mailto:sage [2021/09/23(木) 21:50:54.44 ID:9wzKaMiq.net]: ってことで以降は競プロ禁止
やりたい人は競プロのスレで
554 名前：デフォルトの名無しさん mailto:sage [2021/09/23(木) 22:02:49.74 ID:j+XImBaS.net]: >>542
そういう強権的なやり方は嫌われると思う
555 名前：デフォルトの名無しさん [2021/09/23(木) 22:22:06.57 ID:WWdZV+h/.net]: 俺はお前が嫌い
556 名前：デフォルトの名無しさん mailto:sage [2021/09/23(木) 22:56:16.76 ID:pkzlOfob.net]: >>541
要はフィードバックが欲しくてソース貼ってるのか？
ならせめて入力仕様と出力仕様くらいは書こうな
競プロなら問題へのリンクでもいい
557 名前：デフォルトの名無しさん mailto:sage [2021/09/23(木) 23:17:56.15 ID:Peq2Gbnq.net]: codeLLDBを消去しやがるからavastアンインストールしてやったわ
558 名前：デフォルトの名無しさん mailto:sage [2021/09/24(金) 00:59:53.09 ID:HPu5FO6/.net]: >>541 添削しました。お納めください。

1. Cをそのままコピペしただけじゃねえか
　 Rustの機能を試すだぁ？enumもtraitもパターンマッチも使えないのに何が検証だ馬鹿野郎
　「Cコピペしたけどメリット無いね！」って後何回繰り返すんだ？
2. なんだこの察してちゃんなコードは。保育園にいるつもりか？
　意図の明確なコードが1行も無いんだが？
3. お前がここにゴミを貼る妥当性が一つも無い
　 Rustの世界に持ってきた概念のどれも使わないで、何が検証できると思ってるんだ？
　例えるなら「ひらがなしか知らない外国人が日本語の良し悪しを検証します！」っていうもんだぞ
　誰がマトモに付き合うんだ？
559 名前：デフォルトの名無しさん mailto:sage [2021/09/24(金) 01:50:08.20 ID:Dee2NcuI.net]: >>529
CやC++だと非安全コードはどこにでも現れる可能性があるので100%のコードを人力で確認する必要があったが
rustでは安全性に関してはunsafeな部分のみ(例えば全体の1%)を確認すれば良いという話では
静的チェックで100%なんとかしようという話はしていないと思うが
560 名前：デフォルトの名無しさん mailto:sage [2021/09/24(金) 02:35:54.11 ID:Bn8yEU3N.net]: そうだなーと思う反面unsafeだらけのコードを目の前にしてげんなりする未来も見えるという…
561 名前：デフォルトの名無しさん mailto:sage [2021/09/24(金) 04:43:03.82 ID:ow12Eod1.net]: ほとんどの用途でunsafeを直接使うことは無いんじゃない？
グローバル変数はOnceCellで解決してしまったし
もし生ポ操作するとしたら新たな型を作ってその中に閉じ込める
562 名前：デフォルトの名無しさん [2021/09/24(金) 08:02:15.31 ID:ljIO2QUf.net]: そういうコードが書ける事が問題だとあれほど批判してたのに
563 名前：デフォルトの名無しさん mailto:sage [2021/09/24(金) 08:30:26.85 ID:ow12Eod1.net]: >>551
それは何も問題ではないよ
例えばVec型もpushやpopですら内部はunsafe利用だけど我々はそれを知らず気にせず安全に使うことができる
564 名前：デフォルトの名無しさん mailto:sage [2021/09/24(金) 10:22:26.34 ID:RvXrBe+X.net]: >>551
どのレスに対するコメント？
565 名前：デフォルトの名無しさん mailto:sage [2021/09/24(金) 13:18:46.57 ID:/gk8ByXn.net]: そもそも競プロにメモリ安全性とかいらないしC++で書いといてくださいよ
566 名前：デフォルトの名無しさん mailto:sage [2021/09/24(金) 14:03:53.31 ID:6DqL6o69.net]: Rustの良いところはメモリ安全だけではなかろう？
567 名前：デフォルトの名無しさん mailto:sage [2021/09/24(金) 19:03:51.27 ID:clPGC+m8.net]: 機能性で言えば競プロに必要なものは大抵の言語が備えてるだろうし
使いやすさで言えばRustはきっちり書くことを求められてるから素早く書くのには向いてないし
それでも敢えてRustを選ぶ理由は趣味や慣れくらいなのでは
568 名前：デフォルトの名無しさん mailto:sage [2021/09/24(金) 21:51:28.01 ID:73j3AhJA.net]: releaseビルドするとTrojan:Script/Wacatac.B!mlを検出して
Windows Defenderに怒られる
--release付けないと大丈夫
誤検知かな？
569 名前：デフォルトの名無しさん mailto:sage [2021/09/24(金) 22:12:48.28 ID:ow12Eod1.net]: >>553
ごめん
例えばUnsafeCellの存在はRustの借用ルールに制約されることなく自由に新たな型を設計して作る道を開いているけど
あくまでも安全な型を作るための素材であって具体的にはRefCellやOnceCellなどの様々な安全な型を提供する素材となっているように
unsafeの存在も上位レベルで安全な関数やモジュールを提供するための素材としてのみ用いるべきではないか
ということを伝えたかったのです
570 名前：デフォルトの名無しさん [2021/09/24(金) 23:54:29.51 ID:561kcuCK.net]: つまり競プロ君のunsafeの使い方はただ危ない逸脱のみであり、
安全かつ便利な何かを提供する目的のための使い方ではなく、
Rustの精神に反している、と。
したがって競プロの話は、
このRust本スレでやるべきことではなく、
ここでは禁じて別スレでやるべき、と。
571 名前：デフォルトの名無しさん mailto:sage [2021/09/25(土) 00:09:12.18 ID:bZXyxueH.net]: >>559
競プロくんを競プロの代表扱いするのはさすがに競プロの人に失礼では
572 名前：デフォルトの名無しさん mailto:sage [2021/09/25(土) 01:22:46.71 ID:HzR9ZlyY.net]: Rustの精神とかそんな大層な話でもないでしょ
建設的に話せない奴に付き合う必要はないというだけ
573 名前：デフォルトの名無しさん [2021/09/25(土) 03:09:21.77 ID:r08K7R9X.net]: >>558
違う人が書いた事を、さも自分が書いたように返答するのはどうかと思う
574 名前：デフォルトの名無しさん mailto:sage [2021/09/25(土) 08:30:11.81 ID:0L4s8Q79.net]: >>562
え？？
>>558は自分の意見を書いただけでこのスレにしか書いていないし参考にしたサイトや書き込みもないよ
もし偶然にそっくりな内容なものがどこか他にあるなら見てみたいので教えて
575 名前：デフォルトの名無しさん mailto:sage [2021/09/25(土) 22:50:40.30 ID:jDRrdRW5.net]: >>559
こういう自分の意見にあわないと何でも排除したいヤツはどこにでもいるんだよなあ
576 名前：デフォルトの名無しさん mailto:sage [2021/09/26(日) 00:09:45.69 ID:EgHC/Y9j.net]: Range関連での質問です

(Included(&x), Included(&y)) はx..=yと書けますが、
(Excluded(&x), Included(&y)) を似たように書く方法ってありますか？
577 名前：デフォルトの名無しさん mailto:sage [2021/09/26(日) 01:40:54.44 ID:v4wa9AaY.net]: >>565
ないんじゃない？

(3..=5).skip(1)で、妥協するかなぁ
578 名前：デフォルトの名無しさん mailto:sage [2021/09/26(日) 01:56:26.69 ID:wsLZ/M6d.net]: Range はよく使うから構文糖を入れてちょっと簡単にするという判断がうまれたんだと思うんで、
それほど頻出しないパターンは明示的に書くしかしょうがないと思う。
自分のプログラムでよく使うのであればそういう関数を用意しておけというくらいの妥協になる。
579 名前：デフォルトの名無しさん mailto:sage [2021/09/26(日) 03:07:15.60 ID:RXeC0HEE.net]: >>565
range式も魔法があるわけではなく
それぞれ対応する構造体があって各traitなどを実装してるだけなのですが
stdにあるのは以下の6種類のみですね
assert_eq!(.., std::ops::RangeFull);
assert_eq!(3.., std::ops::RangeFrom { start: 3 });
assert_eq!(..7, std::ops::RangeTo { end: 7 });
assert_eq!(..=7, std::ops::RangeToInclusive { end: 7 });
assert_eq!(3..7, std::ops::Range { start: 3, end: 7 });
assert_eq!(3..=7, std::ops::RangeInclusive::new(3, 7));
例えば開始点のあるRangeFrom・Range・RangeInclusiveはIteratorも実装

一方でその(Excluded(&x), Included(&y))形式すなわち
(Bound<T>, Bound<T>)および(Bound<&'a T>, Bound<&'a T>)型だと
実装されているのはRangeBoundsトレイトのみでIteratorトレイトなどは無いという違いがあるようです
開始がUnboundedだと意味がないからでしょう
つまりイテレータで回したい時にはこの形式では使えないので
(Excluded(x), Included(y)) は (x+1)..=y と書くしかないと思います
もちろんSkip構造体のコストを払って(x..=y).skip(1)もアリです
580 名前：デフォルトの名無しさん mailto:sage [2021/09/26(日) 03:55:02.75 ID:EgHC/Y9j.net]: >>566 >>568
すみません、言葉足らずでした
BTreeMap/Setのrangeメソッドに渡す引数を意図していました
こちらに渡すのはイテレータではないのでskip(1)はできないようです

>>567 >>568
あまり頻出ではないですし仕方ないですかね
実際困るわけではないのですが、
アンバランスなので気になってしまいました
581 名前：デフォルトの名無しさん [2021/09/29(水) 09:06:12.26 ID:W9rNFdvq.net]: 無職の人工衛星おじさん来て
582 名前：デフォルトの名無しさん mailto:sage [2021/09/30(木) 11:51:35.89 ID:8/yMCOJS.net]: ttps://lkml.org/lkml/2021/7/7/349
完全にストップしたな。最低だよ。
583 名前：デフォルトの名無しさん mailto:sage [2021/09/30(木) 12:33:08.03 ID:Ti8kA/OA.net]: >>571
どういう意味や？
584 名前：デフォルトの名無しさん mailto:sage [2021/10/01(金) 12:54:11.60 ID:xF/FYN4O.net]: >>573
どういう意味や？
585 名前：デフォルトの名無しさん mailto:sage [2021/10/01(金) 13:00:05.87 ID:EZf94GZ+.net]: 自問自答かいな
586 名前：デフォルトの名無しさん mailto:sage [2021/10/01(金) 14:16:55.18 ID:5hzjqknK.net]: Rust for Linuxに関しては結局それ以降進展無しということ？
587 名前：デフォルトの名無しさん mailto:sage [2021/10/01(金) 14:33:36.85 ID:2Q9z0ScR.net]: そりゃ普段の作業はGitHub上でやって、まとまったところでパッチ投げるんだから
LKMLで日々の進捗報告なんかしたら迷惑でしかない
588 名前：デフォルトの名無しさん mailto:sage [2021/10/01(金) 14:40:28.89 ID:5hzjqknK.net]: https://github.com/Rust-for-Linux/linux
ここかな？全然活発だったわ
589 名前：デフォルトの名無しさん mailto:sage [2021/10/01(金) 15:23:00.24 ID:25/eRB6c.net]: いや実際のドライバーが動かないのにごねてるだけやん。。話になってないんだが。
590 名前：デフォルトの名無しさん mailto:sage [2021/10/01(金) 23:00:07.65 ID:CSO4Qyhi.net]: as usize祭りの回避ができてきてる━━━━(ﾟ∀ﾟ)━━━━!!

let mut heap: BinaryHeap<Reverse<(usize, usize)>> = BinaryHeap::new();
heap.push(Reverse((0, 0)));

while let Some(Reverse((_, now))) = heap.pop() {
　let mut que: VecDeque<(usize, usize)> = VecDeque::new();
　que.push_back((now, 0));
　while let Some((next, cnt)) = que.pop_front() {
　　if cnt == price[now].1 { break; };
　　for &i in &list[next] {
　　　if total[i] > total[now] + price[now].0 {
　　　　total[i] = total[now] + price[now].0;
　　　　heap.push(Reverse((total[i], i)));
　　　}
　　　que.push_back((i, cnt + 1));
　　}
　}
}
591 名前：デフォルトの名無しさん mailto:sage [2021/10/02(土) 02:05:08.49 ID:JhHEfT92.net]: >>578
そうなんだ。誰がどこでごねてるの？
592 名前：デフォルトの名無しさん [2021/10/02(土) 07:25:57.30 ID:VZaTbxB/.net]: VSCodeか何かで、編集中のファイルを（保存する度ではなく）リアルタイムで構文チェックしてもらうことってできないの？
目が悪いもので、C#みたいに間違えたら即指摘みたいなのがすごく助かるんだけど・・・・
593 名前：デフォルトの名無しさん mailto:sage [2021/10/02(土) 08:17: ]: [ここ壊れてます]
594 名前：40.16 ID:KFBxuoB8.net mailto: rust-analyzer入れれば若干のラグはあるけどそんな感じでやってくれると思うが []: [ここ壊れてます]
595 名前：デフォルトの名無しさん mailto:sage [2021/10/02(土) 08:21:40.61 ID:KFBxuoB8.net]: すまんオートセーブもつこうてたわｗ
596 名前：デフォルトの名無しさん mailto:sage [2021/10/02(土) 09:01:16.43 ID:hpIN2xHl.net]: >>581
IntelliJRustにon the fly analysisあるぞ
597 名前：デフォルトの名無しさん mailto:sage [2021/10/02(土) 15:27:53.04 ID:4qLxMBdK.net]: 普通にVscodeでRustの拡張入れたらやってくれん？
俺が思てる構文チェックとかの支援とは違うんかな
598 名前：デフォルトの名無しさん mailto:sage [2021/10/02(土) 15:48:21.44 ID:BIOPTGX0.net]: vscode+rust-analyzerでオートセーブ無効でもリアルタイム構文チェックしてくれるよ
599 名前：デフォルトの名無しさん mailto:sage [2021/10/02(土) 17:14:40.18 ID:0lneUYYy.net]: いつrust-analyzerに移行するか悩み中。
600 名前：デフォルトの名無しさん mailto:sage [2021/10/02(土) 17:43:54.53 ID:KFBxuoB8.net]: >>586
Auto Saveオフだと、指摘してくれないやつ結構ない？
セーブして初めて指摘されるやつが結構あるような
601 名前：デフォルトの名無しさん mailto:sage [2021/10/02(土) 17:45:45.06 ID:cWlg4bES.net]: rust-analyzerってvimでも使える？
流石にvim捨てるべきかなあ
602 名前：デフォルトの名無しさん mailto:sage [2021/10/02(土) 18:12:12.35 ID:kCAgHltC.net]: vimでもneovimでも使えるよ
603 名前：デフォルトの名無しさん mailto:sage [2021/10/02(土) 21:14:54.36 ID:Yx61ypoH.net]: rls から rust-analyzer の移行なんて躊躇するもんじゃないぞ。
試して合わなければすぐに戻せばいいだけだし、戻りたいと思う可能性は俺はゼロだと思う。
604 名前：デフォルトの名無しさん mailto:sage [2021/10/02(土) 21:57:31.81 ID:BIOPTGX0.net]: >>588
構文チェックとrust-analyzerの検知できる型エラーは保存しなくても指摘されるはず(前者は即時、後者は少しラグがある)
rustcじゃないと検出できないものは確かに保存時しか出ないかもね
特に害あるものじゃないしauto save有効にしても良いのでは？
605 名前：デフォルトの名無しさん mailto:sage [2021/10/02(土) 23:35:42.15 ID:qO3WxvTl.net]: >>589
実際にビルドしてみてそのエラーメッセージをエディタに反映するという仕組み (いわゆる flycheck) は昔からあったんだが、
頻繁に実際にビルドするんじゃなくて処理系の構文解析プロセスとエディタを連携させればもっと効率的なんと違うか？という
のがマイクロソフトによって LSP (Language Server Protocol) として標準化されたという経緯がある。

エディタにとっては場当たり的なエラーメッセージの解析をせずによくなったので昔より楽になってるんだよ。
昔から flycheck をやってるようなエディタはだいたい LSP にも対応してる。
606 名前：デフォルトの名無しさん mailto:sage [2021/10/04(月) 23:18:59.60 ID:AvMOOeeY.net]: https://thenewstack.io/linus-torvalds-on-community-rust-and-linuxs-longevity/
> “Probably next year, we’ll start seeing some first intrepid modules being written in Rust, and maybe being integrated in the mainline kernel.”
607 名前：デフォルトの名無しさん mailto:sage [2021/10/05(火) 01:50:58.24 ID:lj8Vtprb.net]: 統合早いな。多言語プロジェクトでcargo面倒くさい問題はなんかやってんだろうか？
統合されたらソース読んでみよ。
608 名前：デフォルトの名無しさん mailto:sage [2021/10/05(火) 03:19:27.62 ID:jICKdFeA.net]: 言語を組み合わせる場合を含めてビルドプロセスの記述はなんだかんだで make が万能なんだよな。
クソみたいに場当たり的だけど必要だから機能を追加してきたという現実の前には
どんな美しいパラダイムも砂上の楼閣という印象だわ。
609 名前：デフォルトの名無しさん mailto:sage [2021/10/05(火) 11:23:44.05 ID:+tJei17t.net]: cargoが勝手にクレートダウンロードしてくれるのは便利だけどね
セキュリティ的には……どうなんかなー
610 名前：デフォルトの名無しさん mailto:sage [2021/10/05(火) 11:55:21.23 ID:ds6mcw9v.net]: ビルドはmakeからrustc呼ぶ形になってたはず
カーネルに関してはクレートのダウンロードなんかもしないならそれで問題ない
611 名前：デフォルトの名無しさん mailto:sage [2021/10/05(火) 12:47:41.98 ID:ZN1Pvbj4.net]: 余計なことするツールに限ってモジュラリティ低い
612 名前：デフォルトの名無しさん mailto:sage [2021/10/05(火) 12:55:43.82 ID:I8WE2KTE.net]: >>596
既存のものがクソだから俺が全く新しいクールな奴を作ってやるぜ！っていって新しいクソが1つ増えるのはもはや伝統芸やね
613 名前：デフォルトの名無しさん mailto:sage [2021/10/05(火) 15:46:57.33 ID:q+7ifQX8.net]: >>597
そのための --offline オプション
614 名前：デフォルトの名無しさん mailto:sage [2021/10/05(火) 18:59:42.65 ID:EBA9Mr3p.net]: >>600
makeの機能を持つprologは欲しいなぁ。

論理プログラミング言語を拡張したmakeとか堅牢そうな気がするけど、誰もやらないのかしらん。
615 名前：デフォルトの名無しさん [2021/10/05(火) 20:24:54.05 ID:aXfbUEx/.net]: >>602
prolog難しいから流行らない
616 名前：デフォルトの名無しさん mailto:sage [2021/10/05(火) 21:06:12.38 ID:ZN1Pvbj4.net]: 宣言的なものの依存がゴタゴタしたもののデバッグのしずらさを知らんのだろう。呑気なもんだ。
617 名前：デフォルトの名無しさん [2021/10/06(水) 17:08:43.54 ID:XAVgSOSv.net]: rust-analyserだかに移行しようとうおもったけどemacs とは相性悪過ぎて結局rlsに戻した
analの方はcodeいれんとインストール出来んかったりとほぼvs用だなあれ(´・ω・｀)
618 名前：デフォルトの名無しさん mailto:sage [2021/10/06(水) 18:10:02.17 ID:msHyc08D.net]: >>605
lsp-modeとの組み合わせで普通に使えるが
619 名前：デフォルトの名無しさん [2021/10/06(水) 19:54:44.67 ID:yydNkGdJ.net]: マジかeglot使ってたからかも
何かfunction defとかの問い合わせ方法間違ってんのか知らんが常にno docみたいのがmessage表示されて使いもんにならんかった
lspってマジで全然分からんちんで小鳥の餌待ち状態で微塵も弄れないのよね俺(´・ω・｀)
620 名前：デフォルトの名無しさん mailto:sage [2021/10/06(水) 23:28:27.48 ID:msHyc08D.net]: rlsもlspだよ
rlsのlsはlanguage serverのls
621 名前：デフォルトの名無しさん mailto:sage [2021/10/06(水) 23:40:35.33 ID:ET8OV0WS.net]: >>607
標準ライブラリのソースコードがないとか？
rustup component add rust-src
で入ると思う
622 名前：デフォルトの名無しさん [2021/10/07(木) 00:12:56.69 ID:3bOhB6en.net]: あんま多くは試しでないがrust-analyzerインストールする時に入れさせられたvscodeではanal pluginで動いてたしanal自体はインストール出来てると思うんだがな

>>608
そのfuckin msの策定したlspを部分的にとか言語ごとに異なるoverrideてかimplで構成するプロジェクト群がrust-analyzerとかclangdだかとかgoplzとか
ただこれらだけじゃ意味不明のjson object返したり読み込んだりするだけのdaemonで役に立たないから
仲介者としてのeglotとかlsp-modeが必要になる
ここらまでも簡単に弄れるというか(弄れる必要があると言うのか...)がemacsの良いところ(´・ω・｀)
623 名前：デフォルトの名無しさん mailto:sage [2021/10/07(木) 06:40:58.97 ID:F5HUOmxy.net]: anal plug?
624 名前：デフォルトの名無しさん mailto:sage [2021/10/07(木) 11:35:48.71 ID:DOEkOZlT.net]: インストールもなにも実行ファイルのパス通すだけだからね
~/.vscode/ 配下にあるはずだからそれを使うか GitHub からダウンロードしてくれば良い
625 名前：デフォルトの名無しさん mailto:sage [2021/10/08(金) 22:14:06.47 ID:XK73QT2t.net]: べき剰余をオーバーフローさせずに作る関数を作ったヽ(´ー｀)ノ

fn calc(num: usize, pow: usize, m: usize) -> usize {
　let mut bit: usize = 1;
　let mut res: usize = 1;
　let mut tmp_pow: usize = num;

　while pow >= bit {
　　if pow & bit > 0 {
　　　res = (res * tmp_pow) % m;
　　}
　　bit = bit << 1;
　　tmp_pow = (tmp_pow * tmp_pow) % m;
　}
　res
}
626 名前：デフォルトの名無しさん mailto:sage [2021/10/09(土) 10:18:30.30 ID:0okuLqNl.net]: >>613
普通にオーバーフローするが
calc(usize::MAX, usize::MAX, usize::MAX-1);
627 名前：デフォルトの名無しさん mailto:sage [2021/10/09(土) 11:49:04.73 ID:zLg6zd/V.net]: 多分競プロのやつだから各数値は32bitなんだろう
そらオーバーフローしねえよって話
628 名前：デフォルトの名無しさん mailto:sage [2021/10/10(日) 09:49:29.12 ID:bzbLkL2i.net]: 都合のいい仮定置いてそうなのがらしい感じだわな
629 名前：デフォルトの名無しさん mailto:sage [2021/10/10(日) 11:17:36.59 ID:2mgB061S.net]: ↓これと同じアルゴリズムなのに>>613のは読みにくいね
https://ja.wikipedia.org/wiki/冪剰余#途中で剰余をとる

u64で受け取って内部ではu128で計算して
u64で返すようにしとけばオーバーフローしない
630 名前：デフォルトの名無しさん mailto:sage [2021/10/10(日) 11:36:29.13 ID:2mgB061S.net]: u16ならu32、u32ならu64、u64ならu128みたいな関係をジェネリクスで表現できたりする？
631 名前：デフォルトの名無しさん mailto:sage [2021/10/10(日) 11:52:04.33 ID:a5kt/zmp.net]: trait作ってassociated typeで表現するのはできるかな
632 名前：デフォルトの名無しさん [2021/10/10(日) 12:00:59.32 ID:ZuTCKPOD.net]: 関連型使えよ
633 名前：デフォルトの名無しさん mailto:sage [2021/10/10(日) 12:15:12.30 ID:2mgB061S.net]: Traitを各データ型に対して全部実装するのが面倒だから
対応する倍のサイズの型を表現する方法はないのかなって話だったんだけど
なさそうってことだね
634 名前：デフォルトの名無しさん [2021/10/10(日) 16:41:29.53 ID:X3SL3SyY.net]: コンパイラを単純化（高速化）するためにプリミティブ型の型クラスはありません。例えば、Haskellに
あるような数値型全般を表す Num という型クラスは、数値型全般を表しますが実体は IntやDoubleなど。
またはtypescriptのtype Tree = Leaf | Nodeはサポートされません
635 名前：デフォルトの名無しさん [2021/10/10(日) 17:11:17.77 ID:X3SL3SyY.net]: rustはどちらかと言えばほとんどをトレイトで表現しますが、技術的にはこれらは、Tagged unionと呼ばれ
昔はSum typeともバリアント型とも呼ばれていました。プリミティブ型ではありませんが、似た機能を実現
する技術はenum variantsでも表現できます。C20にあるstd:variantもTagged unionです
もちろんassociatedでも似たことは出来るでしょう
https://en.wikipedia.org/wiki/Tagged_union
636 名前：デフォルトの名無しさん mailto:sage [2021/10/10(日) 17:13:00.50 ID:2mgB061S.net]: >>622
num-traitsとenum
637 名前：デフォルトの名無しさん mailto:sage [2021/10/10(日) 19:43:56.21 ID:a5kt/zmp.net]: >>621
マクロの使いどころ
638 名前：デフォルトの名無しさん mailto:sage [2021/10/10(日) 19:46:17.72 ID:a5kt/zmp.net]: >>622-623 の言ってることが何一つわからんのだが
639 名前：デフォルトの名無しさん mailto:sage [2021/10/10(日) 19:56:58.54 ID:XwgBItsn.net]: >>622
おっしゃる通りですがRustでは別の解決方法を取っていますね

まず前者の全般的なNum型がない件ですが
Rustでは単純な例だと以下のように1を足す関数add1ををジェネリックに書こうとすると
(注釈: 足し算の「+」はstd::ops::Add traitを満たせば使えて任意の型でオーバーロード可)
fn add1<T: std::ops::Add<Output=T>>(n: T) -> T {
　n + 1
}
これはコンパイラが通らなくて「1」を型Iにする必要があり「1::<T>」等とでも書ければいいのですが無理です
そこでnum craitのOne traitを使って以下のように書きます
fn add1<T: std::ops::Add<Output=T> + num::One>(n: T) -> T {
　n + num::one::<T>()
}
これで以下のようにジェネリックに1を足すことができました
assert_eq!(add1(36), 37);
assert_eq!(add1(5.0), 6.0);
assert_eq!(add1(1000i128), 1001i128);
さらにこの方式ならば自分で定義する構造体など任意の型もAddとOneのtraitを満たせばadd1()を使える利点があります
つまり最初の話に戻ると全般的なNum型があるよりももっと高度なことができるわけです

後者の件は一般的に代数データ型の直和をどう扱うかという話になりますが
Rustではenumがタグ付き共用体でもあるのでenumでサポートできますね
640 名前：デフォルトの名無しさん mailto:sage [2021/10/10(日) 19:58:36.14 ID:S81FmWQC.net]: >>617
rustは可変参照を基本的に好まないスタイルだから、ああなるのは仕方ないな
641 名前：デフォルトの名無しさん mailto:sage [2021/10/10(日) 21:20:06.28 ID:Dxd5NlvW.net]: 他人のフリして自分のレスに返信してるやつなんなのwww
642 名前：デフォルトの名無しさん mailto:sage [2021/10/10(日) 21:23:34.82 ID:XwgBItsn.net]: >>628
可変参照は関係あるのかな？
どちらもbit処理を下から順にするアルゴリズムで変わりなく
>>613はbitマスクを大きく(左シフト)していく方法
>>617はbitマスクは常に1で本体を小さく(右シフト)していく方法の違いだけだよね
だから後者の方式でもRustでコーディングできて動くよね
両者の差分
　 fn calc(num: usize, pow: usize, m: usize) -> usize {
　-　let mut bit: usize = 1;
　+　let mut bit: usize = pow;
　　let mut res: usize = 1;
　　let mut tmp_pow: usize = num;
　
　-　while pow >= bit {
　-　　if pow & bit > 0 {
　+　while bit > 0 {
　+　　if bit & 1 > 0 {
　　　　res = (res * tmp_pow) % m;
　　　}
　-　　bit = bit << 1;
　+　　bit = bit >> 1;
　　　tmp_pow = (tmp_pow * tmp_pow) % m;
　　}
　　res
　 }
643 名前：デフォルトの名無しさん mailto:sage [2021/10/11(月) 00:12:55.43 ID:EeZezr6D.net]: >>630
アルゴリズムではなくて、ポインタを渡すのか、実数値を渡すのか
そこを明確にしているRustの仕様から引数を可変参照にするのは・・という意味では

そして>>617が何を読みにくいといっているのかも、よくわからんし
644 名前：デフォルトの名無しさん [2021/10/11(月) 00:34:40.68 ID:JbC5nNmw.net]: >>624 >>627
がねがねその通りで、言った通りトレイトだが、「Num型があるよりももっと高度なことができる」これは弁明的。
近代的な言語はmixinもしくはアドホック多相で（高度なことが）出来る場合がほとんどであり、無いものを無いと
要求できず弁護をするのはちょっと違う。他にも角度のように、0-360まで制限したいプリミティブ型が欲しいのに
PascalのようなSubrange型も足りていない。範囲を表す表現、0..360はあるのに。些細な事だが、コンパイラを
速くする事を現在は主眼なので（仕様に矛盾が無ければ）いずれは拡張されるのかもしれないが
645 名前：デフォルトの名無しさん [2021/10/11(月) 06:54:36.68 ID:95tWd+L1.net]: mutをつけたベクター型について教えてください
これはまず、入っているのは参照なんですか？
また、参照が変わらない(?)のに、参照先を変更するにはmutがなぜ必要になってくるのですか？
(所有権概念のせいなのでしょうか？それともスマートポインタの仕組み上、参照するアドレスが変わるのでしょうか？)
646 名前：デフォルトの名無しさん mailto:sage [2021/10/11(月) 08:28:39.20 ID:LNZ+tGdJ.net]: >>633
let mut x = vec![1,2,3];

xに入ってるのはVec<i32>、これはスマートポインタ(pointer, capacity, length)。
「参照」というのはRustでは&Vec<i32>のようにアンパサンドがついてる型のこと
なのでxに入ってるのは参照ではない

例えばx.push(10)するのにxがmutじゃなきゃいけないのは
直接的にはpushのシグニチャが&mut selfを要求してるからだけど
考え方としては「multiple readers or single writer」ルールをコンパイル時に強制するため

連続したバッファを確保できなければアドレスが変わる可能性も有るし
ゼロキャパシティ
647 名前：なら具体的なアドレスを持ってない []: [ここ壊れてます]
648 名前：デフォルトの名無しさん mailto:sage [2021/10/11(月) 13:32:30.30 ID:15cV1HfU.net]: Cortex-M対応がClangよりRustの方が進んでいて草
649 名前：デフォルトの名無しさん mailto:sage [2021/10/11(月) 14:07:37.59 ID:lgurMcJY.net]: core::ptr::unique::Uniqueもalloc::raw_vecもただのdoc(hidden)なのに
Vecがスマートポインタってデタラメ広めてる奴らどこが出処だよ。

以下の関係で、
Vec has-a RawVec
RawVec has-a Unique

- Vecがrustの作法を強制するためのnewtypeパターン←composition
- RawVecが動的配列の低レベルapi←composition
- Uniqueがユニークポインタ←smart pointer

これだけだろ。
rustのコレクションはデータ構造上直接実装することになる型以外
Box含めて基本newtypeパターン(composition)だぞ。

>>633
GCのある言語しか触ったことない限りその発想にはならんから
まずアロケータの仕組みからやりな。
650 名前：デフォルトの名無しさん mailto:sage [2021/10/11(月) 14:34:19.59 ID:Ei1usHzb.net]: ホラふきがあらわれた！
651 名前：デフォルトの名無しさん mailto:sage [2021/10/11(月) 14:44:50.63 ID:CP46ljNK.net]: また他人のフリして間違いを指摘するレスが来るから乞うご期待www
652 名前：デフォルトの名無しさん mailto:sage [2021/10/11(月) 15:28:05.06 ID:YVW/m0g2.net]: compositionだからスマートポインタでないという理屈だと Rc も Arc も非公開な内部型の composition だからスマートポインタでなくなってしまう
653 名前：デフォルトの名無しさん mailto:sage [2021/10/11(月) 15:42:18.11 ID:LNZ+tGdJ.net]: >>636
C++のことは一旦忘れて、Rustにおけるスマートポインタの意味を学ぶことをすすめる
https://doc.rust-lang.org/book/ch15-00-smart-pointers.html
654 名前：デフォルトの名無しさん mailto:sage [2021/10/11(月) 18:57:50.60 ID:0Mn4AOx6.net]: >>640
The concept of smart pointers isn’t unique to Rust: smart pointers originated in C++ and exist in other languages as well.
とあるけど？
655 名前：デフォルトの名無しさん mailto:sage [2021/10/11(月) 19:29:34.65 ID:YVW/m0g2.net]: We’ve already encountered a few smart pointers in this book, such as String and Vec<T> in Chapter 8, although we didn’t call them smart pointers at the time. Both these types count as smart pointers because they own some memory and allow you to manipulate it. They also have metadata (such as their capacity) and extra capabilities or guarantees (such as with String ensuring its data will always be valid UTF-8).

というわけで Rust の定義では Vec<T> はスマートポインタ
656 名前：デフォルトの名無しさん mailto:sage [2021/10/11(月) 20:38:32.88 ID:oB6cAYFd.net]: クイズ: この中にウソはいくつウソがある？

「またはtypescriptのtype Tree = Leaf | Nodeはサポートされません」
「rustはどちらかと言えばほとんどをトレイトで表現しますが、技術的にはこれらは、Tagged unionと呼ばれ昔はSum typeともバリアント型とも呼ばれていました。」
「rustは可変参照を基本的に好まないスタイルだから、ああなるのは仕方ないな」
「Vecがスマートポインタってデタラメ広めてる奴らどこが出処だよ。」
657 名前：デフォルトの名無しさん [2021/10/11(月) 23:52:58.48 ID:FfJkoMsS.net]: >>633
pub struct Vec<略> {
buf: RawVec<T, A>,
len: usize,
}
pub struct RawVec<略> {
ptr: Unique<T>,
cap: usize,
alloc: A,
}
pub struct Unique<T: ?Sized> {
　pointer: *const T,
　_marker: PhantomData<T>,
}
push|insertの際にlen|capとアロケート先が変化するという事、上のは難しい事をわざと言ってる
スマートポインタ議論は無視でOK。しかしPhantomDataなんて理解してる人に会ったことない
658 名前：デフォルトの名無しさん mailto:sage [2021/10/11(月) 23:58:39.10 ID:ATb6fs5R.net]: >>631
その冪剰余関数の引数は全て数値すなわちCopy traitを持つので
関数呼び出しに参照を渡す必要はありません

また、可変参照の数値を渡す必要がある別の関数がもしあったとしても
普通に値を渡して変更値は返り値とする方がわかりやすいでしょう
659 名前：デフォルトの名無しさん mailto:sage [2021/10/12(火) 02:02:02.32 ID:yPuGDG3+.net]: >スマートポインタ議論は無視でOK。
他人のフリして我がフリ直せww
660 名前：デフォルトの名無しさん mailto:sage [2021/10/12(火) 02:33:26.85 ID:1W2DSIiH.net]: >>633
初級者ならばこのスレで言及されている内部実装の話は知らずとも使えるので無視してもよい
それよりもmutableとimmutableの意味となぜ区別が必要かを理解したほうがいい
あと参照の意味も理解していないようだからそこもまず基本だからおさえるべき
それら基本を理解すればVecの中身が書き換わるならばmut指定が必要とわかるはず
Rustは簡素に理解しやすく出来ているのに他言語のポインタ周辺の概念を無駄に持ち出してきて難しく考えて失敗する人たちが一部いる
661 名前：デフォルトの名無しさん mailto:sage [2021/10/12(火) 07:19:09.45 ID:SacTrMIO.net]: これが基本を理解してないと指摘されたやつのレスw
662 名前：デフォルトの名無しさん [2021/10/12(火) 08:17:13.13 ID:FR/wdn5M.net]: Rusterは他人を同一人物と思い込む素性の悪い病人しか居ないな
663 名前：633 [2021/10/12(火) 08:42:15.75 ID:5WgWwJH0.net]: 初心者丸出しの質問で、なんでこうなった・・・・・
664 名前：デフォルトの名無しさん mailto:sage [2021/10/12(火) 10:28:07.94 ID:XIKPR8ou.net]: >>647
>Rustは簡素に理解しやすく出来ているのに

それには賛同できない
665 名前：デフォルトの名無しさん mailto:sage [2021/10/12(火) 10:28:20.90 ID:h0zcLGc7.net]: このスレにはアンチRustのC++爺さんと
間違った知識を上から目線でレスするRust初心者が各1名住み着いてるから

質問者は回答内容を自分で精査しないとダメだよ
特に後者はタチが悪いので注意して
666 名前：デフォルトの名無しさん mailto:sage [2021/10/12(火) 10:37:06.05 ID:BYAG38Ke.net]: Rustに近々追加される機能で熱いものなにかありますか？
667 名前：デフォルトの名無しさん mailto:sage [2021/10/12(火) 10:43:27.65 ID:Br1er+Qs.net]: Rustに関する質問はteratailで
668 名前：デフォルトの名無しさん mailto:sage [2021/10/12(火) 10:55:07.59 ID:aJ9lzwpY.net]: 現時点でRustなんかどうでもいい
10年後に普及してたら一般プログラマーも使う程度
669 名前：デフォルトの名無しさん mailto:sage [2021/10/12(火) 11:09:47.63 ID:Br1er+Qs.net]: 653見る前に654書いちゃったのでちょっと訂正
Rustに関するまじめな質問はteratailでするのがよい

>>653
もうすぐRust2021がくるぞい
熱いのがあるかっていうと微妙かも
670 名前：デフォルトの名無しさん mailto:sage [2021/10/12(火) 11:23:31.59 ID:lRrdrCP9.net]: >>650
mutの必要有無は他言語では一般的じゃないRustのルールに関連してるんだけど
それが少し難しいので回答する側にもそのルールを理解してない人がそれなりにいるということ

基本的にコンパイラが教えてくれるので深く理解してなくても使う分にはそこまで問題にはならない
671 名前：デフォルトの名無しさん mailto:sage [2021/10/12(火) 12:59:59.43 ID:dsnSo1To.net]: Rustを知るということは、弱点も知ることにつながる
672 名前：デフォルトの名無しさん [2021/10/12(火) 13:01:46.79 ID:k+FFNiZ5.net]: vlangもmutがあるが散々否定される、曰く「理論に沿ったコンピューター工学を元にしてない」だとか
「トランスコンパイラでしょ」とか、NoGCが過大広告でLobsterというのは分かるがリークするでしょとか
673 名前：デフォルトの名無しさん mailto:sage [2021/10/12(火) 13:21:05.00 ID:WmCYyvpu.net]: async/awaitの追加で一旦大きな機能追加目標は終わって、以降は処理系の効率化にリソースを割いていく、みたいな話を読んだ気がする
674 名前：デフォルトの名無しさん mailto:sage [2021/10/12(火) 13:54:32.71 ID:fJneTy5r.net]: 結局他の言語でのメモリモデルも理解してないとrustはまともに使えんよ。
そこを誤魔化すやつはクソだわ。
675 名前：デフォルトの名無しさん mailto:sage [2021/10/12(火) 14:51:47.32 ID:2YI6ZITw.net]: >>633
Rustは書き換え競合を避けるために、書き換え可能な可変参照(for writer)と、書き換えられない参照(for reader)の区別をして、
書き換えられない参照は同時に複数を持てる(multiple readers)けど、可変参照は同時に一つだけしか許さない(single writer)とすることで、競合を避けている。
Rustではmutかどうかもその観点からなので、変数が別のVecになるだけでなく、同じVecのまま配列内容や長さの変化しても、内容長さ同じだが領域拡大で場所移動でも、書き換わりとしてmutが必要。
だから、Vecのメソッドでmutを要求してるのはそれらの結果論にすぎないし、Vecの内部構造がこうなってるからという説明は不要で筋違い。

>>661
それは違うな。
むしろ頭を一旦ゼロにする柔軟な人ほど理解が早い。
他言語での様々なモデル(メモリモデルやクラスモデルや…)をベースに難しく考える人ほど混乱して理解が遅い。
676 名前：デフォルトの名無しさん mailto:sage [2021/10/12(火) 14:59:49.12 ID:fJneTy5r.net]: >むしろ頭を一旦ゼロにする柔軟な人ほど理解が早い。
>他言語での様々なモデル(メモリモデルやクラスモデルや…)をベースに難しく考える人ほど混乱して理解が遅い。
これを本気で考えてるならバカとしか言いようがない。
C、もしくはアセンブラをバインディングした時に確実にぶっ壊れるコードになるわ。
677 名前：デフォルトの名無しさん mailto:sage [2021/10/12(火) 15:34:41.08 ID:2YI6ZITw.net]: >>663
それはABIやFFIの話であってRustの話ではない。
Rustで完結するシステムでは一切考慮する必要ない。
他言語ライブラリなど利用の際も、適切な仲介モジュールがあれば、利用側で考慮する必要はない。
各言語との連携部分では、それぞれその言語の知識が不可欠なのは当たり前。
だが、それはRustの話ではなく、Rustにおいてはその知識は必要ない。
678 名前：デフォルトの名無しさん mailto:sage [2021/10/12(火) 16:09:45.89 ID:Br1er+Qs.net]: メモリモデルって並行プログラミングやらないならあんまり関係なくない？？？
679 名前：デフォルトの名無しさん mailto:sage [2021/10/12(火) 16:12:51.35 ID:BYAG38Ke.net]: アトミック操作のOrderingの話なんかはC++の定義に丸投げしてるから他の言語の知識が必要というのは一応正しい
680 名前：デフォルトの名無しさん mailto:sage [2021/10/12(火) 16:27:05.41 ID:2YI6ZITw.net]: >>666
それは理解するのにC++の知識を一切必要としない。
なぜならC++言語仕様とは独立して定められている。
つまり、その件についてもRustを理解習得するために他の言語の知識は必要ない。
681 名前：デフォルトの名無しさん [2021/10/12(火) 18:24:19.63 ID:natODgzZ.net]: >>662
「Vecの内部構造がこうなってるからという説明は不要で筋違い」うーん、それこそ趣旨が違うよ。
vec[0] = 2などとして内容長さ同じの場合の理解では、１つの可変参照と、複数の参照を持つ事を
知っているのは必要だが通常では長さや容量が拡張されるpushやinsertは内部構造により説明される。
mutatorであるpushを呼ばない限りはmutは必要なければ、「mutをつけたベクター型」では無くて
配列という質問になるのでは？
682 名前：デフォルトの名無しさん mailto:sage [2021/10/12(火) 19:12:36.47 ID:2YI6ZITw.net]: >>668
公開(pub)されていないstruct Vecの内部構造や非公開のRawVecなどを持ち出してくる人たちがいるから、
「Vecの内部構造がこうなってるからという説明は不要で筋違い」と書いた。
そこは長さや容量を持っている等の概念の理解だけで十分であるし、実際に公表されている情報もそこまで。
683 名前：デフォルトの名無しさん [2021/10/12(火) 19:33:58.77 ID:natODgzZ.net]: >>667
C++の知識を「あまり」必要としないのは確かだがC20/C22などの仕様を「参考」にしているのは明らか。
というかLLVMから見てClangっぽく見えるように頑張っていると公式が言っている
684 名前：デフォルトの名無しさん [2021/10/12(火) 19:37:41.99 ID:natODgzZ.net]: >>669
なるほど言いたい事は理解してるが、長さや容量を持っている等の概念の理解ならライブラリソースを
示した方が明らかでしょう。親切だと褒められる事はすれど不要と切って捨てるほどではないのでは？
685 名前：デフォルトの名無しさん mailto:sage [2021/10/12(火) 21:00:30.83 ID:fJneTy5r.net]: >>664
rustが単独で使われるなんてことは絶対にない。
低レイヤーのことがまるでわかってないってことがよくわかったよ。
686 名前：デフォルトの名無しさん mailto:sage [2021/10/12(火) 22:00:42.97 ID:lRrdrCP9.net]: >>662
「multiple readers or single writer」のセーフティルールは
参照だけに適用されるものではなくて参照の所有者を含めて適用されるもの
687 名前：デフォルトの名無しさん mailto:sage [2021/10/12(火) 22:09:23.38 ID:+W0FsG+B.net]: >>672
Rustでプログラムを書くに当たってRustを構成する様々な低レベルのレイヤーのうちどこまで書き手は意識すべきと考えますか？

さすがにCPUを構成するシリコンひとつひとつの振る舞いを意識することは出来ないので、
これより先は気にしなくて良いという境界は存在すると思うのですが、それはどのあたりにあるとお考えでしょうか
688 名前：デフォルトの名無しさん mailto:sage [2021/10/12(火) 22:18:28.12 ID:1W2DSIiH.net]: >>672
no_stdでさらにシステムコール(あるいは相当)はasmでレジスタ渡しで呼び出しに至るまでRust完全単独で既存OS(など)利用もあるしOS作成ならOS側もRust単独
689 名前：デフォルトの名無しさん mailto:sage [2021/10/12(火) 23:07:50.81 ID:XIKPR8ou.net]: >>664
>Rustで完結するシステムでは一切考慮する必要ない。

それって議論の価値ある？　だって現実的じゃないじゃん
研究者のための言語だっていうなら、それもありだけど
ここにいる人間は実用を求めてるわけでしょ。多分……
690 名前：デフォルトの名無しさん mailto:sage [2021/10/12(火) 23:22:14.99 ID:ElEzb70r.net]: すまんが何を言っているかさっぱり分からない
自分が書いてるのは9割方Rustで完結したプロジェクトだけど、みんなFFIばっかり書いてるのか？
691 名前：デフォルトの名無しさん mailto:sage [2021/10/12(火) 23:52:39.59 ID:XIKPR8ou.net]: Win32APIとリンクしたり、そういうプログラムは書かないってことね
692 名前：デフォルトの名無しさん mailto:sage [2021/10/12(火) 23:56:08.22 ID:ElEzb70r.net]: Win32API使いたいんなら単にwindows-rsクレート使えば良いだけで
その先のC ABIがどうなってるかとか気にする必要はないと思うが
693 名前：デフォルトの名無しさん mailto:sage [2021/10/12(火) 23:57:43.15 ID:ElEzb70r.net]: ああでもwindows-rs自体は割とunsafe あるから気にしないとダメかな
694 名前：デフォルトの名無しさん mailto:sage [2021/10/13(水) 00:00:43.80 ID:PhFIUWEp.net]: いや、そもそもwindows-rsクレート使おうが
C理解してないと使えないよ
だってwindows-rsの型定義は「今のところ」まともじゃないもん
ポインタは何でもかんでもDWORDだし
695 名前：デフォルトの名無しさん mailto:sage [2021/10/13(水) 00:05:34.07 ID:1HIX7TKw.net]: 確かに例が悪かった。windows-rsに関してはunsafe がある以上呼び出し先のCの知識は必須だね
言いたいのは自分でunsafeを書かない限り、Rustだけで完結するってこと
そりゃ分野によってはまだライブラリ不足で完結しにくいのもあるだろうけど、多くの分野で完結すると思うがなぁ
696 名前：デフォルトの名無しさん mailto:sage [2021/10/13(水) 00:37:10.90 ID:bi9uBzGZ.net]: で、そういうメモリをほとんど気にしないソフトはrustで書く必要がないものなんだよね。
ファッションでやってることがバレちゃったね。
697 名前：デフォルトの名無しさん mailto:sage [2021/10/13(水) 00:38:57.86 ID:fXfbCLiK.net]: Rust以外のプログラミング言語を考えれば理解しやすい
C言語を全く知らなくても使えるようにその言語だけで書かれたAPIで何でも利用できる
Rustも同様でC言語を全く知らなくても使えるようにRustだけで書かれたAPIで何でも利用できるようにすることができるし実際にほとんどの分野ではそうなっている
その上でRustの場合は効率面から元のAPI向き出しで例えばCStr使ったりするなどC言語でのAPIのまま提供するモジュールも存在するというだけにすぎなくてそこはあくまでもFFI領域
したがって「他の言語と同様にRustもC言語を全く知らなくても使える」で正解
698 名前：デフォルトの名無しさん mailto:sage [2021/10/13(水) 01:08:46.05 ID:4amWetfo.net]: >>683
rustで書く必要性が薄いってのは結構当てはまるとは思うが、
だからといってメモリ回りの知識がrustで何か書くには絶対必須とはならんだろう
699 名前：デフォルトの名無しさん mailto:sage [2021/10/13(水) 01:16:25.82 ID:fXfbCLiK.net]: >>683
例えばstd::fsやstd::netなどは本来ならCのABIでやりとりするものだが
そんなこといっさい気にする必要なくRustの型で渡してRustの型で返ってくるようにRustの標準ライブラリが作られている
そこにCの知識は全く必要としない
700 名前：デフォルトの名無しさん mailto:sage [2021/10/13(水) 07 ]: [ここ壊れてます]
701 名前：:24:31.94 ID:WqU30Pep.net mailto: たくさん書くのは自信がなさの表れ
そんな必死になるような話じゃないだろうに []: [ここ壊れてます]
702 名前：デフォルトの名無しさん mailto:sage [2021/10/13(水) 09:00:38.12 ID:W/9iWpHx.net]: Cを理解してないとRustは使えない、と
ウソをつく人がいるからだろう
703 名前：デフォルトの名無しさん mailto:sage [2021/10/13(水) 09:25:52.29 ID:bi9uBzGZ.net]: そう思い込んでりゃいいんでない？
近くにいなけりゃ放置するよ。近くにいればボコボコにするけど。
704 名前：デフォルトの名無しさん [2021/10/13(水) 09:41:01.46 ID:+i9fv0nZ.net]: >>674
cpuはシリコンウエハ一枚から切り取ったものからなっている
複数のシリコンの集合体ではない
705 名前：デフォルトの名無しさん mailto:sage [2021/10/13(水) 10:15:02.35 ID:hOkEY9I6.net]: >>688
そういうやつの相手をムキになってやってるうちは自分も同じレベルだって気付けよな
706 名前：デフォルトの名無しさん mailto:sage [2021/10/13(水) 10:36:12.77 ID:gkjY8I9d.net]: >>690
ちなRyzenとか、組み込みマイコンとかは、マルチチップを繋いで一つにパッケージしてるのもあるけどね。
シリコン一つ一つとかポエムっぽいのは秋になったからか？
707 名前：デフォルトの名無しさん mailto:sage [2021/10/13(水) 14:45:58.97 ID:qAYNHtUZ.net]: >>690
シリコン原子一粒一粒の意味
708 名前：デフォルトの名無しさん mailto:sage [2021/10/14(木) 18:50:15.29 ID:1TrBYNn/.net]: コンピュータアーキテクチャの基礎知識(メモリモデル、アクセスオーダ、スレッディング等)やOSのシステムコール、APIの知識の事を "C言語の知識" と呼ぶ人が居るのね。
まあどうでもいいけど。
709 名前：デフォルトの名無しさん mailto:sage [2021/10/14(木) 19:43:21.65 ID:JvADELGn.net]: システムコールにしても最終的にはレジスタに積んでsyscall命令もしくは割り込みするだけだからCでもRustでもasmと共存するだけか
C言語の知識は要らないな
710 名前：デフォルトの名無しさん mailto:sage [2021/10/14(木) 20:55:23.77 ID:1TrBYNn/.net]: まあシステムコールやAPIは C や CPP のヘッダ形式で定義/提供されてるという事を言いたいなら判らんでもないが、
そこまでコアな言語仕様知識は要らないねえ。
711 名前：デフォルトの名無しさん mailto:sage [2021/10/14(木) 21:55:10.80 ID:GbD2vike.net]: rustは書けるけどCが書けない人いる？
そういう人がいないとCがいるかいらないかわからない
自分はCの知識が役に立ったと思う
712 名前：デフォルトの名無しさん mailto:sage [2021/10/14(木) 22:21:20.24 ID:dWpPrl+Q.net]: RustでWebバックエンド書いてる人になら普通にいるんじゃない？
Web系ならこれまでのキャリアで全くCに触れなくてもおかしくないし
713 名前：デフォルトの名無しさん mailto:sage [2021/10/15(金) 10:55:12.45 ID:GXWQCf9x.net]: 昔からRust for Rubyistsとかあるしスクリプト系言語から流れて来る人もそれなりにいるかと
714 名前：デフォルトの名無しさん [2021/10/15(金) 12:44:17.46 ID:P5mUityt.net]: スマートポインタやシェアードポインタ、所有権なんかは、C++0xあたりで導入された考えだから
どの程度の範囲をC言語と言っているのかによる。要らない派が多く「見える」が、知識があって
理解をを妨げるという考えは全否定する。「あって困るものではない」
715 名前：デフォルトの名無しさん mailto:sage [2021/10/15(金) 14:00:41.51 ID:8deGlJY8.net]: >>695
OSプログラムしてるとレジスタ内容をメモリに載せるなんて普通にあることなんだが。
まあrustでOSなんて書かないから関係ないですけどね。
716 名前：デフォルトの名無しさん mailto:sage [2021/10/15(金) 14:27:53.37 ID:lZWoC8Xx.net]: >>701
OSなんて書いたこともないくせに語るなド素人
717 名前：デフォルトの名無しさん mailto:sage [2021/10/15(金) 15:04:44.50 ID:8deGlJY8.net]: >>702
ソースコード読むことすらしてないバカは黙ってて。
718 名前：デフォルトの名無しさん mailto:sage [2021/10/15(金) 15:15:35.47 ID:rb+Oscx7.net]: なんか低レベルな話で盛り上がってるな
719 名前：デフォルトの名無しさん mailto:sage [2021/10/15(金) 15:16:50.75 ID:5/Pqp5xe.net]: そんなことよりシステムコールの呼び出しにCの知識は必要ないっていうコメント対して>>701のレスが噛み合ってないんだが、何を言いたかったのか解説してくれないか
720 名前：デフォルトの名無しさん mailto:sage [2021/10/15(金) 15:20:05.89 ID:8deGlJY8.net]: なるほど、レジスタからメモリ書き込みの同期タイミングなどが必要とかそこまで具体的に言わないと理解できないレベルなのか。
すげー馬鹿しかいないのなら仕方ないな。
721 名前：デフォルトの名無しさん mailto:sage [2021/10/15(金) 15:33:44.29 ID:5/Pqp5xe.net]: システムコールの呼び出しとはまったく関係ないな
722 名前：デフォルトの名無しさん mailto:sage [2021/10/15(金) 15:40:54.74 ID:lZWoC8Xx.net]: OS書いたことも無いのに恥ずかしい奴
723 名前：デフォルトの名無しさん mailto:sage [2021/10/15(金) 15:45:02.58 ID:lZWoC8Xx.net]: >>705
それな

> OSプログラムしてるとレジスタ内容をメモリに載せるなんて普通にあることなんだが。

何でいきなり一人だけ見当ハズレなこと言い出したのかだけでも説明してほしいわ
724 名前：デフォルトの名無しさん mailto:sage [2021/10/15(金) 16:38:42.56 ID:XGfxQXO+.net]: >>701
Rustはインラインasmできるので好きなレジスタと好きな変数(メモリ)の行き来演算できるしRustだけでOSも書ける
725 名前：デフォルトの名無しさん [2021/10/15(金) 17:41:49.92 ID:W8XYkXKH.net]: >>710
どうせunsafeなんだろ
726 名前：デフォルトの名無しさん mailto:sage [2021/10/15(金) 18:11:50.56 ID:rb+Oscx7.net]: 寒色は人権すらないからな
727 名前：デフォルトの名無しさん mailto:sage [2021/10/15(金) 18:54:33.37 ID:0qD/Pqit.net]: >>711
そりゃアセンブリですから
safeにするには不変条件を満たすように自分でやらなきゃいけない
728 名前：デフォルトの名無しさん mailto:sage [2021/10/15(金) 18:55:28.40 ID:IFdb5cTy.net]: Rust？　人気らしいね、でもオイラやらないよ
Cは嫌いだし、その後釜狙いの言語はどうせ肌に合わないさ
大半の人には必要ない言語だよね、だからオイラGoをやるよ
729 名前：デフォルトの名無しさん mailto:sage [2021/10/15(金) 18:58:20.72 ID:WKIFTMdH.net]: GoのほうがよっぽどCの後釜感あるがな
GCのあるCという感じ
730 名前：デフォルトの名無しさん mailto:sage [2021/10/15(金) 19:22:21.57 ID:PoOS8yLC.net]: >>711
unsafeを誤解しているようだけど
CやC++と同じ状況すなわちその部分のメモリ安全性は自己管理となるだけ
だから論理的に安全な操作でそれがローカルに閉じ込められて他に影響を及ぼさないならば使われうる
例えば標準ライブラリのVecもその内部実装の一部でunsafeが使われているが我々はVecを安全に使うことができる

>>715
つまりGoはCやC++の代替になれない
731 名前：デフォルトの名無しさん [2021/10/15(金) 19:27:43.08 ID:vEXHgFWD.net]: rustの強みである静的メモリ安全性っていうのが活かせてないやんって意味で言ったんやけど
cやc++と同じ状況ならむしろrustよりcやc++使うよね？
732 名前：デフォルトの名無しさん mailto:sage [2021/10/15(金) 19:36:00.75 ID:sYZbhEbz.net]: 量の概念がないやつが定期的に現れるな
コード全域がunaafeなのと局所的なのは全然違うでしょ
733 名前：デフォルトの名無しさん mailto:sage [2021/10/15(金) 19:46:42.29 ID:PoOS8yLC.net]: >>717
例えばVecは実装内部でunsafeを用いているが
Vecはメモリ安全性を保証する
そしてVecを用いたプログラムもRustコンパイラが通ればメモリ安全性が保証される
734 名前：デフォルトの名無しさん [2021/10/15(金) 19:48:51.64 ID:eqKsqNtm.net]: それならC++も同じでは？
735 名前：デフォルトの名無しさん [2021/10/15(金) 19:49:28.65 ID:OmwX7nxr.net]: >>719
unsafeなのにメモリ安全性どうやって保証してるの？
736 名前：デフォルトの名無しさん [2021/10/15(金) 19:52:54.07 ID:eqKsqNtm.net]: C++の場合は、vector自身がメモリーの所有権を持ってるので安全性が保障されるんだけど。
737 名前：デフォルトの名無しさん mailto:sage [2021/10/15(金) 20:08:04.69 ID:PoOS8yLC.net]: >>721
え？何を言ってるの？
Vecに限らずRustの各型を含めた標準ライブラリの内部はもちろんunsafeだらけだけど
論理的に安全な操作のみ、かつ、内部に閉じ込められていて外部に影響を及ぼさないもののみ
だからそれら型を含めた標準ライブラリを我々は安全に使うことができる
そしてそららを用いた我々のプログラムはコンパイラが通ればメモリ安全性を保証される
738 名前：デフォルトの名無しさん [2021/10/15(金) 20:14:36.90 ID:eqKsqNtm.net]: >>723
じゃあC++と変わりませんね。
739 名前：デフォルトの名無しさん [2021/10/15(金) 20:15:19.52 ID:I/84Z1Ml.net]: >>723
だからアスペか？
論理的に安全な操作のみ、かつ、内部に閉じ込められていて外部に影響を及ぼさないってことをどうやって保証してるのか聞いてんだけど？
国会の答弁みたいな返答やめろよ
というか外部にメモリ及ぼさないはメモリ安全性が保たれるの必要条件じゃないんだけど
740 名前：デフォルトの名無しさん [2021/10/15(金) 20:15:56.65 ID:I/84Z1Ml.net]: 外部にメモリ及ぼさないじゃなくて外部に影響及ぼさないだった
741 名前：デフォルトの名無しさん mailto:sage [2021/10/15(金) 20:21:27.95 ]: [ここ壊れてます]
742 名前： ID:PoOS8yLC.net mailto: >>724
C++はコンパイルが通ってもメモリ安全性は保証されません
Rustはコンパイラが通ればメモリ安全性が保証されます
全く異なります

>>725
論理的にそれらを満たす操作かどうかです
Rustコンパイラが通ればメモリ安全性を保証するかどうかも論理的に基づいて保証されます []: [ここ壊れてます]
743 名前：デフォルトの名無しさん [2021/10/15(金) 20:33:33.14 ID:WHarWmnu.net]: >>727
メモリ安全性を保証することを諦めればコンパイル通るのは当然だよね？
こんな基本的なこともわからないんですか？
744 名前：デフォルトの名無しさん mailto:sage [2021/10/15(金) 20:36:47.57 ID:jQ7TSjOD.net]: Cしか知らない人ってプログラミング言語の仕様とコンピュータのアーキテクチャが区別できないってマ？
型理論も知らないってマ？
745 名前：デフォルトの名無しさん mailto:sage [2021/10/15(金) 20:40:52.58 ID:PoOS8yLC.net]: >>728
その通りでC++はコンパイルが通ってもメモリ安全性が保証されない言語
一方でRustはコンパイルが通ればメモリ安全性が保証される言語
746 名前：デフォルトの名無しさん [2021/10/15(金) 20:50:24.31 ID:LC/Ahxji.net]: >>730
>unsafeを誤解しているようだけど
>CやC++と同じ状況すなわちその部分の>メモリ安全性は自己管理となるだけ
って自分で言ってるよね？自分の過去の発言と言ってること矛盾してない？
rustのunsafeはメモリ安全性を保証することを諦めてるって言いたかったようだけど今は言ってること無茶苦茶じゃない？
747 名前：デフォルトの名無しさん mailto:sage [2021/10/15(金) 20:51:16.86 ID:U2SV1SiG.net]: >>722
これが一般的なC++erの認識だとしたら恐ろしいな
748 名前：デフォルトの名無しさん mailto:sage [2021/10/15(金) 20:58:34.88 ID:NxDOUPls.net]: unsafeなコードが周りを滅茶滅茶にしない保証は無いよ
749 名前：デフォルトの名無しさん mailto:sage [2021/10/15(金) 21:01:02.97 ID:NxDOUPls.net]: unsafeを使った場合の安全性の保証を機械的にやりたければ↓みたいなので契約プログラミングする手はあるね
https://crates.io/crates/contracts
750 名前：デフォルトの名無しさん mailto:sage [2021/10/15(金) 21:10:23.11 ID:PoOS8yLC.net]: >>731
もちろんRustの標準ライブラリの実装内部には多数の細かい小さなunsafeがあってその部分はコンパイラによるメモリ安全性保証の範囲外
それそれの内部ローカルのunsafe使用が論理的にメモリ安全であるか否かの保証はコンパイラではなく人間が行ないunsafeはそのためにある
その上でRustコンパイラはプログラム全体のメモリ安全性を保証する
751 名前：デフォルトの名無しさん [2021/10/15(金) 21:17:10.00 ID:Ue2FksZS.net]: >>735
人間がどうやって行うの？
752 名前：デフォルトの名無しさん mailto:sage [2021/10/15(金) 21:31:51.20 ID:XGfxQXO+.net]: 話は簡単だ
C/C++はプログラム全てがRustのunsafe状態
つまりC/C++はプログラム全てを人間がメモリ安全であると保証しなければならないが人間なので複雑化するとミスも生じる
GAFAM各社はメモリ安全に関するバグが全く減らずセキュリティ脆弱性の多くがこの問題に起因することに気付いた
そこでコンパイラがメモリ安全であると保証するRustを採用して少しずつC/C++から移行させていってる段階
753 名前：デフォルトの名無しさん [2021/10/15(金) 21:34:04.93 ID:OlLYCHFC.net]: unsafe blockはマーが全力で頑張ります！ゾーンだからな
アルゴリズムにおいてあるアルゴリズムが正当であると判定するアルゴリズムは存在しないんだからラストコンパライでも完全なセーフティは保証は出来ないけどな
ただ完全ではないものの他の注意すべき所をランコンに任せてunsafe部にヒューマンリソース限定出来るのはc++を遥かに優れた点よね(´・ω・｀)
754 名前：デフォルトの名無しさん mailto:sage [2021/10/15(金) 21:39:33.56 ID:NxDOUPls.net]: 布教しようとしなくたっていいんだよ
めんどくせえから
755 名前：デフォルトの名無しさん [2021/10/15(金) 21:42:55.26 ID:eqKsqNtm.net]: >>737
GAFAがその体たらくとは信じがたいけど、resource管理は所有権ベースでほぼ解決するし、逆に所有権以外で解決することは出来ないと思う。
756 名前：デフォルトの名無しさん [2021/10/15(金) 21:45:54.09 ID:kEafjbCd.net]: >>738
チューリングマシンの停止性問題のこと言ってるんだろうけど違うよ
あるアルゴリズムじゃなくて任意のね
「あるプログラムが正当であると判定するプログラムは存在しない」じゃなくて「任意のプログラムを正当であると判定するプログラムは存在しない」が正しい
これが5chクオリティか
757 名前：デフォルトの名無しさん mailto:sage [2021/10/15(金) 21:58:02.76 ID:rb+Oscx7.net]: Rustコンパイラによるメモリ安全性の保証は信頼してても、unsafe使ってる標準ライブラリを信頼しない話おもしろいね。
実際に問題なく動いてるんだから仕様を信頼すればいいのに。
758 名前：デフォルトの名無しさん mailto:sage [2021/10/15(金) 22:06:00.13 ID:PoOS8yLC.net]: >>742
人間が局所的に注力すれば済むのがRust
人間がプログラム全般に注力しなければならず破綻したのがCとC++
759 名前：デフォルトの名無しさん [2021/10/15(金) 22:07:41.72 ID:OlLYCHFC.net]: >>741
うーんまぁ日本語で論理学考える事なんてあんましないから間違えてるのかもしれんが
あるアルゴリズム、ある整数等々で俺はある集合(=アルゴリズム全体で構成される集合)の元の任意性を表してんたんだけどな(´・ω・｀)
760 名前：デフォルトの名無しさん mailto:sage [2021/10/15(金) 22:11:36.31 ID:wjdlJ99Z.net]: >>743
勝手に破綻したことにするのやめな？
そういうとこやぞお前マジ
761 名前：デフォルトの名無しさん [2021/10/15(金) 22:18:09.07 ID:JTaIEN+o.net]: >>744
その言い訳は厳しいよ
まあワイもまともに勉強するまでもそこあたりあやふやだったしそんな気にすんなや
762 名前：デフォルトの名無しさん mailto:sage [2021/10/15(金) 22:39:44.83 ID:XGfxQXO+.net]: >>740
C/C++に限界を感じたGAFAMたち大手IT企業がRustに結集
特定の言語がIT業界を挙げて支持されるのは初めて

プログラミング言語「Rust」のための「Rust Foundation」設立 -- AWS(Amazon)、Microsoft、Google、Mozilla、Huaweiが創設
https://japan.zdnet.com/article/35166267/

Facebookが「Rust Foundation」に参加
https://japan.zdnet.com/article/35170192/
763 名前：デフォルトの名無しさん [2021/10/16(土) 00:08:25.70 ID:dPfgeqZY.net]: >>717
それどこの0か100しか無い世界？
764 名前：デフォルトの名無しさん mailto:sage [2021/10/16(土) 00:34:25.94 ID:bSvFIUA3.net]: C++はこれで鼻から悪魔出るから

vector<int> hoge {0};
int& fuga = hoge[0];
for (size_t i = 0; i < 5; ++i) {
hoge.push_back(i);
}
cout << fuga;
}

nsafeがどうたらぬ気にしてRustはこういうのが防げるってだけでもそれなりの価値はある

ちなみにunsafeブロックは本当に慎重に作らないと、unsafeの外部をちょっといじっただけで鼻から悪魔が出たりする
https://doc.rust-jp.rs/rust-nomicon-ja/working-with-unsafe.html
unsafeブロック外のidx < arr.len()をidx <= arr.len()にしただけで死ぬ
765 名前：デフォルトの名無しさん mailto:sage [2021/10/16(土) 03:36:57.11 ID:I/G6evYm.net]: unsafeなコードが1行でもあったらRustで書く意味ないと主張する人が定期的に現れるのはなぜなのか
766 名前：デフォルトの名無しさん mailto:sage [2021/10/16(土) 03:54:24.52 ID:0owCAudu.net]: >>750
C++が劣ることを認めたくない人が「unsafeがあるならC++と同じだからRustの存在意義はない。」という間違った主張をしてるみたい
767 名前：デフォルトの名無しさん mailto:sage [2021/10/16(土) 04:04:47.91 ID:4kIP2zxZ.net]: C++との対決は別の専用スレがあるのでそっち使ってくださいね
768 名前：デフォルトの名無しさん mailto:sage [2021/10/16(土) 04:11:16.75 ID:0owCAudu.net]: >>752
同感
C++な人はここでやらずに
向こうの専用スレでやってほしい

C++ vs Rust
https://mevius.5ch.net/test/read.cgi/tech/1619219089/
769 名前：いつもの光景 [2021/10/16(土) 07:19:55.59 ID:VQLpYdr0.net]: Vec型の質問に高卒が答える
　↓
当然の如く高卒がバカにされる
　↓
高卒発狂
　↓
パソコンがどうの、C++がどうの、いつもの大先生問答に発展
770 名前：デフォルトの名無しさん [2021/10/16(土) 09:07:15.06 ID:GnSu5gfs.net]: >>749
ちなみになんでこれで悪魔がでるんですか？
無学ですみません
771 名前：デフォルトの名無しさん [2021/10/16(土) 09:21:09.42 ID:wH7tzS3T.net]: >>755
fugaがhogeのメモリ参照を取った後にhoge.push_back()でデータを追加している。
データ追加ではhogeの内部で確保していたメモリ領域が足りなくなると
新しいアドレスに確保しなおす（元の領域は開放する）ので、
fugaが指しているアドレスはアクセスしてはいけない領域になってる。（ダングリングポインタ）
その状態でcoutでfugaを使ってるから。
772 名前：デフォルトの名無しさん [2021/10/16(土) 09:48:04.61 ID:GnSu5gfs.net]: >>756
なるほど
ダングリングポインタになっているんですね
教えてくださってありがとうございます
773 名前：デフォルトの名無しさん mailto:sage [2021/10/16(土) 10:29:54.02 ID:N8k1BZc2.net]: unsafeなtraitとそうでない通常のtraitってどう違うんでしょうか
implにunsafeって書かないといけない点以外で
774 名前：デフォルトの名無しさん mailto:sage [2021/10/16(土) 12:13:05.40 ID:MVC0A82Z.net]: バカは実際にバグが起きるかどうかを考えてなくて
バグを誰かのせいにできるかどうかしか考えてないんだろ。
だからこんなしょーもないものが持て囃されるってわけだ。
775 名前：デフォルトの名無しさん mailto:sage [2021/10/16(土) 13:08:52.57 ID:xy6guhnI.net]: 東アジア圏は原因の究明と再発防止より責任の追及と処罰を優先する文化だからな
気をつければ問題ないみたいな精神論が平気で唱えられるのも同様
システム工学先進国のアメリカあたりと比べたらかなり後れている
776 名前：デフォルトの名無しさん [2021/10/16(土) 20:42:26.55 ID:jYqji68p.net]: それは東アジア人の性質ってか東朝鮮の性質だろ(´・ω・｀)
777 名前：デフォルトの名無しさん mailto:sage [2021/10/17(日) 12:48:28.83 ID:5UKSiAtl.net]: CargoでC/C++のコードをビルドするときにヘッダファイル等の依存関係って何処まで面倒を見てくれるんだろ？
自分で全部記述しないとダメなのか、自動的に追跡してくれるのか・・・
ググってもCのコードも一緒にビルドできます以上の情報が見つからん
778 名前：デフォルトの名無しさん mailto:sage [2021/10/18(月) 10:43:24.73 ID:oPyph5kC.net]: 面倒見るわけねーじゃん。
ヘッダーファイル依存をまともに解決しようと思うと、ビルド速度に影響がモロに出る。
解決するには暗黙のキャッシュ使うことになって問題が起きやすくなる。
779 名前：デフォルトの名無しさん mailto:sage [2021/10/18(月) 11:14:38.10 ID:jL9+j5XP.net]: >>762
一番基本的なやり方だとcc crate使うことになると思うけど
このやり方だとヘッダやライブラリは自分で指定する必要ある
使ったことないけどpkg_config crateとか使えば多少は楽になるのかもしれない

C/C++コードが別プロジェクトからの流用ならそのプロジェクトのビルドツールに乗っかるのが楽かも
例えば cmake や autocfg/autotools といった crate はあるみたい
780 名前：デフォルトの名無しさん mailto:sage [2021/10/18(月) 12:25:26.72 ID:cow76Y8p.net]: >>749
vectorじゃなくて、listを使うと大丈夫。
C言語は、もともと、linked list が代名詞の様な言語。
それを引き継いだC++もstd::listこそが主役。
ところが、stroustrupがvectorを推奨するから混乱してる。
781 名前：デフォルトの名無しさん mailto:sage [2021/10/18(月) 12:39:56.60 ID:jL9+j5XP.net]: >>765
それは初耳。誰が linked list が C の代名詞と言っているの？
経験上は配列使うことの方が多いように思うんだが
782 名前：デフォルトの名無しさん mailto:sage [2021/10/18(月) 15:20:57.34 ID:gU1bKDav.net]: >>765
std::listはn番目アクセス遅いよ
だからstd::vectorを利用するケースが圧倒的に多い
783 名前：デフォルトの名無しさん mailto:sage [2021/10/18(月) 15:29:58.26 ID:+iNX7XVA.net]: listそんな使うことないやろ。挿入と削除が早いだけやんけ。何が言いたかったんだか。
784 名前：デフォルトの名無しさん mailto:sage [2021/10/18(月) 21:23:43.42 ID:292fwFlx.net]: 確かにlistはあまり使った記憶がないなー
キャッシュのミスヒットを考えると、
vectorでリロケートした方が速い場合もあるし
785 名前：デフォルトの名無しさん mailto:sage [2021/10/18(月) 23:37:04.31 ID:Qq+Ry0m8.net]: listは敵キャラの弾幕なんかの座標管理なんかに使える
786 名前：デフォルトの名無しさん mailto:sage [2021/10/19(火) 12:19:23.96 ID:5XPa2/LH.net]: ほぼcだよねこれ。
https://github.com/Rust-for-Linux/linux
787 名前：デフォルトの名無しさん mailto:sage [2021/10/19(火) 12:22:25.90 ID:GgDBkr4o.net]: (Cで書かれてるLinuxカーネルのフォークなんだから当たり前やろ)
788 名前：デフォルトの名無しさん mailto:sage [2021/10/19(火) 15:27:28.34 ID:0LtRxxZs.net]: そもそも全部書き直すならLinuxを冠する意味が・・・
789 名前：デフォルトの名無しさん mailto:sage [2021/10/19(火) 16:06:41.74 ID:9axoCOPN.net]: 何で？
(全部書き直すなど誰も言ってないけど理由を聞いてみたい)
790 名前：デフォルトの名無しさん mailto:sage [2021/10/19(火) 16:12:52.85 ID:473S9WY0.net]: うん、それ、RustでLinuxを作り直してるんじゃなくて、元々のLinuxをベースにして、新しい機能をRustで開発しようとしているプロジェクトでしょ
791 名前：デフォルトの名無しさん [2021/10/19(火) 18:28:24.83 ID:lJqU9SJa.net]: 嘘つき
792 名前：デフォルトの名無しさん [2021/10/19(火) 18:57:21.27 ID:C9DkQou5.net]: 日本語不自由どころか
頭が不自由だと拝察します
793 名前：デフォルトの名無しさん mailto:sage [2021/10/19(火) 18:58:18.97 ID:bh+xrreW.net]: panicは無事無くなったんかな。
794 名前：デフォルトの名無しさん mailto:sage [2021/10/19(火) 19:07:22.39 ID:0VPrblkh.net]: 彡 ⌒ ミ
(´・ω・`) 頭が不自由という言葉が引っかかったので飛んできました
795 名前：デフォルトの名無しさん [2021/10/19(火) 19:29:57.38 ID:k3wLx80J.net]: 彡 ⌒ ミ
(´・ω・`) 飛ぶとかカッパの風上にも置けんな、泳げや
796 名前：デフォルトの名無しさん mailto:sage [2021/10/19(火) 20:33:01.03 ID:q+n6NKoj.net]: >>778
アロケーターのpanicのことなら7月に出たパッチでなくなったみたい
https://lore.kernel.org/lkml/20210704202756.29107-1-ojeda@kernel.org/
797 名前：デフォルトの名無しさん mailto:sage [2021/10/19(火) 20:49:57.64 ID:XSR/7M6W.net]: C++erはほんとゴシップ談義が好きやな
Rustスレにまでそのカルチャー持ち込まんで欲しいわ
798 名前：デフォルトの名無しさん [2021/10/19(火) 21:31:52.96 ID:3gMaYVXy.net]: ペチパーと大差ないからな
799 名前：デフォルトの名無しさん mailto:sage [2021/10/20(水) 10:48:38.28 ID:kKtRU0ug.net]: ターゲットも開発者も丸かぶりだからしゃあない
800 名前：デフォルトの名無しさん [2021/10/20(水) 13:23:40.75 ID:nZj/SCQk.net]: で、非同期ライブラリはどれが標準になるのよ？
801 名前：デフォルトの名無しさん [2021/10/20(水) 13:24:10.28 ID:nZj/SCQk.net]: で、非同期ライブラリはどれが標準になるのよ？
802 名前：デフォルトの名無しさん [2021/10/20(水) 13:29:36.31 ID:4F9a+p6K.net]: tokio
803 名前：デフォルトの名無しさん [2021/10/20(水) 16:05:21.56 ID:Ojn1Tksn.net]: std
804 名前：デフォルトの名無しさん [2021/10/20(水) 18:46:14.43 ID:2vbfBLJv.net]: どっちでもいいけど、インターフェースは統一して欲しいな。
今のところtokioか優勢みたいね。
805 名前：デフォルトの名無しさん mailto:sage [2021/10/20(水) 21:12:16.85 ID:rAmGIrdk.net]: std::sync::mpsc ってなんで send がノンブロッキングなんだろうなぁ。
806 名前：デフォルトの名無しさん mailto:sage [2021/10/20(水) 23:01:04.88 ID:Px+syONf.net]: ブロッキングなSenderがほしいならchannel_sync使うんだべさ
807 名前：デフォルトの名無しさん [2021/10/20(水) 23:32:51.88 ID:4F9a+p6K.net]: ブロッキングとかノンブロッキングとか何度か解説読んだ気がするけど意味がわからないわ
808 名前：デフォルトの名無しさん [2021/10/21(木) 00:05:01.15 ID:5bux1k1I.net]: 迷惑な香具師だな
809 名前：デフォルトの名無しさん mailto:sage [2021/10/21(木) 02:48:53.14 ID:rcBT1TlJ.net]: おまいら mut のことを何て呼んでる？
俺は心の中でムットと呼んでいる
810 名前：デフォルトの名無しさん mailto:sage [2021/10/21(木) 02:53:24.97 ID:4380fmPV.net]: ミュータブルの略なので……
811 名前：デフォルトの名無しさん mailto:sage [2021/10/21(木) 03:47:37.11 ID:mWga6xPa.net]: インテジャーはイント
キャラクターはチャー
なんだから、ムットでも何でも好きに呼べばよろし

ちなみに俺は心の中でムトゥと踊る^H^H呼んでる
812 名前：デフォルトの名無しさん mailto:sage [2021/10/21(木) 08:50:47.46 ID:rE4toNa0.net]: マッだろjk
813 名前：デフォルトの名無しさん mailto:sage [2021/10/21(木) 08:54:53.70 ID:NOaHdDiV.net]: マットな
814 名前：デフォルトの名無しさん mailto:sage [2021/10/21(木) 11:02:50.76 ID:s+STdMnX.net]: cv::Mat は?
815 名前：デフォルトの名無しさん [2021/10/21(木) 13:03:22.69 ID:rHBxJh+b.net]: >>799
メアット
816 名前：デフォルトの名無しさん mailto:sage [2021/10/21(木) 13:17:43.38 ID:rE4toNa0.net]: メッ
817 名前：デフォルトの名無しさん mailto:sage [2021/10/21(木) 15:58:29.41 ID:X5IbXF0A.net]: そんなくだらない疑問より誰か>>758に答えてくれませんでしょうか
818 名前：デフォルトの名無しさん mailto:sage [2021/10/21(木) 16:23:52.35 ID:iSzsEmw9.net]: >>802
implにunsafeって書かないといけないのと同じことだけど
implを書くやつが要求されてるsafetyルールを担保しないといけない

そのためのマーカー
819 名前：デフォルトの名無しさん [2021/10/21(木) 16:35:52.56 ID:wNducfW7.net]: うんこすれっど
820 名前：デフォルトの名無しさん mailto:sage [2021/10/21(木) 19:56:22.82 ID:wPmlSLSw.net]: >>791
sync_channelってのがあるのか。ありがと。
ちゃんとランデブーもできるって書いてあるな。
821 名前：デフォルトの名無しさん mailto:sage [2021/10/23(土) 00:54:23.67 ID:pgS4Ah89.net]: Rust 1.56.0 リリース！
https://tech-blog.optim.co.jp/entry/2021/10/22/080000
822 名前：デフォルトの名無しさん mailto:sage [2021/10/23(土) 01:45:44.26 ID:BVy1/we8.net]: let x = f64::cos(3.14);
みたいなのをf64::を省略して書きたいのですがどうすればよいですか？
use f64::cos; みたいなことはダメなようです
823 名前：デフォルトの名無しさん mailto:sage [2021/10/23(土) 12:44:59.32 ID:rv17aNSC.net]: 1回はf64と言わないと伝わらないので
let p = 3.14_f64;
let x = p.cos();
824 名前：デフォルトの名無しさん mailto:sage [2021/10/23(土) 14:40:08.49 ID:BVy1/we8.net]: すみません、p.cos()の記法がなんかイヤでcos(p)みたいな記法をしたいってことでした
825 名前：デフォルトの名無しさん [2021/10/23(土) 18:48:04.65 ID:/3ucisXu.net]: use f64
でだめなら無理じゃね
826 名前：デフォルトの名無しさん mailto:sage [2021/10/23(土) 18:52:41.89 ID:qtW8jcI5.net]: modなら確かにuseで省略できるけど
Box::newのBox::を省略したいみたいな話だしなあ
827 名前：デフォルトの名無しさん mailto:sage [2021/10/23(土) 18:55:33.73 ID:qhVW7VS5.net]: fn cos(x: f64) -> f64 {
f64::cos(x)
}

cos(3.14)

素直にp.cos()のほうがいいとは思う
828 名前：デフォルトの名無しさん mailto:sage [2021/10/23(土) 18:55:43.78 ID:rVbtEKl1.net]: let cos = f64::cos;
ならいける

https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=3c7b96b61723e46d132c9e0f2d46911b
829 名前：デフォルトの名無しさん [2021/10/23(土) 19:43:20.47 ID:2qA+vCFq.net]: fn main() {
println!("{}", cos(&32));
println!("{}", cos(&4.5))
}

trait GetDouble {
fn get_double(&self) -> f64;
}

fn cos(num: &dyn GetDouble) -> f64 {
f64::cos(num.get_double())
}

impl GetDouble for f64 {
fn get_double(&self) -> f64 {
*self
}
}

impl GetDouble for i32 {
fn get_double(&self) -> f64 {
f64::from(*self)
}
}
https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=cb0e5606622069ca33b0ef0971fa94b4
これでいこう
830 名前：デフォルトの名無しさん mailto:sage [2021/10/23(土) 20:42:27.27 ID:qhVW7VS5.net]: ジェネリックにしたいならIntoでいいんじゃないかな

fn cos(x: impl Into<f64>) -> f64 {
f64::cos(x.into())
}
831 名前：デフォルトの名無しさん mailto:sage [2021/10/23(土) 20:49:05.66 ID:+aPgOjd/.net]: ジェネリックにしたいなら戻り値も引数に合わせたいのでは
num_traits::Float::cos など使うべき
https://docs.rs/num-traits/0.2.14/num_traits/float/trait.Float.html#tymethod.cos
832 名前：デフォルトの名無しさん mailto:sage [2021/10/24(日) 14:23:12.50 ID:eQqSgpa/.net]: 文法でrustとc++/cが似ているって言うやつは何をもって似ていると言っているだろう
ムーブセマンティクスがデフォだし、classはない、for文はイテレータだし、変数と関数の宣言の�
833 名前：痰｢がはっきりしているし 何よりも型は前置じゃないし []: [ここ壊れてます]
834 名前：デフォルトの名無しさん mailto:sage [2021/10/24(日) 14:52:08.66 ID:spG6Bthy.net]: C++とスクリプト言語ぐらいしか知らないんじゃないの？
835 名前：デフォルトの名無しさん mailto:sage [2021/10/24(日) 14:55:21.00 ID:lUSERxty.net]: >>817
誰がもなにもオフィシャルなドキュメントでC++に似せたと言っている
型引数が<>だったりブロックが{}だったりそういうレベルで似てると言っている
836 名前：デフォルトの名無しさん mailto:sage [2021/10/24(日) 14:56:01.04 ID:lUSERxty.net]: C/C++というよりC familyに似せたと言っていたからちょっとニュアンスは違ってくるか
837 名前：デフォルトの名無しさん mailto:sage [2021/10/24(日) 15:13:22.96 ID:eQqSgpa/.net]: >>819
ソースをくれ
公式で構文を似せたとか言っていないと思うが

C++: references, RAII, smart pointers, move semantics, monomorphization, memory model

https://doc.rust-lang.org/reference/influences.html
838 名前：デフォルトの名無しさん mailto:sage [2021/10/24(日) 15:37:41.12 ID:IF6Ria+p.net]: 型名がintならc++ぽいというのはなんか違うんだよね
->とか<<<とか気持ち悪いことをし始めたらc++感が出てくる
839 名前：デフォルトの名無しさん mailto:sage [2021/10/24(日) 15:38:30.82 ID:lUSERxty.net]: >>821
web.archive.org/web/20150401014855/http://doc.rust-lang.org/nightly/intro.html
> you may find the syntax easier if you've used a "curly brace" programming language before, like C or JavaScript

確かに似せたとまでは言ってなかった

generics の angle bracket についてはコアメンバーが言及してるしC++の影響受けてると言って良いと思う
https://old.reddit.com/r/rust/comments/6l9mpe/minor_rant_i_wish_rust_had_gone_with_square/
840 名前：デフォルトの名無しさん mailto:sage [2021/10/24(日) 15:44:23.48 ID:zP2CpnNP.net]: C++ iostream の << 演算子をパクらなかったのは、やっぱりあれが失敗作だからだよね
841 名前：デフォルトの名無しさん mailto:sage [2021/10/24(日) 15:46:45.70 ID:IF6Ria+p.net]: >>823
thx、ソースまで探してくれてありがとう
個人的にはC++を感じるというエモーション(?)がどこなのかを聞きたかった
842 名前：デフォルトの名無しさん [2021/10/24(日) 16:28:47.34 ID:snvhdKAH.net]: よくある質問
RustはLLVMの上に構築されており、LLVMから見てClangっぽく見えるように頑張っているので、LLVMの
性能が向上したらRustの性能向上にもつながります。
https://prev.rust-lang.org/ja-JP/faq.html
843 名前：デフォルトの名無しさん mailto:sage [2021/10/24(日) 16:53:50.00 ID:RHSebvs6.net]: 見た目はC++に似ているかも知れないけどML系列の方が近いんじゃない？
コンパイラがうるさいところとか「コンパイルが通れば大体動く」という感触はHaskellに近い
Vecに限定したくないなあとか関数に分けると型表記が面倒だなあとかはHaskellには無かったけど
844 名前：デフォルトの名無しさん [2021/10/24(日) 17:08:25.09 ID:6Jy8RsQO.net]: move semanticsとかcall by ref(not call by val in terms of ptr)とかは他のスクリプトではないの多いしな(rakuぐらいじゃね？)
糞みたいに面倒なbig fiveとか書いて来てるc++ちゃんと理解してる連中はrustの基本部分の理解はかなり早そう

記法は全然似てないてかerror handlerの部分とか全くの別物になってるしな
比較的若いgoとかktとかの方が書いててなんとなく似てる様な気もする(´・ω・｀)
845 名前：デフォルトの名無しさん mailto:sage [2021/10/24(日) 17:32:03.31 ID:spG6Bthy.net]: もう長いことC++書いてないけど、考えれば考えるほどC++つらいわ。昔の自分はよく書いてたな
846 名前：デフォルトの名無しさん mailto:sage [2021/10/24(日) 17:59:25.66 ID:tj18qr6S.net]: 本当はMLが好きな人がMozillaでC++書かされるのに疲れた結果生まれた言語なのでMLやC++の要素を併せ持つのは必然
847 名前：デフォルトの名無しさん mailto:sage [2021/10/24(日) 20:02:44.06 ID:WKsYUqIz.net]: >>828
GoやKotlinに似てたらc系列ぐらいの雑さでしょ
848 名前：デフォルトの名無しさん [2021/10/24(日) 21:17:24.37 ID:8hWi5KuQ.net]: ChromeよりMozillaの方が性能良いことが、Rustを使うべきである証明になってるのでは？
849 名前：デフォルトの名無しさん mailto:sage [2021/10/24(日) 22:01:13.83 ID:zrg/m0jp.net]: 流石に乱暴すぎる
850 名前：デフォルトの名無しさん mailto:sage [2021/10/24(日) 22:21:07.85 ID:HVo+cqVA.net]: Chrome も Rust 使おうみたいな話なかったっけ
851 名前：デフォルトの名無しさん mailto:sage [2021/10/24(日) 22:21:39.42 ID:spG6Bthy.net]: セルフホストされるまではOCamlで書かれてたので、Chromeより性能の良いMozillaを作ったRustを最初に実装したOCamlを使うべき証明になってるのでは？
852 名前：デフォルトの名無しさん [2021/10/24(日) 22:28:24.77 ID:P21IrDZK.net]: chromeユーザーだけどfirefoxの方が性能いいってマジなんか？
853 名前：デフォルトの名無しさん mailto:sage [2021/10/24(日) 22:49:18.90 ID:IF6Ria+p.net]: https://amethyst.rs/posts/amethyst--starting-fresh
アメジストが死んだ... ｴﾝﾀﾞｧｧｧｧｧｧｧｧｧｧｧｧｧｲﾔｧｧｧｧｧｧ
rustのゲームエンジンはbevy一強になるのか
854 名前：デフォルトの名無しさん mailto:sage [2021/10/24(日) 23:27:29.19 ID:q0uVfP5C.net]: GUIのツールキットはよ(｀･ω･´ )
855 名前：デフォルトの名無しさん mailto:sage [2021/10/24(日) 23:30:13.19 ID:zP2CpnNP.net]: ちゃんとリリースまでたどり着いたrustのゲームってあるの？
856 名前：デフォルトの名無しさん mailto:sage [2021/10/24(日) 23:47:38.31 ID:IF6Ria+p.net]: >>838
icedじゃだめなん?
>>839
今のところない
試作を含むならネット上に転がっているよ

bevyね...レンダラーがwgpuだからね
現状はレイトレーシングとか無理
ゲームエンジンに挑戦するいい機会かも
857 名前：デフォルトの名無しさん mailto:sage [2021/10/24(日) 23:55:17.08 ID:J36a/Om9.net]: >>824
C++はシフト演算子をなぜ入出力に使いまわそうとしたのか未だに理解できない
見にくく＆わかりにくくなってる
858 名前：デフォルトの名無しさん [2021/10/25(月) 00:09:38.02 ID:dMwiicPm.net]: >>841
shellのリダイレクトに似てると思ったからだろ
859 名前：デフォルトの名無しさん mailto:sage [2021/10/25(月) 00:21:35.96 ID:dRHq7DJG.net]: >>841
当時の C++ には可変長引数を現代的な型システムの枠組みで扱う方法がなかった。
(C++11 からは variadic template がある。これも今となっては現代的と言えるかどうか……。)
新しいオブジェクトを追加したときにオーバーロードが可能である必要など
の諸々の事情が積み重なって演算子オーバーロードの仕組みを使うのが妥当という結論になり、
オーバーロード可能な演算子の中で比較的それらしく見えるのが << だったという経緯。

記法だけなら printf で不満は出なかっただろうけど、
printf (というか C の可変長引数の仕組み) は型システム的な保護が全然できないぶっ壊れなので
それを是とすることも出来なかった。 (廃止もしなかったけど。)

良くはないが他にどうにも出来なかったんだよ。
860 名前：デフォルトの名無しさん mailto:sage [2021/10/25(月) 00:30:55.79 ID:dRHq7DJG.net]: 歴史が長くなるとしょうもない事情の積み重ねでグダグダになるのもよくあること。
Rust もいずれはそうなる。そしてそのときは新しい何かで置き換えられるんだよ。

でも Rust の場合は Edition という区切りで新しい Rust 自身で置き換えつつ
過去の Rust とも共存することを最初から意図したデザインにしているので
比較的長く維持されるんじゃないかな。
861 名前：デフォルトの名無しさん mailto:sage [2021/10/25(月) 10:06:46.78 ID:vPVmdF1Z.net]: 実際、型安全であるiostreamよりprintfのがよっぽどマシって議論はある。
しょーもない技術要素よりも視認性のがよっぽど大事だったりするわけで。
862 名前：デフォルトの名無しさん mailto:sage [2021/10/25(月) 11:11:20.41 ID:DCgj0YIV.net]: >>840
iced日本語入力できなくない？
863 名前：デフォルトの名無しさん [2021/10/25(月) 11:14:28.05 ID:vmRZrQEp.net]: >>827
>「コンパイルが通れば大体動く」という感触はHaskellに近い
C/C++でも「コンパイルが通れば大体動く」けど
Haskellはコンパイル時にアルゴリズムミスまでチェックしてくれるのか？
864 名前：デフォルトの名無しさん [2021/10/25(月) 11:32:11.39 ID:dMwiicPm.net]: 単にHaskellはC/C++よりも型安全性の度合いが強いってこと言いたいんだろ
865 名前：デフォルトの名無しさん mailto:sage [2021/10/25(月) 11:51:09.02 ID:fl6GjyRy.net]: >>846
Font読み込めば出来るっぽいよ
866 名前：デフォルトの名無しさん [2021/10/25(月) 12:13:25.40 ID:Zg5tRANc.net]: >>847
アスペルガーか？
867 名前：デフォルトの名無しさん mailto:sage [2021/10/25(月) 15:20:38.75 ID:YZjFvrvy.net]: Rustでゲームエンジン作ったら億万長者になれるのかな
868 名前：デフォルトの名無しさん mailto:sage [2021/10/25(月) 17:18:01.27 ID:uPCS+ug6.net]: UnityやUnreal Engine並のを作れるならできるんじゃね
さもなきゃプロプライエタリなエンジンなんてきょうび流行らん
869 名前：デフォルトの名無しさん mailto:sage [2021/10/25(月) 17:29:16.50 ID:SuqdiOg2.net]: Rustの方が圧倒的に高速なら儲かるんじゃね？
知らんけど
870 名前：デフォルトの名無しさん mailto:sage [2021/10/25(月) 17:42:54.30 ID:dQPM/Zr0.net]: C++に勝てると思ってるの？
871 名前：デフォルトの名無しさん mailto:sage [2021/10/25(月) 18:33:26.15 ID:WHGdQ2cY.net]: フラッピーバードでも億稼げるんだからいけるいける
872 名前：デフォルトの名無しさん mailto:sage [2021/10/25(月) 18:38:23.54 ID:SAo0WBxS.net]: もうインディー2Dゲームぐらいはリリースされてるのかと思ったけど
まだなのか
873 名前：デフォルトの名無しさん mailto:sage [2021/10/25(月) 19:12:07.52 ID:rY5vWaGm.net]: >>851
億万の金とリソースをかけなきゃ使い物になるエンジンなんて作れないんじゃないの？

まあ、そこまでいかなくともユーザーのいる既存のツールで開発止まっているもの（MMDとか）のクローン作ればワンチャンあるかもね。
874 名前：デフォルトの名無しさん mailto:sage [2021/10/25(月) 20:03:31.88 ID:cubP7NbG.net]: ゲームエンジンでボトルネックとなるような重い処理ってなんなの
描画関連が重いならGPU側処理がメインでCPUで動くプログラムは何で書いても良いのでは
875 名前：デフォルトの名無しさん [2021/10/25(月) 20:21:36.23 ID:tU+lYK+H.net]: 行列計算とメモリー帯域、PS5とPCを比べれば一目瞭然。PC4-25600でさえメモリー帯域が25GB/sで
デュアルチャネルで50GB/s、PS5は帯域幅218GB/s、
つまり描画が重いのではなく、CPUやGPUで行列計算した結果をメモリーへ格納したり再び取り出したりが重い。
描画だけなら4K再生できるVRAMの速度だけで終わる話
876 名前：デフォルトの名無しさん mailto:sage [2021/10/25(月) 20:24:03.79 ID:RLuxZR0I.net]: >>851
儲かるかは知らんがbevy engineの作者はお賽銭で40万/月貰っているぞ
877 名前：デフォルトの名無しさん mailto:sage [2021/10/25(月) 22:52:02.92 ID:JVD00Zwu.net]: ゲーム1本も出てないってそれなんかデカイ問題あるんじゃないの。
使ってみたら、あれこれ全然意味ないわ的な。
878 名前：デフォルトの名無しさん mailto:sage [2021/10/25(月) 23:04:10.31 ID:WHGdQ2cY.net]: そらまあUnityとかみたいなガチゲームエンジンとかと比べたら意味ないんじゃね
879 名前：デフォルトの名無しさん mailto:sage [2021/10/26(火) 00:13:42.72 ID:T+NfAItu.net]: ゲームとか組み込みと並んで過去の資産が積み上がっているところだろう
現状グラフィックAPIなどのバックエンドは全部C/C++だぞ
一朝一夕の話ではないが、取り組み続ける必要がある
とりあえずコールオブデューティのTreyarchは触っているぽい
880 名前：デフォルトの名無しさん mailto:sage [2021/10/26(火) 00:19:35.84 ID:T+NfAItu.net]: インディ→ue4かunity
大手→ゲームの開発スパン3-4年+ゲームエンジン開発期間

今から積極的取り組んでも公表できる成果ができるは8-10年じゃない
そういえば任天堂もrust人材を募集してたよ
881 名前：デフォルトの名無しさん mailto:sage [2021/10/26(火) 09:14:11.61 ID:1uavI5d4.net]: カスタムアロケータ回りがしょぼいからガチのゲームエンジン用としては現状まだきついのでは
882 名前：デフォルトの名無しさん mailto:sage [2021/10/26(火) 09:43:34.49 ID:AMOvMfiW.net]: たしかにコンシューマゲーム会社なんかがRust採用を進めていく、ってのはなんかありそうだね
プロダクトのプロトタイプ作成とかめっちゃあると思うんだけど、そういうのとかで、どんどん試してみて欲しい
彼らがRustコミュニティに貢献してくれるのか、っていうとなんか怪しい気はするけど
883 名前：デフォルトの名無しさん mailto:sage [2021/10/26(火) 11:03:35.61 ID:ftLfN9xo.net]: 最近はマイコンもセキュリティ機能が重要視されているけど
処理系は相変わらずC/C++でRustを推進みたいな流れにはなっていない矛盾
884 名前：デフォルトの名無しさん mailto:sage [2021/10/26(火) 11:18:59.50 ID:BJDScnmh.net]: そもそも組み込みで使えるrustコンパイラがないからな
885 名前：デフォルトの名無しさん mailto:sage [2021/10/26(火) 12:47:26.53 ID:hwHjfkE+.net]: 限定的ながらCortex-M用のバックエンドがあるじゃん
886 名前：デフォルトの名無しさん mailto:sage [2021/10/26(火) 13:14:38.26 ID:I5hwU/3x.net]: 俺のH8はどうなるんや
887 名前：デフォルトの名無しさん mailto:sage [2021/10/26(火) 14:24:23.79 ID:ZxZWHA9I.net]: LLVMバックエンドがあるならなんとかできるのでは
ないなら知らん
888 名前：デフォルトの名無しさん mailto:sage [2021/10/26(火) 15:31:08.95 ID:bUwN0t0N.net]: >>870
RL78に乗り換えてどうぞ。LLVMバックエンドもあるよ
889 名前：デフォルトの名無しさん mailto:sage [2021/10/26(火) 15:43:31.64 ID:BNqSw8pO.net]: 僕はRX-78-2からRX-78NT-1に乗り換えたよ
みんなもそうしなよ
890 名前：デフォルトの名無しさん mailto:sage [2021/10/26(火) 15:50:06.56 ID:BJDScnmh.net]: 嘘だと言ってよバーニィ
891 名前：デフォルトの名無しさん mailto:sage [2021/10/26(火) 15:54:33.07 ID:BJDScnmh.net]: 真面目な話Green Hillsが対応したら組み込みでも大分状況変わると思うんだが
なんか内部では研究してるみたいだし
892 名前：デフォルトの名無しさん mailto:sage [2021/10/26(火) 16:50:59.50 ID:BwJyZYHo.net]: ルネサスは近年arm32bitとしてraファミリ出してる。h8とかsuperhな人は今すぐ乗り換えろ
893 名前：デフォルトの名無しさん mailto:sage [2021/10/26(火) 17:52:31.12 ID:9Njhbr90.net]: バックエンドがある組み込み向けISAはCortex-M系、RISC-V系、RL78、AVR8あたり？

>>876
RAで済むなら他社のCortex-M系マイコンでも良いんじゃね感が・・・
894 名前：デフォルトの名無しさん mailto:sage [2021/10/26(火) 20:33:41.25 ID:T+NfAItu.net]: >>865
基本カスタムアロケータは自作では?
895 名前：デフォルトの名無しさん mailto:sage [2021/10/26(火) 21:43:49.66 ID:BJDScnmh.net]: アロケータ自作は大げさじゃないか
heaplessクレートでどうにかなるんじゃないかな
オレは使ったことないけど
896 名前：デフォルトの名無しさん mailto:sage [2021/10/26(火) 21:51:14.59 ID:PDIGoDZx.net]: Unityでいけるくらいならデフォルトのアロケータで十分では？
jemallocとかに切り替えてもいいけど、どちらにしても自作するほどかね
897 名前：デフォルトの名無しさん [2021/10/26(火) 21:59:07.68 ID:zVG+0sad.net]: うんこ
898 名前：デフォルトの名無しさん [2021/10/26(火) 22:58:46.15 ID:Fg4TonRG.net]: Unity使うなら内部のGCはBoehm GCなんだからGC_MALLOC使ったほうが良いのでは？
オレはRc<T>使いながらBoehmが使えるのか知らんけど
899 名前：デフォルトの名無しさん mailto:sage [2021/10/27(水) 00:00:42.78 ID:6YxZEOiV.net]: 別にゲームにカスタムアロケータが必須なんてことはないと思うが
UnityみたいにGCありの言語で書く場合にGCのスパイクが許容できないから
独自のメモリプールとかを書かざるを得ないのでは
それともC++でもアロケータ自作してるのか？
900 名前：デフォルトの名無しさん mailto:sage [2021/10/27(水) 00:23:45.53 ID:c5Twcn5s.net]: UnityってBoehm GCなんだ？
それで十分動くんならRustにもGCあってもよかったんじゃない？
901 名前：デフォルトの名無しさん mailto:sage [2021/10/27(水) 00:29:03.79 ID:QIbcJ+ZF.net]: ならGo使えば良くない？
902 名前：デフォルトの名無しさん [2021/10/27(水) 00:46:21.16 ID:l1Jw+QgM.net]: goはboehmじゃなく2017年ごろまでtcmallocで今は派生（随分、中身が違う）してるはず
903 名前：デフォルトの名無しさん mailto:sage [2021/10/27(水) 07:18:35.73 ID:4kTRaQF8.net]: Boehmてストップザ・ワールドは起こらんの？
904 名前：デフォルトの名無しさん [2021/10/27(水) 08:48:37.83 ID:NxiqMK2Z.net]: Boehmってカタカナ的には何て読むの？
905 名前：デフォルトの名無しさん mailto:sage [2021/10/27(水) 09:08:54.86 ID:CWN4UblG.net]: ボエヒムじゃないの？
906 名前：デフォルトの名無しさん mailto:sage [2021/10/27(水) 10:46:43.20 ID:OgmKOgHT.net]: ベームかボームだろ、ボエヒムとかワロタw
907 名前：デフォルトの名無しさん mailto:sage [2021/10/27(水) 11:14:08.33 ID:7BguKBbd.net]: ドラクエの呪文みたいだな
908 名前：デフォルトの名無しさん [2021/10/27(水) 11:35:17.90 ID:Ru0zcXw7.net]: ドイツ語のoeは日本語ではエって転写される
909 名前：デフォルトの名無しさん mailto:sage [2021/10/27(水) 12:01:22.63 ID:dNMmh9m9.net]: Phoenix
910 名前：デフォルトの名無しさん mailto:sage [2021/10/27(水) 12:11:52.89 ID:AHUxp5wd.net]: 412 名前：以下、名無しにかわりましてVIPがお送りします投稿日： 2013/01/19(土) 21:03:25.42 ID:a2pD/tlo0

FランのFはフェニックスのFや！
例えこんなところで落ちぶれても不死鳥のごとく上流階級に返り咲くんや！！

414 名前：以下、名無しにかわりましてVIPがお送りします投稿日： 2013/01/19(土) 21:04:02.87 ID:dT9mn0sK0

>>412
フェニックスは「phoenix」
911 名前：デフォルトの名無しさん [2021/10/27(水) 14:01:22.92 ID:t2iD5tO8.net]: cafe la boheme
912 名前：デフォルトの名無しさん [2021/10/28(木) 12:12:05.45 ID:hM84Yf/1.net]: >>887
スレチだが、Boehmなので本来はSTWだけなのでUnityにGCラグが発生していたことは有名ですが、2018/12頃に
インクリメンタルGCが出来て改善された。
https://blog.unity.com/technology/feature-preview-incremental-garbage-collection
またUnityでゲームなどを作るときに良くやるのがGCを動かさないこと（＝オブジェクトを破棄しない）で
オブジェクトプールを使用して1度作ったオブジェクトをプールして置き破棄させない方法など、Unityにある
文字列比較などを使用しないなど細かい事をやる。本末転倒といえばその通り
913 名前：デフォルトの名無しさん mailto:sage [2021/10/29(金) 02:30:41.55 ID:dwfT6x3M.net]: 典型的なバッドノウハウだな
とはいえ日本でUnityが一番つかわれているであろう現場のモバイルゲーム開発は
昔はケータイJavaのゲーム開発やってた場合が多いのでその辺のGCバッドノウハウに慣れちゃってるという
Boehmはボエーンて読んでるわ
914 名前：デフォルトの名無しさん mailto:sage [2021/10/29(金) 02:58:27.64 ID:j8WlttkF.net]: oe はドイツ語の o の代替綴りとしてあてられることが多い。
つまり boehm の本来の綴りは bohm ってことね。
o はオの口の音でエという感じなので音としては中途半端で、カタカナに当てはめにくい。

ドイツ語の発音通りをあえてカタカナにするならボェーンに聞こえるんだけど、
bohm という人名は通例ではベームと表記してるね。
915 名前：デフォルトの名無しさん mailto:sage [2021/10/29(金) 02:58:48.47 ID:j8WlttkF.net]: あれ？ 2ch に投稿したらウムラウトが消えてる……。
916 名前：デフォルトの名無しさん mailto:sage [2021/10/29(金) 03:36:42.46 ID:Ws4Kkx5X.net]: appleをアップルと記載するような文化やからね。カタカナにしてしまったら本来の発音との差異なんて気にしたらキリがない
917 名前：デフォルトの名無しさん mailto:sage [2021/10/29(金) 04:15:21.99 ID:feAEAXNj.net]: 名女優のオードリー・ヘップバーンと
ローマ字表記のヘボン式で有名なヘボン氏が実は同じ綴り同じ発音の同じ姓みたいなもんか
918 名前：デフォルトの名無しさん [2021/10/29(金) 05:16:40.74 ID:eAaOJvH1.net]: ドイチュ語と描いてない >>898 は失格
919 名前：デフォルトの名無しさん mailto:sage [2021/10/29(金) 21:33:27.38 ID://DLIqvB.net]: まじかあ、これが可能だったのかあ

let v = vec![1, 2, 3];
println!("{}", v[if true { 1 } else { 2 }]);
920 名前：デフォルトの名無しさん mailto:sage [2021/10/29(金) 23:53:13.86 ID:3N24c0Lq.net]: >>901

ヘボンさんは自分でも気に入って「平文」なんてハンコ
持ってたくらいだから定着しちゃったんだよなｗ
921 名前：デフォルトの名無しさん mailto:sage [2021/10/30(土) 00:22:25.21 ID:9U1YWI6I.net]: 音韻と音声は異なる。ある言語で同じ音だと認められる音が音韻で、
たとえば日本語だとシンブンシという言葉に表れる二個のンは実際には違う音
なのに同じ音として処理している。
(だからヘボン式ローマ字では書き分けるルールになっている。)

音韻として同じでも音声として幅はあり、そして音韻は言語に依存するもんだから、
外国語の音を転写してくるとどう頑張ったって辻褄の合わない部分は出てくる。
922 名前：デフォルトの名無しさん mailto:sage [2021/10/30(土) 01:29:07.34 ID:fDTZDMBU.net]: >>901
唐鳳は上手いよな
923 名前：デフォルトの名無しさん mailto:sage [2021/10/30(土) 02:41:12.91 ID:z8LGC696.net]: いつの間にか[T; N]にIntoIteratorがimplされてるな
しかも興味深いことにVec等と異なり消費されないようだ
借用ルール的にはどういう扱い？
924 名前：デフォルトの名無しさん mailto:sage [2021/10/30(土) 08:30:57.45 ID:zPV0av3I.net]: イテレータが理解できないやつ定期的に湧くな
925 名前：デフォルトの名無しさん [2021/10/30(土) 09:56:39.69 ID:gRDEN/XN.net]: 常駐
926 名前：デフォルトの名無しさん mailto:sage [2021/10/30(土) 11:34:48.67 ID:cxTfS1zf.net]: >>902
ドイちェン
927 名前：デフォルトの名無しさん mailto:sage [2021/10/30(土) 20:52:05.52 ID:/cDwb9ic.net]: >>907
Rust 1.53.0で配列にIntoIteratorが実装された
あと識別子に日本語も使えるようになった
配列は要素がCopyを実装しているかどうかで所有権の扱いが変わる

#[derive(Debug,Clone,Copy)]
struct 構造体 {
　値: isize,
}
fn main() {
　let 配列 = [構造体{値:1}, 構造体{値:2}, 構造体{値:3}];
　for 変数 in 配列 {
　　println!("{:?}", 変数);
　}
　println!("{:?}", 配列[0]);
}

例えばこれはコンパイルが通って動くけど
構造体のderiveのCopyを外すと
配列の所有権はfor in内部のinto_iter()で移動してしまいコンパイルが通らなくなる
928 名前：デフォルトの名無しさん [2021/10/30(土) 21:00:13.45 ID:zJlZfWf6.net]: >>911
ぶっちゃけ日本語の識別子わかりやすいって思ってしまった
929 名前：デフォルトの名無しさん mailto:sage [2021/10/30(土) 22:32:29.50 ID:EbhCJ5wH.net]: 日本語識別子わかりやすいんだけど入力に手間がかかるのがつらい
930 名前：デフォルトの名無しさん mailto:sage [2021/10/30(土) 23:29:17.10 ID:s2ubgEFJ.net]: let v0 = vec![1, 2, 3];
let mut v1 = v0;
v1.push(120);

let mut v0 = vec![1, 2, 3];
let v1 = &mut v0;
v1.push(120);

所有権関連で試してみてるんだけど、この二つの違いってなんなん？
いまいちよくわからん
上のはmutでないvecをlet mutの変数に入れるとpushできてまうし
下のはlet mutでない変数なのに&mutでいれるとpushできてまう
931 名前：デフォルトの名無しさん mailto:sage [2021/10/30(土) 23:56:55.99 ID:cJtJXOgj.net]: https://doc.rust-lang.org/rust-by-example/scope/move/mut.html
932 名前：デフォルトの名無しさん mailto:sage [2021/10/31(日) 00:40:09.42 ID:ndmOeSWD.net]: >>914
それぞれpushした後にv0とv1がどうなってるか確認してみるとわかる
933 名前：デフォルトの名無しさん [2021/10/31(日) 01:41:05.72 ID:e5ZzvOAs.net]: うんこ荒らすな！
934 名前：デフォルトの名無しさん [2021/10/31(日) 02:16:55.91 ID:HeT/GYnp.net]: すまんがVSCode + Rust-Analyzerで勉強中なんだけどさ
数ヶ月前は変数の型が表示されていたのに、今じゃ全然表示されなくなっちゃったんだけど・・・・どうすればいいんだぜ？
935 名前：デフォルトの名無しさん mailto:sage [2021/10/31(日) 03:00:17.77 ID:9uKpC+QX.net]: int * constみたいなもん

参照先のアドレスは変更不可だけどそのアドレスが指してるvectorは&mutだから変更可能
936 名前：デフォルトの名無しさん mailto:sage [2021/10/31(日) 03:02:55.52 ID:nF8ypkXG.net]: >>914
他の言語での余計な知識を捨て去ってゼロから考えるとわかりやすかったよ
今回の件で関係するルールは単純でこれだけかな？

【所有権】
・所有権を持てるのは一人だけ
・使う(＝代入や関数引数も含まれる)と所有権は移動する
・ただしCopyトレイト実装型は使う時にCopyされるので所有権は移動しない

【所有権を持つ可変と非可変】
・その変数の中身を書き換える予定があるなら変数を可変(mut)に宣言しておく
・他の変数に代入しなおせば可変か非可変か変更可能(つまりその変数を使う時の制限ヒント)

【参照(＝貸出＝借用)】
・所有権が移動されたくなければ参照で貸し出す
・可変参照(&mut)の貸し出しは1人のみに参照独占で元も可変変数であること
・非可変参照(&)の貸し出しは同時に何人でも可能
・まとめるとsingle writer or multi readers

所有権を明確にするのはメモリ自動解放のため
可変を明確にするのは並行(concurrent)/並列(parallel)での競合回避のため
937 名前：デフォルトの名無しさん [2021/10/31(日) 07:46:34.10 ID:dD8mFzoB.net]: >>918

inlayHints
938 名前：デフォルトの名無しさん mailto:sage [2021/10/31(日) 09:44:05.10 ID:726CqcoT.net]: 所有権を伸ばして発音すると昇龍拳みたいに聞こえる
出掛かりが無敵なところも似てる
939 名前：デフォルトの名無しさん mailto:sage [2021/10/31(日) 09:51:39.37 ID:5rE8GYET.net]: ヒカヘンサンショウ
940 名前：デフォルトの名無しさん [2021/10/31(日) 13:37:02.02 ID:r7nTmIjE.net]: 丁寧で優しい920を弄りたくないけど、これを読める人は914のような質問はしないね
941 名前：デフォルトの名無しさん mailto:sage [2021/10/31(日) 13:58:11.88 ID:yTUS2Zye.net]: 以下の関数をジェネリックにする方法ありますか？
fn is_one_two_three<A: AsRef<[isize]>>(a: A) {
　assert_eq!(&[1, 2, 3], a.as_ref());
}
fn main() {
　let a = [1, 2, 3];
　is_one_two_three(a);
　let a = vec![1, 2, 3];
　is_one_two_three(a);
}
配列もVecも受け取る関数でこれはコンパイルも通り動いているのですが
isizeと型が決め打ちのところをジェネリックにTとしたいです
どうするとよいでしょうか？
942 名前：デフォルトの名無しさん mailto:sage [2021/10/31(日) 14:34:45.61 ID:ZiqPaZpd.net]: >>925
数値型を一般化する trait を使うのが普通かな。
自分で定義しても良いが num_traits::FromPrimitive を使うならこんな感じ
https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=1fbd536dd6c9ea76beb20a666b085190
943 名前：デフォルトの名無しさん mailto:sage [2021/10/31(日) 16:04:00.70 ID:2p54m3kz.net]: >>914
気持ちの上では他の言語と対応付けるのではなく Rust のルールで理解すべきという点で >>920 に
同意ではあるんだが、そうは言っても知っていると引っ張られるのも仕方のない話で、
入門初期では多少はしょうがないとも思う。

あえて C++ で同等のものに置き換えるとするとこんな感じかな。

#include <vector>

int main(void) {
{
const std::vector<int> v0 = {1, 2, 3};
std::vector<int> v1 = v0;
v1.push_back(120);
}
{
std::vector<int> v0 = {1, 2, 3};
std::vector<int>* const v1 = &v0;
v1->push_back(120);
}
}

この場合は所有権の概念はあまり関係なくて
メソッド呼出しの演算子が参照を自動で調整してしまうのも混乱の原因になってる気がする。
mut が何にかかっているのか見えにくい。
944 名前：デフォルトの名無しさん mailto:sage [2021/10/31(日) 16:25:11.82 ID:KIvWC7vb.net]: >>927
少なくとも上は全く同等じゃない
C++では表現出来ない
945 名前：デフォルトの名無しさん mailto:sage [2021/10/31(日) 16:52:46.17 ID:2p54m3kz.net]: >>928
ムーブの仕組みが違うのはしょうがない。
この場合は const 性の話だと思ったから……
946 名前：デフォルトの名無しさん mailto:sage [2021/10/31(日) 17:14:21.91 ID:WrAvX4Kw.net]: C++で考えるのは弊害しかないじゃん
何がしょうがないだよ
947 名前：デフォルトの名無しさん mailto:sage [2021/10/31(日) 17:47:23.34 ID:dE1SXutD.net]: 弊害しかないは言いすぎ
この場合mutをどこに付けると何が可変になるかの話だから
C++でconstをどこに付けると何が不変になるのかを例に出すのは自然なたとえだと思いますよ
948 名前：デフォルトの名無しさん mailto:sage [2021/10/31(日) 21:58:15.04 ID:4rIS02S1.net]: let mut vec0 = vec![vec![0, 2, 3]; 3];

for mut i in vec0.iter_mut() {
　i.push(9);
}

for mut i in &mut vec0 {
　i.push(9);
}

この二つのループの意味は同じ？
こういう二つの書き方があるのでちょっとわかりにくい気がする
949 名前：デフォルトの名無しさん mailto:sage [2021/10/31(日) 22:14:30.87 ID:4rIS02S1.net]: へー、これが通るんだ
ちょっと笑った

let vec0 = vec![0, 2, 3];
let mut vec0 = vec0;
vec0.push(99);
950 名前：デフォルトの名無しさん [2021/10/31(日) 22:21:16.21 ID:xmsO/hLH.net]: >>933
シャドーイングだから当たり前でしょ
951 名前：デフォルトの名無しさん mailto:sage [2021/10/31(日) 22:22:32.67 ID:fTPwCWVK.net]: シャドーイングOKな言語でもlintが禁止してきてイラっとする
952 名前：デフォルトの名無しさん mailto:sage [2021/10/31(日) 22:31:01.48 ID:4rIS02S1.net]: >>934
状態まで置き換え可能なのはおかしいような気がする
せっかく不変変数にしてるのに事実上代入可能にしてることに何の意味があるんだろう
953 名前：デフォルトの名無しさん mailto:sage [2021/10/31(日) 22:44:51.38 ID:2W4wB6er.net]: クソみたいな名前が増えないようにだよ
954 名前：デフォルトの名無しさん mailto:sage [2021/10/31(日) 22:57:25.82 ID:Ou5/KoYl.net]: >>924
「関係するルールは単純でこれだけ」と言って関係ないものも含めて8個もルールを羅列するやつが丁寧で優しいわけがないよ
955 名前：デフォルトの名無しさん mailto:sage [2021/10/31(日) 23:04:28.74 ID:4rIS02S1.net]: >>937
変数名の再利用と状態変更はちがくね？
そもそも変更しないと宣言して変数をシャドーイングして変更可能にするのも疑問だけど、
まあそれは仕様だとして、それが変数名の再利用とは無関係じゃんね　再利用しない前提なんだから
956 名前：デフォルトの名無しさん mailto:sage [2021/10/31(日) 23:09:50.30 ID:59hJVDPo.net]: もはや何言ってるかわからないレベル
957 名前：デフォルトの名無しさん [2021/11/01(月) 00:28:06.90 ID:lB3Z2euD.net]: >>936
状態置き換えてない
新しい方の変数を参照するようにしているだけ
958 名前：デフォルトの名無しさん mailto:sage [2021/11/01(月) 00:30:02.23 ID:cNNz1tH7.net]: >>932
mut i ってmut必要だっけ
959 名前：デフォルトの名無しさん mailto:sage [2021/11/01(月) 01:16:30.92 ID:FrHt6Y1+.net]: >>932
> for mut i in vec0.iter_mut() {
> for mut i in &mut vec0 {

どちらもiは&mutになるので同じfor文になる
そしてlet mut i = &mut ... と書いている時と同じく左側のmutは不要(warning)
960 名前：デフォルトの名無しさん mailto:sage [2021/11/01(月) 01:31:09.18 ID:FrHt6Y1+.net]: >>925
配列もVecも受け取る関数ならば
as_ref()でスライスに揃える方法だけでなく
961 名前：r> 配列もVecもそのままの型で使う方法もあり どちらもa[i]の形はIndexトレイトで使えるので例えば fn get_second_item<A: std::ops::Index<usize, Output=T>, T: Copy>(a: A) -> T { a[1] } fn main() { let a = [1.1, 2.2, 3.3]; assert_eq!(2.2, get_second_item(a)); let a = vec!["a", "b", "c"]; assert_eq!("b", get_second_item(a)); } と配列/Vec側も中身のf64/&str側もジェネリックに書ける []: [ここ壊れてます]
962 名前：デフォルトの名無しさん mailto:sage [2021/11/01(月) 08:15:24.70 ID:Qg2QcgLf.net]: 背後にある考え方を説明せずにルールだけ教えても理解できないよ。

まあ、ルールに一貫したコンセプトがないんだったら「こういうものだ」と押し付けるしかないけど。
963 名前：デフォルトの名無しさん mailto:sage [2021/11/01(月) 23:13:41.76 ID:PK ]: [ここ壊れてます]
964 名前：aNA1In.net mailto: 可変の場合は面倒でもmutが必要ってしたほうがわかりやすいような気がするなあ []: [ここ壊れてます]
965 名前：デフォルトの名無しさん mailto:sage [2021/11/01(月) 23:57:09.03 ID:HKf+kmzN.net]: let mut p = &mut q;　の左辺mutを書くとwarningが出る理由は、pはmutではなく、あくまでも&mutであるためだろう。
つまり、そこに左辺mutを書いてしまう人はきちんと理解していないという意味ではなかろうか。
966 名前：デフォルトの名無しさん mailto:sage [2021/11/02(火) 07:53:30.47 ID:eth2zNwx.net]: let mut ~~はそこで定義される変数が可変（再代入可能）になるもので、
&mut ~~はそこで作成される参照が可変になる、という理解なんだけど、
どうもしっくり来てない。引数の宣言で&mutとつけるとどうなるの、とかすぐ出てこない。
967 名前：デフォルトの名無しさん mailto:sage [2021/11/02(火) 08:18:58.33 ID:gnq/E+lb.net]: let mutのmutはコード生成には不要だけど&mutのmutは必要だと言う話を聞いた
968 名前：デフォルトの名無しさん [2021/11/02(火) 09:44:55.98 ID:px0qcy1y.net]: 950
969 名前：デフォルトの名無しさん mailto:sage [2021/11/02(火) 11:55:17.95 ID:22+2FiF4.net]: let mutのmutはbindingがmutableかどうか
&mutは型が&mut Tなのかどうか

Cのconst pointerとpointer to constと同じ
Rustはデフォルトimmutableなのでmutableにしたい場合にのみmutで修飾

普通使わないけどパターンマッチと組み合わせると
let &mut mut x = &mut y;
みたいな書き方もありうる
970 名前：デフォルトの名無しさん [2021/11/03(水) 12:07:17.82 ID:gDAMFAnt.net]: mutが必要ってより、for mutにfor let mutにならないことが不思議
971 名前：デフォルトの名無しさん mailto:sage [2021/11/03(水) 17:34:54.99 ID:eoGGfQG1.net]: それは単にforの文法がlet不要なように設計されたってだけでは
972 名前：デフォルトの名無しさん mailto:sage [2021/11/03(水) 18:34:42.48 ID:+koatzK+.net]: let パターン = ...
for パターン in iter
match パターン ...
fn hoge(パターン: TypeName, ...)
ってことやぞ
973 名前：デフォルトの名無しさん [2021/11/03(水) 19:26:40.94 ID:6uw3PT+q.net]: Rustにはif let Some(3) = v {}とか、 while let Some(i) = a {}とかあり。letは不変のキーワードじゃなく
右辺に対するパターンマッチ展開で、for letがないのは、forはfor..inしかなく、Cのようなfor ;条件;の文が
存在しないためという考えらしいです。。。
974 名前：デフォルトの名無しさん mailto:sage [2021/11/04(木) 06:57:56.88 ID:9Ddr56R/.net]: forで変数の初期化が要るみたいな発想になる時点でC由来の処理系に洗脳されているんじゃぁ・・・
975 名前：デフォルトの名無しさん mailto:sage [2021/11/04(木) 13:00:03.95 ID:UnTZr4yd.net]: for p in v { … }　は
v.into_iter().for_each(|p| …)　と同じ機能たけど
長いメソッドチェーンな時など敢えてforでなくfor_each使ったりも
976 名前：デフォルトの名無しさん mailto:sage [2021/11/04(木) 20:16:49.18 ID:UnTZr4yd.net]: ただしfor文は値を返せないのが弱点かな
イテレータならfor_eachの代わりにfoldしたりfindしたりあるいはmapやfilterなど色々処理して最後にcollectしたりと値を返せる
977 名前：デフォルトの名無しさん mailto:sage [2021/11/04(木) 20:24:42.58 ID:faLe9vBn.net]: >>958
forやwhileは、そもそもループが実行されないパターンがあるので、それは無理ってなったらしい
だからloopでは値を返すことができるので、loopを使うぺし
978 名前：デフォルトの名無しさん mailto:sage [2021/11/04(木) 21:17:21.49 ID:MjRPJM3Z.net]: >>959
for式やwhile式がOptionを返してループ0回ならNoneで済む話ではないのでしょうか？
979 名前：デフォルトの名無しさん mailto:sage [2021/11/04(木) 21:26:55.06 ID:sNasn9tC.net]: forで値を返したいとか言ってるやつまだいたのかw
980 名前：デフォルトの名無しさん mailto:sage [2021/11/04(木) 23:50:24.53 ID:faLe9vBn.net]: >>960
ループ内は実行されないからNoneも返せないってことよ
loopは明示的に自分でbreakするから許容

let test: = if true { 1 };
たとえば、これでtestにNoneが入るとかおかしいことになるってわかるっしょ？
それと同じこと。
981 名前：デフォルトの名無しさん mailto:sage [2021/11/04(木) 23:51:56.14 ID:Cqbrs2k1.net]: 実際問題としてHITUYOU
982 名前：デフォルトの名無しさん mailto:sage [2021/11/04(木) 23:52:15.61 ID:Cqbrs2k1.net]: ごめん誤爆した。

実際問題として必要な場面がないだろ。
983 名前：デフォルトの名無しさん [2021/11/05(金) 08:00:41.30 ID:Q0weZe1J.net]: forの話なら、これって今はどっちで書くのが一般的？ルールとして基本はHOFで書くのを
やっぱり強制したいのだけど
https://doc.rust-lang.org/stable/rust-by-example/fn/hof.html
984 名前：デフォルトの名無しさん mailto:sage [2021/11/05(金) 13:18:20.54 ID:/SSooQm2.net]: rust現場で使ってる人は何系のシステム作ってるん？
985 名前：デフォルトの名無しさん mailto:sage [2021/11/05(金) 14:22:06.73 ID:pAK9gvBl.net]: 現場で使ってる人なんていません
986 名前：デフォルトの名無しさん mailto:sage [2021/11/05(金) 14:42:52.35 ID:Z0sGs5cT.net]: 求人検索をしてみても、Rust使ってるとこなんて指で数えられるぐらいしかなさそうかな
987 名前：デフォルトの名無しさん mailto:sage [2021/11/05(金) 15:22:01.85 ID:4VZvWnUi.net]: とりあえずいつもの貼っておく
https://www.rust-lang.org/production
988 名前：デフォルトの名無しさん mailto:sage [2021/11/05(金) 15:29:07.01 ID:ShfctMVX.net]: 試験的にGoからRustに切り替え中だよ。両方ともバックエンドとフロントエンドまでやってるのでそのまま移植出来て簡単…じゃなかった
インフラはサクッと終わったけど、フロントは素のWasmで実装するもGoより遥かに複雑で難解なRustでやる意味は？的な事になって
vDOM系フレームワークで実装するも、Non-vDOM系のが殆どの場面で速い事が分かったのでやり直し中

で、本番環境で運用できるのか？となると最初の印象に反して｢出来る｣と思うね。
動かし始めて不具合が出た時に、何処がヤバいのか分からない怖さがない。
過去の資産と経験則は捨ててRustのお作法に従うようにするのが大切、下手にアレを使いたいので使い回すとかやると余計苦労する。
989 名前：デフォルトの名無しさん mailto:sage [2021/11/05(金) 19:10:07.53 ID:0gW7V402.net]: >>970
もしよろしければオススメのRustフレームワークを教えてください
990 名前：デフォルトの名無しさん mailto:sage [2021/11/05(金) 20:26:36.98 ID:RvCa6Qvn.net]: ちんちんぶらぶらRustすぱーと
991 名前：デフォルトの名無しさん [2021/11/05(金) 20:33:04.86 ID:JniLXeAQ.net]: うちではバイトの女子大生も使ってるが
Rustを使うような企業はネット求人になんか頼らんだろうね、今のところ
992 名前：デフォルトの名無しさん mailto:sage [2021/11/05(金) 21:52:24.97 ID:ShfctMVX.net]: >>971
Dominator
993 名前：デフォルトの名無しさん mailto:sage [2021/11/05(金) 23:26:41.71 ID:DvmJ6O3T.net]: Dominatorってこれか
https://github.com/Pauan/rust-dominator
virtual DOM使わずゼロコストでリアクティブか

ベンチマーク見るとVue/React/Angularなどは非常に遅いんだな
https://rawgit.com/krausest/js-framework-benchmark/master/webdriver-ts-results/table.html
Vanilla JSで頑張るのでなければRustでDominatorを使った方が良さそうってことか
ウェブフロントエンドまでRustの時代が来るとは驚き
994 名前：デフォルトの名無しさん mailto:sage [2021/11/05(金) 23:41:27.00 ID:7Nx3lyuG.net]: おもしろそうだけど、メンテが辛くなりそう。仕事でそんなん大丈夫かしら？
995 名前：デフォルトの名無しさん mailto:sage [2021/11/06(土) 01:14:13.09 ID:8rFQ20lW.net]: ダメに決まってんじゃん。。無理やり使おうとしてるのが丸わかりだわ。
996 名前：デフォルトの名無しさん mailto:sage [2021/11/06(土) 01:50:27.76 ID:BsA8c5Gl.net]: >>975
少くともその表に載ってるsolidってのは非vDOM系のJSフレームワークだけど…
その表ではDominatorとどっちが速いですか？
そしてそれはなぜですか？
それを勘案しても、
Vanilla JSで頑張るのでなければRustでDominatorを使った方が良さそうってなりますか？
997 名前：デフォルトの名無しさん [2021/11/0 ]: [ここ壊れてます]
998 名前：6(土) 01:55:12.94 ID:eYFGObaB.net mailto: フロントエンドのwasmでrustを使う意味が分からん、assemblyscriptなんかでts変換したほうがよっぽど
人材確保も容易で速度も出そうだけど、まあ全部１つの言語に統一したいという欲望は分かるが []: [ここ壊れてます]
999 名前：デフォルトの名無しさん mailto:sage [2021/11/06(土) 08:58:19.69 ID:8rFQ20lW.net]: その種の願望はいつだって失敗してるのに何回でもこだわるバカが出てくる。
ビジュアルプログラミングとかノーコード並みに愚かだわ。
1000 名前：デフォルトの名無しさん mailto:sage [2021/11/06(土) 09:42:55.78 ID:DjcFpt23.net]: 夢は終わらねえ！
1001 名前：デフォルトの名無しさん mailto:sage [2021/11/06(土) 10:40:16.97 ID:YOvBnwY8.net]: htmlマクロが微妙だよな。yewもしかり
マクロの仕様理解して書かないといけないからwebpackみたいなコンパイラー挟んでreact,vueみたいなhtmlベースでかけたら普及進むと思う
1002 名前：デフォルトの名無しさん mailto:sage [2021/11/06(土) 10:43:29.52 ID:gG2xt4rU.net]: フロントエンドはElmで書いた方がいいと思う
Elmの設計をパクったRust用フレームワークよりElmそのもので書いた方がいい
1003 名前：デフォルトの名無しさん mailto:sage [2021/11/06(土) 11:32:19.13 ID:dvoeGWeX.net]: >>979
WasmはもともとC/C++をブラウザのフロントエンドで使いたい願望から
始まったものだ。
意外に思うかもしれないが、C/C++を使いたい人はRustの1000倍くらい多い。
1004 名前：デフォルトの名無しさん mailto:sage [2021/11/06(土) 12:19:33.04 ID:v/Totsm8.net]: >>979
AssemblyScriptはメモリ管理GC問題があるし文法が単にTSの限定サブセットに過ぎないため色々と辛すぎる

そのためWebAssemblyでの使用言語調査結果もこんな状況でRustが圧勝
https://blog.scottlogic.com/ceberhardt/assets/state-of-wasm/desired-language.png

>>978
Wasm⇔JSのオーバーヘッドがあるので処理が少なくほとんどDOM操作になる時だけはJSのみで書いたほうが速い (当たり前)
そのためほぼDOM操作のそのベンチマークではRustフレームワークがわずか数％遅くなっているが現実には処理内容次第ですぐに逆転する

>>983
Elmは型クラス(Rustではtrait)がなく例えば抽象的なイテレータも持てず色々と辛い

このスレはRustにアンチな人がRustを貶めようと常駐して頑張ってるようだけど
Rustを用いるのがベストな方法な場合が非常に多いよ
1005 名前：デフォルトの名無しさん [2021/11/06(土) 16:27:09.97 ID:Y613N0Im.net]: もはや人類の発展はRustにかかっていると言ってもいい
1006 名前：デフォルトの名無しさん mailto:sage [2021/11/06(土) 16:30:35.71 ID:3ClRyBcI.net]: Rustのお陰でハゲが治りました！
1007 名前：デフォルトの名無しさん mailto:sage [2021/11/06(土) 16:45:26.77 ID:EdJhZAmA.net]: C++ドロップアウターの掃き溜まり
1008 名前：デフォルトの名無しさん mailto:sage [2021/11/06(土) 16:57:33.02 ID:5yvdtcf3.net]: similar word exists: `掃き溜め`
similar word exists: `吹き溜まり`
1009 名前：デフォルトの名無しさん mailto:sage [2021/11/06(土) 21:24:09.65 ID:8rFQ20lW.net]: rustがベストな時が多いとかよくそういうデマを平気で流せるよね。。
1010 名前：デフォルトの名無しさん mailto:sage [2021/11/06(土) 21:39:59.60 ID:1qW/ULGd.net]: シャドーイングがよくわかりません。
変数名によって中身が一意に決まらなくなることによって、安全性も下がるし並列性？も確保できなくなる気がするのですが、変数が全mutableな言語より安全性マシだしRustは関数型言語じゃないから並列性そこまで重要視してないし書き味のが大事だぜってことですか？
1011 名前：デフォルトの名無しさん mailto:sage [2021/11/06(土) 21:47:09.97 ID:PDDtrjdC.net]: 安全性も下がるし並列性？も確保できなくなる気がするのは気のせいではないでしょうか
1012 名前：デフォルトの名無しさん mailto:sage [2021/11/06(土) 22:22:33.53 ID:9KDcj+aF.net]: >>991
プログラミング初心者には難しいかもしれないけど
一般的にプログラミング言語ではスコープという概念があってスコープが異なれば同じ変数名でも全く別のものとして認識され格納場所は異なるし型が異なってもよい
その中でもブロックスコープは多くのプログラミング言語で採用されていてブロックが始まると新たなスコープが出来て同じ変数名でも全く別のものとして扱われる
今回のシャドーイングスコープも同様でシャドーイングの時点から新たなスコープが始まるため同じ変数名でも全く別の変数として扱われる
だから安全性は全く下がらないし並行でも並列でもシャドーイングで問題が生じることはない
むしろシャドーイングの利用で利便性が高まっていることがプログラミング経験を重ねると理解できる
1013 名前：デフォルトの名無しさん mailto:sage [2021/11/06(土) 22:44:27.14 ID:EdP5MzkQ.net]: ダイナミックスコープはいらない子だった・・・？
1014 名前：はちみつ餃子 mailto:sage [2021/11/06(土) 23:40:03.82 ID:tiSLGdpm.net]: ダイナミックスコープがデフォルトの言語なんて Emacs Lisp くらいしか見たことないわ。
1015 名前：９９１ mailto:sage [2021/11/07(日) 06:37:58.76 ID:It35Zcf7.net]: 意図したシャドーイングならともかく、間違って同じ変数名つけたコード片突っ込んでしまった系だと他言語にあるらしい２重宣言エラーないの怖くないですか？

新たなスコープが生まれるので並列性に問題ないことはなんとなく理解できました
1016 名前：デフォルトの名無しさん [2021/11/07(日) 07:11:27.61 ID:F+zOFISG.net]: D言語の再来。
1017 名前：デフォルトの名無しさん mailto:sage [2021/11/07(日) 07:13:38.67 ID:pJhT3MIE.net]: 次スレは？
>>980が1時間待っても立てなかったら俺がやる
1018 名前：デフォルトの名無しさん mailto:sage [2021/11/07(日) 08:48:10.79 ID:N5JIOUKU.net]: 質問いいですか
1019 名前：デフォルトの名無しさん mailto:sage [2021/11/07(日) 10:09:41.36 ID:k2ts2WHd.net]: くたばれ
1020 名前：1001 [Over 1000 Thread.net]: このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 74日 11時間 14分 14秒
1021 名前：過去ログ ★ [[過去ログ]]: ■ このスレッドは過去ログ倉庫に格納されています

[ 新着レスの取得/表示 (agate) ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef