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/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

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

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

>>716
英語で出る分には多目に見たが、日本語で出るんなら出版社の不買運動だな
どこが訳すか知らんけど

**デフォルトの名無しさん** · 2018/06/27(水) 17:59:19.20

不買運動何人参加するの？大規模にやろうぜ

**デフォルトの名無しさん** · 2018/06/27(水) 18:21:05.70

英語なら多目に見るｗｗｗｗｗｗｗｗ

**デフォルトの名無しさん** · 2018/06/27(水) 18:35:05.31

>>712
ありがとう、そういうオチか。&で正常に動かないのも納得です
暗黙の変換って便利ですけど理解が浅いとハマる元だったりしますよね
不適切な入力を入れると自分が書いたつもりのコードとは無関係っぽいエラーを出して？？？になったり

>>713
#[link(name = "・・・")]
extern {
　fn func1(x: *const u8) -> u32;
　fn func2(y: u32);
　fn func3(z: &u32);
}
fn main() {
　unsafe {
　　let mut a = func1("foo.dat".as_ptr()); //C側でメモリが確保されアドレスが帰ってくる
　　func2(a); //アドレスを使って処理
　　func3(&a); //確保したメモリを解放
　}
}
これは動きます。u32をstd::os::raw::c_voidにするとfunc2のaで
>use of moved value: `a`
>= note: move occurs because `a` has type `std::os::raw::c_void`, which does not implement the `Copy` trait
そんな事を言われても困る・・・ついでにenumなので格納されているアドレス値の確認も面倒
usizeなら問題ない。ドキュメントが正しいならusizeはポインタのサイズらしいしこっちの方が楽かも

**デフォルトの名無しさん** · 2018/06/27(水) 19:40:13.19

訳本情報どこにある？

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

てかrust覚えるなら普通にc++のスマポくらいは知っとかんとわけわからんだろ。

**デフォルトの名無しさん** · 2018/06/27(水) 19:45:28.45

今日発売の新しいrust本買った人いるのかな
評判良ければKindle出た頃に買おうかなと思うけど

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

貧乏なのでPacktの糞本を$10セールの時しか買えない

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

訳本amazonにあったわ
早速予約した

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

オライリーの本って、オンラインに無料であるやつとおなじやなかったん？

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

>>727
オライリーの原著は去年12月に発売、今年8月に訳本

今日発売された英語の本は公式ドキュメント(第2版)の印刷版
版元はno starch press

**デフォルトの名無しさん** · 2018/06/28(木) 01:06:21.38

>>721
他の人も似たようなこと書いてるけど、Cの配列は結局はポインタに過ぎないから
C側がポインタを求めれば、当然Rust側でもポインタを渡す

あと>>711の
>同じコードでも型によって所有権の移動のしかたが違うのか
は半分正解で半分不正解
正確には、型によって違うんじゃなくて、Copyトレイトをimplしてるか否かで違う
u32はCopyトレイトをimplしてるから所有権はmoveじゃなくてcopyされる
c_voidはCopyトレイトをimplしてないから所有権をmoveしようとする

The Bookちゃんと読んだ？読んでないなら一度きちんと通読することを勧める

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

rustやるのにあったほうがいい前提知識ってどれくらい？
c++とhaskellがまともに出来ないときつい？

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

そんなわけないだろw
どっちかてと根気が必要だ

**デフォルトの名無しさん** · 2018/06/28(木) 07:54:11.40

いや最低限c++のコンストラクタ、デストラクタの動くタイミングくらいは知っとかないと無理だろ。

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

>>729
一応deriveでCopy(とClone)を実装すればいいらしいと言うところまでは確認しているのですが
１．std::os::raw::c_voidへ追加で実装できるのか未確認(できたとしてもモンキーパッチになってしまう)
２．別名の型を新規に作る(usizeもしくはusizeへのエイリアスに対するメリットが思いつかない)
なもんで問題なさそうならusizeで良いかなと・・・
というかCのライブラリを使うと>>721みたいなケースは良くあると思うけど他の人はどうしているんだろ
libcのc_voidもlib.rsを見るとstd::os::raw::c_voidと同じみたいだし同様の現象が起きそうです
ググると引数はc_voidを使って戻り値はusizeを使っているようなコードも出てくるしusizeが正攻法なのか？

