Rust part9

**デフォルトの名無しさん** · 2020/08/23(日) 01:07:35.52

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 part8
https://mevius.5ch.net/test/read.cgi/tech/1579834072/

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

>>154
数学が分からん人には、LinkedListの優秀性も理解できない。
実験しても実験の仕方が間違っているので間違った結果になっているが、
本人が気づかない。
C++のStrousstrup氏も間違っている。
集団幻想。
それだけ数学的なことは才能が必要だということだ。
多数決では、ArrayListが圧勝と言うことになってしまっているが、それは
本等は間違い。

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

数学的なことは、99%位の人が正しく理解できないので、ベンチマークテスト
のプログラムも1%位の人しか正しくかけない。
だからデタラメな集団幻想が、LinkedListが過小評価に繋がっている。
まだ、雑誌などでは学歴フィルターというか、頭の良さフィルターをかけて入社
させない仕組みがあるので、あまり間違ってはないが、ネットはめちゃくちゃ。
見ていたら、論文にまでしてしまっているひとまでいるようだが、間違っている。

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

>>95
グラフ表現とかでもlinkedlist使わんの？

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

あーあっち側の人すかー
有意義な議論ができるかと思ってた
皆さまご苦労さまです

**デフォルトの名無しさん** · 2020/09/19(土) 11:06:03.78

とりあえずベンチマーク取ってみたらええやん。。よくいる種類の馬鹿だよね。
こういうタイプはフィボナッチヒープとか大好きなんだよな。

**デフォルトの名無しさん** · 2020/09/19(土) 11:36:48.27

ArrayListおじさんはArrayDequeをどう評価するの？

**デフォルトの名無しさん** · 2020/09/19(土) 12:38:52.28

>>162
グラフは何かしらのツリー構造を使うからLinkedListは使わないでしょ

**デフォルトの名無しさん** · 2020/09/19(土) 16:29:00.47

https://ideone.com/lH56m8
ArrayListとLinkedListを思いつくままに比較した。
結論は特に無し。

**デフォルトの名無しさん** · 2020/09/19(土) 16:47:45.15

https://ideone.com/O4aPii
sumi2 1,222,328 164,294,013 (1.000000:134.410742)
を追加。

**デフォルトの名無しさん** · 2020/09/19(土) 17:53:59.50

まだ続くなら、動的配列とリストの具体的なベンチマークのコードを載せてくれ
rustが好ましい

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

>>167
Javaでは、末尾追加の aitと、途中削除の rit、先頭への追加は、LinkedListの方が
速いという結果だね。
この場合、要素数が2万個だけど、もっと多くなると理論上、その差はいくらでも開いて行く。
また、単純に全要素を足すsumitとsumforでは、0.25%, 1.4% の差しかない。
逆に、末尾追加のalastは、ArrayListの方が4.8倍速い。
これはLinkedListの場合、1要素ずつメモリアロケーターを呼び出しているので遅くなっており、
予想通り。
しかし、先頭追加のa0とalastの時間差が、LinkedListではほとんどない(理論上は全くないのだが)
のに対し、ArrayListでは82倍もあるのも予想通りの結果。
LinkedListは、先頭、末尾、途中のどこを操作しても、理論上、時間差が(ほぼ)ないが、
ArrayListは、大きく違ってくるというのが理論上予想されたことで、このベンチマークは正しく
それを反映している。

**デフォルトの名無しさん** · 2020/09/19(土) 18:27:51.00

>>170
なお、末尾追加も、同じサイズのノードに限定したものなら、メモリアロケーターが
劇速のものが作れるので、LinkedListでも、ArrayListに匹敵するくらい速度が
出るように作れる。

**デフォルトの名無しさん** · 2020/09/19(土) 18:28:30.00

>>171
間違った。
匹敵どころか、要素数が多くなった場合、LinkedListが追い抜く。

**デフォルトの名無しさん** · 2020/09/19(土) 18:30:31.19

この結果は、JavaのLinkedListが、素直にLinkedListを素朴に実装しているから
出てきたもの。
一方、STLは、設計が悪いので初心者が誤解を招く結果が出てしまう。
それは、追加する場所をアドレスではなく、先頭からの通し番号で指定する
ことが標準になっていたりするから。

**デフォルトの名無しさん** · 2020/09/19(土) 18:48:41.03

>>173
> 先頭からの通し番号で指定することが標準になっていたりするから。

