Rust part12

**デフォルトの名無しさん** · 2021/08/24(火) 22:55:27.78

公式
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/

**デフォルトの名無しさん** · 2021/09/23(木) 20:34:50.85

>>538-540
スレッドは知識の集合知である場所だと思うから、
B木を考えても、情報が細分化される場合には、
携わる人数（情報）が少ないほうを葉にするのが妥当だと思うけど

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

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

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

ただし、ここはRustのrootだと解釈している

**デフォルトの名無しさん** · 2021/09/23(木) 21:50:54.44

ってことで以降は競プロ禁止
やりたい人は競プロのスレで

**デフォルトの名無しさん** · 2021/09/23(木) 22:02:49.74

>>542
そういう強権的なやり方は嫌われると思う

**デフォルトの名無しさん** · 2021/09/23(木) 22:22:06.57

俺はお前が嫌い

**デフォルトの名無しさん** · 2021/09/23(木) 22:56:16.76

>>541
要はフィードバックが欲しくてソース貼ってるのか？
ならせめて入力仕様と出力仕様くらいは書こうな
競プロなら問題へのリンクでもいい

**デフォルトの名無しさん** · 2021/09/23(木) 23:17:56.15

codeLLDBを消去しやがるからavastアンインストールしてやったわ

**デフォルトの名無しさん** · 2021/09/24(金) 00:59:53.09

>>541 添削しました。お納めください。

1. Cをそのままコピペしただけじゃねえか
　 Rustの機能を試すだぁ？enumもtraitもパターンマッチも使えないのに何が検証だ馬鹿野郎
　「Cコピペしたけどメリット無いね！」って後何回繰り返すんだ？
2. なんだこの察してちゃんなコードは。保育園にいるつもりか？
　意図の明確なコードが1行も無いんだが？
3. お前がここにゴミを貼る妥当性が一つも無い
　 Rustの世界に持ってきた概念のどれも使わないで、何が検証できると思ってるんだ？
　例えるなら「ひらがなしか知らない外国人が日本語の良し悪しを検証します！」っていうもんだぞ
　誰がマトモに付き合うんだ？

**デフォルトの名無しさん** · 2021/09/24(金) 01:50:08.20

>>529
CやC++だと非安全コードはどこにでも現れる可能性があるので100%のコードを人力で確認する必要があったが
rustでは安全性に関してはunsafeな部分のみ(例えば全体の1%)を確認すれば良いという話では
静的チェックで100%なんとかしようという話はしていないと思うが

**デフォルトの名無しさん** · 2021/09/24(金) 02:35:54.11

そうだなーと思う反面unsafeだらけのコードを目の前にしてげんなりする未来も見えるという…

**デフォルトの名無しさん** · 2021/09/24(金) 04:43:03.82

ほとんどの用途でunsafeを直接使うことは無いんじゃない？
グローバル変数はOnceCellで解決してしまったし
もし生ポ操作するとしたら新たな型を作ってその中に閉じ込める

**デフォルトの名無しさん** · 2021/09/24(金) 08:02:15.31

そういうコードが書ける事が問題だとあれほど批判してたのに

**デフォルトの名無しさん** · 2021/09/24(金) 08:30:26.85

>>551
それは何も問題ではないよ
例えばVec型もpushやpopですら内部はunsafe利用だけど我々はそれを知らず気にせず安全に使うことができる

**デフォルトの名無しさん** · 2021/09/24(金) 10:22:26.34

>>551
どのレスに対するコメント？

**デフォルトの名無しさん** · 2021/09/24(金) 13:18:46.57

そもそも競プロにメモリ安全性とかいらないしC++で書いといてくださいよ

**デフォルトの名無しさん** · 2021/09/24(金) 14:03:53.31

Rustの良いところはメモリ安全だけではなかろう？

**デフォルトの名無しさん** · 2021/09/24(金) 19:03:51.27

機能性で言えば競プロに必要なものは大抵の言語が備えてるだろうし
使いやすさで言えばRustはきっちり書くことを求められてるから素早く書くのには向いてないし
それでも敢えてRustを選ぶ理由は趣味や慣れくらいなのでは

**デフォルトの名無しさん** · 2021/09/24(金) 21:51:28.01

releaseビルドするとTrojan:Script/Wacatac.B!mlを検出して
Windows Defenderに怒られる
--release付けないと大丈夫
誤検知かな？

**デフォルトの名無しさん** · 2021/09/24(金) 22:12:48.28

