Rust part11

**デフォルトの名無しさん** · 2021/06/17(木) 00:24:12.56

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

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

日本語の情報
https://rust-jp.rs/

※Rustを学びたい人はまず最初に公式のThe Bookを読むこと
https://doc.rust-lang.org/book/

※C++との比較は専用スレへ
C++ vs Rust
https://mevius.5ch.net/test/read.cgi/tech/1619219089/

前スレ
Rust part10
https://mevius.5ch.net/test/read.cgi/tech/1617367084/

**デフォルトの名無しさん** · 2021/07/10(土) 13:41:38.31

>>195
面白い観点だな。
楽しい言語も流行らないか・・・、なんか考えさせられる。

**デフォルトの名無しさん** · 2021/07/10(土) 13:52:24.60

>>199
ureq 使えよ

**デフォルトの名無しさん** · 2021/07/10(土) 14:01:01.07

ハッカー専用の言語ってあるの？

**デフォルトの名無しさん** · 2021/07/10(土) 14:20:32.32

prolog

**デフォルトの名無しさん** · 2021/07/10(土) 14:25:24.27

いつまで miri のトラブルを放置しておくの?

ゴミ言語

**デフォルトの名無しさん** · 2021/07/10(土) 14:28:17.22

ハッカーって・・・なに？

**デフォルトの名無しさん** · 2021/07/10(土) 14:44:49.05

unsafeモードが使えても、safeモードでのコード生成結果が予測できないのであれば
使うのは難しい。

**デフォルトの名無しさん** · 2021/07/10(土) 14:53:04.04

無駄な通信と監視と役立たずのゴミでツリーを汚すゴミ

**デフォルトの名無しさん** · 2021/07/10(土) 16:15:47.34

ハッカーは書くスピードと実行時間が重要だからnimとかが向いてそう
少なくともRustは絶対にハッカーの第一言語にならない

**デフォルトの名無しさん** · 2021/07/10(土) 16:53:00.70

お前がそう思うんならそういうことでいいよ

**デフォルトの名無しさん** · 2021/07/10(土) 17:38:05.35

ハッカーとか呼んでねえからキーボードでもしゃぶってろ

**デフォルトの名無しさん** · 2021/07/10(土) 17:43:28.58

最強言語議論スレでやれ

**デフォルトの名無しさん** · 2021/07/10(土) 17:56:33.98

犯罪者用言語とか使いたくないなあ

**デフォルトの名無しさん** · 2021/07/11(日) 01:09:10.02

ハッカー != 犯罪者がモダンな解釈だと思うんだが。
○にかけのお爺さんかな？

**デフォルトの名無しさん** · 2021/07/11(日) 02:27:33.50

ロシア人ハッカーグループって言ったら
犯罪者っぽくね？

**デフォルトの名無しさん** · 2021/07/11(日) 02:54:13.69

イスラエル人ハッカーグループって言うと
なにか巨大な国際政治がらみの陰謀っぽい

**デフォルトの名無しさん** · 2021/07/11(日) 03:33:22.44

日本人ハッカーグループ
よわそう

**デフォルトの名無しさん** · 2021/07/11(日) 03:47:16.72

日本は、一人当りのGDPだと先進30カ国中最下位レベルだけど、純粋な頭脳線だと、
三位以内に入ることが良くある。

**デフォルトの名無しさん** · 2021/07/11(日) 09:25:42.31

純粋な頭脳線

**デフォルトの名無しさん** · 2021/07/11(日) 09:54:14.29

>>199
Rustはasync/awaitを言語レベルでゼロコストでサポートする代わりに非同期ランタイムを別途用意する必要がある
これによりRustでは様々な非同期ランタイムを言語と独立に自由に作ることができる
例えば非同期ランタイムを自作することも当然できてfuturesクレイトをその部品として使うことができる

もちろん非同期ランタイムを自作せずとも既に様々なコミュニティから提供されているのでそれを使うこともできる
具体的には例えば最も使われているtokioなどのチュートリアルを見るのが良いかな
https://tokio.rs/tokio/tutorial

**デフォルトの名無しさん** · 2021/07/11(日) 11:06:14.34

>>219-220
その考え方が古い。(というか最初から？)間違ってる。

