Rust part8

**デフォルトの名無しさん** · 2020/01/24(金) 11:47:52.41

Mozilla発のRust言語のスレ

公式
https://www.rust-lang.org/
https://blog.rust-lang.org/
https://github.com/rust-lang/rust

Web上の実行環境
https://play.rust-lang.org

前スレ
Rust Part7
http://mevius.5ch.net/test/read.cgi/tech/1563114707/

**デフォルトの名無しさん** · 2020/01/24(金) 12:03:40.01

このスレにバグがある確率
↓

**デフォルトの名無しさん** · 2020/01/24(金) 13:58:51.88

この世のC/C++プログラムにバグが一つでもあるぐらい%

**デフォルトの名無しさん** · 2020/01/24(金) 15:10:27.64

>>2
このスレの仕様が定義されてないから
バグがあるかどうかは不定です

**デフォルトの名無しさん** · 2020/01/24(金) 23:17:19.37

質問です。
こんな構造体を作っていました。

struct Iter<T: Iterator> {
buffer : Option<char>,
iter : T
}

このとき T::Item が char であるような制限を表現する方法はありますか？

**デフォルトの名無しさん** · 2020/01/25(土) 00:04:14.38

struct Iter<T: Iterator<Item=char>>

**デフォルトの名無しさん** · 2020/01/25(土) 00:07:06.67

>>6
ありがとうございます。
上手くいきました。

**デフォルトの名無しさん** · 2020/01/25(土) 09:25:49.56

どういたしまして

**デフォルトの名無しさん** · 2020/01/25(土) 10:02:56.84

ミスがある前提で作られたソフトウェアなんぞ使いたくないわ。

**デフォルトの名無しさん** · 2020/01/25(土) 10:26:45.49

個人のミスが重大な問題にならないようシステムで防ぐんだぞ
1つのミスがそのままProductionのバグになるわけじゃないから

個々の部品が予期しない故障をする前提で設計したシステムと
個々の部品は想定外の故障はしない前提で設計したシステムと
どちらのほうが高い信頼性を実現できるのかは歴史を見れば明らか

だから優れたプログラマーは自分がミスを犯す前提で
そのミスが重大な問題につながらないよう個人単位でもシステムを構築してる

**デフォルトの名無しさん** · 2020/01/25(土) 10:50:03.15

ミスをしないエンジニアは存在する

俺だ

**デフォルトの名無しさん** · 2020/01/25(土) 10:53:31.57

>>10
おまえの関わった製品には署名しといて。
絶対使わないから。

**デフォルトの名無しさん** · 2020/01/25(土) 10:59:09.24

>>11
5chに書き込んでる時点で
何か人生ミスってる気がする

**デフォルトの名無しさん** · 2020/01/26(日) 03:02:59.13

https://play.rust-lang.org/?version=stable&;mode=debug&edition=2018&gist=511e2be2ae90342a9c36f759e73108b6
勉強がてらたらい回し関数をメモ化仕様で書いてみたんですけどあってますかね…自信がないです

**デフォルトの名無しさん** · 2020/01/26(日) 14:50:16.22

返す変数間違ってました

**デフォルトの名無しさん** · 2020/01/26(日) 15:15:02.80

あーなんかいろいろ間違ってたんで出直します

**デフォルトの名無しさん** · 2020/01/26(日) 17:36:36.36