ちなみにこのコードだとusizeを使ってもmutが不要の警告が出るんですよね。これもそんな事を言われても
困るのですが

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

>>733
Cで確保したポインタ（特に○○ハンドルみたいなリソース）は普通はopaque structで受けると思う。
https://rust-lang-ja.github.io/the-rust-programming-language-ja/1.6/book/ffi.html#%E3%82%AA%E3%83%9A%E3%83%BC%E3%82%AF%E6%A7%8B%E9%80%A0%E4%BD%93%E3%81%AE%E8%A1%A8%E7%8F%BE

どちらかというと、func2の引数が参照渡しでなくて値渡しなのが問題では。
見た感じfunc2では借用して呼び出し後に返してもらえばいいっぽいけど。

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

>>732
えーなんで？rust書いてる人の大半は知らないでしょ

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

こりゃC++まだ覚えてない人はrustなんか勉強してる場合じゃないねｗ

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

c++といってもRAIIとスマートポインタくらいで良いのでは
知らなくてもtrplなど読めばなんとかなるとは思うが
代数的データ型なども同様

あとは用途次第だけどFFIやるならCのメモリレイアウトくらいは押さえておいた方がよい

**デフォルトの名無しさん** · 2018/06/28(木) 13:32:58.62

そんないい加減なことでいいのだろうか？
ちゃんとC/C++一から十まできちんと理解した方がよいのでは？
それからじゃないとそこがいい加減でRustなんて本当に使えるようになったと言える？

**デフォルトの名無しさん** · 2018/06/28(木) 14:08:04.32

C++完全に理解した人間なんて世界中に何人いるやら

**デフォルトの名無しさん** · 2018/06/28(木) 14:14:44.86

Cはともかく、C++に時間を割く必要はないじゃろ

**デフォルトの名無しさん** · 2018/06/28(木) 14:20:27.58

むしろCすら知らないほうが変な先入観とか無くて所有権とかライフタイムとか素直に理解しやすそうな気もする

**デフォルトの名無しさん** · 2018/06/28(木) 14:28:13.71

必要という理由が分からない
言語なんて使いながら覚えていくもんでしょ

**デフォルトの名無しさん** · 2018/06/28(木) 15:28:41.63

>>738
RustはC/C++分かってないと書けない
→C/C++を分かるまでやる
→C/C++がわかってしまえばそもそもRustなんて不要だと気づく
→Rustを捨てる

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

>>730
確かにC++とHaskellが出来きればRustの習得にはそれほど苦労しないだろうとは思う
ただ、理解できるまでにかかる時間量の問題であって、それがないとキツイってわけじゃない
むしろ、Rustの学習するためにC++とHaskellを先に学習するとか時間の無駄
The Bookが懇切丁寧に解説してくれるので前提知識はなくても全く問題ないと思う
ただし、Goみたいな言語と違ってサンプルコード読めばある程度理解できて
何となくで書けてしまうような言語ではないのでThe Bookの熟読は必須
それと、FFIする場合はある程度のCの知識は必要だよ

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

FFIしたいけどCは知らん、とかレアケースだから
そんな心配はせんでいい

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

別にRustは大して関数型言語じゃないし、Rustのために他の関数型言語から、っていうのは本末転倒すぎるな

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

全然モナドってないし、関数型言語フレーバーぐらいでしょ

**デフォルトの名無しさん** · 2018/06/28(木) 17:13:53.31

C++は速いがコーディングストレスで禿げる
Rustで若干のパフォーマンスを犠牲にしてでも、いかに毛髪を守れるかがテーマ