>>553
ごめん
例えばUnsafeCellの存在はRustの借用ルールに制約されることなく自由に新たな型を設計して作る道を開いているけど
あくまでも安全な型を作るための素材であって具体的にはRefCellやOnceCellなどの様々な安全な型を提供する素材となっているように
unsafeの存在も上位レベルで安全な関数やモジュールを提供するための素材としてのみ用いるべきではないか
ということを伝えたかったのです

**デフォルトの名無しさん** · 2021/09/24(金) 23:54:29.51

つまり競プロ君のunsafeの使い方はただ危ない逸脱のみであり、
安全かつ便利な何かを提供する目的のための使い方ではなく、
Rustの精神に反している、と。
したがって競プロの話は、
このRust本スレでやるべきことではなく、
ここでは禁じて別スレでやるべき、と。

**デフォルトの名無しさん** · 2021/09/25(土) 00:09:12.18

>>559
競プロくんを競プロの代表扱いするのはさすがに競プロの人に失礼では

**デフォルトの名無しさん** · 2021/09/25(土) 01:22:46.71

Rustの精神とかそんな大層な話でもないでしょ
建設的に話せない奴に付き合う必要はないというだけ

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

>>558
違う人が書いた事を、さも自分が書いたように返答するのはどうかと思う

**デフォルトの名無しさん** · 2021/09/25(土) 08:30:11.81

>>562
え？？
>>558は自分の意見を書いただけでこのスレにしか書いていないし参考にしたサイトや書き込みもないよ
もし偶然にそっくりな内容なものがどこか他にあるなら見てみたいので教えて

**デフォルトの名無しさん** · 2021/09/25(土) 22:50:40.30

>>559
こういう自分の意見にあわないと何でも排除したいヤツはどこにでもいるんだよなあ

**デフォルトの名無しさん** · 2021/09/26(日) 00:09:45.69

Range関連での質問です

(Included(&x), Included(&y)) はx..=yと書けますが、
(Excluded(&x), Included(&y)) を似たように書く方法ってありますか？

**デフォルトの名無しさん** · 2021/09/26(日) 01:40:54.44

>>565
ないんじゃない？

(3..=5).skip(1)で、妥協するかなぁ

**デフォルトの名無しさん** · 2021/09/26(日) 01:56:26.69

Range はよく使うから構文糖を入れてちょっと簡単にするという判断がうまれたんだと思うんで、
それほど頻出しないパターンは明示的に書くしかしょうがないと思う。
自分のプログラムでよく使うのであればそういう関数を用意しておけというくらいの妥協になる。

**デフォルトの名無しさん** · 2021/09/26(日) 03:07:15.60

>>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)もアリです

**デフォルトの名無しさん** · 2021/09/26(日) 03:55:02.75

>>566 >>568
すみません、言葉足らずでした
BTreeMap/Setのrangeメソッドに渡す引数を意図していました
こちらに渡すのはイテレータではないのでskip(1)はできないようです

>>567 >>568
あまり頻出ではないですし仕方ないですかね
実際困るわけではないのですが、
アンバランスなので気になってしまいました

**デフォルトの名無しさん** · 2021/09/29(水) 09:06:12.26

無職の人工衛星おじさん来て

**デフォルトの名無しさん** · 2021/09/30(木) 11:51:35.89

ttps://lkml.org/lkml/2021/7/7/349
完全にストップしたな。最低だよ。

**デフォルトの名無しさん** · 2021/09/30(木) 12:33:08.03

>>571
どういう意味や？

**デフォルトの名無しさん** · 2021/10/01(金) 12:54:11.60

>>573
どういう意味や？

**デフォルトの名無しさん** · 2021/10/01(金) 13:00:05.87

自問自答かいな

**デフォルトの名無しさん** · 2021/10/01(金) 14:16:55.18

Rust for Linuxに関しては結局それ以降進展無しということ？

**デフォルトの名無しさん** · 2021/10/01(金) 14:33:36.85

そりゃ普段の作業はGitHub上でやって、まとまったところでパッチ投げるんだから
LKMLで日々の進捗報告なんかしたら迷惑でしかない

**デフォルトの名無しさん** · 2021/10/01(金) 14:40:28.89

https://github.com/Rust-for-Linux/linux
ここかな？全然活発だったわ

**デフォルトの名無しさん** · 2021/10/01(金) 15:23:00.24

いや実際のドライバーが動かないのにごねてるだけやん。。話になってないんだが。

**デフォルトの名無しさん** · 2021/10/01(金) 23:00:07.65

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));
　　}
　}
}

**デフォルトの名無しさん** · 2021/10/02(土) 02:05:08.49

>>578
そうなんだ。誰がどこでごねてるの？

**デフォルトの名無しさん** · 2021/10/02(土) 07:25:57.30