なんでそんな間違った前提を置いてるんだ？
C++ の std::list にそんな機能はないってことをたびたび指摘されてるが、
あんたは今までリンクリストの優位性がどうこう言ってたのとは別の人なんか？
(いや、そんなはずはないよな、こんな荒らし野郎が何人もいるとは思いたくない。)

**デフォルトの名無しさん** · 2020/09/19(土) 19:00:07.16

Javaはmalloc/freeが超速いので、他の言語よりはLinkedListに優しい

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

>>175
どうせ妄想を書いてるだけだろ

**デフォルトの名無しさん** · 2020/09/19(土) 19:22:13.23

GC言語は領域の再利用をgc時に行うからnewの時に空きを探す手間が少ない。
単純に端っこから割り当てていくだけ。

**デフォルトの名無しさん** · 2020/09/19(土) 19:39:34.30

>>174
あ、記憶違いだったわ。
STLが汚すぎて。

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

Listスレかな?

**デフォルトの名無しさん** · 2020/09/19(土) 23:26:19.32

https://ideone.com/NZEWm8
vectorとlistも比較した。
listのsumiとsumi2が小さすぎるので何か間違ってる予感。
全体的に古臭い書き方ですまそ。

**デフォルトの名無しさん** · 2020/09/19(土) 23:52:44.02

ゲームエンジン・データベースなどの本には、メモリプールを作る方法が、よく載っている

同じサイズの要素を、まとめて確保して、そのプール内で管理する方法

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

次はhashmap vs vector

**デフォルトの名無しさん** · 2020/09/20(日) 00:06:23.82

ここで定番のRustハッシュ関数遅い問題で一悶着

**デフォルトの名無しさん** · 2020/09/20(日) 00:17:48.39

>>167
実行順やJITの兼ね合いがあるから
ちゃんとやるならJMHで測ったほうがいいよ

**デフォルトの名無しさん** · 2020/09/20(日) 01:00:22.31

>>181
システムコールの呼び出し回数を押さえるため？
でも通常のmalloc/freeもプロセス再起動されなければ領域再利用されるよね。
なら最初にmallocでガバっと取って、実際に使う時にfreeしてmallocしなおせば良くない？
ゲーム専用機の場合はシステムのAPIもいまいちだったりするから自前でメモリ管理もありだと思うし、DBの場合もキャッシュやら共有メモリやらmmapしてどうたらで自前で管理したいのもわかる。
でもそれ以外で普通のOS上のアプリで自前でメモリプール管理するメリットってどれだけあるの？

**デフォルトの名無しさん** · 2020/09/20(日) 01:12:40.58

予め決まったサイズを確保することが多いから、予めまとめて確保しておいて数珠繋ぎにしておけば最速で出し入れできる

**デフォルトの名無しさん** · 2020/09/20(日) 01:16:59.26

16msecの間にすべての処理を完了しないといけないからmalloc呼び出しなんてありえないよ

**デフォルトの名無しさん** · 2020/09/20(日) 01:29:40.54

>>167
このデータの作り方だとLinkedListでもかなり連続したメモリ領域が使われてる可能性が高いような気がする

Javaの場合はList<int>じゃなくList<Integer>で
値を使うケースだとポインタを辿る必要があるのでそれも結果に影響しそう

**デフォルトの名無しさん** · 2020/09/20(日) 03:23:18.11

>>159 に答えれる方いませんか？
ここはリスト議論のスレッドですか？

**デフォルトの名無しさん** · 2020/09/20(日) 08:14:35.07

>>184
情報サンクス。
JMH勉強になりました。存在すら知らなかったです。

>>188
AutoboxingとUnboxingも大事なところで平然とやりまくってるので、
こちらもご指摘のとおり結果をぼやかしちゃってると思います。
LinkedListはなるべく不連続にリンクされたデータを準備してみよう！
という心意気は当初あったのですが、サボりましたｗ

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

挿入が必要なら普通はヒープ組むのになんで誰も突っ込まんの？

**デフォルトの名無しさん** · 2020/09/20(日) 10:27:51.76

テキストエディタのようなものだと、アプリを起動して編集し始めた時から、
新しく追加したデータに関しては、対応するノードは、Heapからアロケートしても、
連続したアドレスに載っている。
ロードした直後、最後の行のノードのアドレスと、編集で追加したノード
のアドレスが近い。
編集で追加した行の直前直後のノードのアドレスと、編集で追加したノードのアドレスは
不連続である。
しかし、キャッシュは、何も、最後の1つのページだけしか覚えておけないわけでなく、
1000種類位は覚えておける。
だから、このくらいだと、どちらもキャッシュに乗ることになる。

