Rust Part5

**デフォルトの名無しさん** · 2018/02/11(日) 20:07:24.54

Mozilla発のRust言語のスレ

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

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

前スレ
https://mevius.5ch.net/test/read.cgi/tech/1507970294/

**デフォルトの名無しさん** · 2018/06/20(水) 18:54:56.56

>>616
dreadedに水増ししたの？ｗ

**デフォルトの名無しさん** · 2018/06/20(水) 18:55:44.33

>>617
お前と匿名の一人で統計語ろうっておかしいと思わん？

**デフォルトの名無しさん** · 2018/06/20(水) 18:57:44.45

あとこいつ好感度と使用者の数をごっちゃにしてるの？凄いよそれは
フィボナッチ数列も書けないだけはあると思うよ

**デフォルトの名無しさん** · 2018/06/20(水) 20:41:21.29

フィボナッチ数列って円周率みたくいまもなお計算され続けてたりするのかな

**デフォルトの名無しさん** · 2018/06/20(水) 21:15:36.40

どう考えてもRustなんかよりJavaのほうが愛好家多いだろ
プロダクトの数考えろよ

**デフォルトの名無しさん** · 2018/06/20(水) 21:52:02.37

GithubではJavaScriptが一番多いからJavaScriptが一番愛された言語だよ(お前の中で)
この記事オカズに1年ぐらい黙れそう？
http://wolfbash.hateblo.jp/entry/2017/07/30/193412

**デフォルトの名無しさん** · 2018/06/20(水) 22:24:58.84

ハンバーガーはマクドナルドが世界一売上高いんだから、マクドナルドのハンバーガーが世界一美味いに決まってるだろ？

**デフォルトの名無しさん** · 2018/06/20(水) 22:35:12.33

>>617
なんで一つのサンプルで統計的にとらえるんだ？
プログラマー的におかしいと思わん？

**デフォルトの名無しさん** · 2018/06/20(水) 23:15:44.76

そういや何でmainが必要なんだろね

**デフォルトの名無しさん** · 2018/06/21(木) 07:34:12.21

Nimへの風評被害記事を貼るのはやめろ

**デフォルトの名無しさん** · 2018/06/21(木) 09:00:57.14

初見の人のために何度も貼るけど↓が本スレ

http://mevius.5ch.net/test/read.cgi/tech/1514107621/

ここはキチガイと戯れるスレ

**デフォルトの名無しさん** · 2018/06/21(木) 10:39:54.15

>>623
それ>>8でオレが貼った記事な
このスレでも反論の余地の出なかった良記事。Nimについてはともかく
Rustのクソさについては本当によくまとまってる

**デフォルトの名無しさん** · 2018/06/21(木) 12:34:03.16

真正のアホだった

**デフォルトの名無しさん** · 2018/06/21(木) 17:49:56.62

だからさー。文句あるなら記事に反論してみなよ

取り下げられた記事以外誰も出せないまま人格批判だけとか全く理論的じゃないし
そういう人ばっかだよねRust信者って

**デフォルトの名無しさん** · 2018/06/21(木) 18:20:34.36

ここ本スレじゃなかったのか
お邪魔しました

**デフォルトの名無しさん** · 2018/06/21(木) 18:35:12.47

>>631
archive. fo/7NUr2
なんかある？

**デフォルトの名無しさん** · 2018/06/21(木) 18:46:46.63

>>633
だから取り下げられた記事は反論にならないって
本人が間違いだって取り下げたんだから

**デフォルトの名無しさん** · 2018/06/21(木) 19:00:49.88

>>634
読んでもねぇのに自分勝手に判断して否定するバカが
「理論的じゃない」とかよく言えたな

その言葉そっくりそのままお返しするよ

**デフォルトの名無しさん** · 2018/06/21(木) 20:30:12.03

>>635
自分勝手じゃないよ？
そもそも論を取り下げたのは向こうじゃん
取り下げられた論が議論の俎上に上がるのはおかしいでしょ

**デフォルトの名無しさん** · 2018/06/21(木) 21:05:10.85

ある人がどのレベルでプログラミングしてるか、という差がある
ある人にとってはプログラミングとは設計作業に他ならず
ある人にとってはプログラミングが指の労働でしかない

書き間違えるから、書き忘れるから、という理由でもって
しょうもないバッドノウハウを拝み続ける者すらいる
塩と砂糖を入れ間違う、塩を入れ忘れる、自称料理人
そーいうレベルのプログラマ