VSCodeか何かで、編集中のファイルを（保存する度ではなく）リアルタイムで構文チェックしてもらうことってできないの？
目が悪いもので、C#みたいに間違えたら即指摘みたいなのがすごく助かるんだけど・・・・

**デフォルトの名無しさん** · 2021/10/02(土) 08:17:40.16

rust-analyzer入れれば若干のラグはあるけどそんな感じでやってくれると思うが

**デフォルトの名無しさん** · 2021/10/02(土) 08:21:40.61

すまんオートセーブもつこうてたわｗ

**デフォルトの名無しさん** · 2021/10/02(土) 09:01:16.43

>>581
IntelliJRustにon the fly analysisあるぞ

**デフォルトの名無しさん** · 2021/10/02(土) 15:27:53.04

普通にVscodeでRustの拡張入れたらやってくれん？
俺が思てる構文チェックとかの支援とは違うんかな

**デフォルトの名無しさん** · 2021/10/02(土) 15:48:21.44

vscode+rust-analyzerでオートセーブ無効でもリアルタイム構文チェックしてくれるよ

**デフォルトの名無しさん** · 2021/10/02(土) 17:14:40.18

いつrust-analyzerに移行するか悩み中。

**デフォルトの名無しさん** · 2021/10/02(土) 17:43:54.53

>>586
Auto Saveオフだと、指摘してくれないやつ結構ない？
セーブして初めて指摘されるやつが結構あるような

**デフォルトの名無しさん** · 2021/10/02(土) 17:45:45.06

rust-analyzerってvimでも使える？
流石にvim捨てるべきかなあ

**デフォルトの名無しさん** · 2021/10/02(土) 18:12:12.35

vimでもneovimでも使えるよ

**デフォルトの名無しさん** · 2021/10/02(土) 21:14:54.36

rls から rust-analyzer の移行なんて躊躇するもんじゃないぞ。
試して合わなければすぐに戻せばいいだけだし、戻りたいと思う可能性は俺はゼロだと思う。

**デフォルトの名無しさん** · 2021/10/02(土) 21:57:31.81

>>588
構文チェックとrust-analyzerの検知できる型エラーは保存しなくても指摘されるはず(前者は即時、後者は少しラグがある)
rustcじゃないと検出できないものは確かに保存時しか出ないかもね
特に害あるものじゃないしauto save有効にしても良いのでは？

**デフォルトの名無しさん** · 2021/10/02(土) 23:35:42.15

>>589
実際にビルドしてみてそのエラーメッセージをエディタに反映するという仕組み (いわゆる flycheck) は昔からあったんだが、
頻繁に実際にビルドするんじゃなくて処理系の構文解析プロセスとエディタを連携させればもっと効率的なんと違うか？という
のがマイクロソフトによって LSP (Language Server Protocol) として標準化されたという経緯がある。

エディタにとっては場当たり的なエラーメッセージの解析をせずによくなったので昔より楽になってるんだよ。
昔から flycheck をやってるようなエディタはだいたい LSP にも対応してる。

**デフォルトの名無しさん** · 2021/10/04(月) 23:18:59.60

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.”

**デフォルトの名無しさん** · 2021/10/05(火) 01:50:58.24

統合早いな。多言語プロジェクトでcargo面倒くさい問題はなんかやってんだろうか？
統合されたらソース読んでみよ。

**デフォルトの名無しさん** · 2021/10/05(火) 03:19:27.62

言語を組み合わせる場合を含めてビルドプロセスの記述はなんだかんだで make が万能なんだよな。
クソみたいに場当たり的だけど必要だから機能を追加してきたという現実の前には
どんな美しいパラダイムも砂上の楼閣という印象だわ。

**デフォルトの名無しさん** · 2021/10/05(火) 11:23:44.05

cargoが勝手にクレートダウンロードしてくれるのは便利だけどね
セキュリティ的には……どうなんかなー

**デフォルトの名無しさん** · 2021/10/05(火) 11:55:21.23

ビルドはmakeからrustc呼ぶ形になってたはず
カーネルに関してはクレートのダウンロードなんかもしないならそれで問題ない

**デフォルトの名無しさん** · 2021/10/05(火) 12:47:41.98

余計なことするツールに限ってモジュラリティ低い

**デフォルトの名無しさん** · 2021/10/05(火) 12:55:43.82

>>596
既存のものがクソだから俺が全く新しいクールな奴を作ってやるぜ！っていって新しいクソが1つ増えるのはもはや伝統芸やね

**デフォルトの名無しさん** · 2021/10/05(火) 15:46:57.33