なお、ArrayListの場合、途中へ追加すると、半分近くの要素に対してコピー動作が
必要になるが、その際、キャッシュを全て使い切ってしまうことがある。
配列の全データが100MBだとすると、このコピー動作のために100MB分のデータが
いったんキャッシュに読み込まれる必要がある。
キャッシュはL3ですら8MB程度しかないので、これだと全くキャッシュが足りなくなる。
その点、LinkedListは、このようなキャッシュ汚染は生じない。

**デフォルトの名無しさん** · 2020/09/20(日) 10:32:00.78

>>192
さらに、100MBのようなデータだと、ArrayListで全データを巡る際でも、
キャッシュミスもキャッシュ汚染も生じる。
だから、ArrayListがキャッシュで有利と言っても、現実的には2MBくらいまで
がその優位性は維持できない。
そしてLinkedListも実際的な用途では、>>192に述べたような状況になるので、
キャッシュミスは余り生じない。

**デフォルトの名無しさん** · 2020/09/20(日) 10:48:59.50

>>193
テキストエディタの例だと、100万行のファイルを読み込んだとしても、
実際に閲覧したり、書き込んだりしたい場所は、数箇所に集中することが
多い。
LinkedListの場合だと、編集時に行を挿入する場合、全データを移動する
必要が無いので、1行当たり、数10バイトくらいのコピーで済む。
この場合、キャッシュ汚染はほとんど生じない。
一方、ArrayListだと、100万行のコピー動作が必要になり、その際に
キャッシュを浪費してしまう。

**デフォルトの名無しさん** · 2020/09/20(日) 10:55:21.87

L1,L2はkbyteオーダーだろ
余裕でキャッシュミスするわ

>>189
一言多いってよく言われないか？

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

>>195
>L1,L2はkbyteオーダーだろ
>余裕でキャッシュミスするわ
そこは、ArrayListで挿入する時の移動動作でもね。

**デフォルトの名無しさん** · 2020/09/20(日) 14:40:25.89

なんでテキストエディタの例でArratListが出てくるんだ

**デフォルトの名無しさん** · 2020/09/20(日) 17:50:32.22

スレ間違ってますよ

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

>>195
すみません。
スレチ馬鹿が多いので言わないと分からないかと思い書いてしまいました。

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

CSのスレでも立てればいいのにな
無駄なマウントとプライドで議論になってないじゃん

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

あっちで相手にされないからこっちに来るんだろう

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

あっちってどこ？

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

本人にだけ判れば良いんだよ

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

Rust 初心者ってか始めてもないけど、
fn main() {
　 println!("Hello, world!");
}
これってセミコロン要るの？

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

>>204
そのケースはコンパイラー的にはどっちでもいいけど
println!の戻り値をmain関数の戻り値として意識的に扱いたいわけじゃないだろうから
セミコロン書くほうがいいと思う

**デフォルトの名無しさん** · 2020/09/24(木) 04:24:32.56

なんでreturn文省略するん

**デフォルトの名無しさん** · 2020/09/24(木) 08:46:29.52

>>205
なるほど。
たまたまprintlnの戻り値が()だからエラーが出ないんですね。

**デフォルトの名無しさん** · 2020/09/24(木) 19:57:00.21

関数型のフリがしたいから。

**デフォルトの名無しさん** · 2020/09/24(木) 20:40:06.68

return省略は関数型なのか？
関数型をふりをするなら {} を省略して = で書くとかでは

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

lispのprognみたいな感じじゃね。
セミコロンを書くとその後に空の式があるようにみなすのはイケてないと思うけど。

**デフォルトの名無しさん** · 2020/09/24(木) 21:34:50.13

expressionをstatementにするのがセミコロン
statementは`()`として扱われる
セミコロン不要にして必要に応じて`()`を明記するスタイルのほうがイケてたとは思う

returnを省略するのは慣習
関数を含めて式が値に評価されていくというメンタルモデルなので
”return文”という感覚ではないのかもね

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

C++系言語に見た目を近づけるという設計意図があるから()を明記するという判断にはならなかっただろうとおもう