**デフォルトの名無しさん** · 2018/06/21(木) 21:10:50.36

クソ言語はRuで始まるの法則。
ソースはRubyｗｗｗｗｗ

**デフォルトの名無しさん** · 2018/06/21(木) 21:12:31.35

>>636
何故取り下げたかの理由も書いてあったがそっちのほうは完全に消えたかな…
アーカイブすら残ってなさそうだ…
「他の記事を貶めるような記事は品性が疑われるからやっぱり取り下げる」
みたいな理由だっと思うけど、どうせお前はそれも認めないんだろ…

………ふぅ………もういいよ……
お前の頭ん中ではRustはクソ言語で良いよ……

**デフォルトの名無しさん** · 2018/06/21(木) 21:16:43.31

まあ人気であることは否定できないし好きに言わせとけば

**デフォルトの名無しさん** · 2018/06/21(木) 21:55:24.51

Rubyスレいってこい

**デフォルトの名無しさん** · 2018/06/21(木) 22:10:18.40

>>636
そういう人だね
お前だけは確実に

**デフォルトの名無しさん** · 2018/06/22(金) 06:32:29.82

rustup update stable

**デフォルトの名無しさん** · 2018/06/22(金) 07:54:28.27

クソ言語に固執し続けるクソ人間

**デフォルトの名無しさん** · 2018/06/22(金) 08:36:26.70

1.27.0がstableになったんね

**デフォルトの名無しさん** · 2018/06/23(土) 08:31:56.29

rustは個人開発向けで仕事に使うものじゃないのね。

**デフォルトの名無しさん** · 2018/06/23(土) 09:39:24.90

ソースは？

**デフォルトの名無しさん** · 2018/06/23(土) 10:17:10.81

Cargo.tomlに対応するrustcの最低バージョン番号を書く方法ってある？

**デフォルトの名無しさん** · 2018/06/23(土) 10:36:49.30

ネタスレで質問するやつはキチガイ

**デフォルトの名無しさん** · 2018/06/23(土) 11:42:32.40

スレチ
Rustスレに行け

**デフォルトの名無しさん** · 2018/06/23(土) 12:03:08.67

キチガイがまともなふりして質問するふりするんだよなー

**デフォルトの名無しさん** · 2018/06/23(土) 12:36:47.01

>>648
https://qiita.com/tatsuya6502/items/8b31e2b162aff78787fe
プロジェクトフォルダにrust-toolchainファイル置いてその中で指定出来るみたい
toolchain指定なんでrustup必須になるのと固定指定しかできないっぽいけど

**デフォルトの名無しさん** · 2018/06/23(土) 17:56:54.88

みんな英語どうやって勉強したの

◆QZaw55cn4c · 2018/06/23(土) 18:09:48.96

>>653
受験勉強で

**デフォルトの名無しさん** · 2018/06/23(土) 18:09:55.67

>>653
俺は英語なら分かるんだけど、日本語はさっぱり分からん

**デフォルトの名無しさん** · 2018/06/23(土) 18:11:27.27

>>654
すげーな
オライリーのやつKindleで読んでるけどまず訳すのが大変だわ

**デフォルトの名無しさん** · 2018/06/23(土) 18:27:07.96

>>655
英語圏に生まれたかったと切に思う

**デフォルトの名無しさん** · 2018/06/23(土) 19:52:59.41

訳さず英語で読んだ方が…
情報の早さ・量・正確さが段違いだし原著読むと意外と難しい単語使われてない。
bind(bound)を束縛とかアホかと。
せめて結びつけとかにしろよと。
翻訳のセンス無さすぎ。
もしくはわざと小難しくして地位を守ってるのか…

**デフォルトの名無しさん** · 2018/06/23(土) 19:59:41.54

結びつけだとassociateの訳ともとれそう
英語と一対一で対応できる和訳の方があとから英語情報に触れるときのハードルを下げると思う

◆QZaw55cn4c · 2018/06/23(土) 20:01:25.05

>>658
get / put / take なんかで言い換えしたからといって、わかりやすくなったとは思わない

**デフォルトの名無しさん** · 2018/06/23(土) 20:13:20.08

それにしても～を～に束縛しますとかセンス無さすぎる。
明治時代の翻訳見習ってほしい。
漢籍の素養が必要だが…

**デフォルトの名無しさん** · 2018/06/23(土) 20:59:38.24

