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

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

みずほはもっとマクロなレベルでの設計の問題じゃないの知らんけど

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

つかCOBOLならもともとメモリ安全性は高いだろ

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

昔の 1% は (注意を払うという対処法で) なんとかなったが現代のコード規模の 1% は深刻だという話なんだよ。

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

静的チェックでその１％が埋まると思ってるのがお気楽だなと思うわ。

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

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

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

vscodeでセーブした時に、ifに付けちゃった括弧を外して欲しいんだけど、何をどう設定すればいいの？

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

処理系の勉強をかねてRustで
ttps://www.sigbus.info/compilerbook
これをやってみようと思う
序盤で二分木＆再帰・・・うへー

**ハノン** ◆QZaw55cn4c · 2021/09/23(木) 18:32:58.93

>>532
二分木はむしろ非再帰で組めといわれたら罰ゲームなんですよ‥‥

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

なんかこのスレ競プロの厄介な人に乗っ取られた？
クソコードを延々と貼り付けてるあたり開き直ったか

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

競プロは別スレ建てて分離しましょう
競プロの件はいずれもRustを利用＆学習する人々にとって役に立たない有害なものばかりでこのスレと別件ですから

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

競技プログラミング総合スレ 63
https://mevius.5ch.net/test/read.cgi/tech/1627477128/

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

>>535
いやRustで競プロをする人もいるじゃんね
Rustを使用している人は、仕事だけの人、競プロだけの人、仕事でも競プロで使う人、のそれぞれの合計

ということは、そこから競プロを排除するってことは、より少ない人数だけを対象にするスレを立てるってことだから、
競プロの話題を禁止したい人が、「Rust原理主義者スレ」とでもして、自分たちが別スレをたてて
原理主義者たちだけで移動するのが論理的かつ合理的ヽ(´ー｀)ノ

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

とキチガイが申しております

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

>>537
あなたはまず何の説明も無しにコード貼り散らかして祭りだとか言うことの目的を教えなさいよ

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

ブログトップにキモい自撮り写真貼ってるやつを見てから
競プロ臭のくっさいコードはスルーすることに決めてる

**デフォルトの名無しさん** · 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の良いところはメモリ安全だけではなかろう？