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/16(木) 20:47:15.02

引数がマイナスになることもあるので条件判断の必要からisizeなんだよね
もしusizeを引数にするとしても、引数に渡すところでisize as usizeになるので、やっぱりusize祭りが大発生

お祭りワッショイワッショイ

**デフォルトの名無しさん** · 2021/09/16(木) 21:30:12.52

引数がマイナスになるならチェックしないと範囲外アクセスするだろ馬鹿か？

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

今どきIndex使って回すとか化石脳かよ

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

ボロクソワロタ

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

>>425
グローバル変数を使うのはありえないな
staticは使ってもモジュール内に閉じ込める
どの言語でも常識

**デフォルトの名無しさん** · 2021/09/17(金) 01:14:24.53

グローバル変数小文字にしたら警告出なかったっけ

**デフォルトの名無しさん** · 2021/09/17(金) 03:56:57.86

そもそもusizeで受け取って呼び出し側でケアすべきやろ

**デフォルトの名無しさん** · 2021/09/17(金) 13:27:45.55

>>412
経験的に、縛れば縛るほど最終的にはラクできるようなのを皆知ってると思う
ラクに書けるような言語は一見いいのだが
人間が生まれ持って自堕落であるのを伴って
最終的には苦しみをもたらすことになるコードを書いてしまう

**デフォルトの名無しさん** · 2021/09/17(金) 15:13:45.88

>>420も煽りのつもりで普段書いてないrustを
イキって書いたんだろうけど
煽り返された上にクソコードが掲示板に一生残るのは辛いよなあ

**デフォルトの名無しさん** · 2021/09/17(金) 15:20:07.79

3歩あるけば忘れるからヘーキヘーキ

**デフォルトの名無しさん** · 2021/09/17(金) 16:32:00.60

いきなり unsafe fn とか書いてるあたり普段からrust書いるが競プロとかでついた変な癖を引きずってる人だと思う
余計悪いが

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

>>420
これって何するコードなの？

**デフォルトの名無しさん** · 2021/09/17(金) 18:51:16.87

>>437
ゴミカスコード力を披露するコードだよ
Rustどうこう言うやつはこのレベルが多い

**デフォルトの名無しさん** · 2021/09/17(金) 20:36:20.90

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.push((a_yr, a_xc))
　　　　}
　　　　if map[a_yr as usize][a_xc as usize] == 1 {
　　　　　total += 1;
　　　　}
　　　}
　　}
　}
　next_pos = tmp_next_pos;
}

**デフォルトの名無しさん** · 2021/09/17(金) 21:04:31.14

>>439
しつこいなw

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

isize ってどういう時に使います？
添字は基本的に usize しか使いませんし符号付き整数が欲しくなったらi32かi64で大体事足りるのでいまいち使い所が分かってません

**デフォルトの名無しさん** · 2021/09/17(金) 21:43:47.45

添え字に使う値を算出する途中計算で負数が必要になったら isize が妥当という場合もある。

**デフォルトの名無しさん** · 2021/09/17(金) 21:44:59.72

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
意識高い系がウンコードを量産し罵倒するクソスレ

**デフォルトの名無しさん** · 2021/09/17(金) 21:45:51.61

そして、その結果、as usize祭りにもなる場合もある

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

>>432
経験的に縛れば縛るほど脱法行為が横行する。

**デフォルトの名無しさん** · 2021/09/17(金) 22:20:51.81

RustlingsをReplitで動かして学習したいのですが、これってrustlingsコマンドはどうやって動かすのですか？
https://github.com/rust-lang/rustlings
公式サイトが用意しているReplitの環境で学習をやりたいのです

よろしくお願いします

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

>>446
ReplitのRustのバージョンが古くて(1.44）ビルド失敗するっぽい
見た感じローカルでやるのとそんな変わらん気がするから、
こだわりないならローカルでやるのが吉
この環境ビルドむっちゃくちゃ遅いし

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

>>439
なぜそんなに下手なの？
配列のインデックスを取り出して配列をアクセスしてるだけなら
そのインデックスは最初からusize型にしておくだけてしょ

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

>>445
脱法行為もなにも>>420のコードで負のindex渡されたらおかしくなるやんけ

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

とはいえ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を使っていろいろやる）
}

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