逆に聞くが「変数にbindする」って日本語にどう訳したら自然なんだ？「結びつける」は別の意味になるぞ

明治期のアレは翻訳っていうよりは対応する訳語を創出するって感じだから、単純な翻訳じゃないぞ

「縛りつける」みたいな感じになるしかないと思うんだが
束縛は単純に漢語にしただけで大差なかろう

**デフォルトの名無しさん** · 2018/06/23(土) 21:03:29.72

>>652
ありがとう
一応そういうのあるんだ
そのページの下に書いてある、edition 指定出来るようになるのを期待、という感じかな

**デフォルトの名無しさん** · 2018/06/23(土) 21:53:58.53

> 翻訳のセンス無さすぎ。

お前にはあるかのような口ぶりで

> せめて結びつけとかにしろよと。

↑こんなこと言い放ちつつも

> もしくはわざと小難しくして地位を守ってるのか…

束縛っていうふつうの単語を小難しく感じると白状し
地位を守るだのなんだのという珍妙な価値観まで丸出しにするとは恐れ入る

**デフォルトの名無しさん** · 2018/06/23(土) 22:00:12.26

まあ、英語のbindからして数理論理の変数束縛と同じ単語を別の意味で使いまわしてる
近い分野なんだから専門用語もう少し考えてくれても良かったのに

**デフォルトの名無しさん** · 2018/06/23(土) 22:31:42.63

慣れちゃってるから気づきもしなかったけど代入からして大概だよな。
英語だと単にassignだぞ。

**デフォルトの名無しさん** · 2018/06/23(土) 22:44:14.17

その点、グーグルは気が利いてて、
「錆は、安全性、スピード、並行性に重点を置いたシステムプログラミング言語です。
以前のバージョンのRustが錆びてインストールされている場合、」
だからな

**デフォルトの名無しさん** · 2018/06/24(日) 00:43:46.88

「バインドする」で良いのでは
traitとかcrateとか訳すとよくわからなくなるもの多いし全部カタカナでよい

**デフォルトの名無しさん** · 2018/06/24(日) 00:53:31.43

a に 1 を綴じます。

**デフォルトの名無しさん** · 2018/06/24(日) 01:02:45.16

タイプアノテーションのないバリアブルのタイプはライトサイドをエバリューションしたときのタイプになります

**デフォルトの名無しさん** · 2018/06/24(日) 02:00:22.91

是々非々だな。
型アノテーションのない変数の型は右側を評価したときの型になります
束縛するはバインドするでよかった。SMの趣味ないし。

**デフォルトの名無しさん** · 2018/06/24(日) 07:41:58.64

束縛と代入ってなにか違うんけ？

**デフォルトの名無しさん** · 2018/06/24(日) 08:29:18.59

誰に確認したわけじゃないが、変数に何か値を設定するのが代入で、値に名前を付けるのが束縛だという認識
fn foo(...) {...} は、ある関数に対しfooという名前をつけるので「関数をfooに束縛する」とは言うかもしれないけど、
「fooに関数を代入している」とは言わない、みたいな

**デフォルトの名無しさん** · 2018/06/24(日) 09:14:33.52

緊縛と挿入!

**デフォルトの名無しさん** · 2018/06/24(日) 09:46:27.06

単にイミュータブルかミュータブルかの違いでないの？

**デフォルトの名無しさん** · 2018/06/24(日) 09:52:28.95

>>673
伝統的な表現だと宣言に近いニュアンスかな

**デフォルトの名無しさん** · 2018/06/24(日) 10:29:37.13

rustはバインドしていない状態の変数も合法だからややこしい

let hoge;
hoge = 100; // これをコメントアウトするとコンパイルできない
println!("{}", hoge);

**デフォルトの名無しさん** · 2018/06/24(日) 12:51:16.68

初心者なんですが、文字列を作成して返す関数を作るときって、
fn hoge() -> String { "hoge".to_string() }
と書くものですか？
それとも
fn hoge() -> &'static str { "hoge" }
と書くべきでしょうか？

**デフォルトの名無しさん** · 2018/06/24(日) 13:59:02.13

その例だと関数にする必要なくない

**デフォルトの名無しさん** · 2018/06/24(日) 15:24:02.20

>>678
テケトーにググっただけ

つ https://qiita.com/Mizunashi_Mana/items/db88cb0bff002abce1ae

**デフォルトの名無しさん** · 2018/06/24(日) 18:18:06.50

