X

Rust Part7

■ このスレッドは過去ログ倉庫に格納されています
0318デフォルトの名無しさん
垢版 |
2019/09/15(日) 00:25:56.87ID:84ndTw+e
ヌルポチェック境界チェックしてたら遅くなるに決まってるやん
Cはそんなことしなくて済むから爆速な訳で
0319デフォルトの名無しさん
垢版 |
2019/09/15(日) 11:32:00.80ID:iFCAy1qK
絶対にめくれないからパンツいらないスカートで
アスレチックでもスカイダイビングだもなんでもするのがCだわな
0321デフォルトの名無しさん
垢版 |
2019/09/15(日) 12:03:39.49ID:IVfbaIvY
いいねｗ
0324デフォルトの名無しさん
垢版 |
2019/09/15(日) 14:06:50.28ID:JVfSd4XU
風呂でもセックスでもパンツ脱がないのがRustだわな
0325デフォルトの名無しさん
垢版 |
2019/09/15(日) 14:41:05.29ID:CYqvBFjr
スカートも不要なのがC
0328デフォルトの名無しさん
垢版 |
2019/09/15(日) 22:55:46.82ID:IVfbaIvY
Rustはむしろ貞操帯
0331デフォルトの名無しさん
垢版 |
2019/09/16(月) 08:18:42.11ID:jUyoTXTl
何をするにも貞操帯外したり付けたりガチャガチャして複雑になるんだよなあ
0333デフォルトの名無しさん
垢版 |
2019/09/16(月) 08:38:49.73ID:5uT5V90s
そんなふうに考えていた時期が俺にもありました
でも今はderef coercionでハッピーな毎日です
0335デフォルトの名無しさん
垢版 |
2019/09/17(火) 08:51:01.90ID:/BOEHyZy
Tのままでチェックするからこうなるんでu32にしてチェックしていいならそうする
TもCopy + Into<u32>でトレイト拘束するだけですむ
0338デフォルトの名無しさん
垢版 |
2019/09/18(水) 00:07:56.14ID:H2DpgLxy
数年後、Rustの世間的な評価はマクロが濫用されてるからクソ
になってる気がする
0339デフォルトの名無しさん
垢版 |
2019/09/18(水) 08:28:44.98ID:no1kSscq
そりゃ言語拡張性からいったらマクロは最強だよ。
そんなことは30前にlispが示してる。
0342デフォルトの名無しさん
垢版 |
2019/09/18(水) 10:47:59.35ID:pbP4krHb
✗ Rustのマクロが汎用されているからクソ
○ プリプロセッサで単純に置換する不健全なマクロを汎用するからクソ
Rustはまだましなほう
0343デフォルトの名無しさん
垢版 |
2019/09/18(水) 11:34:11.09ID:RM25JK7K
ライブラリで定義するのはいいがプロジェクト内ではレビューの時に面倒だからなるべく書きたくないな
0346デフォルトの名無しさん
垢版 |
2019/09/18(水) 13:41:17.68ID:1cXUqFYA
汎用する？
0347デフォルトの名無しさん
垢版 |
2019/09/18(水) 14:40:03.73ID:5wL1TG3Q
直接依存するクレートのfeatureはdependenciesに記述できますが、依存するクレートが更に依存するクレートのfeatureをセットしたいときはどうすれば良いんでしょうか
0348デフォルトの名無しさん
垢版 |
2019/09/18(水) 15:00:15.00ID:f+hbVZ57
エアプだからよく知らんけど依存クレートが依存x2クレートのfeature使うなら依存クレートのtomlにfeature書いてあるし、
依存クレート経由しないで依存x2クレート使うなら自クレートが直接依存してるわけだから自クレートのtomlにfeature書くだけじゃないの？
0350デフォルトの名無しさん
垢版 |
2019/09/21(土) 23:26:15.34ID:ajCyJ6wo
アホに良いコードは書けないのだ
アホでも書けるとかいう奴は、アホかアホな組織に属してるかその両方かだ

その両方かだ、って一度言ってみたかったんだ
0351デフォルトの名無しさん
垢版 |
2019/09/21(土) 23:27:32.62ID:ajCyJ6wo
書くところ間違ったアホです
0352デフォルトの名無しさん
垢版 |
2019/09/21(土) 23:54:56.27ID:B7P1QhOW
世の中アホが書いたコンパイラの教科書が広く出回っているから紛らわしいな
0354デフォルトの名無しさん
垢版 |
2019/09/22(日) 12:22:35.80ID:OEThTvH6
ajo ← スペイン語で発音しろ
0355デフォルトの名無しさん
垢版 |
2019/09/22(日) 13:20:45.75ID:NWulzMwt
AWK
0356デフォルトの名無しさん
垢版 |
2019/09/25(水) 16:41:02.11ID:GHCxkzpX
ローカル変数を意図的に snake_case じゃなく書きたいんだが、警告を出さない方法ある？
例えば win32 API 関連を扱う時にやはり camelCase がスマートに思えるシーンがあるんだ
0357デフォルトの名無しさん
垢版 |
2019/09/25(水) 16:56:24.39ID:r0+GDB9/
allow(non_snake_case)
を使いたまへ
0358356
垢版 |
2019/09/25(水) 18:23:59.57ID:GHCxkzpX
>>357
怒られなくなりました
ありがとうございます