**デフォルトの名無しさん** · 2018/06/28(木) 17:18:23.47

>>748
C++程度で禿げてたらRustのコンパイル通らん

Rustのコンパイル通せるならC++でやる方がよいコード書ける

つまりRustは実用にならん。C++er養成ギプスって話ならわかる

**デフォルトの名無しさん** · 2018/06/28(木) 17:41:56.51

結論：やっぱりC++からしっかりやったほうがよい

**デフォルトの名無しさん** · 2018/06/28(木) 17:46:58.11

>>750
違う違う、そもそもRustは不要って結論な

C++勉強してC++そのまま使い続ければいい

**デフォルトの名無しさん** · 2018/06/28(木) 17:47:09.81

C++98
C++03
C++TR1
C++11
C++14
C++17
C++20
C++23
C++26
C++29
C++32
C++35
C++38

**デフォルトの名無しさん** · 2018/06/28(木) 17:56:38.73

なんだコンパイルできないおじさんか。。

**デフォルトの名無しさん** · 2018/06/28(木) 18:32:36.30

>>746
単純に最初期のRustコンパイラはOcamlで組まれてたからって事情でないの

**デフォルトの名無しさん** · 2018/06/28(木) 18:34:20.70

>>749
C++より潜在的なメモリ管理バグを減らせるってのは十分有用な話では

**デフォルトの名無しさん** · 2018/06/28(木) 18:54:33.03

リストとリスト操作をなんで組み込んでくれなかったのかな？
::とか@とかあるだけでだいぶ捗るよね（一部の人にとって）

**デフォルトの名無しさん** · 2018/06/28(木) 19:41:35.09

パフォーマンス面だけで言えば、リンクトリストは問題外だからじゃない？

**デフォルトの名無しさん** · 2018/06/28(木) 20:19:23.05

コンパイルできないおじさんのコードもNLL有効にしたらコンパイルできたから
来年にはrust書けるようになるよ

**デフォルトの名無しさん** · 2018/06/28(木) 20:29:59.05

別にどの言語だろうと所有権を考えるってのは普遍的に必要だとは思うぞ。
rustだろうとc++だろうとはたまた動的言語でもメモリ以外にも資源管理なんて
問題はどこにでも出てくるわけで。

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

consとかが使えないのはmutとの兼ね合いもあるんじゃないの
あれ完全にイミュータブルリスト向けだもんよ

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

https://www.reddit.com/r/rust/comments/8ub964/microsoft_announces_using_rust_to_build_some_of
MSもRust使ってるんですか
やるしかない

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

>>734
なるほど。c_voidの正体はそれでしたか

引数は既成Cライブラリの仕様なのでなるべく変更したくありません

*mutを使うコードを検討していて気がつきましたがRustの生ポインタにfunc1が返すアドレスを入れると
Cと同じ危険を抱えますよね。func3でアドレスがNULL=0になりますからその後に触ると当然クラッシュします

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

NLLいまだに理解できなくて使えない

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

>>761
actixとactix-webのメインコントリビュータもよく見ると普通にMS所属の人だった
ttps://github.com/actix/actix/graphs/contributors
ttps://github.com/actix/actix-web/graphs/contributors

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

MSは英語なので、大目に見てもらえる

**デフォルトの名無しさん** · 2018/06/28(木) 22:08:43.56

> Please never sell Rust to Microsoft!

ちょっとわらった

**デフォルトの名無しさん** · 2018/06/28(木) 22:56:56.15

言語に関してはMSがオーナーになるのは大勝利だろ

**デフォルトの名無しさん** · 2018/06/28(木) 23:58:14.47

ではここからはC# おじさんどぞー

**デフォルトの名無しさん** · 2018/06/29(金) 00:13:26.39

MSには新しいプログラミング言語のQ#があるから

Q# 【量子プログラミング】
https://mevius.5ch.net/test/read.cgi/tech/1513059627/l50

**デフォルトの名無しさん** · 2018/06/29(金) 00:20:17.66