プルリクとかも出す前にさんざん確認してんのに出してからすぐ｢あ、ここ間違ってた…｣みたいになるよね(´・ω・`)

**デフォルトの名無しさん** · 2020/01/26(日) 21:41:08.18

Vec<String> を拡張すると定義外ってエラー出るんですけどなんでかわかる人います？
他のライブラリでVec拡張してるソース見ると特殊なことせずにimplできてるんですけどどうすればこのエラー取り除けますか？
impl From<Vec<&str>> for Vec<String> {
fn from(v: Vec<&str>) -> Self {
v.into_iter().map(String::from).collect()
}
}
error[E0117]: only traits defined in the current crate can be implemented for arbitrary types
|
88 | impl From<Vec<&str>> for Vec<String> {
| ^^^^^---------------^^^^^-----------
| | | |
| | | `std::vec::Vec` is not defined in the current crate
| | `std::vec::Vec` is not defined in the current crate
| impl doesn't use only types from inside the current crate
|

**デフォルトの名無しさん** · 2020/01/26(日) 22:08:40.96

>>18
ざっくりいうと
外部crateで定義された型 + 外部crateで定義されたtrait
の組み合わせでインプリするのは無理
どっちか片方が自crateで定義されたものなら問題ない

coherence ruleとかorphan ruleとかいうやつ
https://doc.rust-lang.org/error-index.html#E0117

**デフォルトの名無しさん** · 2020/01/26(日) 23:22:19.61

>>19
おお、ありがとう
impl Vec<&str>　の単体でも駄目だったから自trait作って実装した！
結構制約厳しいな
外部トレイトに実装するならめんどくさいけどマーカーつけとけよって意味かな

**デフォルトの名無しさん** · 2020/01/27(月) 17:44:19.37

こんな関数は書けますか？
① イテレータを受け取る
② 受け取る引数は ① のただひとつのみ
③ 条件を満たす範囲を「スライスで」返す

スライスを作る記法は &s[1..10] みたいな感じなのでスライスの元になるオブジェクト s が必要なように見えますが、
スライスを返したいというのはいかにもありそうなことなので出来ないはずはないだろうという思いもあります。

イテレータは実際にはなんらかのシーケンスをたどるものではなく値の生成器である場合もありますが、
それらを区別するような制約を表現できますか？

**デフォルトの名無しさん** · 2020/01/27(月) 18:55:02.93

>>21
無理じゃね？
スライスじゃなくtakeやskip使ってイテレータを返すべきケースだと思うけど

**デフォルトの名無しさん** · 2020/01/27(月) 22:07:00.22

スライスは連続したメモリ領域である必要があって
任意のイテレータがその条件を満たすのは不可能。
たまたま連続した場合だけスライスを返すのはunsafe使えば書ける。
ただ普通はイテレータ返してランダムアクセス必要なタイミングでcollectすると思う。

**デフォルトの名無しさん** · 2020/01/27(月) 22:21:05.46

あと標準のイテレータは特に値の生成方法に関する型制約はないので
区別したいなら独自のイテレータ型を作って
標準イテレータへの変換を実装する感じかな。

**デフォルトの名無しさん** · 2020/01/27(月) 22:29:13.49

入力が連続したメモリ領域だってんなら引数をイテレータじゃなくてスライスにすればいい
当たり前だけどスライスを作れるもの以外からはスライスは作れないからな

**デフォルトの名無しさん** · 2020/01/27(月) 22:46:49.78

ごめん、なんか変なこと言ってるわ・・・スルーして

**デフォルトの名無しさん** · 2020/01/27(月) 23:06:14.69

>>23
>たまたま連続した場合だけスライスを返すのはunsafe使えば書ける。

イテレータを受け取ってスライスを返すとした場合
スライスの元になってるシーケンスのlifetimeが関数内に閉じるから
unsafe使ったとしてもborrow checkerにひっかからない？

**デフォルトの名無しさん** · 2020/01/27(月) 23:19:10.77

>>27
from_raw_partsでスライスを作った場合は元のポインタ由来のライフタイムは関係なくなるので
ボローチェッカは通るんじゃないかな？
もちろんそのスライスの実体が生きているかどうかは
自己責任になるけど。

**デフォルトの名無しさん** · 2020/01/28(火) 00:18:00.02

>>28
なるほど
イテレータからイテレータの元のシーケンスが取得できればそれでいけるってことか
ちょっと見てみたらslice::Iterのas_sliceとかも内部でfrom_raw_parts使ってた

自分では使わないと思うけど勉強になった

**デフォルトの名無しさん** · 2020/01/28(火) 10:36:24.22

RustでOSのkernel描いてる例ある？

21 · 2020/01/28(火) 10:56:11.58

>>22-29
ありがとうございます。
スライスの役目や Rust の習慣について誤解していたみたいです。

【誤解】
　スライスは範囲を表現する高級なオブジェクト
　Vec にも配列にも使えるのでコンテナ全般に使えると思った

【正解】
　スライスは「メモリの」範囲を表現するオブジェクト
　実体としてはいわゆる fat pointer

【背景】
　Vec は内部的に連続したメモリ領域で管理しているので普通の配列のようにスライスを作れる
　C++ でいえば vector の data や string の c_str みたいなもの

【見落とし】
　配列でも Vec でもスライスの型表記は同じなのでどうしてだろうと気にかかってはいたが掘り下げて調べなかった
　型が同じなのは実際に同じだからなわけですね

**デフォルトの名無しさん** · 2020/01/28(火) 12:14:44.10

質問あると自分の理解が怪しいのが分かって助かるわ。

**デフォルトの名無しさん** · 2020/01/28(火) 19:57:36.65

let template = if spaces { "{1}{0}{1}" } else { "{1}{0}" };
format!(template, 1, 2);
これだとリテラルかけってエラー出るだけど、解決方法ないかな？

**デフォルトの名無しさん** · 2020/01/28(火) 20:03:41.33

iter[1..4]とか書けた方がiter.skil(1).take(4).collect()よりシンプルでええやん！
とは思ったが、そういう使い方したらそもそも駄目よ、という意思が表れているのかもしれん

**デフォルトの名無しさん** · 2020/01/28(火) 20:21:31.82

>>33
標準のformatでは無理だね。templateのパースエラーを返す手段がないので。
dynfmtクレートとかならいけると思う。

**デフォルトの名無しさん** · 2020/01/28(火) 22:00:20.47

>>34
range(&self, from: usize, to: usize) -> Option
があればいいのにね

>> 35
ありがとう、リテラルのみは統一感出るけどかなり不便だね。
デバッグ用じゃなくともDisplayとかもあるからResult返すマクロも入れといてくれたらいいのにね

**デフォルトの名無しさん** · 2020/01/28(火) 22:12:59.36

>>36
いえいえ

**デフォルトの名無しさん** · 2020/01/28(火) 22:31:23.29

>>34
Rust的にはcollectによるメモリコピーみたいな
重い操作は見た目上も重くしたいんだと思ってる。

**デフォルトの名無しさん** · 2020/01/29(水) 00:56:46.27

collectを二度書くと罪悪感で一度にならないか一生懸命考える

**デフォルトの名無しさん** · 2020/01/29(水) 02:14:46.64

>>33
単純な用途ならリテラル返すマクロを書くといいかも
複雑な用途ならテンプレートエンジンかな

macro_rules! my_format {
(true) => ("{1}{0}{1}");
(false) => ("{1}{0}");
}

println!(my_format!(true), 1, 2);

**デフォルトの名無しさん** · 2020/02/01(土) 18:37:08.80

https://tech-blog.optim.co.jp/entry/2019/07/18/173000#%E3%83%87%E3%83%90%E3%83%83%E3%82%B0%E6%A9%9F%E8%83%BD%E3%81%AE%E6%B4%BB%E7%94%A8

のデバッグ機能の追加のところを読んで一通り導入してみたんだが、ブレークポイントで止まったところがなぜかバイナリ表示になってしまう

解決策を教えてください

**デフォルトの名無しさん** · 2020/02/02(日) 05:59:15.53

Slackで聞け

**デフォルトの名無しさん** · 2020/02/02(日) 19:09:35.21

>>41
CodeLLDB初めて使ってみたがオレ環では特に問題なく使える
ソースマップ定義してないから標準ライブラリとかにstep inすればバイナリで表示されるけど
自分のソースのブレークポイントでバイナリ表示はされない

単純にdebug symbolが有効になってないとか？
launch.jsonのcargoのコマンド確認してそれでbuildしたバイナリを
rust-lldbでデバッグできるかどうかで切り分けてみたら？

**デフォルトの名無しさん** · 2020/02/02(日) 21:47:21.49

解決しました
上記はMac用のデバッグのやり方のようです

**デフォルトの名無しさん** · 2020/02/04(火) 01:45:10.19

vscodeでrust始めたんだけどオートコンプリートがまともに働いてくれてない気がする
メソッド内の変数だと候補を出したり出さなかったりする

**デフォルトの名無しさん** · 2020/02/04(火) 02:12:55.41

>>45
vscodeやめてインテリなんとか使えば？

**デフォルトの名無しさん** · 2020/02/04(火) 02:38:52.83

vscode での Rust の補完って LSP を使うんでないの？
処理系と連携するって最強じゃんと思ってたんだが。

**デフォルトの名無しさん** · 2020/02/04(火) 20:47:39.21

コンパイラから出てくる補完情報が成熟してないんで、まだ完璧には遠い
独自の解析はracerとintellij rustがやってて、精度はintellijの方が高い

あんまIDE使いたくないからrlsには頑張って欲しい

**デフォルトの名無しさん** · 2020/02/04(火) 21:22:29.69

本体のソース見たいけど/* compiler built-in */ってなってて読めない。
どうやったら見れる？

**デフォルトの名無しさん** · 2020/02/05(水) 23:43:19.76

Rust の char::is_ascii とかは pub const fn is_ascii(&self) -> bool なのに is_whitespace とかは pub fn is_whitespace(self) -> bool みたいになってるのなんでだろ？
&self でも self でもどっちかに統一してよさそうな気がするんだけど。

**デフォルトの名無しさん** · 2020/02/05(水) 23:45:58.49

なんかツイッターで以下２つについてコンパイルできねーっていうつぶやきがあったんですが、
試してみたらコンパイルできちゃったんですがどういうことなのでしょう
Rust2015/2018どっちでもコンパイルできちゃいました

//その1
let y: &i32;
let x = 5;
y = &x;
println!("{}", y);

参照元yの変数宣言が参照先のxより先に変数宣言されたからエラー。

//その2
let mut x = 5;
let y = &mut x;
*y += 1;
println!("{}", x); //これがエラー

**デフォルトの名無しさん** · 2020/02/05(水) 23:58:35.71

>>50
is_asciiはstrやsliceにもあるからそれに揃えたんじゃないかな

**デフォルトの名無しさん** · 2020/02/06(木) 00:18:39.33

>>51
NLLで救えるようになったケースだね。
Rust1.30くらいまで戻せばエラーになるけど
今は2015でも2018でもNLLがデフォルトなのでエラーにはならない。

**デフォルトの名無しさん** · 2020/02/06(木) 00:30:48.24

drop順でエラーになってたやつだね

**デフォルトの名無しさん** · 2020/02/06(木) 00:59:10.03

>>52
なるほど、全部を &self に揃えなかったのは、やっぱ self の方が効率的って判断なのかな？

ワイはまだ初心者で Rust 脳になりきれてないんだけど、参照渡しってのは実質的に (C/C++ で言うところの) ポインタをやりとりしてる感じでしょ？
(単純な場合は最適化で消えると思うけど。)
char 程度の大きさならポインタを渡すのでもコピーして渡すのでも差はないし、ポインタだと間接参照になる分だけ無駄っぽい。

という理解をしてて、 char のメソッドは全部 self でいいくらいじゃないかと思ってた。

**デフォルトの名無しさん** · 2020/02/06(木) 01:31:54.89

>>55
ascii系は昔はAsciiExtってトレイトに別れてたから
その名残だと思う。

**デフォルトの名無しさん** · 2020/02/06(木) 01:51:52.29

>>56
歴史的経緯ってやつか。
比較的新しい言語なのに、やっぱりそういうこともあるのね。

**デフォルトの名無しさん** · 2020/02/06(木) 11:48:46.94

The Rust Programming Language 第2版で勉強中なんだけど
この内容に連動した練習問題か使用例みたいなのどこかにないだろうか？英語でいい

**デフォルトの名無しさん** · 2020/02/06(木) 14:10:02.33

https://www.rust-lang.org/learn
このページの上のほうにある3つのボタンがそれそれ
1. The Bookの最新版
2. Rustlings course(練習問題的なやつ)
3. Rust by Example(使用例)

英語で問題ないなら2018対応してる最新のThe Book読んだほうがいいかも

**デフォルトの名無しさん** · 2020/02/06(木) 14:27:06.44

英語がしんどい人 (日本語しかわからん人) にオススメなのはありますか？

**デフォルトの名無しさん** · 2020/02/06(木) 15:54:58.65

The Bookの日本語版かオライリーの訳本
https://doc.rust-jp.rs/book-ja-pdf/book.pdf
https://www.oreilly.co.jp/books/9784873118550/

原著で読んだから訳の良し悪しはわからないけど
The Book含めて数冊読んだ中ではオライリー本が圧倒的にわかりやすかった

58 · 2020/02/06(木) 17:27:24.00

>>59
ありがと
こんな感じの欲しかった
って言うかPDFだけ読んでたから思い付かなかったけど本家にあったのか

**デフォルトの名無しさん** · 2020/02/06(木) 20:07:27.95

手を動かしたいなら自転車本もあり
オライリーはちょっと古くなってるからなー

**デフォルトの名無しさん** · 2020/02/06(木) 22:23:34.76

オライリー本の古くなってる箇所はEdition Guide読めば問題ないよ

多少古くてもOwnershipやLifetimeあたりの重要コンセプトをわかりやすく書いてるものがおすすめ

**デフォルトの名無しさん** · 2020/02/06(木) 22:57:58.42

>>58みたいに英語でいいならrustupでインストールしたら付いてくるdocとそのリンク先にあるやつ読んだほうが良いぞ。

// ランタイム持ってないからasync/awaitがゼロコスト理論斬新すぎる

**デフォルトの名無しさん** · 2020/02/07(金) 16:10:10.85

自クレートの名前やバージョンを取得するマクロって無かったっけ？

**デフォルトの名無しさん** · 2020/02/07(金) 16:23:48.41

Rust のライブラリって検索できるようになってるじゃん？
あれって名前だけじゃなくて引数の型とかで検索できたりしないのかなぁ。
Haskell (GHC) の Hoogle みたいに

**デフォルトの名無しさん** · 2020/02/07(金) 16:25:17.48

>>67
あ、 Inparameters ってやつをクリックすれば出てくるのか。

**デフォルトの名無しさん** · 2020/02/07(金) 16:30:12.12

>>66
これ？
https://doc.rust-lang.org/cargo/reference/environment-variables.html#environment-variables-cargo-sets-for-crates

**デフォルトの名無しさん** · 2020/02/07(金) 16:36:53.27

>>69
それだ！ありがとう

**デフォルトの名無しさん** · 2020/02/07(金) 16:54:52.66

>>69
へー。
そのための専用のマクロってわけじゃなくて cargo が環境変数を設定してくれるって話なのね。
Cargo.toml を見ないとわかるはずもないからなんらかの連携があるのは当たり前といえば当たり前だけど。

**デフォルトの名無しさん** · 2020/02/10(月) 11:00:28.83

io::Errorとかってprintln!("{:?}", err )とかしても
Os { code: 13, kind: PermissionDenied, message: "Permission denied" }
みたいに出るだけで｢どのファイル｣かが分からないんですが、外部のクレートの関数から上のようなエラーが帰ってきた場合それが｢どのファイル｣によって起きてるのかというのはどうやって知れば良いんでしょうか？

**デフォルトの名無しさん** · 2020/02/10(月) 18:06:05.22

>>72
自分が明示的にパスを渡してるケースじゃなければ
クレートの作者にファイルパスも入れてクレメンスするしかないかも

**デフォルトの名無しさん** · 2020/02/10(月) 20:19:23.72

バイナリサイズはまだCの方が全然小さいけどRustはC以上になにが含まれてるの？
もちろん標準ライブラリとかは使ってないやつはバイナリに含まれないよね？

**デフォルトの名無しさん** · 2020/02/10(月) 21:25:29.97

>>74
明らかに大きいのはbacktrace用のデバッグシンボル。
これはstripすれば縮む。
それ以外はC側が共有ライブラリとしてどれだけ外に出してるかによるかと。

**デフォルトの名無しさん** · 2020/02/10(月) 22:55:31.36

メモリ管理がランタイムにあるしdrop checkerもあるからランタイムはデカイよ。

**デフォルトの名無しさん** · 2020/02/10(月) 23:49:02.35

>>75
backtrace用のデバッグシンボルってreleaseでもついてくるの？

>>76
drop checkerってborrow checkerの書き間違え？borrow checkerってcompile-time以外でも走るのって一部の実装だけって認識だけど
ARCとか使うとランタイムとか増えるの分かるけど使ってないハロワだけのやつでもCより多いのが疑問

**デフォルトの名無しさん** · 2020/02/11(火) 00:10:31.83

https://www.reddit.com/r/rust/comments/bzdwru/hello_world_executable_size_268k_in_rustrelease/

**テトリス** ◆SYKnw8OJpw · 2020/02/11(火) 00:36:46.52

Windows10のキャラクターがゴミ過ぎて無駄に苦労する
やっぱLinux使うしか無いんか？
でもゲームしたいからWindows環境が良いんだよな…

**デフォルトの名無しさん** · 2020/02/11(火) 01:09:07.15

>>77
releaseでもデバッグシンボルはついてくる。
取って欲しいってIssueは立ってるけど
stripすればいいって感じなのか、あまり動きはない。
あとCのHelloWorldが小さいのはコードの大半が
libcにあるせいなのでは。

**デフォルトの名無しさん** · 2020/02/11(火) 01:18:02.99

バイナリサイズを小さくしたいならここを読む
https://github.com/johnthagen/min-sized-rust

**デフォルトの名無しさん** · 2020/02/11(火) 18:54:33.07

組み込みで使おうなんて本気で考えてる奴はこんなところで聞いたりせんだろ。

**デフォルトの名無しさん** · 2020/02/12(水) 12:54:11.29

>>70
いえいえ

**デフォルトの名無しさん** · 2020/02/17(月) 17:53:09.28

cargo install mdbook

としたとき、依存するライブラリクレートも一斉にインストール (というかキャッシュみたいな扱い？) されたようです。
ローカルに入ったライブラリクレートのドキュメントから一斉に、網羅的に検索する仕組みはありますか？
標準ライブラリのドキュメントは名前や引数で検索できますが、それを手元に入っているライブラリ全てに拡大したようなものが欲しいです。

**デフォルトの名無しさん** · 2020/02/17(月) 18:00:40.10

>>84
ビルド用の一時ディレクトリ以下に展開されただけで他から使えるようにはなってないよ

**デフォルトの名無しさん** · 2020/02/17(月) 18:17:09.06

>>85
そうなんですか。 Windows でやってるんですけど、
C:\Users\<ユーザー名>\.cargo\registry\src
に入っているのはビルド時の一時ファイル扱いという理解でいいんですかね？

他のプログラムをビルドしたときに必要になるライブラリクレートに共通するものが (このフォルダに) あったときでも
使いまわしはされないんでしょうか？
見かけ上は独立してるけど cargo が裏でうまいことやってくれるって感じなんでしょうか？

本当は Cargo book を読めばいいんでしょうけど、英語がわからなすぎて基本的な理念がよくわかってないです。

**デフォルトの名無しさん** · 2020/02/17(月) 20:49:03.97

$ cargo doc --open
doc生成すればプロジェクトの依存クレートすべてWeb形式で検索できるけど
そういうことではない？

**デフォルトの名無しさん** · 2020/02/17(月) 22:42:46.96

>>84
cargo installはバイナリクレートをインストールするためのワンライナーなんで
ライブラリクレートをどうこうする為のものではないよ。
バイナリのビルドに成功したら.cargo\binにコピーしてゴミは削除する。
バイナリクレートのドキュメントを読みたいならそれ自身を読みに行くんだよ。
rustdocは開発者向けでユーザー向けじゃない。

mdbookのrustdocが読みたいなら単にソースコードをクローンして自分でcargo doc叩けばビルドしてくれるけど。

**デフォルトの名無しさん** · 2020/02/18(火) 00:10:35.64

構造体のメソッドでメンバ変数の値ひっぺがすのにstd::mem::take使うの面倒だな

84 · 2020/02/18(火) 10:09:42.44

>>87
「そのプロジェクト (に依存する全ての)」ではなく「ローカルに残っている全ての」というつもりでした。

>>88
> cargo installはバイナリクレートをインストールするためのワンライナーなんで
> ライブラリクレートをどうこうする為のものではないよ。

「為のものではない」ということは察していたんですが、
ライブラリのソースコードは残っているので裏で Cargo が動くために情報を残してもいるのだろう
と考えて特定のプロジェクトに限定せず横断的な処理をする方法があるのかどうかということを考えていました。

バイナリクレートをアップデートするときのために残してあるだけなんですかね……？
とりあえず、プロジェクトごとに独立していると考えておきます。

**デフォルトの名無しさん** · 2020/02/18(火) 10:18:22.88

>>90
.cargoは全プロジェクト共通のキャッシュなので
プロジェクトまたいでも再利用はされる。
ただcargoコマンド自体はプロジェクト毎の操作しか提供しない、という感じ。
そういうツールを作ること自体は可能と思うけど。

84 · 2020/02/18(火) 10:59:25.45

>>91
なるほど。
見かけ上はプロジェクトの独立性があるように抽象化されているという感じですね。

なるべくなら過去に使ったことのあるライブラリクレートから使えそうなものを
探した方がキャッシュ (?) の増大を抑えられるし、
よく使われるライブラリの方が信頼性が高いだろうというのが元々の動機でした。

ツールの使い方もおぼつかないので定番と言えるのがどのあたりなのかとかいった肌感覚もなくて、
実際のコードを色々と見て回るのにどういうやり方が良いのか模索しています。

**デフォルトの名無しさん** · 2020/02/20(木) 05:16:24.39

https://ideone.com/6mGYO9

これの14行目15行目のところを10行目のところのように１つの文で書ける方法ってありますか？

**デフォルトの名無しさん** · 2020/02/20(木) 19:48:24.79

Haskell の default 宣言みたいなのは Rust にありますか？

たとえば関数 foo が返す値の型が a もしくは b の可能性があり、
関数 bar が受け取る値の型が a もしくは b のときに bar(foo()) という式で型が定まりません。
このときに a と b の間での優先度を決める方法があるかという質問です。

具体的な状況があるわけではなくて、言語機能を学ぶ中で生じた疑問です。

**デフォルトの名無しさん** · 2020/02/20(木) 20:19:05.71

>>93
こんな感じかな。

buf = buf.replace(ch, &<String as std::iter::FromIterator<&char>>::from_iter(&[' ', ch, ' ']));

**デフォルトの名無しさん** · 2020/02/20(木) 20:57:27.42

>>95
thanks!

**デフォルトの名無しさん** · 2020/02/20(木) 21:07:18.17

俺だったらformat!(" {} ", ch)にするかforを[" ( ", " ) ", ...]で回すかな

**デフォルトの名無しさん** · 2020/02/20(木) 21:09:56.45

>>94
>たとえば関数 foo が返す値の型が a もしくは b の可能性があり

Rustで戻り値の型が1つに決まらない関数書ける？

**デフォルトの名無しさん** · 2020/02/20(木) 21:27:49.34

型が曖昧な時はだいたいターボフィッシュでなんとかなるやろ

**デフォルトの名無しさん** · 2020/02/20(木) 21:55:52.56

>>94
型が定まらない関数は定義不能。
aまたはbを返したいならenum c {a, b}にしてcで返すしかないかと。

**デフォルトの名無しさん** · 2020/02/20(木) 22:48:30.93

>>94
rustはsum typeしかない。それだと実行時に型を評価する方法とunion typeがいる。

**デフォルトの名無しさん** · 2020/02/21(金) 01:30:08.71

正直TypeScriptの1 | 2 の型記法欲しい

**デフォルトの名無しさん** · 2020/02/21(金) 08:48:56.60

>>94 って多分こういう事では?

trait X { ... }
impl a for X { ... }
impl b for X { ... }

fn foo<T: X>() -> T { ... }
fn bar<T: X>(_: T) { ... }

bar(foo())

Rust の文法詳しくないんで間違ってたらすまん

**デフォルトの名無しさん** · 2020/02/21(金) 09:15:56.88

>>103
もしそうならdyn Xで返せばいいね。
その場合は型がAかBかの評価は実行時になるけど
どちらにしてもAとBのどっちを優先する、みたいなのはないな。

94 · 2020/02/21(金) 10:40:19.65

>>103-104
近いですが a と b との関係がもっと無関係なもの (仮想関数を使えない) を考えていました。
コードにするならこんな感じです。

struct Foo {}
struct Bar {}
trait X<T> { fn foo(&self) -> T; }
trait Y<T> { fn bar(&self, T); }
impl X<Foo> for Foo { fn foo(&self) -> Foo {Foo{}} }
impl X<Bar> for Foo { fn foo(&self) -> Bar {Bar{}} }
impl Y<Foo> for Bar { fn bar(&self, _x: Foo){} }
impl Y<Bar> for Bar { fn bar(&self, _x: Bar){} }
fn main() { Bar{}.bar(Foo{}.foo()); }

いずれにせよ方法はなさそうですね。
型を明記すればよい話ではあるのですが、ふと疑問に思ってしまったもので。

**デフォルトの名無しさん** · 2020/02/21(金) 13:18:50.41

いや、こちらも勉強になるよ。

**デフォルトの名無しさん** · 2020/02/21(金) 15:11:57.88

型推論でどの型のメソッドを呼び出せばいいか決まらないときに
特定の型のメソッドを優先させるような記述方法があるかってことだったのか
>>99のエスパー力すごいな

**デフォルトの名無しさん** · 2020/02/21(金) 15:21:44.11

ターボフィッシュで指定するか型指定した変数で一旦受けるかだね
https://play.rust-lang.org/?gist=3d288900b3f655687d0ba22cc37cbb23

逆にこのケースでdefaultの型が決まっちゃうのってちょっと怖い

94 · 2020/02/21(金) 18:02:02.28

Rust の型システム (Hindley-Milner) は ML 系言語で実績があるやつなので、
(型に関して) ML 系で出来ることはおおよそ出来るのではないかと思いつつ、
Rust 的には明記させたい場面かもな……みたいな気持ちでした。

やはり勝手に決まって欲しくないというのが Rust ユーザの感覚なんですね。

※ Haskell が ML 系と言えるかどうかは諸説あります

**デフォルトの名無しさん** · 2020/02/22(土) 01:53:24.77

これ出来たらかっこいい見たいな型推論の活用ってある？

**デフォルトの名無しさん** · 2020/02/22(土) 12:47:45.08

ファントムタイプは（名前が）かっこいい

**デフォルトの名無しさん** · 2020/02/22(土) 16:08:52.19

C++ をやってた感覚から言うと Rust の str::parse っていいよね。

C++ は返却値の側からの推論が無いから普通の関数 (メンバ関数) として parse みたいなものを書けない。
いや、書けるけど型が推論されないからいちいち型を明記しなけりゃならない。
昔は演算子でやる C++ のスタイルを上手い案だと思ってたけど、
普通に関数 (メソッド) でやれるもんならその方がいいわ。

**デフォルトの名無しさん** · 2020/02/25(火) 12:01:50.32

異なる関連型を持つ複数のトレイトオブジェクトを1つのVecに入れるのはAnyとかを使わないと無理でしょうか？

**デフォルトの名無しさん** · 2020/02/26(水) 07:52:56.79

IntelliJのRustプラグイン、ここのところぶっ壊れてないですか？

**デフォルトの名無しさん** · 2020/02/28(金) 06:03:14.29

1.41.1

**デフォルトの名無しさん** · 2020/02/28(金) 12:10:25.14

これは大失態だな

**デフォルトの名無しさん** · 2020/03/03(火) 21:00:42.72

static TEST = &'static str = "test";

このTESTの文字列の最後の一文字だけを参照として&'static charで作ることってできる？
型レベルで一文字ってことを保証したいのとメモリ節約したい

**デフォルトの名無しさん** · 2020/03/03(火) 21:53:23.53

>>117
charは4byteで&strはutf-8でasciiの部分は1byteだから無理そう。

**デフォルトの名無しさん** · 2020/03/03(火) 22:01:05.88

charは4バイトでポインタ（参照）は8バイトだから節約するどころかむしろメモリ食ってるなｗｗｗ

**デフォルトの名無しさん** · 2020/03/03(火) 22:09:48.50

charにする場合は’staticは無理なんじゃないかな
&strをsliceして1文字分にしたほうが素直だと思う

let x: &'static str = "test";
let y: &'static str = &x[x.len()-1..];
let z: &char = &x.chars().next_back().unwrap();

**デフォルトの名無しさん** · 2020/03/03(火) 22:48:24.81

そこまでメモリ節約したいって組込系か何かか

**デフォルトの名無しさん** · 2020/03/03(火) 23:11:15.82

charでなくu8を使うシーンに思える

**デフォルトの名無しさん** · 2020/03/03(火) 23:13:54.10

asciiと分かってるなら u8 だよね
どっかで u8 ベースの文字列操作ライブラリ見かけた気がする

**デフォルトの名無しさん** · 2020/03/03(火) 23:14:25.42

>>120
それだと最後の1文字が2バイト以上の時に死ぬから
結局全体をcharsするしかないような。

**デフォルトの名無しさん** · 2020/03/03(火) 23:30:49.39

これだ
https://crates.io/crates/bstr
作者が有名人なので前にチェックしてた

**デフォルトの名無しさん** · 2020/03/04(水) 00:03:26.33

おお、いっぱい回答くれた　ありがとう
レス止まってたけど見てる人はいるんだね。

素直にsliceしようと思ったけど、
str.chars.last()
このlastって消費されないけどなんで？
型的には
fn last(self) -> Option<char>
だけどなんで消費されないか分かんない
&strみたいな元々消費不可能ならコンパイルエラーでると思ってたんだけど。
https://doc.rust-lang.org/std/iter/trait.Iterator.html#method.last

**デフォルトの名無しさん** · 2020/03/04(水) 00:12:13.85

消費されるのは&strじゃなくてそのイテレータだからね。
"abcd".chars()で得られるのは、{ String : source, index : 0 }みたいな形のChars型で、これがindexをインクリメントしながら文字を取得してくれる。

**デフォルトの名無しさん** · 2020/03/05(木) 00:35:43.70

use std::fmt::{self, Display, Write};
このselfってどういう意味？

**デフォルトの名無しさん** · 2020/03/05(木) 00:38:13.00

>>128
use std::fmt;と同じ。

**デフォルトの名無しさん** · 2020/03/06(金) 00:28:35.73

まさにこの質問と同じ状況でコンパイル出来ないんですけど、分かる人いますか？
https://stackoverflow.com/questions/46393890/mutable-borrow-in-loop

**デフォルトの名無しさん** · 2020/03/06(金) 01:12:13.19

>>130
回答に書いてあるじゃん・・・
dostuff()やfixme()が受け取るselfに’aでlifetimeアノテーションをつける理由ないよね

**デフォルトの名無しさん** · 2020/03/06(金) 19:38:23.62

>>131
ライブラリ側が同じデータ構造しててループで回したいけど同じエラーで出来ません
これって並列にループ回す可能性があるからシングルスレッドでも禁止されるんですか？
すみません、初心者で

**デフォルトの名無しさん** · 2020/03/06(金) 21:38:26.09

>>132
ある値に対するmutable referenceは同時には1つしか存在できない
ってのはRustの基本ルールの1つ
この場合は並列に回す可能性があるかどうかは関係ない

Test構造体自体のライフタイムが’aで
dostuff()が&’a mut selfを取るなら
1回目のdostuff()呼び出し時にselfをmutableに借りてくるけど
Test構造体のライフタイムと同じだけ借りることになるから
2回目のdostuff()呼び出し時には1個目を借りたまま2個目を借りようとしてることになる
だからエラー

**デフォルトの名無しさん** · 2020/03/07(土) 13:13:11.28

>>133
なるほど。
ライブラリ側なので修正できないんですが、AcとRefCell使って解決できる問題ですか？

**デフォルトの名無しさん** · 2020/03/08(日) 08:35:20.95

>>134
どのライブラリのどのメソッド？

**デフォルトの名無しさん** · 2020/03/08(日) 11:34:51.20

その構造体の意図が分からんので、あんまりアドバイスできない
単にライブラリ作者がrustに慣れていないだけなら、適切な形に直してもらうのがシンプルで合理的だし、
>>130のTest::fixme相当のメソッドは誰にも呼び出して欲しくないのかもしれないなら、使うべきじゃない
Test::dostuffを繰り返し呼び出したいだけならRefCellで何とかなる

**デフォルトの名無しさん** · 2020/03/08(日) 11:38:51.13

Rustで型パズルみたいな状況になるのは、見落としている前提があったり、設計レベルで何か考慮が足りないことが原因な事が多いと個人的には思ってる
姑息な解決をしてたら余計にドツボにはまる

**デフォルトの名無しさん** · 2020/03/09(月) 04:03:43.73

>>135
>>136
このライブラリです。
https://github.com/fulmicoton/kuromoji-rs
https://github.com/fulmicoton/kuromoji-rs/blob/master/src/lib.rs#L246-L256

こういう風に使おうとしていて、Testと同じ状況です。
let mut tokenizer = kuromoji::Tokenizer::normal();
for s in ["Example", "Example2"].iter() {
tokenizer.tokenize_str(s);
}

**デフォルトの名無しさん** · 2020/03/09(月) 06:35:47.93

>>138
Tokenizer自体は'aで定義されてないからTestとは状況違うんじゃない？

**デフォルトの名無しさん** · 2020/03/09(月) 10:07:04.49

コンパイラをだましても本質的な解決にはならん。
そろそろrustマンセーしてる輩も気づくころだろうね。

**デフォルトの名無しさん** · 2020/03/09(月) 12:37:33.41

なんかトレイトの命名でなるべく名詞ではなく動詞を使う(WriterではなくWrite、ReaderではなくRead)みたいなのがオフィシャルの文書で有ったような気がするんだけど見つからない
そんな指針って無かったっけ？

**デフォルトの名無しさん** · 2020/03/09(月) 12:52:18.51

>>141
オフィシャルにはapi-guidelinesだと思うけど特になさそう。
このissueで議論されてるけど特に結論はでてないし。
https://github.com/rust-lang/api-guidelines/issues/28

**デフォルトの名無しさん** · 2020/03/09(月) 13:05:24.07

>>141
話し合いしている様子は見つけた。
https://github.com/rust-lang/api-guidelines/issues/28
どちらを優先するという話ではなく、使い分けがあるっぽい。

**デフォルトの名無しさん** · 2020/03/09(月) 21:11:10.09

一年くらい前に挫折して最近また勉強し始めたんだけど参照周りの仕様変わった？
https://doc.rust-jp.rs/rust-by-example-ja/scope/borrow/freeze.html
これとかエラーにならないし

**デフォルトの名無しさん** · 2020/03/09(月) 21:47:20.13

>>144
昔は一度借用するとスコープアウトするまで借りっぱなしだったけど、今は使われなくなった時点で返すようになってる。
non lexical lifetimeというやつ。
英語版だとちゃんとエラーになるように修正されてるね。
https://doc.rust-lang.org/rust-by-example/scope/borrow/freeze.html

**デフォルトの名無しさん** · 2020/03/09(月) 22:32:56.28

>>138
試しに触ってみた感じだけど、戻り値をVecに格納しようとすると怒られるよね。
で、よく見ると引数のtextはtokenizer自身と全く関係の無い寿命であって良いのに、tokenizerとtextの寿命が同じであるってシグネチャで言ってるから何かマズそう
多分もっと理解できる人も居るだろうけど、selfとtextの寿命を無関係にしたら動くってなんとなく分かる
pub fn tokenize_str<'s, 'a>(&'s mut self, mut text: &'a str) -> Vec<&'a str> {
ってやったら動くよ。省略ルールで
pub fn tokenize_str<'a>(&mut self, mut text: &'a str) -> Vec<&'a str> {
と同義。

俺の頭の中の理解じゃプルリク送れるほど明快に説明できないが、適当にローカルに落とすかgithubでforkして使っても良い

**デフォルトの名無しさん** · 2020/03/09(月) 22:35:30.43

>>145
non lexical lifetimeっていうのね。Rust日本語情報が少ないので助かるわ。thx

**デフォルトの名無しさん** · 2020/03/09(月) 23:22:38.75

>>147
しかしそもそも借用によるフリーズって意味なくなってるから
そのページ全体書き直した方がいい感じ。
フリーズするならシャドーイングによるmut外しかな。

**デフォルトの名無しさん** · 2020/03/10(火) 15:02:44.20

>>138
Linderaってのがkuromoji-rsの後継らしいからそっち使えば？
https://qiita.com/mosuka/items/0fdaaf91f5530d427dc7
https://github.com/lindera-morphology/lindera

該当箇所のライフタイムは修正されてるのでtokenizerのインスタンスをループで使っても問題ない
https://docs.rs/lindera/0.3.4/src/lindera/tokenizer.rs.html#163-173

ただドキュメントは整備されてないし
ライブラリ自身のテストも通らない状態になってるから
本格的に使うなら自分でメンテするくらいの覚悟が必要かもしれん

**デフォルトの名無しさん** · 2020/03/10(火) 19:42:21.39

>>149
ありがとうございます、後継なんてあったんですね。
最近出来たみたいですがそれほどメンテされてないみたいですしこの先不安なので素直にPython使うことにします。
日本関係依存のライブラリはRustユーザー少ないので確立されたものがないのが辛いですね...

**デフォルトの名無しさん** · 2020/03/10(火) 19:58:15.03

rustも字句解析も相当知ってなきゃそれ使うの無理だろ。。

**デフォルトの名無しさん** · 2020/03/11(水) 18:46:16.77

vecのinto_iter呼んだらconsumeするって
fn into_iter(self) -> イテレータ {self}
こういうふうになってるってこと？
よく分かってない質問ですみません。

**デフォルトの名無しさん** · 2020/03/11(水) 18:56:11.75

あ、consumeじゃないわこの場合
moveって言いたかった

**デフォルトの名無しさん** · 2020/03/11(水) 19:43:34.97

自己解決？

https://doc.rust-lang.org/std/vec/struct.Vec.html#impl-IntoIterator
impl<T> IntoIterator for Vec<T>

こうなってるからそのまま self を返してるに違いない
よーわからんけどなんとなく納得

**デフォルトの名無しさん** · 2020/03/11(水) 19:46:02.45

よく分からないのに納得してしまうのはよくない

**デフォルトの名無しさん** · 2020/03/11(水) 20:15:44.69

>>154
ソースで理解したいんならここ。

https://doc.rust-lang.org/src/alloc/vec.rs.html#1934-1952

Vecのポインタを使ってIntoIterを構築して、元のVecはforgetでメモリ管理対象から外してる。

**デフォルトの名無しさん** · 2020/03/11(水) 20:40:35.00

>>155 おっしゃるとおり
>>156 おおおお！！！
想像とは違ってunsafeの中であれこれしてた！
impl<T> IntoIterator for Vec<T> {
type Item = T;
type IntoIter = IntoIter<T>;
fn into_iter(mut self) -> IntoIter<T> {
unsafe {
let begin = self.as_mut_ptr();
let end = if mem::size_of::<T>() == 0 {
arith_offset(begin as *const i8, self.len() as isize) as *const T
} else {
begin.add(self.len()) as *const T
};
let cap = self.buf.capacity();
mem::forget(self);
IntoIter {
buf: NonNull::new_unchecked(begin),
phantom: PhantomData,
cap,
ptr: begin,
end,
}
}
}
}
いやあ勉強になります

**デフォルトの名無しさん** · 2020/03/11(水) 22:03:42.73

fn into_iter(mut self) -> IntoIter<T>

このmut selfのmutの使い方について
意味は理解してるんだけど公式で解説してる箇所ある？

**デフォルトの名無しさん** · 2020/03/11(水) 22:44:26.55

なんでextern crate crate_name;ってuse crate_name;に統合されたの？

**デフォルトの名無しさん** · 2020/03/11(水) 23:04:39.68

>>159
RFCに書いてある理由はこの辺り
https://github.com/withoutboats/rfcs/blob/modules/0000-modules/motivation.md#underlying-problems

**デフォルトの名無しさん** · 2020/03/12(木) 06:53:02.39

serde, reqwestとかを使ってるだけの小さいツールなのに
targetディレクトリ以下がいつの間にか2GB以上喰ってて驚いた
無駄遣いしすぎだろ

**デフォルトの名無しさん** · 2020/03/12(木) 09:00:30.33

ぜろこすとおーばーへっど(笑）

**デフォルトの名無しさん** · 2020/03/12(木) 09:20:01.92

>>158
公式系のやつを一通り検索したけどなさそうだね。
確かに頻出パターンではないし、mut selfが必要になる頃には
それくらい分かるだろってことなんだろうか。

**デフォルトの名無しさん** · 2020/03/13(金) 01:08:14.21

容量くうのってインクリメンタルコンパイルのせいかしら？

**デフォルトの名無しさん** · 2020/03/13(金) 16:12:49.45

cargo run --bin bin_a　で bin_a から a にバイナリ名をrenameできる方法ない？
オプションとかで

**デフォルトの名無しさん** · 2020/03/13(金) 17:20:18.20

>>165
標準ではないと思うから以下の三択
1. コマンドを自作する
2. プラグインを探す
3. Cargo.tomlの編集で我慢する

**デフォルトの名無しさん** · 2020/03/13(金) 17:48:43.18

>>164
インクリメンタルコンパイルの内部構造知らないけど、仕組み的に一個前の状態しかもたないから関係なさそう

**デフォルトの名無しさん** · 2020/03/13(金) 20:50:49.12

お前らのtargetディレクトリは何GBあるんだ？

**デフォルトの名無しさん** · 2020/03/13(金) 21:21:22.50

duとかdustでどのcrateが容量食ってるのか
きちんと確認したほうがいい

**デフォルトの名無しさん** · 2020/03/13(金) 22:52:16.46

dustで一番ディスク喰ってるプロジェクトを調べてみたよ

target/debug/depsの下に
lib(serde|derive_more|syn|reqwest|chrono_tz)-xxxxxxx.(so|rlib)
が各ライブラリごとに3つずつぐらいあって、それぞれ21～38MBぐらいあった
その他、依存ライブラリの依存ライブラリと思われる *.rlib ファイルが260個
これだけで 1.4GB

target/debug/build の下が400MBぐらい
target/debug/incremental の下は100MBもない

同様のファイルがtarget/releaseにもあって合わせると 2.3GB

**デフォルトの名無しさん** · 2020/03/14(土) 01:08:40.11

エコシステムが充実してるのはいいが、
ぞろぞろと依存を引き連れて落ちてくるのはしんどいな。

**デフォルトの名無しさん** · 2020/03/14(土) 09:57:16.83

う、うん…

**デフォルトの名無しさん** · 2020/03/14(土) 13:30:22.96

Rustに限らず誰が書いたかも知らないまま誰がチェックしたかも知らないまま何がダウンロードされるかも知らないままインストールするのが当たり前になっちゃってるよな
ソースが公開されてるとは言えこれじゃいかんよなぁとは思いつつ楽だからまぁいっかな…って感じだわ(´・ω・`)