Stringもstrも返す可能性があるなら Cow<str> で
それ以外なら使えるときは &str を使うのが良いのでは

**デフォルトの名無しさん** · 2018/06/24(日) 19:01:12.28

Stringとstrを両方残しちゃうあたり
優柔不断でグダグダな言語に思えてしまう

**デフォルトの名無しさん** · 2018/06/24(日) 19:14:57.34

はあ…？

**デフォルトの名無しさん** · 2018/06/24(日) 19:22:46.99

C FFIに関する技術資料ってどこにあるんだろ？
ttps://rust-lang-ja.github.io/the-rust-programming-language-ja/1.6/book/ffi.html
にチュートリアルはあるけどexternの記述方法とかがわからない
見よう見まねで書けなくはないけどそのまま行くのは事故の元だし
ついでにlibcが何をしているのかもわからない

**デフォルトの名無しさん** · 2018/06/24(日) 20:18:07.31

>>684
CのヘッダからRustのインターフェースを自動生成してくれる
bindgenを追っかけてみればよいかと
https://github.com/rust-lang-nursery/rust-bindgen

**デフォルトの名無しさん** · 2018/06/24(日) 22:15:14.01

>>683
せめて理論的に反論しろよグダグダ言語の信者

**デフォルトの名無しさん** · 2018/06/24(日) 22:29:21.43

>>686
ごめんなさい
論はどこですか？

**デフォルトの名無しさん** · 2018/06/24(日) 23:26:54.62

>>685
えぇ・・・ソース見るしかないのかよ・・・
リファレンスマニュアル見てもちゃんと書いてないんだよな
さらにググってもリファレンスマニュアルが引っかかってこない罠

**デフォルトの名無しさん** · 2018/06/24(日) 23:57:53.79

>>684,685
unsafeまわりの文書に入ってる（ただしdraft）
https://doc.rust-lang.org/nomicon/ffi.html
公式文書はgithubのorganization（rust-lang、rust-lang-nursery）から探している

**デフォルトの名無しさん** · 2018/06/25(月) 00:22:53.39

C言語ライブラリの関数を3回呼び出すコードと格闘すること数時間。ようやく動いた
まだ不明点は残っている
・#[link(～のkindが何を示しているのか判らない
　C FFIの使用例を見るとよく見るんだが・・・
・C言語配列の渡し方が不明
　元は
　>int p[]={16,9};
　>foo(p);
　とりあえず
　>foo("\x10\x09".as_ptr());
　などと書けばデータ上は整合するから動くけどどう見てもスマートな記述方法ではない
・文字リテラルの仕様が不明
　↑の表記を得るのに数回試行錯誤した

データの与え方もCStringを使った(＝\x00終端する)方法は出てくるけど、そうではない方法は
中々見つからなかった。結局↑の表記に落ち着いたが

>>689
ありがとう。kind値について書いてありますね。静的リンクだとkind = "static"らしいですが
付けても付けなくてもファイルサイズは大差ないようです。何が違うのだろう

**デフォルトの名無しさん** · 2018/06/25(月) 12:50:29.35

Cの配列は第一級の値じゃないからas_ptrが正攻法だと思う

**デフォルトの名無しさん** · 2018/06/25(月) 20:19:17.73

>>689によればFFIで使用できる物として
・#[repr(C付きのstruct
・#[repr(C付きのenum
・box？
・vec
・str
が挙がっているけどCと互換性があるのはこれらのみって事なのだろうか
vecを試してみたら動いたけどextern時に安全じゃないから#[repr(C)]付きのstruct使えなどと言いだした

>>691
マジかよ！確かに文字列は汎用性が高いけど可読性が良くない・・・必要に応じて抽象化しろという事か

**デフォルトの名無しさん** · 2018/06/25(月) 20:24:02.61

Rustの側では変更しないけどCの側で変更するような変数ってmutにしないと駄目よね？

**デフォルトの名無しさん** · 2018/06/25(月) 22:00:13.27

あっ、ヤベェ・・・いきなり重大なバグ出してら
×　foo("\x10\x09".as_ptr());
○　foo("\x10\x00\x00\x00\x09\x00\x00\x00".as_ptr());
こうだよな
標準で[16: i32, 9: i32]を"\x10\x00\x00\x00\x09\x00\x00\x00"に変換してくれるようなのが欲しい

**デフォルトの名無しさん** · 2018/06/25(月) 22:05:44.09

