Rust part25

**デフォルトの名無しさん** · 2024/07/31(水) 00:46:26.17

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

公式ドキュメント
https://www.rust-lang.org/learn

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

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

※Rustを学ぶ際に犯しがちな12の過ち
https://dystroy.org/blog/how-not-to-learn-rust

※Rustのasyncについて知りたければ「async-book」は必読
https://rust-lang.github.io/async-book/

※次スレは原則>>980が立てること

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

ﾜｯﾁｮｲスレ
プログラミング言語 Rust 4【ﾜｯﾁｮｲ】
https://mevius.5ch.net/test/read.cgi/tech/1514107621/

**デフォルトの名無しさん** · 2024/08/23(金) 21:41:42.80

>>369
それは単純に参照を借りっぱなしになってるエラー
どこまで何をしたいのかによるけど
そのコンパイルエラーを解消したいだけなら
Cons(T, Box<List<T>>)を
Cons(Rc<T>, Box<List<T>>)にして
Some(t)をSome(t.clone())すればよい
ちなみにUnsafeCellは内部可変性の源泉なので
そういう新たな汎用型を作る時に使うものでunsafeだよ
一般プログラマーは使ってはいけない

**デフォルトの名無しさん** · 2024/08/23(金) 21:46:56.38

名前に露骨に Unsafe って付いてるんだから十分な理解なしに使うのはやめておけという意図は感じるよな。

**デフォルトの名無しさん** · 2024/08/23(金) 21:47:30.17

>>370
UTF-32の方が単純で良かったんじゃないか？

**デフォルトの名無しさん** · 2024/08/23(金) 22:02:55.80

>>373
ファイルもネット通信もUTF8に統一されていってる状況だから
それらを無変換で済むUTF8がベストだよ
UTF32はメモリを無駄に消費してメリットがないよね

**デフォルトの名無しさん** · 2024/08/23(金) 22:05:42.82

UTF-8 はランダムアクセスに難があるが文字列のランダムアクセスってそんなに要らんだろという割りきりだな。
やりたければ UTF-32 用の型を使えるし、あくまでも言語の基本には UTF-8 を据えるってだけ。

**デフォルトの名無しさん** · 2024/08/23(金) 22:07:14.75

>>371
そこは一般プログラマーじゃないと仮定して、UnsafeCell使うならこんな感じでいいんですかね？
RustのUBにちょっと詳しくなくて

https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=509935956fa3b81133414a9e19920557

**デフォルトの名無しさん** · 2024/08/23(金) 22:26:58.16

UnsafeCellは内部可変性を持つ安全な型を作るためのunsafeな部品として存在している
目的外に使う人に対しては今後は他の質問についても答えない

**デフォルトの名無しさん** · 2024/08/23(金) 22:27:06.29

>>376
値が数値だから今のところ問題ないけどこの実装だとListを新しいConsに突っ込んだ瞬間に
先頭の値の参照先が無効になりそうだな

自作にこだわらないならtyped-arenaを使うといい
https://docs.rs/typed-arena/latest/typed_arena/
小さいライブラリだから自作の参考にもなると思う
ライブラリ使わないならどこかでunsafeは必要になる

**デフォルトの名無しさん** · 2024/08/23(金) 22:50:35.38

ちょっとuser-friendlyに整理してみた
https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=509935956fa3b81133414a9e19920557

>>378
ListNode<T>は絶対にBoxに包むようにして、itemはヒープ上のTを指してるので
unsafeの中で間違ってBoxをdropしなければ無効な参照は発生しないと思うんですが、どうなんでしょう

typed-arena!
存在は知ってたけど、RefCellと組み合わせてグラフをなんかいい感じに扱えるやつくらいの認識だったので完全に盲点でした
これでいけそうです、ありがとうございます

**デフォルトの名無しさん** · 2024/08/23(金) 22:55:03.65

おっとリンク再生成してなかった
ちょっとuser-friendlyに整理してみた版
https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=b0ca47dce14c07da2936f1964bc54485

**デフォルトの名無しさん** · 2024/08/23(金) 23:21:46.23

安全だと思い込んでunsafeを使うやつはCでも使っとけ

**デフォルトの名無しさん** · 2024/08/23(金) 23:29:15.36