>>597
そのための --offline オプション

**デフォルトの名無しさん** · 2021/10/05(火) 18:59:42.65

>>600
makeの機能を持つprologは欲しいなぁ。

論理プログラミング言語を拡張したmakeとか堅牢そうな気がするけど、誰もやらないのかしらん。

**デフォルトの名無しさん** · 2021/10/05(火) 20:24:54.05

>>602
prolog難しいから流行らない

**デフォルトの名無しさん** · 2021/10/05(火) 21:06:12.38

宣言的なものの依存がゴタゴタしたもののデバッグのしずらさを知らんのだろう。呑気なもんだ。

**デフォルトの名無しさん** · 2021/10/06(水) 17:08:43.54

rust-analyserだかに移行しようとうおもったけどemacs とは相性悪過ぎて結局rlsに戻した
analの方はcodeいれんとインストール出来んかったりとほぼvs用だなあれ(´・ω・｀)

**デフォルトの名無しさん** · 2021/10/06(水) 18:10:02.17

>>605
lsp-modeとの組み合わせで普通に使えるが

**デフォルトの名無しさん** · 2021/10/06(水) 19:54:44.67

マジかeglot使ってたからかも
何かfunction defとかの問い合わせ方法間違ってんのか知らんが常にno docみたいのがmessage表示されて使いもんにならんかった
lspってマジで全然分からんちんで小鳥の餌待ち状態で微塵も弄れないのよね俺(´・ω・｀)

**デフォルトの名無しさん** · 2021/10/06(水) 23:28:27.48

rlsもlspだよ
rlsのlsはlanguage serverのls

**デフォルトの名無しさん** · 2021/10/06(水) 23:40:35.33

>>607
標準ライブラリのソースコードがないとか？
rustup component add rust-src
で入ると思う

**デフォルトの名無しさん** · 2021/10/07(木) 00:12:56.69

あんま多くは試しでないがrust-analyzerインストールする時に入れさせられたvscodeではanal pluginで動いてたしanal自体はインストール出来てると思うんだがな

>>608
そのfuckin msの策定したlspを部分的にとか言語ごとに異なるoverrideてかimplで構成するプロジェクト群がrust-analyzerとかclangdだかとかgoplzとか
ただこれらだけじゃ意味不明のjson object返したり読み込んだりするだけのdaemonで役に立たないから
仲介者としてのeglotとかlsp-modeが必要になる
ここらまでも簡単に弄れるというか(弄れる必要があると言うのか...)がemacsの良いところ(´・ω・｀)

**デフォルトの名無しさん** · 2021/10/07(木) 06:40:58.97

anal plug?

**デフォルトの名無しさん** · 2021/10/07(木) 11:35:48.71

インストールもなにも実行ファイルのパス通すだけだからね
~/.vscode/ 配下にあるはずだからそれを使うか GitHub からダウンロードしてくれば良い

**デフォルトの名無しさん** · 2021/10/08(金) 22:14:06.47

べき剰余をオーバーフローさせずに作る関数を作ったヽ(´ー｀)ノ

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
}

**デフォルトの名無しさん** · 2021/10/09(土) 10:18:30.30

>>613
普通にオーバーフローするが
calc(usize::MAX, usize::MAX, usize::MAX-1);

**デフォルトの名無しさん** · 2021/10/09(土) 11:49:04.73

多分競プロのやつだから各数値は32bitなんだろう
そらオーバーフローしねえよって話

**デフォルトの名無しさん** · 2021/10/10(日) 09:49:29.12

都合のいい仮定置いてそうなのがらしい感じだわな

**デフォルトの名無しさん** · 2021/10/10(日) 11:17:36.59

↓これと同じアルゴリズムなのに>>613のは読みにくいね
https://ja.wikipedia.org/wiki/冪剰余#途中で剰余をとる

u64で受け取って内部ではu128で計算して
u64で返すようにしとけばオーバーフローしない

**デフォルトの名無しさん** · 2021/10/10(日) 11:36:29.13

u16ならu32、u32ならu64、u64ならu128みたいな関係をジェネリクスで表現できたりする？

**デフォルトの名無しさん** · 2021/10/10(日) 11:52:04.33

trait作ってassociated typeで表現するのはできるかな

**デフォルトの名無しさん** · 2021/10/10(日) 12:00:59.32

関連型使えよ

**デフォルトの名無しさん** · 2021/10/10(日) 12:15:12.30

Traitを各データ型に対して全部実装するのが面倒だから
対応する倍のサイズの型を表現する方法はないのかなって話だったんだけど
なさそうってことだね