ハッカー == 凄い奴的な意図でしかないので
ロシアだろうがイスラエルだろうが某大陸だろうが
超エリートなんだろうなとしか思わない(事になってる)。
犯罪者はクラッカーと言って区別される(事になってる)。

区別しようと言い出したのは…(ry

**デフォルトの名無しさん** · 2021/07/11(日) 12:38:13.92

でも発端の>>195の「ハッカー」はホワイトかブラックかは知らんがセキュリティ関連の話ちゃうんか？

**デフォルトの名無しさん** · 2021/07/11(日) 12:47:21.47

>>225
モダンな解釈だと良いハッカー=ホワイトハッカー悪いハッカー=ハッカーですね
あと老人ホームから抜け出してまで5chなんてしたら家族に迷惑かかりますよ
迷惑かけない内に尊厳死をおすすめします

**デフォルトの名無しさん** · 2021/07/11(日) 12:48:22.75

そんな高度な話だったんだ
小学生がうんこちんちんって罵倒してるようなものだと理解していた

**デフォルトの名無しさん** · 2021/07/11(日) 15:23:07.49

>>227
> 悪いハッカー=ハッカー
では無いよ、と書いてる事が理解できないかな？

>>227 がどう思おうがどうでも良いけど
話が通じないことがある事くらいは理解しといた方が
身のためだぞ。

ttps://ja.m.wikipedia.org/wiki/ハッカー
迷惑かけない内に勉強し直す事お勧めておきます。

**デフォルトの名無しさん** · 2021/07/11(日) 15:31:18.36

相変わらずマウンター専用言語になっとるな

**デフォルトの名無しさん** · 2021/07/11(日) 15:34:34.85

正しい定義がどうだろうと>>195の意図なんかわからんのでどうでもいいうんこちんちん

**デフォルトの名無しさん** · 2021/07/11(日) 16:25:58.47

仕様や実装のマイナーな機能を使って人を驚かせるのがハッカーだ、と思ってるのでは
Cのポインタ祭りとかLISPのマクロ生成マクロとかを好むのだ、と

**デフォルトの名無しさん** · 2021/07/11(日) 16:31:55.44

クソどうでもいい

**デフォルトの名無しさん** · 2021/07/11(日) 16:37:35.60

ハッカーの定義はどうでも良いからせめてrustの何がダメかを語れよ

**デフォルトの名無しさん** · 2021/07/11(日) 16:47:25.03

rustは文字列の扱いに難があるなあ
sjisのコンテンツとかマルチバイトのファイル名(WinだとUTF16?)の扱い方がよくわからん

**デフォルトの名無しさん** · 2021/07/11(日) 16:48:48.06

Non-Lexical Lifetimes が制御フローレベルなので実装をデバッグできるやつがほとんどいない。
c++と同じレベルの複雑さを有するようになってきている。
cargoのビルドシステムがあまりに強制的すぎる。
メモリを直接いじる必要のある効率的なアルゴリズムでは結局unsafeになる。
メモリ最適化の許す範囲があまりに非自明でcから呼ぶのは不安定すぎる。

**デフォルトの名無しさん** · 2021/07/11(日) 17:06:54.98

コンテナ類が実際にどのように格納されているかが分からないと言うのは、
それをunsafeで扱うのが難しくなってる。
どこでコピーが生じて、どこがmoveなのかも分かりにくいことがあるし。

**デフォルトの名無しさん** · 2021/07/11(日) 17:08:44.89

ライフタイムもちゃんと仕様が書いてないから、手探り状態で試さないといけないし
プログラムするのに時間が掛かる。
色々やっても結局、C/C++のような効率のよい方法を取ることは不可能な場合もあるし。

**デフォルトの名無しさん** · 2021/07/11(日) 17:30:39.23

素晴らしい言語ですね
カニかわいい

**デフォルトの名無しさん** · 2021/07/11(日) 18:42:50.97

ときどき、Javaの検査例外みたいなやらかし感を感じる
厳密にしすぎると却って使いづらいみたいな

**デフォルトの名無しさん** · 2021/07/11(日) 19:53:14.68

Box<dyn Error>やanyhowやeyreを使えば良いのでは

**デフォルトの名無しさん** · 2021/07/11(日) 21:00:56.13

>>235
Windows 系以外のすべての言語は、UTF-8

だから、MSYS/MinGW でも、UTF-8以外でバグるので、
UTF-8以外を使っちゃいけない！

唯一バグらないのは、WSL。
Windows Terminal, VSCode のRemote WSL などで、

ls /mnt/c/Users/Owner/Documents/
と入力すると、日本語のフォルダ名も、正しく表示される

出力
あ
い

たぶん、Windowsが変換しているのだろう

**242** · 2021/07/11(日) 21:05:19.71

WSL は一種のチート

ハイパーバイザーでLinux を起動して、
Linux側から、Windows側のドライブを見た時に、

UTF-8 以外の言語をUTF-8に変換する

まあ、漏れの推測だけど

**デフォルトの名無しさん** · 2021/07/11(日) 21:46:26.10

>>242
そこに文句言われてもねー
要件に文句を付けるのはフェアじゃない

現実にUTF16でネーミングされたファイルがあって、
それにどう対応するかって話なんだけど

**242** · 2021/07/11(日) 22:51:28.82

だから、プログラマーの基本は、Windows 系など、UTF-8 以外を使わない事！
この大原則を守っていない人は、システムを作れない

システムには、ascii しか使えない！
これが大原則

**デフォルトの名無しさん** · 2021/07/11(日) 22:51:54.52

>>244
WinならOsStringのエンコーディングは普通にUTF-16だから何の問題もないと思うが
sjis扱いたいならencoding-rsとか
結局何に困ってるのかわからないと何とも言いようがない

**デフォルトの名無しさん** · 2021/07/11(日) 22:52:47.14

Ruby外耳に構うなよ

**デフォルトの名無しさん** · 2021/07/12(月) 00:42:25.80

じつはわしはRustはやったことなかったのだが、
これまでの経験上おそらく >>236 みたいな感じだろうなと想像してたら
ほんとうにそのとおりでワロタw
アホみたいに「安全ドグマ」に縛られるとたいがいそうなる

**デフォルトの名無しさん** · 2021/07/12(月) 01:08:52.63

>>245
プログラマーの基本！　とか　システムを作れない(ｷﾘｯ　とか言われても
既存のシステムがそうなってるんだという話
「システムには、ascii しか使えない！」とか言ったら、客に帰れと言われるだけ

>>246
sjisファイルを読み込みたい
でもチュートリアルにあるようにBufReaderは使えない
そりゃ読み込んだ後、変換処理したら何でもありでしょ
でも、ネイティブに処理できん？と思う
むしろ安全性にこだわる割に文字に対するこの雑さは何なの？と

**デフォルトの名無しさん** · 2021/07/12(月) 01:27:11.82

論理的な問題点以前に、言語として見た目的な美しさも無いし、記述が
簡潔でもなければ直感的でもなく、無駄に長くなる。

**242** · 2021/07/12(月) 01:50:03.57

システムには、ascii しか使わないのは、Linux の基本

AWS でも、そう。
半角空白もバグるから、使わない

必ず、客から注意される。
日本語のファイル名・半角空白を使わないでと。
バグるから

例えば、5ch は、sjis だからバグだらけ。
; を書いていないのに、文字列の後ろに、; が付いてるとか

sjisとか、Windows以外では、どうしようもない

**デフォルトの名無しさん** · 2021/07/12(月) 02:01:17.96

encoding-rsつかいにくい

**デフォルトの名無しさん** · 2021/07/12(月) 02:17:50.78

>>249
バイト列としてVec<u8>に読んじゃえば後はCと一緒じゃん
それともlocaleとwchar_tフル活用したいという話？

**デフォルトの名無しさん** · 2021/07/12(月) 02:37:38.72

>>253
それでcrlfでsplitしろって？
なんて原始的な…

**デフォルトの名無しさん** · 2021/07/12(月) 03:41:51.48

UTF-8(とchar用のUTF-32)以外滅んでほしいが､過去の遺産がそれに対応してないという現実的な問題...
まぁencoding_rsってクレート使って変換してやればヨシ

**242** · 2021/07/12(月) 04:00:29.19

>>242
に書いたみたいに、

sjis, UTF-16 などのWindows 用言語で、
唯一バグらないのは、WSL だけ

WSL でLinux側から、Windows側のドライブを見た時だけ、
日本語のファイル名を正常に変換できる

Windows Terminal, VSCode のRemote WSL などで使える

ひょっとして、Windows用言語を扱っていて、WSLを使っていないの？

**デフォルトの名無しさん** · 2021/07/12(月) 09:20:21.53

>>249
変換せずに扱いたいのか？いまいちよくわからんが、既存の言語で理想的なやつってどれ？
Rustは文字列に関しては最もちゃんとしてる方だと思うけど

**デフォルトの名無しさん** · 2021/07/12(月) 09:26:54.48

あ、あとascii/WSLおじさんは気にしなくていいと思うよ
少なくともRustにそんな制限はない
Cとかだとasciiに限定したい気持ちもわからなくはないけど

**デフォルトの名無しさん** · 2021/07/12(月) 09:39:13.23

・ファイルシステム上のエンコーディング
・OSのAPIのエンコーディング
・言語のAPIのエンコーディング
・言語の文字列のエンコーディング
それぞれ独立だし変換しあってることをおじさんは理解していないと見える

**デフォルトの名無しさん** · 2021/07/12(月) 09:40:16.32

最後2つは基本的に同じだけど

**デフォルトの名無しさん** · 2021/07/12(月) 09:56:37.25

>>255
でもUTF8は「ひらがな」ですら3バイトになるので困る。

**デフォルトの名無しさん** · 2021/07/12(月) 11:12:15.24

>>256
へー WSL って言語だったんだωωω

**デフォルトの名無しさん** · 2021/07/12(月) 11:13:38.78

>>260
違うよ

**デフォルトの名無しさん** · 2021/07/12(月) 11:24:40.84

>>257
どれが理想的というか、rustは特にめんどい気がした
fgetsが出来ればそれでいいんだが

**デフォルトの名無しさん** · 2021/07/12(月) 12:42:05.71

>>261
最近だと何に困った？

**デフォルトの名無しさん** · 2021/07/12(月) 12:58:50.09

>>249
sjisを変換せずそのまま内部表現として標準的に扱うプログラミング言語って具体的に何？

もちろん全ての言語でバイト配列としては扱えるけどsjisにとってそれは無意味であり
先頭から全読みしないとsjisの1バイト目か2バイト目かすらわからない欠陥sjis仕様のためsjisそのまま使うことはないよね

仮に入力も出力もsjisなら内部表現もsjisのままにしてsjis処理関数いっぱい
書くのも見合うケースがあるかもしれないけど
入出力の片方がsjisでないならば他との変換必ず必要だから内部表現をsjisにこだわる意味はないよね

一方で内部表現として処理を無条件に簡単にしようとするとUTF32で1文字32bitにするしかないけど常にUTF32強制ではメモリが無駄すぎる
そこでメモリ上だけでなくファイルもネット通信も無駄を避けるためにUTF8を用いる
という当たり前の帰結になりRustもそうだけどこれの何が不満なの？

**デフォルトの名無しさん** · 2021/07/12(月) 13:37:26.66

>>266
いや、内部表現なんてどうだっていいんだって
utf8以外のテキストを使うとResult<Error>でぶっ飛ばされるのが面倒なの

**デフォルトの名無しさん** · 2021/07/12(月) 13:41:52.17

>>267
それはUTF8文字列として扱う関数を使うからそうなる
普通に生バイト列として扱う関数を呼べばよい
このへんは多くのプログラミング言語で同じ話

**デフォルトの名無しさん** · 2021/07/12(月) 13:45:10.21

>>264
fgetsで良いって言うなら単にVec<u8>で読むだけだと思うけど
エラー処理が面倒というならとりあえずunwrapしてればいいし
そういうので文字数がかさむのが嫌だというなら、Rustは合ってないんじゃないかな
Rustは基本的にソースコード上にいろいろ明記したい言語なので

**デフォルトの名無しさん** · 2021/07/12(月) 14:07:37.33

>>269
それって行の切り出し(改行までのsplit)って自分で書かなきゃだめ？

**デフォルトの名無しさん** · 2021/07/12(月) 14:14:18.06

>>270
それは書かないといけないね
たぶんRustが好きな人は「fgetsだと何が改行コードとして想定されてるのか分からなくて不安」
って人が多いんじゃないかな
実際Linux環境でCR改行のファイルをfgetsするとどうなるのかよく分からんし
そういうふうに処理系がうまくやってくれることを期待するならGoとかもほうが合っているかも

**デフォルトの名無しさん** · 2021/07/12(月) 14:16:40.71

splitすればいいだけじゃなくて？

**デフォルトの名無しさん** · 2021/07/12(月) 14:18:27.57

うーん、Windowsでsjisファイル読み込むのってそんなにニッチなのか……

>>271
>たぶんRustが好きな人は「fgetsだと何が改行コードとして想定されてるのか分からなくて不安」
>って人が多いんじゃないかな

BufReaderがあるので、それはないかと

**デフォルトの名無しさん** · 2021/07/12(月) 14:29:03.08

>>273
read_lineはLF区切りって決まってるからそんなに気にならないけどな
fgetsはプラットフォーム依存じゃなかったっけ？
もう忘れてしまったけど

**デフォルトの名無しさん** · 2021/07/12(月) 14:30:57.94

これはRustの問題ではない
例えばスクリプト言語であるJavaScriptでもsjisファイルを読み込むにはNodeでも標準サポートはない
だから生バッファに読み込んで次にそのsjisを内部へ変換するという手順となる
いずれにせよ文字コード変換の一行が余分に入るだけでありどの言語でも大した問題ではない

**デフォルトの名無しさん** · 2021/07/12(月) 14:31:19.34

>>272
うん、それはそうなんだ>splitすればいい

でも、なんでこんなにしつこく聞いたかっていうと
最近の言語にこんな基本的な機能ないわけないだろ？と思ったからなんだ

確かに自分で書いたって大した処理じゃない
でも、一人ひとりがそんな原始的なコード書いてるの？
ありえない　標準で用意しとけやって

**デフォルトの名無しさん** · 2021/07/12(月) 14:35:03.79

>>275
文字コード変換だけなら文句は言わない
昔からMulitbyteToWideCharを噛ませるぐらいのことはやってたからね

**デフォルトの名無しさん** · 2021/07/12(月) 14:40:47.93

最近の言語としては標準ライブラリが小さいというのはあるね
代わりに外部ライブラリをたくさん使うという方針
今のケースならこれかな
https://crates.io/crates/bytelines

**デフォルトの名無しさん** · 2021/07/12(月) 14:48:08.10

>>278

おおっ！　これ良さそうだね！
試してみる！　サンキュー

**デフォルトの名無しさん** · 2021/07/12(月) 14:48:41.98

要はバイナリのsplitがあればいいんだろ
まあニッチだし標準には入りにくいだろうな

**デフォルトの名無しさん** · 2021/07/12(月) 14:56:20.42

>>265
ログ的なものや、テキストファイルが大きくなる。
開発中にはソースやバイナリを高頻度に単純コピーでバックアップしたいが、
そのとき、毎回毎回大きくなるのでディスクの無駄使いになる。

**デフォルトの名無しさん** · 2021/07/12(月) 15:01:47.66

>>281
それはもうutf8の問題じゃないんじゃないか？

**デフォルトの名無しさん** · 2021/07/12(月) 15:08:46.48

>>281
今さら何を言ってるんだ？
UTF-8が長いとか短いとか論争してたのは20世紀の過去の話であり今は2021年だ
UTF-9のエイプリルフールRFCが出たのですら16年前の2005年だ
既に20世紀に今後は世界中全てUTF-8で行くと方向が決まった

**デフォルトの名無しさん** · 2021/07/12(月) 15:25:03.01

日本語処理が僅かに遅くなる。

**デフォルトの名無しさん** · 2021/07/12(月) 16:15:05.27

>>242
No.
Linux やら BSD やらでファイル名を UTF-8 と保証しているものはたぶん少数派だ。
ロケール設定で UTF-8 を選ぶのが多数派になっているのは疑いがないが、
システムとして保証しない分だけ Windows よりつらい。

**デフォルトの名無しさん** · 2021/07/12(月) 16:35:47.66

>>282
日本人そっちのけで勝手にアメリカ人が作った文字コード。
日本(と中国)だけが不利になった。

**デフォルトの名無しさん** · 2021/07/12(月) 16:36:54.04

最近でもJSは日本語の文字イベントがサポートされてない。
アメリカ中心。

**デフォルトの名無しさん** · 2021/07/12(月) 17:25:47.35

UTF-8の規格制定の時にはアジア圏も割と口出しだんではなかった？

**デフォルトの名無しさん** · 2021/07/12(月) 17:31:04.46

余り上手く行ってなかったと聞いている。

**デフォルトの名無しさん** · 2021/07/12(月) 17:47:35.65

>>287
日本語の文字イベントという意味不明なものは何だ？
日本語じゃない文字イベントというのも聞いたことないぞ

**デフォルトの名無しさん** · 2021/07/12(月) 19:18:49.33

sjisのfgets()相当の件だけど
標準のBufReaderのlines()で回すのは何が不満なんだっけ？

use std::error::Error;
use std::fs::File;
use std::io::{BufReader, BufRead};
use encoding_rs::SHIFT_JIS;
use encoding_rs_io::DecodeReaderBytesBuilder;

fn main() -> Result<(), Box<dyn Error>> {
　let file = File::open("sjis.txt")?;
　let reader = BufReader::new(DecodeReaderBytesBuilder::new().encoding(Some(SHIFT_JIS)).build(file));
　for line in reader.lines() {
　　println!("utf8: {}", line?);
　}
　return Ok(());
}

**デフォルトの名無しさん** · 2021/07/12(月) 19:44:27.20

>>290
nativeのWin32やMFCだと、IMEで日本語入力した時、WM_CHARで
SJISやUnicodeの文字コードを取得できるが、ブラウザ上のJSだと、
英字の範囲でしかそれに該当するイベント、つまり、IMEで
漢字やひらがなを打った結果を取得する文字イベントが無い。

**デフォルトの名無しさん** · 2021/07/12(月) 19:46:32.99

>>292
https://developer.mozilla.org/ja/docs/Web/API/Element/compositionstart_event
はい次

**デフォルトの名無しさん** · 2021/07/12(月) 20:38:52.08

>>291
いいね！
取得した文字列をOsStringに変換しなくても
なぜかファイルパスとして正常に動作するし(UTF16じゃなくていいのか……)
encoding_rs標準になればいいのに

**デフォルトの名無しさん** · 2021/07/12(月) 22:26:31.98

encoding_rsが標準になって欲しい(stdに入って欲しい？)のはなぜ？

**デフォルトの名無しさん** · 2021/07/12(月) 22:49:13.65

>>295
・基本機能だから
・ロジックを標準化するため
・Cargo.tomlのdependancyに記述するのが面倒だから
特にバージョン指定

**デフォルトの名無しさん** · 2021/07/13(火) 00:30:07.97

>>296
stdに取り込む提案のRFC書いてみたら？

**デフォルトの名無しさん** · 2021/07/13(火) 03:10:04.82

>>293
中身を理解して無いくせに黙ってろ。

**デフォルトの名無しさん** · 2021/07/13(火) 03:20:46.36

ｗｗｗ

**デフォルトの名無しさん** · 2021/07/13(火) 06:39:54.56

UTF8（とASCII）以外の文字コードを扱うのが基本機能とは思えんが

**デフォルトの名無しさん** · 2021/07/13(火) 07:23:42.37

>>296
> 基本機能だから
UTF-8さえ標準で扱えれば問題ない､UTF-8は世界標準だから
よって基本機能ではない
なので標準化する必要もないし､cargo.tomlに依存ライブラリを書くのが面倒ならapt-getでライブラリをインストールして使うC言語でも使えばいい

**デフォルトの名無しさん** · 2021/07/13(火) 08:54:58.88

>>301
「utf8以外を使う場合のやり方を標準化してほしい」って要望に対して
「utf8を使え」ってのは答えになってない

**デフォルトの名無しさん** · 2021/07/13(火) 09:10:42.11

今は多少議論の余地があっても、数年したら
「なんでstdにSJIS扱うライブラリ入ってるの？　めったに使わないのにバカじゃねーの」
って言われるのが目に見えてる

**デフォルトの名無しさん** · 2021/07/13(火) 09:14:58.89

エンコーディング関連のコードは量が多いだろうから
あらゆるプログラムのコンパイル時間を増やしたりバイナリサイズを大きくしたりするだけの価値があるかという議論にはなりそう

**デフォルトの名無しさん** · 2021/07/13(火) 09:17:07.48

encoding_rsはSJISのためのライブラリじゃないでしょ