**デフォルトの名無しさん** · 2020/03/14(土) 13:52:26.42

わからないまま終わる。そんなのは嫌だ(´・ω・｀)

**デフォルトの名無しさん** · 2020/03/14(土) 13:58:57.65

実際なんかの言語で問題起こしていたような

**デフォルトの名無しさん** · 2020/03/14(土) 14:53:10.70

node.js

**デフォルトの名無しさん** · 2020/03/14(土) 15:14:32.21

誰が書いたかも知らないまま誰がチェックしたかも知らないまま何がインストールされるかも知らないままOSをインストールするのが当たり前になっちゃってるよな

**デフォルトの名無しさん** · 2020/03/15(日) 11:00:03.22

公式アプリストアしか使えないとか真逆の動きだろ
何指してるんだ？

**デフォルトの名無しさん** · 2020/03/15(日) 12:03:48.31

実際のところ、そんなのいちいち精査してられんだろう。

**デフォルトの名無しさん** · 2020/03/16(月) 23:59:03.20

arrayvecとsmallvecってどっち使えばいいの？

**デフォルトの名無しさん** · 2020/03/17(火) 04:52:34.09

好きな方。

**デフォルトの名無しさん** · 2020/03/17(火) 10:23:26.40

arrayvecとsmallvecよく見てないけど同じぐらい人気だからどっちでもよさそう
それよりもロガー周りが何選んだらいいか分からん(env_logger抜きで)
ファイル保存したいからlog4rsかfernかslogで迷ってる
ライブラリ選びはホントにRustの欠点だよな