依存クレートの中からunsafeを検索して一覧表示するようなツールある？

**デフォルトの名無しさん** · 2024/08/24(土) 00:11:50.62

数えるだけならcargo-geiger
ナンセンスすぎて使ったことないけど

**デフォルトの名無しさん** · 2024/08/24(土) 05:53:44.99

>>382
あまり意味がない気もする
actix-webの作者は「unsafe使うな」「それはRustのやり方ではない」という沢山の声にうんざりして開発停止する事件が起きた
unsafeは危険というよりも「このコードの安全性はコンパイラでは検証しないので実装者が責任を持つ」ブロックと考えて、よくテストされたライブラリについてならある程度信用して良いと思う

**デフォルトの名無しさん** · 2024/08/24(土) 07:54:28.69

unsafeは人間が安全性を保証しなければいけないため、必ず多くの監視者がいなければいけない。
そして不必要なコードと必要で安全なコードを皆で選別しなければならない。
パフォーマンスにほぼ影響なく無くせるケースは無くすべきというのが第一原則。

**デフォルトの名無しさん** · 2024/08/24(土) 07:56:32.18

一方でRustの標準ライブラリには何千ものunsafeが存在していて、安全なインターフェースを提供してくれている。
このおかげで我々はunsafeを使わずにパフォーマンスの高いコードを書くことができる。
標準ライブラリと同様に他のクレートでも下支えをしてくれるものは同じ立ち位置として認められているものが多い。
つまり必要不可欠なものである。
いずれにしてもライブラリ内に隔離して外向けに安全なインターフェースを提供してくれることが第一原則。

**デフォルトの名無しさん** · 2024/08/24(土) 08:06:32.30

Rust の参照についている様々な制約は機械的に解析可能なように制限したのであって
人間的な感覚での適切な抽象やデザインパターンと両立不可能な場合がある。
機械的検証可能性を維持するために不自然なデザインを持ち込むのが健全とは言い難いよ。

unsafe はなるべく低レイヤの小さな範囲に押し込めたほうが良いのは確かだが、
プロジェクトの性質によってはそれがもうちょっと高レイヤまではみ出してくることだってあるだろ。

**デフォルトの名無しさん** · 2024/08/24(土) 08:21:40.08

>>382
grep

**デフォルトの名無しさん** · 2024/08/24(土) 08:22:12.74

>>387
適切な抽象やデザインパターンと両立不可能な場合がある、ってマジ？
そんな話は聞いたことないな
具体的な例を教えて

**デフォルトの名無しさん** · 2024/08/24(土) 09:00:02.66

>>297
tauriがrustを基盤としたフレームワークなのだから
rustと特別な関係にあるservoに移行するのは必然では？

**デフォルトの名無しさん** · 2024/08/24(土) 10:45:01.27

servoが最低限まともに動くようになるには、あと軽く5年はかかる
今のバージョン動かしてみ？
夢見すぎ

**デフォルトの名無しさん** · 2024/08/24(土) 11:01:21.63

>>384
>unsafeは危険というよりも「このコードの安全性はコンパイラでは検証しないので実装者が責任を持つ」ブロックと考えて、よくテストされたライブラリについてならある程度信用して良いと思う
こういうスタンスはダメだよな
作ってるアプリによっては許される場合もあるんだろうけど

**デフォルトの名無しさん** · 2024/08/24(土) 11:31:23.33

>>390
俺はtauriのコアコンセプトはOSが提供するブラウザエンジンを使い、バイナリサイズやセキュリティアップデートの問題を解決することだと俺は思ってるんだ。
だからRust使ってるからservo使うってのは門外漢には自然に見えてもコアコンセプトを忘れてもともとの問題を解決しないOSSになっていってる感じがするんだよな。

**デフォルトの名無しさん** · 2024/08/24(土) 11:47:25.22

ブラウザエンジンの選択肢が増えるだけでしょ
wryの中のfeatureが増えるのかwryごとservoに差し替えるfeatureになるのかは知らんけど

**デフォルトの名無しさん** · 2024/08/24(土) 12:27:15.89

.NET 9の新機能としてC#版Tauriが来るらしい
Go版Tauriもあるらしいし、流行ってるのかな