競技プログラミングは
正しいプログラミングスタイルから離れていく悪です
競技プログラミングスタイルな人と一緒に開発したい人は存在しないでしょう

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

正当なスタイルが分かった上で競技としての割り切り方も分かっているなら問題ないんだけど、
競技から学ぶと変な癖が付きやすいというのは私も感じるなぁ。

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

>>441
off_tとかptrdiff_tの代わり
例えば <*const T>::offset なんかはisizeを引数に取る

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

>>450
自分はだいたい座標やwidth/heightはi32で扱って
indexへの変換処理を関数に抽出してそこでusizeに変えてる
一次元配列に二次元データ入れるときも自然に書ける

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

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は使わなくて良い箇所なら使わない。

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

>>450
let mut test = 100_usize;
アンダースコア使うと読みやすいぞ。おぬぬめ

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

winitのmasterでstdwebのサポートが切られてweb_sysに一本化されていた
stdwebってオワコンになりつつあるのかな？

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

>>455
NonZeroはOptionとかのサイズ最適化やポインタの値がnullでないことを示すのが主目的なので
汎用的な範囲を組み込み型で示すのはちょっと違うかと
必要ならnewtypeパターンで自分で作ればよい

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

配列がusizeなのはpythonなんかのa[-1]の最後尾アクセスを見てると、なぜそんな言語仕様にしたのかと
off_tなんかを見ると不思議に思う。いずれも Index bounds checkが掛るのに。符号無し64bitの巨大な
配列が欲しかったから？でもi128とかあるし

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

インデックスiが実行時に決まるとき
配列のアクセスを内部的には *(p + i) にしたかったからじゃないかな
マイナスのとき～っていう分岐をそこに入れずに最速でアクセスしたかったと

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

>>459
>符号無し64bitの巨大な配列が欲しかったから？
配列にマイナスの値は使わないんだから、そのぶんMAXの数を増やしたほうが
オーバーフローしにくいから安全だろってことらしい

でもどうせi32 as usizeとかi64 as usizeするから意味ないんですけどね！

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

>>451
ほんそれ
めっちゃ判る

**デフォルトの名無しさん** · 2021/09/19(日) 12:55:45.99

>>459
32bit環境だとisizeにするとbyte配列が2GBくらいしか扱えないからじゃないのかね
ついでに一応16bit環境もサポートしてるみたいだし

**デフォルトの名無しさん** · 2021/09/19(日) 15:08:42.28

競プロの書き方を仕事でするわけないだろ
何言ってるんだ

**デフォルトの名無しさん** · 2021/09/19(日) 22:06:10.71

してるバカがいるから言ってんだよバカ。

**デフォルトの名無しさん** · 2021/09/19(日) 22:13:07.84

矯正してやれ

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

アホか
競プロと仕事、書いてる時間がどっちが長いと思ってる
競プロは趣味　仕事で書いてるほうが圧倒的に長い
競プロでの書き方が仕事に引きずられることがあっても逆はない

そういうヤツがいるとか嘘をついてまで、
競プロに難癖つける理由がまったく理解できんわ

**デフォルトの名無しさん** · 2021/09/19(日) 23:07:40.22

お前が競プロスタイルで仕事するかどうかの話じゃないし、競プロに難癖つけてもいない

**デフォルトの名無しさん** · 2021/09/19(日) 23:52:05.14

競プロRustスレを専用に立てて分離するのがベストな解決かな。
大多数を占める普通のRustプログラミングをする人たちにとっては役に立たない、特殊な競プロのコーティング方法が書かれても、批判議論に陥りがちでお互いにメリットないと思うのです。

**デフォルトの名無しさん** · 2021/09/19(日) 23:53:50.32