うわこれは読みたくないw
難しいもんだな

**デフォルトの名無しさん** · 2018/06/25(月) 22:59:19.25

ちなみに間違っている状態でも呼んだC関数は正常に終了します。まさにunsafeです。怖いです
何か対策を考えないと大事故を起こしそう
要素数2しかないのにstructを書くのはコード効率の点からも可読性の面からもあまり良いとは思えないし・・・
いろいろ試してみたら
>let p: [i32; 2] = [16, 9];
>foo(&p);
ならいけるようだ。コンパイラは何も言わないけどこの表記が適切かどうかは不明

Rubyだと
foo([16,9].pack("i2"))　#配列をint2個分の文字列(＝8byteのバイナリ列)に変換
とか書けるんだよなぁ。コストは安くないけど>>694みたいなポカミスは起こらない

**デフォルトの名無しさん** · 2018/06/25(月) 23:46:12.87

>>696
何がしたいかよく分からんが
何故にC側がintの配列なのにRust側では文字列を使おうとしてるんだ？
C側がintってことはRust側で対応する型はisizeだろ
(Cのintが事前に32bitと分かってる場合はi32でも可
同様に64bitだと分かっている場合は対応する型はi64)

つまり、Cで
int[] x = {16, 9};
なら、Rustで同じデータを表すものは
let x: [isize; 2] = [16, 9]; // let x = [16_isize, 9]; でもおk
って書けば良いはず

Rubyと同じように考えようとするから変なことになる
RustでFFIするならCと対応する型は何かを考えれば良い

**デフォルトの名無しさん** · 2018/06/26(火) 00:21:30.73

>>697
いや、isizeはまずいんじゃない？
例えばx86_64だとisize:64bit,int:32bitだし。
libcクレートのc_intならアーキテクチャ毎に適切なサイズになるから
こちらがいいかと。

**デフォルトの名無しさん** · 2018/06/26(火) 00:26:36.57

ついでに言うとFFIするときの型はプリミティブ型以外でも
とりあえずlibcクレートを探すといい。
まぁマイナーなアーキテクチャだと間違ってたりすることもあるから
確認は必要だけど。

**デフォルトの名無しさん** · 2018/06/26(火) 00:50:28.55

とりあえず仕返しにrubyスレ荒らそうぜ
http://mevius.5ch.net/test/read.cgi/tech/1523954817/

**デフォルトの名無しさん** · 2018/06/26(火) 00:50:41.38

>>698
あれ？そうだっけ？
うかっりしてたゴメン

そう言えばCのintはポインタのサイズに合わせるんじゃなくて
アーキテクチャ毎に変わるんだったっけか

**デフォルトの名無しさん** · 2018/06/26(火) 01:08:16.37

調べたらCのintにRustで対応する型はisizeじゃなくてstd::os::raw::c_intだったわ
libcのc_intとの違いがよく分からん
対応アーキテクチャの数か？

**デフォルトの名無しさん** · 2018/06/26(火) 02:21:07.36

>>702
一応libcはno_stdでも動くというメリットがあった気はする。
逆にプリミティブ型限定でも依存ライブラリ増やしたくないならstdなのかな？

**デフォルトの名無しさん** · 2018/06/26(火) 08:11:12.99

>>697
あなたの言うとおりですが、そのような情報はどこをから得られるのか・・・
>>689等のFFIに関する資料に書いてあるようには見えません
std::os::raw::c_intも>>702を見て探してみたら
ttps://doc.rust-lang.org/std/os/raw/index.html
ここにあるのか

配列等の長さが変わる型のC互換性に関する情報もどこにあるんだろ
アドレスの連続性とメモリの確保が保証されている必要があると思いますが

**デフォルトの名無しさん** · 2018/06/26(火) 08:35:08.35

>>704
資料が少ないのはまだ普及してない言語では仕方がない
FFIとか皆が頻繁に使う機能じゃないようなものはなおさら
Cの配列とRustの配列は互換があるはずだけど
悪いがその情報をどこから手に入れたかは覚えていないし
信用されても困る(ついさっきも間違えたしね)
場合によっては資料探すよりソースコード読んだほうが早いことも多いし
根気良く調べるしかないとしか言いようがない
あとはFFIみたいなunsafe部分は出来る限り念入りにテストを書くとか

**デフォルトの名無しさん** · 2018/06/26(火) 09:06:54.14