汎用言語でないからRustと競合はしないな

**デフォルトの名無しさん** · 2018/06/29(金) 05:02:04.02

Visual StudioでRustサポートされないかな
rlsが不安定すぎるのでMSが作り直して欲しい...

**デフォルトの名無しさん** · 2018/06/29(金) 07:15:45.03

rlsもracerもポンコツよね
あんまり力入れてないのかな

**デフォルトの名無しさん** · 2018/06/29(金) 10:18:57.05

intelliJ使えばええやん
インテリじゃない人もタダで使えるよ

**デフォルトの名無しさん** · 2018/06/29(金) 11:21:37.40

支援機能だけ考えるとそうなんだけどさ
手に馴染んだemacsから離れるのは簡単じゃない

**デフォルトの名無しさん** · 2018/06/29(金) 12:06:31.66

ワイもIDE使いこなせない

**デフォルトの名無しさん** · 2018/06/29(金) 12:09:37.82

intellijをつかうのです…
vsなんかよりよっぽどいいですよ…

**デフォルトの名無しさん** · 2018/06/29(金) 12:09:46.01

>>763
従来のborrow checkerの制約が緩くなるだけだから従来の理解してれば不自由なく使えるはず

**デフォルトの名無しさん** · 2018/06/29(金) 12:27:36.55

intelij買ったけどemacs使っちゃうのよね。コード書くのにmouseが必要になるのが受け付けないみたい。

**デフォルトの名無しさん** · 2018/06/29(金) 18:17:46.77

intellijちゃん自力でパースしてるのアホでしょ
CLionもclang使わず自力でやってるけどリリースから随分経つのに初歩的なバグ残ってるみたいだし

**デフォルトの名無しさん** · 2018/06/29(金) 18:55:33.43

>>734の方法だとこんな感じなのかな
enum ABC {}
#[link(name = "・・・")]
extern {
　fn func1(x: *const u8) -> *mut ABC
　fn func2(y: *mut ABC);
　fn func3(z: &*mut ABC);
}
fn main() {
　unsafe {
　　let a = func1("foo.dat".as_ptr()); //C側でメモリが確保されアドレスが帰ってくる
　　func2(a); //アドレスを使って処理
　　func3(&a); //確保したメモリを解放(以降aを触ってはいけない)
　}
}
中身にアクセスしたいならenumを#[repr(C)]付きのstructにして構造を定義すればいいのかな
読み書きするRustのコード全てをunsafeにする必要がありそうだけど

**デフォルトの名無しさん** · 2018/06/29(金) 20:25:27.91

英語は多めに見るおじさん、今頃rustについて必死で勉強して弱点探してるのかな

**デフォルトの名無しさん** · 2018/06/30(土) 01:38:16.37

>>780
func1とfunc2は関数プロトタイプがわかるけど
fn func1(x: *const u8) -> *mut ABC; → ABC* func1(const char *x);
fn func2(y: *mut ABC); → void func2(ABC *y);
fn func3(z: &*mut ABC);に相当するCのプロトタイプはないよね？

**デフォルトの名無しさん** · 2018/06/30(土) 01:40:31.49

func1のxはu8だからunsigned charかuint8_tだね

**デフォルトの名無しさん** · 2018/06/30(土) 01:59:30.31

>>782
func1の引数はRustのコンパイラにその型を使えと言われたから
func2の引数はfunc1の返値に合わせた
func3の引数はfunc1が返したアドレスが格納されているアドレス。Cで言うポインタのポインタでABC **z
自分も詳しいわけではないので勘違いしているかもしれないが一応動いている

**デフォルトの名無しさん** · 2018/06/30(土) 05:09:23.98

>>784
ダブルポインタだったのか
それならvoid func3(ABC **z); → fn func3(z: *mut *mut ABC);

let mut p = func1(...);
let pp = &mut p as *mut *mut ABC;
func3(pp); // 単にfunc3(&mut p)で大丈夫なはず