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を二度書くと罪悪感で一度にならないか一生懸命考える