難癖つけてるだろ

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

からの流れだからな

**デフォルトの名無しさん** · 2021/09/19(日) 23:59:33.71

>>470
それ自体は合ってますよ。
もちろん各々を使い分けられる人もいるでしょう。
でもそれはその人個人の内部の話。
競プロなプログラミングスタイル自体は、正しいプログラミングスタイルから乖離しています。

**デフォルトの名無しさん** · 2021/09/20(月) 00:04:36.59

なんで競プロの話になってるんですか？
usizeをasしまくるのが競プロってこと？

**デフォルトの名無しさん** · 2021/09/20(月) 00:14:27.54

>>472
グローバル変数を用いたりunsafeを闇雲に利用している点

**デフォルトの名無しさん** · 2021/09/20(月) 00:28:27.43

>>462
>>465
その一緒に仕事してるという競プロの人は、どんな困った記述してるんですか？
参考までにコードを晒してくれると助かる

まさか仕事でグローバル変数やunsafeを闇雲に使ってるわけじゃないですよね？

**デフォルトの名無しさん** · 2021/09/20(月) 00:32:13.16

仕事でRust書けるなんていい職場だな

**デフォルトの名無しさん** · 2021/09/20(月) 01:04:41.94

闇雲にunsafeを使うどころか脳死で全部の関数unsafeにする勢いだからな

**デフォルトの名無しさん** · 2021/09/20(月) 01:34:24.92

asはみるけどunsafeは競プロじゃめったにお目にかかれないような

**デフォルトの名無しさん** · 2021/09/20(月) 11:13:37.01

これ初めて知ったんだけど
Webブラウザサイド(フロントエンド)もRustで書けるのね
html!マクロでRustソースの中にHTMLもそのまま書けて更にその中にRustコードが書けてReact.jsのJSXみたいな感じね

https://yew.rs/ja/
Yew は WebAssembly によってマルチスレッドなWebアプリのフロントエンドを作ることができる、モダンな Rust のフレームワークです。

**デフォルトの名無しさん** · 2021/09/20(月) 13:47:36.24

そこまでする？

**デフォルトの名無しさん** · 2021/09/20(月) 15:13:17.24

alert使うだけでunwrap使うwebsysは使いたくない

**デフォルトの名無しさん** · 2021/09/20(月) 21:41:35.24

unwrapはそこらじゅうのサンプルで見かけるが、Rustクックブックでは、unwrapを許可していません。
こういう事も敷居が高い理由です

**デフォルトの名無しさん** · 2021/09/20(月) 22:06:55.37

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のほうに直接実装するのに比べて何かメリットがあるんでしょうか？

**デフォルトの名無しさん** · 2021/09/20(月) 23:56:14.72

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

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

>>482
内部用の非公開関数は
impl S { }
の方にしか書けないから実装は全部そっちに書いて
impl T for S { }
からは呼び出すだけにした方がすっきりする場合がある

**デフォルトの名無しさん** · 2021/09/21(火) 09:21:03.28

>>483
これ見て思ったんだけど、
メソッド名と引数全く同じだった場合で、
構造体のメソッドがpubで、
トレイトのほう優先的に呼び出したい場合ってどうするの？
そもそもメソッド名被らせるなって話ではあるんだけど

**482** · 2021/09/21(火) 10:01:30.32

すみません、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

**デフォルトの名無しさん** · 2021/09/21(火) 14:10:55.34

気持ち悪い

**デフォルトの名無しさん** · 2021/09/21(火) 20:13:53.65

>>473
match お前の職場にはコーディング規約がないの？ {
　規約でunsafeが許されている => { ならunsafe使うの自由だろ。問題があるなら規約を改正しろ }
　規約でunsafeは禁止されているが使ってるヤツがいる => { ならなんでunsafeを利用してコーディングしてるヤツがいるんだよ。そいつをなんとかしろ }
}

結論　別に許可されてるなら自由だろ
それが問題だと思うなら上司にいって禁止させるのが先