**デフォルトの名無しさん** · 2024/08/24(土) 12:33:53.63

疎結合でブラウザを GUI として使うには接続部分を上手く標準化する必要がある。
参加が多いほど標準化の圧力が生まれるし、良いことだと思う。

**デフォルトの名無しさん** · 2024/08/24(土) 13:14:00.45

いまどき疎結合とか意味のないこだわりだな

**デフォルトの名無しさん** · 2024/08/24(土) 13:30:29.34

疎結合とかそういうかっこいい話じゃなくて
今どき新規にGUIツールキット作ってもウィジェット開発してくれる人が集まらないから
Web技術転用してしのぐかって話でしょ？

当のMicrosoftは3連続ぐらいで新GUIツールキットの開発に失敗しバグ残したまま撤退を繰り返してるし

**デフォルトの名無しさん** · 2024/08/24(土) 13:38:09.55

unicode の表示からしてウェブブラウザ以外は規格に追い付いてない感触はあるなあ……

**デフォルトの名無しさん** · 2024/08/24(土) 13:46:07.91

>>393
そう思うならforkすればいいのに
オープンソースなんだし
コード書かない人には一家言もない世界よ

**デフォルトの名無しさん** · 2024/08/24(土) 13:46:41.99

いまはネットワークが高速で繋がっている前提なのなw

**デフォルトの名無しさん** · 2024/08/24(土) 13:54:50.23

>>395
仕組みは組み込みWebViewをネイティブの上で起動してるだけだから作るのが大して手間じゃないし実装してみたって感じでしょ

**デフォルトの名無しさん** · 2024/08/24(土) 14:58:54.54

>>382
github

**デフォルトの名無しさん** · 2024/08/24(土) 15:01:04.10

>>387
＋１

**デフォルトの名無しさん** · 2024/08/24(土) 15:03:55.41

>>401
これホント困るわ

**デフォルトの名無しさん** · 2024/08/24(土) 16:36:29.92

>>400
いや、牛丼屋なのに鰻丼を中心にするんだ…みたいな気持ちがあるだけで、俺は現状 tauri に用はないので…。

ちゃんと使ってる crate はコントリビュートチャンスを伺ってるよ。

**デフォルトの名無しさん** · 2024/08/24(土) 16:50:25.05

unsafeブロックってどこからどこまで囲えば良いんだろう

**デフォルトの名無しさん** · 2024/08/24(土) 18:11:39.50

>>407
「可能な限り小さく」が原則

**デフォルトの名無しさん** · 2024/08/24(土) 18:18:35.56

Rustでunsafeは使ってはいけない
例外的にunsafeの使用が認められるのは以下2点のみ
ベテランが基盤クレートを提供する時
ベテランがFFI部分を記述する時

**デフォルトの名無しさん** · 2024/08/24(土) 18:20:35.25

unsafe なことをやっている箇所をなるべく小さい範囲で囲むべきだがお互いに関係のある複数の unsafe がごく近くにあるならまとめて囲むほうが分かりやすいということはあるかもね。

**デフォルトの名無しさん** · 2024/08/24(土) 18:29:15.33

そういうケースを除くとunsafeを使ってる者は技術力がないだけのバカと
パフォーマンスにほとんど変化しないのに高速化してるつもりで保守性を下げてるアホだからな

**デフォルトの名無しさん** · 2024/08/24(土) 18:32:37.91

Rustでどう書くのか分かりませんが、C言語で書けば、
BYTE *ConvertUintToPtr( Uint32 u ) {
　unsafe {
　　return (BYTE*)u;
　}
}
のような関数をRustで作ることは出来ますかね？

**デフォルトの名無しさん** · 2024/08/24(土) 18:33:08.29

>>408
最小限にするなら、>>380はこうしたほうがいいってことかね
https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=f27cd2a3b6b850770a839c17d6fe3ec4

unsafeブロックもブロックではあるから、通常のブロックと同様にdropが働くから、それに注意して無効な参照をsafe内に持ち出さないようにすればいいってことかね？

**デフォルトの名無しさん** · 2024/08/24(土) 18:43:12.73