**デフォルトの名無しさん** · 2020/03/17(火) 11:06:35.06

まあねぇ。部品は連携してこそのものだから、
どっちでもいいものでもどちらかには決まってた方がありがたいってのはあるわな。
自由の強さと統率の強さは両立できないのでしゃーない。

**デフォルトの名無しさん** · 2020/03/17(火) 11:30:02.19

確かに選びにくいんだけど、型が強いのとコンパイルエラーが見やすいから、移行コストが結構低い気はしている。
なので最近はあまり気にせず適当に選ぶことにしてるな。

**デフォルトの名無しさん** · 2020/03/17(火) 13:15:29.64

スタック上に確保するStringライブラリってあるの？

**デフォルトの名無しさん** · 2020/03/17(火) 17:38:45.49

rust-avって今どういう状況なん？
だいぶ前にlibavの人たちがMozillaから数万ドル支援を受けて始めたとかニュースになってたけどgithub見ても実質的にはほぼ何も進んでないようなコミットばっかだしlibavすらほぼ放置みたいな感じだし
非公開の場所で着々と進んでてそのうち公開されるんやろか

**デフォルトの名無しさん** · 2020/03/18(水) 05:43:30.43

C++の負の仕様引きずってるなってRustの特徴とかある？

**デフォルトの名無しさん** · 2020/03/18(水) 09:41:00.53