```
#[allow(non_snake_case)]
pub fn dummy() {
let hWnd = 0;
}
```
0360デフォルトの名無しさん
垢版 |
2019/09/25(水) 18:54:51.99ID:it7hFznu
ノンスネークケースを表す識別子がスネークケースとはいかがなものか。
allow(non_snake_case)
これ自身を
allow(nonSnakeCase)
と書きたいものである
0361デフォルトの名無しさん
垢版 |
2019/09/25(水) 20:08:08.16ID:r0+GDB9/
そんなことって言うけど大事なことだよね
0362デフォルトの名無しさん
垢版 |
2019/09/25(水) 20:21:48.81ID:bkoUXP+/
ErrorやWarningを出力するときにHelpやNoteで解説も出力してくれてすごく助かる
0368デフォルトの名無しさん
垢版 |
2019/09/26(木) 16:03:54.65ID:JiUn+jUB
ジェネリクスとPhantomData使って特定の関数呼んだかとかの条件付けるんならせめてエラーメッセージもちゃんとして欲しい(´・ω・`)
0373デフォルトの名無しさん
垢版 |
2019/09/27(金) 13:19:26.24ID:I3+hYE7s
RustとRの違い

R
データサイエンティストが仕事で使う
言語として結果を出している
速度は残念ながら遅い

Rust
陰キャが気持ちよくなるために使う
実績ナシ
速度は速いらしい（ソース無し）
0374デフォルトの名無しさん
垢版 |
2019/09/27(金) 13:24:28.05ID:bGFj4S5H
R指定
0376デフォルトの名無しさん
垢版 |
2019/09/27(金) 15:06:25.40ID:I3+hYE7s
RubyとRustの違い

Ruby
陽キャのおもちゃ
負債作成の実績がある
遅い

Rust
陰キャのおもちゃ
なにも作られてないので負債も作られていない
さすがにRubyよりは速い
0377デフォルトの名無しさん
垢版 |
2019/09/27(金) 15:10:10.66ID:FRvVNNut
FirefoxのCSSエンジンとかFirecrackerとかDropboxとかnpmとかあるけど見たくないヤツには見えないからなあ
0380デフォルトの名無しさん
垢版 |
2019/09/27(金) 20:01:19.53ID:PO8lPJ5D
dieselなんかこれじゃない感あるなと思ったらアクティブRecord作った人が作ってるのか
代替ないのかね
0385デフォルトの名無しさん
垢版 |
2019/09/29(日) 13:43:42.91ID:FBG2HAFw
人それぞれだと思うんであくまで参考に聞かせて欲しいんだけど
どれくらいのサイズまで#[derive(Copy)]つけます?
0387デフォルトの名無しさん
垢版 |
2019/09/29(日) 16:30:03.01ID:L34oTjKk
所有権の観点からCopy実装してはならないケースはあるだろうけど、
してもしなくてもいい場合に考慮するのはサイズと意味だろ。
サイズに関して言えば、自分はu64の10倍くらいまでって感じ。
0389デフォルトの名無しさん
垢版 |
2019/09/29(日) 19:21:30.01ID:GZbu7mvl
極力付けないな
ぱっと見分かんないから
0390デフォルトの名無しさん
垢版 |
2019/09/29(日) 20:25:18.89ID:FBG2HAFw
いろいろ感謝

よく例題にありそうな
struct Point { x: i32, y: i32 }
みたいなのなら#[derive(Copy)]しても害はないかなと思って聞いてみた
速度を考えてサイズがusizeの3〜4倍ぐらいまでが相場かなと思ったんだけどね
0392デフォルトの名無しさん
垢版 |
2019/09/29(日) 21:03:36.26ID:L34oTjKk
例えば
let x = y;
と
let x = y.clone();
があったときに前者はノーコストで後者は結構重いかもしれないって感覚があると思うけど、
大きなstructにCopyを実装すると前者で大きなmemcpyが発生してびっくりする、という話。
0393デフォルトの名無しさん
垢版 |
2019/09/29(日) 21:26:23.34ID:FBG2HAFw
イメージした状況は違うけどそんな感じ
参照経由で扱いたい大きなデータなのに
うっかりコピーされる状況にしちゃって勝手にコピーされるのはちょっと
でも小さいデータならコピーされてもいい
0394デフォルトの名無しさん
垢版 |
2019/09/29(日) 21:30:49.24ID:PihB9u3J
MicrosoftのC#のドキュメントに何バイトまでstruct (C#における#[derive(Copy)])使う方がいいか
書いてあるのを見た気がする
値は忘れた
0395デフォルトの名無しさん
垢版 |
2019/09/29(日) 21:33:28.20ID:GZbu7mvl
Sizedなのは当然としてクリッピーなりラストシーが怒ってくれれば気軽に使えるだけどな
0397デフォルトの名無しさん
垢版 |
2019/09/29(日) 23:57:00.22ID:6uuCovZS
使用頻度にも依るんだから計測しろよ
別に難しいことじゃ無いし
0398デフォルトの名無しさん
垢版 |
2019/09/30(月) 00:27:00.93ID:k5ErHMsi
>>392>>393
Copyを実装してようがいまいが(=Move)
let x = y;
したのならどちらも同様にその構造体自体のmemcpyによる複製は行われてるよ？
(もちろんフィールド内の参照が指す先の話じゃなく)
0399デフォルトの名無しさん
垢版 |
2019/09/30(月) 06:40:12.68ID:URkXaUjC
それはわかってるつもり
関数定義で引数を参照にしそこねた場合とかをイメージしてた
Copyつきだとmoveされずに残るから気づきにくい
0400デフォルトの名無しさん
垢版 |
2019/09/30(月) 08:53:42.19ID:i9kRAMDA
それで問題なく動いてるならどうでもいいだろ
遅かったら直せば？
どれだけ速かろうが、なんら価値を産まないプログラムの価値はゼロだよ
0401デフォルトの名無しさん
垢版 |
2019/09/30(月) 09:35:07.62ID:URkXaUjC
動くのは前提で最初（ >>385 ）から速度の話をしてるんですよ
流れで所有権の有効性の一面がでてきたわけですがね
他の人はどれくらいの速度低下を許容しているのか知りたいってのが発端
0402デフォルトの名無しさん
垢版 |
2019/09/30(月) 09:49:38.90ID:Fmg7ESu9
呼び出し規約でレジスタに乗る範囲は意識するかな
大きいのは論外だとして、小さいのは
プロファイルとっても表面化しないまま積み重なっていくだけだから
遅かったらあとで直すってのはまず実施されないよね
0405デフォルトの名無しさん
垢版 |
2019/09/30(月) 10:45:45.14ID:mReccqCd
>>399
しつこくてごめんね、でも分かってるようには思えないなぁ
CopyだろうがMoveだろうがメモリの使用量も速度も何も変わらないよ？
>>391に書いてあるけど複製前の値が使えるか使えないかっていう、所有権の違いだけ


It's important to note that in these two examples, the only difference is whether you are allowed to access x after the assignment.
Under the hood, both a copy and a move can result in bits being copied in memory, although this is sometimes optimized away.

CopyとMoveの違いはassign後のxにアクセスできるか出来ないかの違いしかない
内部的にはどちらもビット単位のコピーが行われる

When should my type be Copy?
Generally speaking, if your type can implement Copy, it should.
Keep in mind, though, that implementing Copy is part of the public API of your type.
If the type might become non-Copy in the future, it could be prudent to omit the Copy implementation now, to avoid a breaking API change.

一般的にCopyが実装可能ならするべき
将来的に非Copyになる予定ならAPIが変わることになるので実装しないべき
0407デフォルトの名無しさん
垢版 |
2019/09/30(月) 11:43:56.12ID:URkXaUjC
>>405
だからcopyもmoveもしたくないんですよ
勝手にcopyを渡されるのでなく参照を渡してアクセスすべきstructのサイズがありますよね
copy vs move でなく copy/move vs 参照 ということ
勝手にcopyされないようにCopyを実装しないサイズについて
他の人の考えを聞きたかったんです

たぶん >>393 にそんな感じって書いたのが良くなかったんだろうな
>>392 の問題点を指摘するべきでした
0409デフォルトの名無しさん
垢版 |
2019/09/30(月) 13:02:43.26ID:7L7I6CKJ
128bitくらいまでならコピーでいいんじゃね
ttps://www.forrestthewoods.com/blog/should-small-rust-structs-be-passed-by-copy-or-by-borrow/
0410デフォルトの名無しさん
垢版 |
2019/09/30(月) 15:22:11.50ID:zXgxGRIB
although this is sometimes optimized away.
の部分も訳してよ
0414デフォルトの名無しさん
垢版 |
2019/10/01(火) 22:05:50.22ID:iKbLcHR3
>>412
大抵は最適化でコピー省略だろうけど
寿命の短い変数から長い変数へmoveする場合は面倒な予感
0415デフォルトの名無しさん
垢版 |
2019/10/01(火) 23:19:08.32ID:5ranOfZi
め、memmove()はmemcpy()、、
moveが真にmoveになるのはハンドルや参照やFATで指し示されたﾌﾞﾂだけなのではないか
bittableなオブジェクトでcopyメソッドの付加をケチっても仕方が無い
bittableなコピーは所有権フリーでふつくしい
■ このスレッドは過去ログ倉庫に格納されています
ニューススポーツなんでも実況