- 1 名前：デフォルトの名無しさん [2024/02/23(金) 17:37:52.13 ID:CheDQupm.net]
- 公式
https://www.rust-lang.org/
https://blog.rust-lang.org/
https://github.com/rust-lang/rust
公式ドキュメント
https://www.rust-lang.org/learn
Web上の実行環境
https://play.rust-lang.org
※Rustを学びたい人はまず最初に公式のThe Bookを読むこと
https://doc.rust-lang.org/book/
※Rustを学ぶ際に犯しがちな12の過ち
https://dystroy.org/blog/how-not-to-learn-rust
※Rustのasyncについて知りたければ「async-book」は必読
https://rust-lang.github.io/async-book/
※次スレは原則>>980が立てること
前スレ
Rust part22
https://mevius.5ch.net/test/read.cgi/tech/1705760500/
ﾜｯﾁｮｲスレ
プログラミング言語 Rust 4【ﾜｯﾁｮｲ】
https://mevius.2ch.net/test/read.cgi/tech/1514107621/
- 142 名前：デフォルトの名無しさん [2024/02/27(火) 12:18:37.87 ID:Q3TDZDiV.net]
- >>136
*selfはそれでいいけど、**selfはそれじゃ説明付かんぞ
- 143 名前：デフォルトの名無しさん mailto:sage [2024/02/27(火) 17:59:37.59 ID:KfBq61Mu.net]
- >>139
&T→Tと同じでBox<T>に対する*演算子もコンパイラビルトインだからDerefのimplは使われない
- 144 名前：デフォルトの名無しさん mailto:sage [2024/02/27(火) 18:12:58.39 ID:lr8nToMg.net]
- Rustってなんでzipを「簡単」に操作するクレートが一つもないんだ？
Tauriがこなれてきたからそろそろ.NETからアプリをRustにポーティングしようかなと思ったらエコシステムがまるで成長していない・・・
- 145 名前：デフォルトの名無しさん mailto:sage [2024/02/27(火) 18:13:56.86 ID:7nYMkiDR.net]
- >>133
まず基本を理解しよう
deref coreceは必ず参照から参照へのみ起きる
Box自体は当然deref coreceされない
その例だと
let b = Box::new("Hello".to_string());
まずc0は単なるBox参照
let c0: &Box<String> = &b;
このc1とc2がderef corece
let c1: &String = &b;
let c2: &str = &b;
そのc1とc2を明示的に書くとこうなる
let c1: &String = &**(&b);
let c2: &str = &**(&**(&b));
この暗黙に適用される&**がderef corece
この自動適用のおかげでstrのメソッドが使える
assert!(b.starts_with("He"));
フルに書くとこうでもちろん対象はbではなく&b
assert!(str::starts_with(&b, "He"));
この&bが前述の通り自動的に&**(&**(&b))となり&str型へcoreceされている
- 146 名前：デフォルトの名無しさん mailto:sage [2024/02/27(火) 18:33:30.42 ID:p5E54fv2.net]
- >>141
圧縮アーカイブならzipクレート
圧縮ならlibflateクレートなど
- 147 名前：デフォルトの名無しさん [2024/02/27(火) 19:01:36.79 ID:MCZ6xJKz.net]
- >>133
＞ coercion
横から素人がすまん、これ何て読めばいいの？
- 148 名前：デフォルトの名無しさん mailto:sage [2024/02/27(火) 19:26:56.87 ID:kSGISY6y.net]
- Rustもちょっと前の熱狂はなくなってしまった感じ
入込数が減ってると思う
- 149 名前：デフォルトの名無しさん [2024/02/27(火) 19:39:57.60 ID:ptyRkm62.net]
- まあ熱狂系の人は実用言語嫌いそうだし、熱狂系がいなくなったのは良いことでは
- 150 名前：デフォルトの名無しさん mailto:sage [2024/02/27(火) 19:51:34.77 ID:gLAGJv50.net]
- >>144
発音[US] kouə́ːrʒən ｜ [UK] kouə́ːʃən
カナ[US]コウアァジョン、[UK]コウアーション
参考：https://eow.alc.co.jp/search?q=coercion
自分はコアジョン派
- 151 名前：デフォルトの名無しさん mailto:sage [2024/02/27(火) 20:18:10.37 ID:p5E54fv2.net]
- >>144
コアーション派
- 152 名前：デフォルトの名無しさん [2024/02/27(火) 20:23:00.40 ID:20aYglde.net]
- >>147
サンクス。愛してる
- 153 名前：デフォルトの名無しさん mailto:sage [2024/02/27(火) 21:54:58.65 ID:Tx+RemT0.net]
- Tのスマートポインタの参照 -> Tの参照
文字の配列の参照 -> 文字のスライス
一連の流れを見るとみんなポインタに熱狂している
- 154 名前：デフォルトの名無しさん mailto:sage [2024/02/27(火) 22:22:03.42 ID:TDjpaGuA.net]
- >>150
そこはポインタと参照の根本的な違いを理解しできるかどうかかな
「Boxというスマートポインタ」の参照を扱うから意外に感じているのかもしれないが
「Boxというスマートポインタ」はヒープ領域の解放責任つまり所有権を持つ
したがってBox自体を他の関数などへ渡してしまってはmoveしてしまい継続して使えなくなる
だからスマートポインタの参照を渡すことになる
一見するとこれはポインタのポインタで無駄な間接参照に感じるかもしれない
しかし参照＝ポインタではなく参照は抽象的なものなのだ
- 155 名前：デフォルトの名無しさん mailto:sage [2024/02/27(火) 22:43:38.35 ID:NfALWDmT.net]
- Rust の参照は借用規則に関わることを除けばポインタとそんなに差はないし普通にオブジェクトの一種なんだよな。
C++ の参照はオブジェクトではなく参照の参照もとれないし参照のポインタもないし、
参照のサイズも取得できないというのに比べたら Rust の参照は実体のあるものとして感じられてしまう。
- 156 名前：デフォルトの名無しさん mailto:sage [2024/02/27(火) 22:57:53.18 ID:FQe9Y4YD.net]
- その橋渡し役がDeref coercion
&Box<T>はそのままだとTのポインタを持つBoxへのポインタとなってしまうが
Box<T>→TのDerefがあるため
&Box<T>→&TとDeref coercionが適用できる
静的にコンパイル時点で行われるため実行時コストはかからない
- 157 名前：デフォルトの名無しさん mailto:sage [2024/02/27(火) 23:09:15.00 ID:xLBlGeUv.net]
- >>142
この辺り最初理解するまで訳分からんかったな
理解すると大したことはないのだが
- 158 名前：デフォルトの名無しさん mailto:sage [2024/02/27(火) 23:37:04.57 ID:IkmURqSK.net]
- >>142
>deref coreceは必ず参照から参照へのみ起きる
&**との違いを認識してもらうための例を出したんだけど伝わらなかったみたいだね
それは別にいいんだけど書いてる内容を見る限り
Deref Coercionの動きを単に擬似的に再定義しようとして&**になると言ってるだけじゃなく
実際に&**が適用されると思ってるみたいに感じるね
だとしたらそれは完全な間違い
derefの実装の中で*演算子が使われることはあってもDeref Coercion自体は*演算子とは関係ないんだよ
Boxのderef実装だって*演算子を使わずself.ptr.as_ref()的な実装で実現してもいいわけだし
- 159 名前：デフォルトの名無しさん mailto:sage [2024/02/27(火) 23:45:58.16 ID:Tx+RemT0.net]
- とにかく、間接参照から直接参照を得る演算の名前はderefでいいんだよね
- 160 名前：デフォルトの名無しさん mailto:sage [2024/02/27(火) 23:58:10.03 ID:cJjIIFX3.net]
- Derefは*
Deref coercionは&**
前者は明示が必要な点が違い
x: &Box<T> とすると
*x: Box<T> (by Deref &T→T)
**x: T (by Deref Box<T>→T)
&**x: &T (xのDeref coercion結果)
x: &Vec<T> とすると
*x: Vec<T> (by Deref &T→T)
**x: [T] (by Deref Vec<T>→[T])
&**x: &[T] (xのDeref coercion結果)
x: &String とすると
*x: String (by Deref &T→T)
**x: str (by Deref String→str)
&**x: &str (xのDeref coercion結果)
- 161 名前：デフォルトの名無しさん mailto:sage [2024/02/28(水) 00:29:07.11 ID:ZZ90UZAT.net]
- >>157
とりあえずDerefの定義が
pub trait Deref {
type Target: ?Sized;
// Required method
fn deref(&self) -> &Self::Target;
}
（https://doc.rust-lang.org/std/ops/trait.Deref.html）
でderef()の戻り値には自動的に&がつくから
*x: Box<T>
*x: Vec<T>
*x: String
はDeref traitと関係ないことを抑えておこう
そこに（by Deref…）を書かれると話がおかしくなる
*Tができることの一部をDeref traitではできない
正確な表現かは分からないけどDerefは&の向こう側でしか*を適用できない
- 162 名前：デフォルトの名無しさん mailto:sage [2024/02/28(水) 00:41:03.68 ID:PK7EwTQ6.net]
- こうだろ
x: &Box<T> とすると
*x: Box<T> (by Dereference)
**x: T (by Deref Box<T>→T)
&**x: &T (xのDeref coercion結果)
x: &Vec<T> とすると
*x: Vec<T> (by Dereference)
**x: [T] (by Deref Vec<T>→[T])
&**x: &[T] (xのDeref coercion結果)
x: &String とすると
*x: String (by Dereference)
**x: str (by Deref String→str)
&**x: &str (xのDeref coercion結果)
- 163 名前：デフォルトの名無しさん mailto:sage [2024/02/28(水) 00:49:10.38 ID:ZZ90UZAT.net]
- なんかゲシュタルト崩壊してきたんだがｗ
関係ないけど微積のdxとかdyを思い出してしまった
- 164 名前：デフォルトの名無しさん mailto:sage [2024/02/28(水) 01:22:37.90 ID:0HAFGBLs.net]
- C/C++書いてる者からすると勝手に変換してくれて楽ちんだなあって感じ
- 165 名前：デフォルトの名無しさん mailto:sage [2024/02/28(水) 01:32:01.63 ID:upo0sX/6.net]
- Deref coercion &**のうち
右側の*は参照に対する参照外しで
左側の*はDerefで定義(実装)されてるものなのね
- 166 名前：デフォルトの名無しさん mailto:sage [2024/02/28(水) 04:46:46.07 ID:EOw65cJZ.net]
- let s = String::from("xyz");
let x: &str = &s;
let x: &str = &&s;
let x: &str = &&&s;
これ全てコンパイル通ってderef coercionされるから
『by Deref &T→T』も適用されていると思うぞ
- 167 名前：デフォルトの名無しさん [2024/02/28(水) 11:30:56.58 ID:eNJqE6SH.net]
- >>163
&&T→&Tのことを&T→Tとは書かないわな
前者の用途にDeref for &Tは存在してる
- 168 名前：デフォルトの名無しさん mailto:sage [2024/02/28(水) 17:44:48.30 ID:8gSKFNHr.net]
- >>156
演算の名前はdereference
derefはDerefトレイトに定義してあるメソッドの名前
>>157
>Derefは*
違う
Derefはトレイト
*はdereference operator
>Deref coercionは&**
違う
Deref Coercionとはcoercionが行われる場合に「&Tを&<T as Deref>::Target」にcoerceすること
Deref Coercionと*などの演算子は全く別の独立したものとして扱われている
それぞれの処理の一部で必要に応じてDerefに定義されたderefメソッドを活用してるというだけ
片方がもう片方に依存してたりもしない
Deref Coercionの処理の一部として呼び出されるderefメソッドを
演算子で擬似的に再定義しようとすれば&**になるというの話はかろうじて理解できるが
前述のように定義が循環してるだけでなく再定義する価値を見いだせない
- 169 名前：デフォルトの名無しさん [2024/02/28(水) 18:08:21.49 ID:8fminEVJ.net]
- なるほどね。勉強になるわ。
- 170 名前：デフォルトの名無しさん mailto:sage [2024/02/28(水) 18:17:32.89 ID:8gSKFNHr.net]
- >>164
&&T→&Tの場合もreference用のビルトインderefが先に動いてDeref for &Tの実装コードは動いてない可能性ない？
- 171 名前：デフォルトの名無しさん mailto:sage [2024/02/28(水) 18:20:50.27 ID:nghz9NTX.net]
- >>164
Deref coercionの定義を理解しよう
Deref T→Uが実装されている時に
(つまり*TがUとなる時に)
&T→&UのDeref coercionが自動適用される
&String→&str (by Deref String→str)
&Vec<T>→&[T] (by Deref Vec<T>→[T])
&Box<T>→&T (by Deref Box<T>→&T)
&&T→&T (by Deref &T→T)
これらはすべてDeref coercion
- 172 名前：デフォルトの名無しさん mailto:sage [2024/02/28(水) 18:22:38.09 ID:nghz9NTX.net]
- >>165
Deref T→Uが実装されている時に
(つまり*TがUとなる時に)
&T→&UのDeref coercionが自動適用される
U＝*T
↓ &Tから出発すると
U＝**(&T)
↓ 両辺の参照をとると
&U＝&**(&T)
つまり
Deref coercionとは&**の自動適用のこと
- 173 名前：デフォルトの名無しさん mailto:sage [2024/02/28(水) 18:49:11.26 ID:T3/1RdIi.net]
- *xが左辺値なら代入、*xが右辺値なら複製とかいう演算に
ビルトインderefみたいな名前をつけるのが間違っている
- 174 名前：デフォルトの名無しさん mailto:sage [2024/02/28(水) 19:13:20.58 ID:fjfA+uEG.net]
- >>170
mutabilityを除けば左右どちらも同じ型だから形が同じであることは問題ない
左はmutabiltyが必要だからderefではなくderef_mutと区別されていてその点でも問題ない
- 175 名前：デフォルトの名無しさん mailto:sage [2024/02/28(水) 20:06:21.19 ID:ZLPgyFVM.net]
- 判りにくい仕組みだけどこれから開発が進むと
文法変えたりするのかな？
- 176 名前：デフォルトの名無しさん mailto:sage [2024/02/28(水) 20:12:51.73 ID:eWXh2LH7.net]
- これほど分かりやすくて便利な明確な仕組みはない
他の言語と比較すれば明らか
- 177 名前：デフォルトの名無しさん mailto:sage [2024/02/28(水) 21:00:40.37 ID:ZLPgyFVM.net]
- これが分かりやすいと思ってる人間には聞いてないよ
- 178 名前：デフォルトの名無しさん mailto:sage [2024/02/28(水) 21:10:22.04 ID:RYfxXFlC.net]
- 他の言語でこれより良いものが存在しないね
RustのDeref
・自動適用されプログラマーの負担を軽減し利便性も良い
・魔法ではなくtrait Derefの実装に基づき動作して分かりやすく自作の型にも適用可能
・コンパイル時に静的に解決され実行時の付加コストゼロで高速動作
- 179 名前：デフォルトの名無しさん mailto:sage [2024/02/28(水) 23:39:05.31 ID:T3/1RdIi.net]
- >>172
Pythonが分かりやすいのは知ってるけど
RustとPythonは両極端だから文法を微調整してもしょうがない
文法を変える必要があるのは両極端を否定する言語だけだ
- 180 名前：デフォルトの名無しさん mailto:sage [2024/02/28(水) 23:49:09.85 ID:ZZ90UZAT.net]
- Derefなのに&が消えてない（小並感）
背景を理解しないと引っかかりやすいRustの七不思議候補
- 181 名前：デフォルトの名無しさん [2024/02/29(木) 01:04:43.74 ID:rccXx8PF.net]
- この仕組みがベストであるという主張は3種類ある
一つは馬鹿な信者が言ってるだけという可能性
一つは本当にこの仕組みがベストである可能性
最後は信者ではないけど素直な馬鹿だからもっと良い仕組みを知らない可能性
このどれであるかは賢い人間がもっと良い仕組みを教えてあげると判別できる
馬鹿な反論が返ってきたら馬鹿な信者
合理的な反論が返ってきたら本当にこの仕組みがベストかもしれない
意見を翻されたら素直な馬鹿
- 182 名前：デフォルトの名無しさん mailto:sage [2024/02/29(木) 01:16:58.91 ID:s7mEAt1S.net]
- この仕組みがない方が良いということ？
下手で全部書くべきと？
- 183 名前：デフォルトの名無しさん mailto:sage [2024/02/29(木) 01:51:37.80 ID:zTVrVDmh.net]
- RustのDerefとそのcoercion枠組みの利点
・プログラマーの負担が減る
・コードが見やすくなる
・枠組みはDerefトレイト利用で明白かつ汎用的になっている
・自分で作った型にも実装して作動させることができる
・静的に解決しているためミスしてもコンパイル時にわかる
・実行時に付加的な動作がなく高速に実行される
これらの利点を上回る方法があるならば知りたい
既存の言語でも新規の方法でも
- 184 名前：デフォルトの名無しさん [2024/02/29(木) 03:43:48.10 ID:JSOAwYd/.net]
- https://manishearth.github.io/blog/2017/01/10/rust-tidbits-box-is-special/
Boxのまほう
- 185 名前：デフォルトの名無しさん [2024/02/29(木) 10:19:46.23 ID:IetxPnTw.net]
- >>179
>下手で全部書くべきと？
どこかの方言？
- 186 名前：デフォルトの名無しさん mailto:sage [2024/02/29(木) 12:07:39.99 ID:/e0OxROz.net]
- >>178
いずれにせよRust信者は自分の信仰を他人に押し付けるために検証可能性を潰すから、科学とはほど遠い姿勢かと。
- 187 名前：デフォルトの名無しさん mailto:sage [2024/02/29(木) 12:33:18.56 ID:sM99e4qp.net]
- Rustの方式の利点は>>180に挙げられているから
もしRustより良い言語が存在するならば
その方式およびRustの利点を上回る利点を挙げればいいんじゃね？
- 188 名前：デフォルトの名無しさん [2024/02/29(木) 12:41:20.92 ID:JSOAwYd/.net]
- そんなに比較したいならﾜｯﾁｮｲスレ行けばいいんじゃね？
https://mevius.5ch.net/test/read.cgi/tech/1701997063
- 189 名前：デフォルトの名無しさん mailto:sage [2024/02/29(木) 13:11:40.55 ID:WGw1+Mi1.net]
- 検証可能とはコンパイラが無謬であることではない
ここが難しい
コンパイラが未完成の状況でも人間が正解の一部をなぜか知っていること
これが検証可能
- 190 名前：デフォルトの名無しさん mailto:sage [2024/02/29(木) 14:11:14.15 ID:s7mEAt1S.net]
- >>182
この仕組みがない方が良いということ？
- 191 名前：デフォルトの名無しさん mailto:sage [2024/02/29(木) 14:14:12.31 ID:s7mEAt1S.net]
- 単に理解できないから難癖つけてるだけだよねこの人
自分の主張も一切ないし
- 192 名前：デフォルトの名無しさん mailto:sage [2024/02/29(木) 14:15:14.41 ID:s7mEAt1S.net]
- 誰かの難癖を自分が思い付いたかのように言ってるだけで
何一つまともな批判はない
- 193 名前：デフォルトの名無しさん mailto:sage [2024/02/29(木) 14:15:53.86 ID:s7mEAt1S.net]
- 全く相手にすべき人間ではないと判断する
よって今後無視する
- 194 名前：デフォルトの名無しさん [2024/02/29(木) 14:45:30.61 ID:NVSKcdtL.net]
- >>184
それは「批判するなら代案出せ」と同じ議論を潰すだけの態度なのでやめよう
技術者なら自分が使っている道具の限界や弱点とは真摯に向き合うべき
その際他の道具との比較も必須ではない
- 195 名前：デフォルトの名無しさん [2024/02/29(木) 14:51:42.06 ID:bXdMb/7T.net]
- 技術的選択は突き詰めれば必ずトレードオフが生じるもの
利点だけを見て欠点に目をつぶったまま良し悪しを論じるのは愚の骨頂
- 196 名前：デフォルトの名無しさん mailto:sage [2024/02/29(木) 14:52:32.46 ID:sM99e4qp.net]
- Rustの方式の利点は>>180に挙げられているから
もし仮にRustより良い言語が存在するならその言語の方式の利点を挙げればいいんじゃね？
- 197 名前：デフォルトの名無しさん [2024/02/29(木) 15:05:04.64 ID:Sa1lr1bM.net]
- >>191
>それは「批判するなら代案出せ」と同じ議論を潰すだけの態度なのでやめよう
議論を潰すというよりも批判から逃げたいだけだろう
- 198 名前：デフォルトの名無しさん mailto:sage [2024/02/29(木) 17:17:49.66 ID:WGw1+Mi1.net]
- 物的な代案や物的証拠により人の心を折ることが検証だと思っているんじゃないか
- 199 名前：デフォルトの名無しさん [2024/02/29(木) 17:44:22.90 ID:JSOAwYd/.net]
- や、そもそも「人の心」の認識が無いのだろう
- 200 名前：デフォルトの名無しさん mailto:sage [2024/02/29(木) 18:01:07.55 ID:OWFCi11w.net]
- わざわざRustスレにまでやって来てRust叩きやってる人だから心の病気なのかもな
- 201 名前：デフォルトの名無しさん mailto:sage [2024/02/29(木) 18:25:15.72 ID:uwbVoB9N.net]
- >>167
>&&T→&Tの場合
これ調べてみたんだけどビルトインderefが優先的に動いて
Deref for &Tの実装は使われてなかった
- 202 名前：デフォルトの名無しさん mailto:sage [2024/02/29(木) 18:37:38.45 ID:OsB1rmqt.net]
- ビルトインは*を明示指定しないといけなくない？
coercionは何も指定しなくてもDeref実装があれば自動的に多段に適用してくれるけど
- 203 名前：デフォルトの名無しさん mailto:sage [2024/02/29(木) 20:49:33.50 ID:NE3ms/ho.net]
- impl Deref for &T
はtrait境界を満たすためだけに定義されてるんだろうな
標準だとDeref境界はPinくらいしか使ってないけど
- 204 名前：デフォルトの名無しさん mailto:sage [2024/02/29(木) 23:55:24.58 ID:uwbVoB9N.net]
- >>199
*演算子のときもDeref CoercionのときもビルトインderefがDeref::derefよりも優先して使われるよ
- 205 名前：デフォルトの名無しさん mailto:sage [2024/03/01(金) 08:46:23.47 ID:SBTwWOM0.net]
- derefの仕方は状況によって使い分けかな
例えばVec<T>からスライス&[T]にする場合
// deref operatorを使う方法
// 一番短く頻出
let slice = &*vec;
// RangeFull Indexを使う方法
// Rangeを変えて汎用的に範囲指定ができるメリット
let slice = &vec[..];
// deref coercion先の型を明示する方法
// 関数呼び出しは引数の型が明記されてるのでこのパターン
let slice: &[T] = &vec;
// deref()メソッドを使う方法
// ただしDerefトレイトのuseが必要
use std::ops::Deref;
let slice = vec.deref();
- 206 名前：デフォルトの名無しさん mailto:sage [2024/03/01(金) 09:18:59.78 ID:LWQ/+31h.net]
- uv、めちゃ速いな
今までの処理時間はなんだったのか
これはRustの印象を良くするツールになるわ
- 207 名前：デフォルトの名無しさん mailto:sage [2024/03/01(金) 10:14:36.96 ID:gvn/awFT.net]
- uvというとCで書かれた非同期マルチプラットフォームライブラリ(Rustにはmioがある！)が有名だが
そのuvはRust製のPythonパッケージマネージャーなのか
- 208 名前：デフォルトの名無しさん mailto:sage [2024/03/01(金) 11:06:37.60 ID:C9bgbnyF.net]
- 速さの定義はわかりやすさの定義よりもわかりやすい
- 209 名前：デフォルトの名無しさん mailto:sage [2024/03/01(金) 16:15:12.75 ID:lzR4RBgp.net]
- JavaScriptでも遅いBabelを速いSWC(Rust製)に換えると爆速
- 210 名前：デフォルトの名無しさん mailto:sage [2024/03/01(金) 19:02:46.24 ID:I+/u+ffT.net]
- Pythonの管理ツールまたなんか出たの！？という気分
- 211 名前：デフォルトの名無しさん mailto:sage [2024/03/02(土) 00:14:54.94 ID:F+x2UUkM.net]
- uvはPython版のcargoを目指しているらしい
- 212 名前：デフォルトの名無しさん [2024/03/02(土) 16:13:07.16 ID:bMlzFBHT.net]
- nvidiaのど汚なさを理解してなさげで不安しかないわ
- 213 名前：デフォルトの名無しさん mailto:sage [2024/03/05(火) 04:09:58.03 ID:n3bQlkHC.net]
- RustでDB使う時の定番ライブラリって何ですか？
- 214 名前：デフォルトの名無しさん [2024/03/05(火) 04:14:48.62 ID:nMHII26b.net]
- ORMが好きならdiesel
ORMが嫌いならsqlx
- 215 名前：デフォルトの名無しさん mailto:sage [2024/03/05(火) 06:15:07.43 ID:Uplx2IYd.net]
- >>211
それRDBじゃん
- 216 名前：デフォルトの名無しさん mailto:sage [2024/03/05(火) 11:41:51.93 ID:6drsihdZ.net]
- RDBじゃないDBの定番とか聞かんだろJK
- 217 名前：デフォルトの名無しさん mailto:sage [2024/03/05(火) 12:54:04.64 ID:iKkb/Eo4.net]
- RDBMSが定番だからね。
- 218 名前：デフォルトの名無しさん mailto:sage [2024/03/05(火) 23:56:12.66 ID:blmx074I.net]
- 最近RDB以外のDBの存在を知った人にありがちな反応だよな
- 219 名前：デフォルトの名無しさん mailto:sage [2024/03/07(木) 15:14:21.16 ID:/no0RfP4.net]
- Rustで一通り文法や機能紹介した入門書の次に読むような定石本ってどのようなのがありますか？C++でいうEffective C++みたいな
- 220 名前：デフォルトの名無しさん mailto:sage [2024/03/07(木) 15:28:53.82 ID:5c4tHUTp.net]
- しゃぶれよ
- 221 名前：デフォルトの名無しさん mailto:sage [2024/03/07(木) 17:13:51.21 ID:NLgNYFMG.net]
- >>216
Rust for Rustaceans
- 222 名前：デフォルトの名無しさん [2024/03/10(日) 13:14:05.30 ID:XsimGsv7.net]
- Rustはデフォルトのhashが遅いという罠
- 223 名前：デフォルトの名無しさん mailto:sage [2024/03/10(日) 20:35:08.28 ID:8NU5B5F+.net]
- >>219
Rustはデフォルトのハッシュ関数が最強最善の暗号学的ハッシュ関数であるSipHashを採用しているため衝突にも強くハッシュDOS攻撃に対しても安全
もし強い衝突耐性を必要としない用途ならばFxHasherなどの速さ重視のハッシュへと簡単に置き換えられる
type Hasher = std::hash::BuildHasherDefault<FxHasher>;
let mut map = HashMap::<Foo, Hasher>::default();
- 224 名前：デフォルトの名無しさん mailto:sage [2024/03/10(日) 20:38:28.49 ID:8NU5B5F+.net]
- こうね
HashMap::<Key, Value, Hasher>
- 225 名前：デフォルトの名無しさん [2024/03/10(日) 21:21:36.22 ID:yMMzzxd+.net]
- 解決案としてはそうなのだが、デフォルト挙動が罠すぎる
デフォルトいらなかったのでは
- 226 名前：デフォルトの名無しさん mailto:sage [2024/03/10(日) 21:26:04.39 ID:hwVh1yHa.net]
- Rustは利用者はアホだと思ってる
だから徹底的に厳しくしてくる
- 227 名前：デフォルトの名無しさん mailto:sage [2024/03/10(日) 21:33:53.98 ID:hwVh1yHa.net]
- 雨が降ってなくても傘を持つように言って来て外出すらさせてくれない
- 228 名前：デフォルトの名無しさん mailto:sage [2024/03/11(月) 00:11:06.91 ID:H3LWtGm6.net]
- デフォルトのハッシュ関数が遅くて困るってことはよく知らずに使ってたってことでしょ？
そう考えると初心者向けにデフォルト厳しくしておくのは正解な気がするわ、セキュリティに関わるし
まあ言語側はそんな事考えずにとにかく一番スタンダードなものデフォルトにしろって考え方もわかるが
- 229 名前：デフォルトの名無しさん mailto:sage [2024/03/11(月) 00:47:18.65 ID:2r+51Qz1.net]
- Rustはimpl std::hash::Hasherで必要なら自由に独自のハッシュ計算器をすぐ作れるし
逆にそれと独立にimpl std::hash::Hashで自分の各型に対してハッシュ計算法を指示できるし
この2種類のトレイトを標準で用意してくれているRustは非常に好環境
- 230 名前：デフォルトの名無しさん mailto:sage [2024/03/11(月) 00:59:26.53 ID:lga6QF6v.net]
- 「最悪の場合でもほどほど」なやつをデフォルトにするのは妥当だと俺も思う。
状況に合わせて選択できたり自分で作れたりする人はそうするんだから、
デフォルトではそうでない人を想定するだろ。
- 231 名前：デフォルトの名無しさん [2024/03/11(月) 02:43:53.87 ID:aDyedTxf.net]
- いやそもそもデフォルトいらんくね？
なんでデフォルト欲しいんだ？
- 232 名前：デフォルトの名無しさん mailto:sage [2024/03/11(月) 11:06:00.19 ID:WfvY/WS3.net]
- 掃除機はAI搭載して吸ってはいけないものを吸ったら止まってくれよ
- 233 名前：デフォルトの名無しさん mailto:sage [2024/03/11(月) 11:06:34.84 ID:WfvY/WS3.net]
- 誤爆した！
- 234 名前：デフォルトの名無しさん mailto:sage [2024/03/11(月) 14:30:36.32 ID:emAmKvKR.net]
- デフォルトを用意するかしないかは言語思想によるから正解不正解では語れないよな
rustの場合は何事も「安全」に基づいて設計されてると認識してる
- 235 名前：デフォルトの名無しさん [2024/03/11(月) 15:25:18.07 ID:WOvDUzj/.net]
- 適切なハッシュ関数を選択するのってそんな簡単なことじゃないからな
ハッシュ関数の特性だけじゃなくhashbrownの特性も知らないといけないしその両方を組み合わせた際のハッシュDoS耐性の程度も評価できないといけない
HashMapのように基本的なデータ構造を使うのにどんな場合でもいちいちユーザーがその選択しなきゃいけないようだと辛すぎるわな
- 236 名前：デフォルトの名無しさん mailto:sage [2024/03/11(月) 19:01:47.22 ID:srElBTmD.net]
- HashMapで使われるHashに重いものを使う必要がある局面は限られてる
でも他人のライブラリの外から必要な時にハッシュアルゴリズムを変えることなんかできないので悩ましい人もいるだろう
- 237 名前：デフォルトの名無しさん mailto:sage [2024/03/11(月) 20:05:38.98 ID:3y0FGSJo.net]
- 僕が美少女とセックスするためのプログラムはRustで作れますか
- 238 名前：デフォルトの名無しさん mailto:sage [2024/03/11(月) 21:13:52.07 ID:2r+51Qz1.net]
- >>233
ライブラリを作成する時にその用途に応じた適切なハッシュを用いればよい
用途により異なるならば安全側に倒すか指定する方法を提供すればよい
- 239 名前：デフォルトの名無しさん mailto:sage [2024/03/11(月) 21:28:56.93 ID:vmVry2mm.net]
- とりあえずデフォルトを使って、必要になったら差し替えればいいんじゃないの？
Rustだとなんか問題あるんだっけ？
- 240 名前：デフォルトの名無しさん [2024/03/11(月) 21:31:16.84 ID:aDyedTxf.net]
- >>236
ライブラリのハッシュを差し替えられない
デフォルトハッシュを使うような人間がどんどん参戦してきてcratesの名前空間を埋め尽くしていく
- 241 名前：デフォルトの名無しさん mailto:sage [2024/03/11(月) 21:41:07.80 ID:6xtSsnXH.net]
- ハッシュ衝突強度安全性が必要かどうかの判断ができない者がRustデフォルトの安全なものを用いることになるのは正しい
そこまで必要としない用途であると判断できた者だけがFxHashなどを用いればいい
RustコンパイラもFxHashを用いている
https://github.com/rust-lang/rustc-hash
- 242 名前：デフォルトの名無しさん [2024/03/11(月) 21:44:11.78 ID:uBu+z/S9.net]
- 安全で高速を名乗ってるくせにライブラリがおっせえ言語だなあ
これ治すにはいちいち依存ライブラリ全てをcloneしてきてチマチマ変更していかないといけないってマジかよ
|
 |