C++の負の仕様って何？

**デフォルトの名無しさん** · 2020/03/18(水) 21:47:04.33

winapi 0.3.8 の環境にて、CoCreateInstanceを行いたいのですが、
REFIIDの指定部分をどのように書けばよいか教えてくださいませ

**デフォルトの名無しさん** · 2020/03/19(木) 00:16:54.84

なんでassert_neはあるけどassert_notはないの？

**デフォルトの名無しさん** · 2020/03/19(木) 01:43:10.57

notと!が続いて少し紛らわしい
なくてもそんな困らない
必要なら作ればいい
とかかな

macro_rules! assert_not {
($cond:expr) => { assert!(!$cond) };
($cond:expr,) => { assert!(!$cond) };
($cond:expr, $($arg:tt)+) => { assert!(!$cond, $($arg)*) };
}

**デフォルトの名無しさん** · 2020/03/19(木) 15:19:47.59

assert!(!false);
の方が紛らわしくないか？
assert_not!は関数名の方に!あるから見間違えないしスッキリするし直感的な気がする
それにneが内部的に反転してるだけならnotあったほうがいいな

**デフォルトの名無しさん** · 2020/03/20(金) 07:03:37.86

usize同士の差の絶対値を求めるのがすごくだるいんですけどなんかいい方法ないすか

**デフォルトの名無しさん** · 2020/03/20(金) 07:38:59.81

if x > y { x - y } else { y - x }
じゃ駄目かい

**デフォルトの名無しさん** · 2020/03/20(金) 08:14:22.57

やっぱそうするしか？

**デフォルトの名無しさん** · 2020/03/20(金) 16:54:06.07

そういう関数を作っておけばええやん。

**デフォルトの名無しさん** · 2020/03/21(土) 19:08:12.84

let mut v = vec![1,2];
std::mem::swap(v[1], v[0]);
assert!(v == vec![2,1]);
こうしたいんですけど、どうすればいいですか？

**デフォルトの名無しさん** · 2020/03/21(土) 19:19:05.58

Vec::swap使え->
Vec::swapは中でunsafe使ってるじゃないですか結局unsafe使わなきゃろくなこと出来ないんですねRustってクソですね

ってやりたい荒らしだろ？
氏ねばいいと思うよ

**デフォルトの名無しさん** · 2020/03/21(土) 19:32:13.45

標準ライブラリ内でunsafe使うのと
自前でunsafe使わされるのとは雲泥の差があると思うんだがｗ

**デフォルトの名無しさん** · 2020/03/21(土) 20:27:19.94

ヤクザかな？