**デフォルトの名無しさん** · 2020/09/25(金) 06:33:09.44

戻り値型の宣言にも -> () っていちいち書かなくていいしなあ
そういうもんだとしか

**デフォルトの名無しさん** · 2020/09/25(金) 07:11:20.18

なんで戻り値は型推論してくんないんだろう。

**デフォルトの名無しさん** · 2020/09/25(金) 07:33:16.25

単純に、セミコロンの有無だけで区別するのが視認性が良くないんだよな。
エディタの方で違いを目立たせられたりしたらいいけど。

**デフォルトの名無しさん** · 2020/09/25(金) 07:58:20.78

>>214
クロージャならやってくれるから技術としては可能だけど、
関数として定義するなら関数仕様としてimpl Traitまでは書こうねということと解釈している

**デフォルトの名無しさん** · 2020/09/25(金) 19:12:30.94

>>215
いまさらどうにもならないが、使いはじめの頃は、もっと視認性のあるフレーズ使ってくれてたらなぁと思ってた。

例えば、F#の
hofe |> ignore
なんかは、冗長ではあるが逆に視認性も良く、捨てる気満々の書き方で気に入ってる。

**デフォルトの名無しさん** · 2020/09/25(金) 23:12:55.80

そういえばelse節の無いif式は()に評価されるんだっけか

**デフォルトの名無しさん** · 2020/09/25(金) 23:17:40.79

https://doc.rust-lang.org/reference/expressions/return-expr.html

ってかそもそもRustのreturnは式だったわ
return bar;はreturn文じゃなくて式文の一種だったわ

**デフォルトの名無しさん** · 2020/09/26(土) 06:07:19.66

コンピューターはともかく、人間にはreturnくらいの文字的冗長性があった方が視認性がいい。

**デフォルトの名無しさん** · 2020/09/26(土) 08:31:48.23

ifは末尾}に;不要なのにletは末尾}に;必要なのだるい

**デフォルトの名無しさん** · 2020/09/26(土) 09:30:48.93

>>220
returnがあればearly returnだと識別できるのでその意味では視認性は高い
ただセミコロンというC系言語経験者が注視しない記号に新しく重要な意味をもたせたから戸惑う

>>221
ifブロック末尾のセミコロンは常に省略できるわけじゃない
https://doc.rust-lang.org/reference/statements.html#expression-statements

セミコロンがないと意図通りパースできないケースってほとんどないと思うので
そのうちJSのASIのようなものでセミコロン不要になる未来もある気がする

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

個人的にはセミコロンうんぬんよりifの中括弧が苦痛

/* c */
#include <stdio.h>
#define min(a, b) ((a) < (b) ? (a) : (b)) // スッキリ
int min2(int a, int b) {return a < b ? a : b;} // ややスッキリ
int min3(int a, int b) {
if (a < b) return a; else return b; // スッキリ？
}
int main() {
printf("%d ", min(3, 2));
printf("%d ", min2(3, 2));
printf("%d ", min3(3, 2));
return 0;
}

// rust
fn main() {
let min = |a, b| if a < b {a} else {b}; // 中括弧が嫌
//let min = |a, b| if (a < b) a else b; // これならスッキリ
//let min = |a, b| if a < b then a else b; // あるいはこれ
println!("{}", min(3, 2));
}

(* ocaml *)
let min a b = if a < b then a else b (* スッキリ *)
let () = print_int (min 3 2)

**デフォルトの名無しさん** · 2020/09/26(土) 12:46:41.58

はいはいdangling else dangling else

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

Goもそうだけど、条件式に括弧を使わないのがいまだに慣れない。

**デフォルトの名無しさん** · 2020/09/26(土) 13:49:35.37

BASIC は要らなかったから慣れてる。
3項演算子考えたやつは天才。

**デフォルトの名無しさん** · 2020/09/26(土) 14:34:05.78

>>225
本文 (?) の波括弧が必須だから
条件式の範囲は自明 (視認性的に) だってことなんだろうな。

**デフォルトの名無しさん** · 2020/09/26(土) 14:40:21.79

>>225
そのへんとモジュールまわりはPythonの影響かなと思った

**デフォルトの名無しさん** · 2020/09/26(土) 16:28:05.98

>>228
PythonというよりRubyだろね
コアチームは過去も含めてRubyコミュニティ出身者が多いから