>>704
arrayとsliceの連続性保証はここですかね。
https://doc.rust-lang.org/reference/type-layout.html#array-layout

**デフォルトの名無しさん** · 2018/06/26(火) 10:23:55.54

今のnightlyだとclippyビルド出来ないよね？
ビルド出来る最後のバージョンと、それをインストールする方法教えてください

**デフォルトの名無しさん** · 2018/06/26(火) 12:18:25.05

RustのABIについてはドキュメント増やすことはできるだろうけど
それ以前の問題としてCのABI知らないとFFIつらいのでは

**デフォルトの名無しさん** · 2018/06/26(火) 18:47:03.15

付き合ってくれてありがとう

まとめるとFFIで使えるのは
・#[repr(C付きのstruct
・#[repr(C付きのunion
・#[repr(C付きのenum　←条件付き
・box？
・vec　←非推奨？
・str
・array
・slice
・std::os::rawの中にある物
このへんで良いのかな
std::os::rawの中とarray、struct、union、strがあれば一通り出来そうか

**デフォルトの名無しさん** · 2018/06/26(火) 20:49:29.40

vecもas_ptr用意されているし非推奨と言うことはないはず
sliceにderefできるし

**デフォルトの名無しさん** · 2018/06/26(火) 23:28:33.57

IDが変わっています

vecの件
>extern {fn foo(p: &std::vec::Vec<i32>);}
>foo(&vec![16, 9]);
これだと
>warning: `extern` block uses type `std::vec::Vec<i32>` which is not FFI-safe: this struct has unspecified layout
>・・・
> = help: consider adding a #[repr(C)] or #[repr(transparent)] attribute to this struct
と言われ正常に動作しない。クラッシュはしないが実行結果がおかしい
>extern {fn foo(p: *const i32);}
>foo(vec![16 as i32, 9 as i32].as_ptr());
これなら問題ないようだ。奥が深い

あとC関数から帰ってきたアドレスをu32へ入れていたのをc_voidへ入れるようにしたら所有権で怒られて動かなくなった
同じコードでも型によって所有権の移動のしかたが違うのか

**デフォルトの名無しさん** · 2018/06/27(水) 00:01:15.59

RustのVec自体には確かCとの互換性はないはずだよ
ただし、Vecはsliceにderefが可能でsliceはCの配列と互換がある

vec![16 as i32, 9 as i32].as_ptr()
はVecに対してas_ptr()メソッドを呼んでるように見えるけど
(ドキュメントを確認すれば分かるが)実際にはVecにas_ptr()メソッドなんて定義されていない
as_ptr()はsliceの方に定義されていて、暗黙的にderefされてからas_ptr()が呼ばれてる
つまり上のコードは丁寧に書き直すと↓と同じ意味(のはず)
let vec: Vec<i32> = vec![16, 9];
let slice: &[i32] = vec.deref();
let ptr: *const i32 = slice.as_ptr();

**デフォルトの名無しさん** · 2018/06/27(水) 00:13:14.65

あとC関数の引数＆戻り値はmove（ポインターか実値）しないとだめじゃない？
&付けて参照渡しにするのはよく分からない、たぶん未定義動作じゃないかなあ

**デフォルトの名無しさん** · 2018/06/27(水) 01:04:32.64

>>707
clippyは最新のnightlyは**追ってない**けど常に開発中だから
ビルドできるバージョンは常に変わる。
自分の環境のビルドできる最大のnightlyに合わせろしか言えん。
常にclippyを使い続けたいなら環境の方をclippyに合わせないとだめ。

>>709
- cの配列はraw pointer
- 配列以外ならrepr(C)してメモリレイアウト合わせるか
- C側でopaque pointer定義してas_ptr
- 汎用ポインタはrust側は

pub enum Void;
type VoidRef = *mut Void;

- cのvoid*がrust側にほしいならlibcクレート
- VLAや不完全配列はrustnomicon読む

まずC abi覚えろ。

std140レイアウトならクレートあるぞ。

**デフォルトの名無しさん** · 2018/06/27(水) 02:41:49.66

Rustだけ覚えればいい時代はまだ来ない
C/C++の知識皆無では

**デフォルトの名無しさん** · 2018/06/27(水) 09:44:32.66

オライリーの訳本が8月に出るのね

**デフォルトの名無しさん** · 2018/06/27(水) 10:05:32.17

本が出る頃には内容が古くなってるやつだろ