>>406
現状だと
servo「うちの鰻丼を置かせてください！」
tauri「まぁ客に出せる味になったらメニューに加えてもいいよ」
くらいの温度感に見えるけどなぁ。これまでの発表はservo側からだし、tauriチームとしてservoに全面移行するなんて話は出てないと思うけど

**デフォルトの名無しさん** · 2024/08/24(土) 18:46:57.91

>>413
unsafeの作法も知らない雑魚はunsafe Rustを使うな
基礎から学んで出直してこい

**デフォルトの名無しさん** · 2024/08/24(土) 18:51:25.05

unsafe Rust使うくらいならCでよくない？
反対意見あったら言ってくれ

**デフォルトの名無しさん** · 2024/08/24(土) 18:52:59.44

>>412
当然できるけど
危険な行為なので熟練者とキチガイしか使わないよ

**デフォルトの名無しさん** · 2024/08/24(土) 18:53:02.17

>>415
一応Referenceのunsafe blockの部分は読んだけど、nomiconも全部読まなきゃだめ？
具体的にどこが間違っている/作法に反しているのか指摘してくれるとありがたいんですが……

**デフォルトの名無しさん** · 2024/08/24(土) 18:55:23.20

>>417
参考のため、どう書けばいいのか教えていただければ幸いです。

**デフォルトの名無しさん** · 2024/08/24(土) 18:55:51.72

>>416
反対意見なんてないよ
人間はバカだからC/C++ではなくRustを使わざるを得ない状況になってるんだし
なるべくならRustなんて使いたくもない

**デフォルトの名無しさん** · 2024/08/24(土) 18:57:28.86

>>416
インフラやFFI部分のライブラリを作る上級者は例外として
unsafeを使うのはキチガイばかりだね

**デフォルトの名無しさん** · 2024/08/24(土) 19:07:44.35

>>412
変換するだけならunsafeも特に要らなくて、ただのasキャストでいいみたいね
fn convert_uint_to_ptr(u: usize) -> *mut u8 {
u as *mut u8
}

これをやるだけの関数なら、まだstableじゃないけど標準ライブラリにもあるようで
安全にするためにstrict provenance rulesなる仕様を検討中な様子
https://doc.rust-lang.org/std/primitive.pointer.html#method.from_bits-1
https://doc.rust-lang.org/std/ptr/fn.with_exposed_provenance_mut.html

**デフォルトの名無しさん** · 2024/08/24(土) 19:24:20.93

ポインタは観測するまで安全

**デフォルトの名無しさん** · 2024/08/24(土) 20:06:41.28

逆参照しなきゃ安全
だけど大体はアドレスがわかってるならそれを指すポインタや参照もわかってるはずなのでアドレスをポインタにする機会はそんなにない

**デフォルトの名無しさん** · 2024/08/24(土) 20:08:48.83

>>392
そらそうやけど、それでうまく行くならC++でええやんいう話になるわな

**デフォルトの名無しさん** · 2024/08/24(土) 20:22:17.51

Rustに不慣れで技術力の低い人がunsafeを使う傾向が高い
ほとんどのケースは既存の安全なパーツを組み合わせるだけで安全に実装できる

**デフォルトの名無しさん** · 2024/08/24(土) 21:14:33.88

>>426
単発君
自分でunsafeを書く必要性がない書く気がないならそれでいいと思うし、その立場は理解したから、どうか他人の足を引っ張らないでくれ
unsafeの書き方を学ぼうという同志がいないのならそのうち去るから、すまないがそれまで待ってくれないか

**デフォルトの名無しさん** · 2024/08/24(土) 21:26:04.07

unsafe で UB になる場合を知りたい場合にはどこに仕様が書いてあるのかがそもそもわからん。

**デフォルトの名無しさん** · 2024/08/24(土) 21:26:45.92

UnsafeCellを使ってる頭のおかしな人のコードはborrow checkerに引っかかってコンパイルを通せないところから始まってるよね
unsafeの使い方を学ぶのではなくsafe Rustの使い方を学ぶべきかと

**デフォルトの名無しさん** · 2024/08/24(土) 22:11:07.05

>>428
現状のベストエフォートのまとめはこれですかねえ
LLVMのマニュアルなんて参照しちゃってるから、LLVM IRまでのloweringの詳細を完璧に把握でもしていない限りこれを一次資料として参考にするってのは無理そうですが……
https://doc.rust-lang.org/reference/behavior-considered-undefined.html