**デフォルトの名無しさん** · 2021/09/21(火) 20:16:09.40

おっと最後にこれが必要か

_ => { コーディング規約ぐらい決めとけ。決められてないぐらいの組織にいるなら文句いうな。諦めるか転職しろ }

**デフォルトの名無しさん** · 2021/09/21(火) 20:37:04.07

キモ

**デフォルトの名無しさん** · 2021/09/21(火) 20:43:04.95

規約で禁止されていてみんな守ってる場合にコーディング規約決めろと怒られるバグ

**デフォルトの名無しさん** · 2021/09/21(火) 20:53:30.60

>>491
規約で禁止されてるなら単純にそいつの問題だろ
それがなんで競プロの影響になるのかまったくわからんぞ

**デフォルトの名無しさん** · 2021/09/21(火) 20:54:04.75

動かないコーディング規約を作られても困るわ
どのタイミングでもいいから自動で弾く仕組みまで作らないと

…誰かgit hookの練習で作ってみない？

**デフォルトの名無しさん** · 2021/09/21(火) 21:04:02.40

こういうキチガイがいて邪魔だから
競プロは専用スレを立ててそこへ隔離すること

**デフォルトの名無しさん** · 2021/09/21(火) 21:09:08.77

なんで競プロの話に規約が出てくるんすか

**デフォルトの名無しさん** · 2021/09/21(火) 21:32:11.36

rust書いたことない障がい者が騒いでるな
ゴミコード晒して叩かれたのが相当悔しかったのか
なら自分の腕を磨けよ
やってることが数人しかいない過疎スレを荒らすって
どうやったらそう言う思考になるわけ

**デフォルトの名無しさん** · 2021/09/21(火) 23:20:56.90

そら競プロの解答コードが規約破りまくりなの見れば関係はあるわな

**デフォルトの名無しさん** · 2021/09/22(水) 02:11:22.59

そもそもunsafeの利用の明確な基準って決められるのか？
利用を完全に禁止することはできるかもしないが、使ってOKな条件を担当者の最良が入り込む余地がないレベルで厳密に決めるのは難しそう

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

>>498
例えばVecの実装にも一部unsafeが使われておりunsafeは忌避すべきものではなく有用なものであるがその使用には厳しい条件がある
①unsafeが極狭い範囲に閉じ込められており抽象化されたインターフェースによりその存在を意識せずに使えること
②unsafeを使用することで明白にその操作の効率が良くなるもしくは低レベル操作によりその使用が避けられないこと
③unsafeの使用部分がその関係する範囲全体の一貫性において完全に安全な操作であると確認できること
以上3点が関係者により合意確認できている場合のみunsafeの使用が認められそして上位ではその存在を気にせず安全に使うことができる

**デフォルトの名無しさん** · 2021/09/22(水) 04:21:37.31

>>498
unsafeのコードにはレビュアーを最低5人指定すること
とすればok

**デフォルトの名無しさん** · 2021/09/22(水) 07:58:09.34

使わざるを得ないパターンを提示(この時点で滅多に無い事が分かる)、当てはまらない物は原則禁止
本来要らない箇所で使おうとする輩が湧いて出ないようにするのが目的

**デフォルトの名無しさん** · 2021/09/22(水) 10:40:17.54

ノーコメントunsafeは問答無用で禁止くらいのことはしてもいいと思う
そのくらいunsafeはやばい

**デフォルトの名無しさん** · 2021/09/22(水) 11:36:51.20

stdのunsafe APIに関してはそうだと思うけど
crates.ioのライブラリ群にまでそういうの持ち出されると面倒だなあ

**デフォルトの名無しさん** · 2021/09/22(水) 12:19:04.62

clippyもpubなunsafe fnにはドキュメントコメントに # Safety のセクションがないとデフォルトで警告出すので
コメントつけるのは最低限やっておくべきラインだと思う
https://rust-lang.github.io/rust-clippy/master/#missing_safety_doc