**デフォルトの名無しさん** · 2021/10/10(日) 16:41:29.53

コンパイラを単純化（高速化）するためにプリミティブ型の型クラスはありません。例えば、Haskellに
あるような数値型全般を表す Num という型クラスは、数値型全般を表しますが実体は IntやDoubleなど。
またはtypescriptのtype Tree = Leaf | Nodeはサポートされません

**デフォルトの名無しさん** · 2021/10/10(日) 17:11:17.77

rustはどちらかと言えばほとんどをトレイトで表現しますが、技術的にはこれらは、Tagged unionと呼ばれ
昔はSum typeともバリアント型とも呼ばれていました。プリミティブ型ではありませんが、似た機能を実現
する技術はenum variantsでも表現できます。C20にあるstd:variantもTagged unionです
もちろんassociatedでも似たことは出来るでしょう
https://en.wikipedia.org/wiki/Tagged_union

**デフォルトの名無しさん** · 2021/10/10(日) 17:13:00.50

>>622
num-traitsとenum

**デフォルトの名無しさん** · 2021/10/10(日) 19:43:56.21

>>621
マクロの使いどころ

**デフォルトの名無しさん** · 2021/10/10(日) 19:46:17.72

>>622-623 の言ってることが何一つわからんのだが

**デフォルトの名無しさん** · 2021/10/10(日) 19:56:58.54

>>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でサポートできますね

**デフォルトの名無しさん** · 2021/10/10(日) 19:58:36.14

>>617
rustは可変参照を基本的に好まないスタイルだから、ああなるのは仕方ないな

**デフォルトの名無しさん** · 2021/10/10(日) 21:20:06.28

他人のフリして自分のレスに返信してるやつなんなのwww

**デフォルトの名無しさん** · 2021/10/10(日) 21:23:34.82

>>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
　 }

**デフォルトの名無しさん** · 2021/10/11(月) 00:12:55.43

>>630
アルゴリズムではなくて、ポインタを渡すのか、実数値を渡すのか
そこを明確にしているRustの仕様から引数を可変参照にするのは・・という意味では

そして>>617が何を読みにくいといっているのかも、よくわからんし

**デフォルトの名無しさん** · 2021/10/11(月) 00:34:40.68

>>624 >>627
がねがねその通りで、言った通りトレイトだが、「Num型があるよりももっと高度なことができる」これは弁明的。
近代的な言語はmixinもしくはアドホック多相で（高度なことが）出来る場合がほとんどであり、無いものを無いと
要求できず弁護をするのはちょっと違う。他にも角度のように、0-360まで制限したいプリミティブ型が欲しいのに
PascalのようなSubrange型も足りていない。範囲を表す表現、0..360はあるのに。些細な事だが、コンパイラを
速くする事を現在は主眼なので（仕様に矛盾が無ければ）いずれは拡張されるのかもしれないが

**デフォルトの名無しさん** · 2021/10/11(月) 06:54:36.68

mutをつけたベクター型について教えてください
これはまず、入っているのは参照なんですか？
また、参照が変わらない(?)のに、参照先を変更するにはmutがなぜ必要になってくるのですか？
(所有権概念のせいなのでしょうか？それともスマートポインタの仕組み上、参照するアドレスが変わるのでしょうか？)

**デフォルトの名無しさん** · 2021/10/11(月) 08:28:39.20

>>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」ルールをコンパイル時に強制するため

連続したバッファを確保できなければアドレスが変わる可能性も有るし
ゼロキャパシティなら具体的なアドレスを持ってない

**デフォルトの名無しさん** · 2021/10/11(月) 13:32:30.30

Cortex-M対応がClangよりRustの方が進んでいて草

**デフォルトの名無しさん** · 2021/10/11(月) 14:07:37.59

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のある言語しか触ったことない限りその発想にはならんから
まずアロケータの仕組みからやりな。

**デフォルトの名無しさん** · 2021/10/11(月) 14:34:19.59

ホラふきがあらわれた！

**デフォルトの名無しさん** · 2021/10/11(月) 14:44:50.63

また他人のフリして間違いを指摘するレスが来るから乞うご期待www

**デフォルトの名無しさん** · 2021/10/11(月) 15:28:05.06

compositionだからスマートポインタでないという理屈だと Rc も Arc も非公開な内部型の composition だからスマートポインタでなくなってしまう

**デフォルトの名無しさん** · 2021/10/11(月) 15:42:18.11

>>636
C++のことは一旦忘れて、Rustにおけるスマートポインタの意味を学ぶことをすすめる
https://doc.rust-lang.org/book/ch15-00-smart-pointers.html