あとは呼んでいるunsafe fn/実装しているunsafe traitのドキュメント（当たり前）と、the Referenceをundefinedで検索した結果とかでいいんでしょうか

**デフォルトの名無しさん** · 2024/08/24(土) 22:14:58.07

既存の安全なパーツを使いこなせる熟練者であることがunsafeを書くための最低限の資格だ
これができないとunsafeを使うべきか否かという入口すら判断できない

**デフォルトの名無しさん** · 2024/08/24(土) 22:53:26.45

Rust のメモリまわりの動作モデルは結局は C/C++ に合わせることにしたみたいな話をどこかで見たようなおぼろげな記憶がちょっとある。
LLVM がなんだかんだで C/C++ を想定した形になってしまっているのとその辺の低レイヤの部分がちゃんとモデル化されている言語が C/C++ くらいしかないから Rust のためにあらためて検討するくらいならもう合わせちゃって良くない？みたいなニュアンスだったと思うんだけどどこで見たのかも思い出せないから違ってたらごめんね。

**デフォルトの名無しさん** · 2024/08/24(土) 23:22:54.73

>>422
有難うございます。
ところで、Rustでは、unsafe 以外では、専ら参照型が使われると思っていたのですが、
unsafe を使わない部分でも、ポインタ型 * が使えるようですね。
Rustにおけるポインタ型を参照型のアドレスに採用する方法も教えていただければ幸いです。
C++ であれば、
T x;　//xは、T型の変数。
T *p = &x;　//pは、T型へのポインタ型。アドレスは変数xのアドレス。
T &r = *p;　//rは、T型の参照型。
で、参照型rのアドレスがpの指すアドレスに一致しますね。

**デフォルトの名無しさん** · 2024/08/24(土) 23:31:10.68

>>433
生ポの参照外しはできない
生ポを参照にすることもできない
それらはunsafe

**デフォルトの名無しさん** · 2024/08/24(土) 23:50:29.93

>>434
では、C++であるならば、以下の様に書けそうなコードをRustで書くとすると
どうなるでしょうか。
BYTE &ConvertPtrToRef( BYTE *p ) {
　unsafe {
　　return *p;
　}
}

**デフォルトの名無しさん** · 2024/08/25(日) 00:56:39.20

unsafe { p.as_ref().expect("p is not null") }
unsafe { p.as_mut().expect("p is not null") }
unsafe { &*p }
unsafe { &mut *p }

**デフォルトの名無しさん** · 2024/08/25(日) 01:28:05.04

そもそもRustの参照とC++の参照が1対1に対応しないので、そこを無視してもどうなんだという問題

**あぼーん** · NG

あぼーん

**デフォルトの名無しさん** · 2024/08/25(日) 06:34:29.42

>>438
まじか

**デフォルトの名無しさん** · 2024/08/25(日) 15:06:59.24

>>433
std::slice::from_raw_parts
std::slice::from_raw_parts_mut

**デフォルトの名無しさん** · 2024/08/25(日) 16:07:14.33

unsafe大好き

**デフォルトの名無しさん** · 2024/08/26(月) 07:21:14.48

unsafe rustよりzig

**デフォルトの名無しさん** · 2024/08/26(月) 07:32:17.72

zigは未完成

**デフォルトの名無しさん** · 2024/08/26(月) 11:03:43.55

zigよりNim

**デフォルトの名無しさん** · 2024/08/26(月) 12:45:51.89

Rustでunsafeを迂闊に使っていると信用失墜リスクがある
例えば安全に書けるシーンでunsafeを使っていればRustに疎くレベルが低いと客観的に判定されてしまう
そして書いたコードは信頼されなくなるため要注意だ

**デフォルトの名無しさん** · 2024/08/26(月) 13:27:24.67

んでNimよりCってわけ

**デフォルトの名無しさん** · 2024/08/26(月) 23:59:19.70

unsafeなしに拘るならそもそもunsafeという仕様のない言語を使えば良いのでは

**デフォルトの名無しさん** · 2024/08/27(火) 00:09:57.79

