Rust part12
■ このスレッドは過去ログ倉庫に格納されています
>>379 ++と―はバグの温床だからそういう傾向 Swiftから削除されたのもRustでrejectされてるのも同じ理由 >>380 起源をたどればそうかもしれないけどRustが直接的に影響を受けたのはRuby ベストなジェネリクスの書き方ってなんだよ Scalaみたいなのがいいの? Scalaみたいに[]にするのもアリだけど配列がちょっとアレになるからさすがに避けたい気がする D言語みたいに、例えば定義時には struct(T) Foo { foo: T } impl(T) Foo { fn(T) new(foo: T) { Self { foo } } } みたいな感じにして、使用時には let bar = Foo!i64::new(42); って感じにするとか・・・? 実際に書いてみるとこれはこれで微妙な気もするが >>379 そこは { let result = counter; counter -= 1; result } または { counter -= 1; counter + 1 } になるの? move || { counter-=1; counter }では??? 後置であるということをそもそも認識できていなかった、やっべえ >>385 初期Rustは [] だったけどまさに配列と被るからと言う理由で <> にした C++と親和性のある構文を目指しているので <> 以外は採用されにくいと思う 型変数を明示しなきゃならないのは汎用プログラミング言語の欠点だよな let mut counter = init + 1; move || { counter -= 1; counter } これが普通だと思うのは俺だけか? >>395 Rubyだと普通にそういう書き方するから特に違和感はないな 配列がusizeだけなのを何とかして欲しい i32 as usizeとかいちいち面倒 >>397 普通に開発していればむしろusizeという別の型になってるおかげでミスなどに気付けて助かったことある人多いと思う i32と別になっていることは非常に重要 usizeだとうっかりマイナスにしちゃって死ぬことがある デバッグビルドならぱにくって気づくけど、 テストすり抜けちゃうとやばい i32は流石にどうかと思うけど グリッドの4-隣接とか8-隣接をforで回すときに中心からの差分で表現したくて、 isizeとusizeでガチャガチャ変換したときはちょっとウザいなーとは思った impl From<u16> for usize はあるのに u32 はないのが面倒 usize のサイズがプラットフォーム依存なのは分かるけど毎回 trt_from().unwap() したくない Rustの難しさってある程度マスターしたあとは納得の難しさなんですか? 面倒だなー。でも(メモリ安全のためには)しょうがないか〜、みたいな 補助輪なし言語でバグなしプログラム作れたらどこに行っても採用されると思うよ >>405 asでも良いけどreleaseだとオーバーフローチェックしてくれないから心許ない constの文脈だとunwrap使えないからas使わざるを得ないけど オーバーフローの懸念がある文脈ならtry_fromはしょうがないのでは usizeがu32以上のプラットフォームだけ想定するならasでいいように思えちゃうんだけど asを使うとu32から別の型に変更したときに修正漏れのリスクがあるのが気になってしまう まあfrom相当のユーティリティ関数自分で用意すれば良いか >>398 じゃあunsafe時には許可して欲しい 緩く簡単に書きたい人向けの言語じゃないよね全体的に それはそう 緩く簡単に書けるせいで起きていた全てのバグを撲滅したい、的な執念を感じる IntelliJ Rust pluginの新バージョン、関数とかの補完を機械学習でやるんだってさ すごいね 試してないけど 誰も見ていなければ海や川でも裸で泳ぐCちゃんと 温泉の女湯でも深夜一人で水着で入るRustちゃん エラーハンドリング可能な形ですっきりしたルールを定義できるならやればいいんだけど 現実にそういう上手い方法がないなら煩雑でも変換の手順を書くしかない。 低レイヤーいじる言語のエラー処理内容の粒度はそれこそプログラムごとに違うとしか言いようがない。 だから仕方ない。 >>414 泳いでるのをDQNに見つかって乱暴されるCちゃん そもそもDQNに覗かれるような温泉には入らないRustちゃん 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 } >>420 関数に定義されていない変数が使われまくり forループの中に変動変数がなく毎回同じ実行 キチガイのコードを読むべきでなかった unsafeだしな そして、その指摘にas usizeを擁護(容認)する意見は皆無だっていう あと祭り発生中の実況だったので稼働するコードではなく、 if a[a_index as usize] == b[i as usize] { } と修正した なんでunsafeなのかもわからないしなんでusizeじゃなくてisizeを受け取るのかもわからん 引数がマイナスになることもあるので条件判断の必要からisizeなんだよね もしusizeを引数にするとしても、引数に渡すところでisize as usizeになるので、やっぱりusize祭りが大発生 お祭りワッショイワッショイ 引数がマイナスになるならチェックしないと範囲外アクセスするだろ馬鹿か? >>425 グローバル変数を使うのはありえないな staticは使ってもモジュール内に閉じ込める どの言語でも常識 そもそもusizeで受け取って呼び出し側でケアすべきやろ >>412 経験的に、縛れば縛るほど最終的にはラクできるようなのを皆知ってると思う ラクに書けるような言語は一見いいのだが 人間が生まれ持って自堕落であるのを伴って 最終的には苦しみをもたらすことになるコードを書いてしまう >>420 も煽りのつもりで普段書いてないrustを イキって書いたんだろうけど 煽り返された上にクソコードが掲示板に一生残るのは辛いよなあ いきなり unsafe fn とか書いてるあたり普段からrust書いるが競プロとかでついた変な癖を引きずってる人だと思う 余計悪いが >>437 ゴミカスコード力を披露するコードだよ Rustどうこう言うやつはこのレベルが多い 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; } isize ってどういう時に使います? 添字は基本的に usize しか使いませんし符号付き整数が欲しくなったらi32かi64で大体事足りるのでいまいち使い所が分かってません 添え字に使う値を算出する途中計算で負数が必要になったら isize が妥当という場合もある。 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 意識高い系がウンコードを量産し罵倒するクソスレ そして、その結果、as usize祭りにもなる場合もある >>432 経験的に縛れば縛るほど脱法行為が横行する。 RustlingsをReplitで動かして学習したいのですが、これってrustlingsコマンドはどうやって動かすのですか? https://github.com/rust-lang/rustlings 公式サイトが用意しているReplitの環境で学習をやりたいのです よろしくお願いします >>446 ReplitのRustのバージョンが古くて(1.44)ビルド失敗するっぽい 見た感じローカルでやるのとそんな変わらん気がするから、 こだわりないならローカルでやるのが吉 この環境ビルドむっちゃくちゃ遅いし >>439 なぜそんなに下手なの? 配列のインデックスを取り出して配列をアクセスしてるだけなら そのインデックスは最初からusize型にしておくだけてしょ >>445 脱法行為もなにも>>420 のコードで負のindex渡されたらおかしくなるやんけ とはいえ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を使っていろいろやる) } 競技プログラミングは 正しいプログラミングスタイルから離れていく悪です 競技プログラミングスタイルな人と一緒に開発したい人は存在しないでしょう 正当なスタイルが分かった上で競技としての割り切り方も分かっているなら問題ないんだけど、 競技から学ぶと変な癖が付きやすいというのは私も感じるなぁ。 >>441 off_tとかptrdiff_tの代わり 例えば <*const T>::offset なんかはisizeを引数に取る >>450 自分はだいたい座標やwidth/heightはi32で扱って indexへの変換処理を関数に抽出してそこでusizeに変えてる 一次元配列に二次元データ入れるときも自然に書ける 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は使わなくて良い箇所なら使わない。 >>450 let mut test = 100_usize; アンダースコア使うと読みやすいぞ。おぬぬめ winitのmasterでstdwebのサポートが切られてweb_sysに一本化されていた stdwebってオワコンになりつつあるのかな? >>455 NonZeroはOptionとかのサイズ最適化やポインタの値がnullでないことを示すのが主目的なので 汎用的な範囲を組み込み型で示すのはちょっと違うかと 必要ならnewtypeパターンで自分で作ればよい 配列がusizeなのはpythonなんかのa[-1]の最後尾アクセスを見てると、なぜそんな言語仕様にしたのかと off_tなんかを見ると不思議に思う。いずれも Index bounds checkが掛るのに。符号無し64bitの巨大な 配列が欲しかったから?でもi128とかあるし インデックスiが実行時に決まるとき 配列のアクセスを内部的には *(p + i) にしたかったからじゃないかな マイナスのとき〜っていう分岐をそこに入れずに最速でアクセスしたかったと >>459 >符号無し64bitの巨大な配列が欲しかったから? 配列にマイナスの値は使わないんだから、そのぶんMAXの数を増やしたほうが オーバーフローしにくいから安全だろってことらしい でもどうせi32 as usizeとかi64 as usizeするから意味ないんですけどね! >>459 32bit環境だとisizeにするとbyte配列が2GBくらいしか扱えないからじゃないのかね ついでに一応16bit環境もサポートしてるみたいだし 競プロの書き方を仕事でするわけないだろ 何言ってるんだ アホか 競プロと仕事、書いてる時間がどっちが長いと思ってる 競プロは趣味 仕事で書いてるほうが圧倒的に長い 競プロでの書き方が仕事に引きずられることがあっても逆はない そういうヤツがいるとか嘘をついてまで、 競プロに難癖つける理由がまったく理解できんわ お前が競プロスタイルで仕事するかどうかの話じゃないし、競プロに難癖つけてもいない 競プロRustスレを専用に立てて分離するのがベストな解決かな。 大多数を占める普通のRustプログラミングをする人たちにとっては役に立たない、特殊な競プロのコーティング方法が書かれても、批判議論に陥りがちでお互いにメリットないと思うのです。 難癖つけてるだろ > 競技プログラミングは > 正しいプログラミングスタイルから離れていく悪です からの流れだからな >>470 それ自体は合ってますよ。 もちろん各々を使い分けられる人もいるでしょう。 でもそれはその人個人の内部の話。 競プロなプログラミングスタイル自体は、正しいプログラミングスタイルから乖離しています。 なんで競プロの話になってるんですか? usizeをasしまくるのが競プロってこと? >>472 グローバル変数を用いたりunsafeを闇雲に利用している点 >>462 >>465 その一緒に仕事してるという競プロの人は、どんな困った記述してるんですか? 参考までにコードを晒してくれると助かる まさか仕事でグローバル変数やunsafeを闇雲に使ってるわけじゃないですよね? 闇雲にunsafeを使うどころか脳死で全部の関数unsafeにする勢いだからな asはみるけどunsafeは競プロじゃめったにお目にかかれないような これ初めて知ったんだけど Webブラウザサイド(フロントエンド)もRustで書けるのね html!マクロでRustソースの中にHTMLもそのまま書けて更にその中にRustコードが書けてReact.jsのJSXみたいな感じね https://yew.rs/ja/ Yew は WebAssembly によってマルチスレッドなWebアプリのフロントエンドを作ることができる、モダンな Rust のフレームワークです。 alert使うだけでunwrap使うwebsysは使いたくない unwrapはそこらじゅうのサンプルで見かけるが、Rustクックブックでは、unwrapを許可していません。 こういう事も敷居が高い理由です ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.1 2024/04/28 Walang Kapalit ★ | Donguri System Team 5ちゃんねる