**デフォルトの名無しさん** · 2021/09/22(水) 12:31:35.55

競プロの人ってレギュレーション守れば何してもいいって考え方の人が多いよね。
規約次第ってのが正にそれ。

unsafe みたいに取り扱いが繊細な機能は基本使わない、使う時には議論した上で限定的に使うみたいな感じに取り扱うのがほとんどだろ。
規約で機械的には決められないと思うよ。

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

競プロでunsafeなんて使わないよ
グローバル変数おじさんなら知らんけど

**デフォルトの名無しさん** · 2021/09/22(水) 13:53:44.01

久々に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
}

**デフォルトの名無しさん** · 2021/09/22(水) 13:54:58.06

なんで来るんだよおじさんー

**デフォルトの名無しさん** · 2021/09/22(水) 13:57:46.22

Rust競プロでグローバル変数（static mut）はマジでおすすめしないぞ、ほんまに
意味わからんWAの原因になりうる

https://qiita.com/qnighy/items/46dbf8d2aff7c2531f4e

**デフォルトの名無しさん** · 2021/09/22(水) 15:00:43.19

そんなに生配列使いたいならCで書けよ

**デフォルトの名無しさん** · 2021/09/22(水) 19:10:57.50

結局規約頼りならrust使う意味は薄いわな。

**デフォルトの名無しさん** · 2021/09/22(水) 20:53:41.87

>>509
それはRustだけでなくcやc++でも起こることなので、注意すれば大丈夫ヽ(´ー｀)ノ
Rustだから駄目、c++ならokという根拠にはならないから

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

>>511
1%でもダメな箇所があったら全部ダメって考える人？

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

理想的な言語には無駄など一切無いのだ

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

規約になんもないからってunsafeまみれだとぶっ叩かれるぞ
そう、actix-webの作者のように

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

>>507 添削しました。お収めくださいまし。

1. 安易にグローバル変数を使うな。状態を引数で持つくらいやれ
2. 引数bitが負になるのかくらい考えろ。脳死でi32とusizeをコピペしてるだろテメー
　暗黙のキャストが無い==明示的にキャストすればいい、じゃねえぞ
　パッと見て汚いなら設計が汚えんだ。動的プログラミングだから汚えんじゃねえ、テメーが汚えんだ
　…負数になる可能性がある場所はたったの1行じゃねえか！どうした？頭使ってる？
4. unsafe外す努力もしねえのか、どうした？5回deleteキー押せば外れるぞ？
5. 値とインデックスが混ざるような書き方、どうして怖がらない？ロボトミー手術でも受けたのか？
6. C/C++には無い機能も使わず、warningもlinterも無視して、一体どうしてrustで書いてるんだ？
　勉強中とすら言えねえじゃねえか。
　まさか、VBAスクリプトを.javaファイルにコピペして「動きません！javaはクソ！」とか言っちゃう伝説のコーダーなのか？

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

質問です
デフォルト値を与えるトレイト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
なぜ？

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

>>517
Default::defaultはどこでも使えるから癖で使ってる人が多いんだと思う

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

以上を踏まえれば最後のコアダンプの原因はS::defaultの無限再帰によるstack overflowだと容易に理解いただけよう

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

>>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(),
　　}
　}
}

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

Defaultトレイトのdefaultと明示するため、で合ってるよ
Arc::cloneにもそのような文化がある

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

>>513
1%のダメな箇所で他の言語の文句言ってるのはrust信者の方ですけどね。

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

まあ、100%良いものなんてないんだし、子供達がせっかく作ったものを評価し、使ってやるというのも、年長者の優しさってものだろう。

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

諸行無常

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

>>522
Rustを置き換えるにはコンパイル時点でのメモリ安全性保証を実現しないといけない
Rustは諸問題を解決してしまったので代わりの言語は数十年出てきそうにない
もし出てきたときには手続き型ではなくなってるだろう

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

みずほのシステムを全部Rustで

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

>>524
ボンクラPGは排除できるから意外と良い選択かもw