unsafeはFFI部分と基盤ライブラリで必須
そのためにある

**デフォルトの名無しさん** · 2024/08/27(火) 01:18:15.13

あんまり必死になると>>307が図星なのがバレるぞ

**あぼーん** · NG

あぼーん

**デフォルトの名無しさん** · 2024/08/27(火) 05:12:31.56

>>450
既に貰ってる

**デフォルトの名無しさん** · 2024/08/27(火) 14:18:24.38

unsafeって危険だから描くんじゃなくて
unsafeを描くことで危険を回避出来るんだ
だからunsafeが使われてるからって危険なコードじゃないんだ
unsafeを観たら危険だと脊髄反射する方が馬鹿の誤解

**デフォルトの名無しさん** · 2024/08/27(火) 14:18:59.31

だから >>445 はピンぼけ的外れ

**デフォルトの名無しさん** · 2024/08/27(火) 14:29:34.76

RustかC++のどちらかなのかはRustで落ち着いたけど
unsafe RustかCかは結局どっちがいいんだい？

**デフォルトの名無しさん** · 2024/08/27(火) 14:38:55.67

>>454
え？いつの間に落ち着いたの？

**デフォルトの名無しさん** · 2024/08/27(火) 14:47:28.58

>>454
Zigだよ
ZigこそがベターCで、C++風味が入っていない

**デフォルトの名無しさん** · 2024/08/27(火) 15:35:17.48

>>452
おまえは何を言ってるんだｗ

**デフォルトの名無しさん** · 2024/08/27(火) 15:36:49.68

>>456
1.0になってから来てくれ

**デフォルトの名無しさん** · 2024/08/27(火) 16:13:13.47

>>454
最大サイズのマインスイーパーを30分かけてじっくり解きたい → C
マインスイーパーは最小でいいから余った時間でソリティアやりたい → (unsafe) Rust
作業に戻る → C++

**デフォルトの名無しさん** · 2024/08/28(水) 04:07:55.29

最大サイズのマインスイーパーだと
プログラムに解かせるのに30分くらいかかるのか
それはメモリを積むと速くなったり
コア数を積むと速くなったり
未知のアルゴリズムで速くなったりする？

**デフォルトの名無しさん** · 2024/08/28(水) 09:07:31.11

まあそうなるよなw
頭悪いたとえ話だから仕方がない

**デフォルトの名無しさん** · 2024/08/28(水) 09:16:54.18

でもプログラムに解かせるのに30分もかからないだろくらいの感覚は常識として持っておいて欲しいところ

**デフォルトの名無しさん** · 2024/08/28(水) 10:32:38.93

マインスイーパーはNP完全であると証明されていてかなり難問
さらにそもそも常に論理的に解けるわけではないためリゾルバーは勝率100%ではなく問題難易度別に平均勝率が示される
具体的には論理的推論で開けられる場所がなくなった時に人間は運ゲーとなるが機雷のある場所の確率計算により勝率を高められる
その手法ならびに巨大サイズによっては計算時間30分はありうるのではないか

**デフォルトの名無しさん** · 2024/08/28(水) 11:57:33.04

>>460
そんな訳無い
10秒もかからん

**デフォルトの名無しさん** · 2024/08/28(水) 12:03:45.27

例えば話悪すぎるのは理解するけど、プログラムにマインスイーパー解かせる話だっけ

**デフォルトの名無しさん** · 2024/08/28(水) 12:21:33.97

>>464
なぜ0.1秒ではなく1秒ではなく100秒ではなく10秒なのか？

**デフォルトの名無しさん** · 2024/08/28(水) 12:23:32.67

>>465
プログラム板のプログラミング言語スレでそれ以外にどんな可能性があるか？

**デフォルトの名無しさん** · 2024/08/28(水) 13:59:37.19

誤魔化せれば何でもいいから意味の無いレスを拾ってごちゃごちゃ書き込んでるんだろう

**デフォルトの名無しさん** · 2024/08/28(水) 16:33:13.07

いつのまにかAndroid公式ドキュメントにRustの章ができてた

**デフォルトの名無しさん** · 2024/08/28(水) 17:22:14.56

AndroidはJNIをJavaとバイナリとの間に噛ませないといけないからほんとに面倒くさい