モジュールはPythonのようにファイルベースじゃなくキーワードで名前空間をきちんと切るし
クロージャの書き方だったりreturnを書かない慣習だったりも他言語に比べて類似性が高い

**デフォルトの名無しさん** · 2020/09/26(土) 16:42:46.56

型システムは ML 系の言語でよくあるやつだし、
そっち方面の影響もあるんじゃないの？

**デフォルトの名無しさん** · 2020/09/26(土) 17:41:02.34

https://doc.rust-lang.org/reference/influences.html

**デフォルトの名無しさん** · 2020/09/26(土) 17:52:07.70

>>231
> Ruby: closure syntax

縦棒で引数囲むのはruby由来だったのか

**デフォルトの名無しさん** · 2020/09/26(土) 18:02:33.75

if a < b => a else => b っていう変なもんを思いついてしまった
だーめだこりゃ

**デフォルトの名無しさん** · 2020/09/27(日) 04:32:18.28

セミコロンとかはEdition上げて撤廃してほしいけど、ここまでRustのOSS書かれてたら無理だろなぁ...

**デフォルトの名無しさん** · 2020/09/27(日) 07:58:10.90

>>232
それはSmalltalkだろ

**デフォルトの名無しさん** · 2020/09/27(日) 08:00:03.20

Rust, Go, Elixir などの新しい言語は、Ruby の影響が強い。
Ruby で最も良いのは、すべての進数の数値リテラルに、_ を含められること

こういうコメントを書かなくて済む
1000000 // 1_000_000

**デフォルトの名無しさん** · 2020/09/27(日) 09:53:51.56

戻り値の有無がセミコロンだけで区別されている現状をどうにかしないとそもそもセミコロン廃止なんて
無理だろうけど、セミコロンレスってそんなにいいかねぇ？

行の折り返しを間違えて別の文になってしまってもスルーされる場合があるのがなんか嫌。
ASIがあるJSでもメジャーどころのスタイルガイドはみんなASIを信用しないでセミコロン使うことに
なっているし。
pythonだとセミコロン使わないスタイルも多いけど、あっちはインデントで判別できるしね。

**デフォルトの名無しさん** · 2020/09/27(日) 10:45:39.75

>>237
>ASIを信用しないでセミコロン使うことに

ASIを信用してないわけじゃないよ
ASIの仕様はJSの仕様で決まってるから例外的に挿入されない場合もはっきり分かってる
セミコロンを使うスタイルが多いのはミニファイとかを考慮してるから

JSの場合は普通に書いてる分にはセミコロンの有無でほぼ違いが無い上に
セミコロンレスで書いてもリンター使って自動挿入できるから実質書き手の自由
1行に複数文書いてるときでもなければセミコロンに特別な意味はないから気にする必要がない

**デフォルトの名無しさん** · 2020/09/27(日) 11:08:19.83

セミコロンは基本的にはあっていいけどたまに}のあとに;必要なやつとかあったりしてこれはイヤ

**デフォルトの名無しさん** · 2020/09/27(日) 11:27:51.54

たしかに「ASIを信用しないで」というと疑っているみたいだから「依存しないで」の方が
適切だったかも。
いずれにしても、どのスタイルガイドもプログラマの意図と異なる判断がされる危険を
挙げていて、それを防ぐためには明示的にセミコロンを記述する方が良いと謳っている。
minifyはそれこそminify時にセミコロンを補完すればいいんだから関係ないと思う。

**デフォルトの名無しさん** · 2020/09/27(日) 11:40:37.55

>>236
Verilog は 1985から出来てたけど？
多分、もっと古い言語からあったんだろう。

**デフォルトの名無しさん** · 2020/09/27(日) 12:00:44.11

セミコロン撤廃要望多いとは思えないんだけどRFCとか書いてる人いるのか？

**デフォルトの名無しさん** · 2020/09/27(日) 12:27:31.82

セミコロン書き忘れる事は多々あるけど、意図しない値が返ってとかならない(はず)なので別に困らない
それより、Docs.rsに見にくいクレートが有る方が困る、AutoとBlanket以外のShow hidden undocumented itemsを
デフォルトで展開するオプションが有れば良いのに、この議題はどっかで見たような気がする。

**デフォルトの名無しさん** · 2020/09/27(日) 12:34:01.78

>>241
1967のPL/Iあたりからかな？登場時期からするともっと広まってもおかしくなかった気もするけど、16/32ビットリテラルしかなかった時代には需要なかったんだろうね。verilogは何ビットでもいけるから必要だけど。
最近は128ビット型とかBigIntとかでようやく必要になってきたってことか。

**デフォルトの名無しさん** · 2020/09/27(日) 12:55:24.47

rustのAPI documentなんか読みづらい気がする
うまく説明できないけど

型クラスのあたりも見づらい

**デフォルトの名無しさん** · 2020/09/27(日) 13:55:00.63

>>240
きちんとした手順にそったminifyだけを指して言ったわけじゃないんだが
GoogleやAirbnbのstyle guideを見ると確かにそういう意図ではないみたいだね
npmやGithubみたいにセミコロンレスのstandard style使ってるところも多いから
「メジャーどころはみんなセミコロンを明示的に書く」というのはちと言い過ぎかな

いずれにしろJSの場合は1コマンドで一瞬で切り替え可能で書く時はどっちでいいから
Rustとはかなり事情が違うと思う

**デフォルトの名無しさん** · 2020/09/27(日) 14:15:05.14

>>242
探してみたらRFCあったけどCloseされてた
https://github.com/rust-lang/rfcs/issues/2583

C/C++/G#/Javaあたりから来た人はセミコロンあるのが普通だろうけど
Go/Scala/Swift/Kotlin/Ruby/Pythonだとセミコロンないのが普通なので面倒くさく感じるのよ

RFCのやり取りや↓ここの議論を見るとセミコロンが不要になる可能性はもうないね
https://internals.rust-lang.org/t/make-some-separators-optional/4846

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

セミコロンレスってフォーマット的な改行と文末の改行を文脈を見て判断する必要があるから好きじゃないなぁ。
一文が複数行になりやすいビルダーパターンとかイテレータアダプタの類いが特に。
入力する側としてはほとんど無意識に打ってるから特に面倒とも感じないし。

**デフォルトの名無しさん** · 2020/09/27(日) 15:18:06.12

IntelliJ使えばセミコロンを殆ど見えないような色に設定できるぞ

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

典型的なbikeshed

**デフォルトの名無しさん** · 2020/09/28(月) 01:45:21.81

>>223
ocamlってセミコロン必要じゃなかったっけ？

**デフォルトの名無しさん** · 2020/09/28(月) 07:53:40.34

>>251
この例では必要になる場所は無い

**デフォルトの名無しさん** · 2020/09/28(月) 09:58:13.64

docsのフロント部分は特に強いUXデザイナーがいない感じがすごくする

**デフォルトの名無しさん** · 2020/09/28(月) 18:49:05.66

>>251
トップレベルの分を区切るのに;;を使う
ただしletの直前、ファイルの最後、などでは省略できる
https://ocaml.org/learn/tutorials/structure_of_ocaml_programs.ja.html
構文は
https://ocaml.org/releases/4.11/htmlman/language.html

let min a b = if a < b then a else b (* letの直前だから;;省略 *)
let () = print_int (min 3 2) (* ファイルの最後だから;;省略 *)

**デフォルトの名無しさん** · 2020/10/01(木) 14:03:33.62

slice::windowsのstrバージョンみたいなのってないのでしょうか。
ようするにある文字列に含まれる連続するn文字を頭から順に返すイテレータを作ってくれるようなやつです。

**デフォルトの名無しさん** · 2020/10/01(木) 18:29:40.74

>>255
ないのでVec<char>を生成してwindowsを呼ぶとか

let cs: Vec<_> = String::from("あいうえお").chars().collect();
let ws: Vec<_> = cs.windows(2).map(|v| v.iter().collect::<String>()).collect();

**デフォルトの名無しさん** · 2020/10/01(木) 18:54:04.45

文字幅が可変長 (utf-8) であっても windows みたいなことをするのはそんなにコスト大きくないよね？
ふたつのポインタを一文字ずつ進めるだけなんだから O(N) で出来るはず。

**デフォルトの名無しさん** · 2020/10/02(金) 09:46:31.03

アロケートなしだと、
(0..s.len()-n).map(|i| &s[i..i+n])
となるけど自分で-nとか+nとかiとかやるのめっちゃアホくさいしそのうちミスりそう

**デフォルトの名無しさん** · 2020/10/02(金) 14:20:31.00

>>258
アロケートなしならこれでもいけるはず。utf8を食わせると死ぬけど
.as_bytes().windows(2).map(|v| std::str::from_utf8(v).unwrap())