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/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)で大丈夫なはず

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

ダブルポインタはあんま想定してなさげな気はする。
俺だったらもう一枚、インターフェイスかましてもう少し楽なインターフェイスにしてから
rustと繋げるわ。

**デフォルトの名無しさん** · 2018/06/30(土) 11:27:27.95

結局C/C++ある程度わかってないと話にならないよね。
経験ないやつはいきなりrust勉強してる場合ではない。

**デフォルトの名無しさん** · 2018/06/30(土) 12:46:04.79

コンパイルできないならまずプログラミングを勉強しなおしたほうがいいよ

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

FFIの話をrust全体の話に主語をでかくしてるおっさんがおるな

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

FFIもrustの魅力の一つなのですが？
C/C++知らないやつはいつまでたってもrustを全て分かったことにならない
半人前のまま
別に必要なとこだけ使うスタンスでもいいけど半人前のクセにいっぱしのrustプログラマーヅラしないでね

**デフォルトの名無しさん** · 2018/06/30(土) 16:34:04.77

昔はアセンブラ知らずにC++語るなとか言われてたが時代は変わったもんだな

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

結局どの言語を選べばいいのかわからなくなった
C++？Go？

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

Coqを選べばいいと思うよ

**デフォルトの名無しさん** · 2018/06/30(土) 17:07:23.25

目的に合ったもの
やりたいものをやればいい

**デフォルトの名無しさん** · 2018/06/30(土) 17:07:54.55

迷うならGoでいいんでは。

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

Prolog

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

rustを視野に入れながらgoという選択はない
kotkinかswiftかgoかってなら分かるけど

**デフォルトの名無しさん** · 2018/06/30(土) 17:52:45.29

分からないなら無理してrust使わなくていいって意味じゃろ

**デフォルトの名無しさん** · 2018/06/30(土) 18:08:54.39

腐ってないでお前らも俺と一緒にRustで競技プログラミングしようぜ！

https://yukicoder.me/submissions?submitter=5971

**デフォルトの名無しさん** · 2018/06/30(土) 18:21:37.09

クロージャで再帰が出来ないのって所有権的な問題？

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

rustは競プロには向かない
https://users.rust-lang.org/t/rust-for-competitive-programming/17682

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

クロージャの再帰ってこれのこと？

recursion - Is it possible to make a recursive closure in Rust? - Stack Overflow
https://stackoverflow.com/questions/16946888/is-it-possible-to-make-a-recursive-closure-in-rust

**デフォルトの名無しさん** · 2018/06/30(土) 18:57:41.58

>>802
おー、できた
ありがとう
ローカル関数だと外部変数キャプチャできないし、クロージャだと再帰できないし、
同時にしたいときどうすんのかなーって思ってたから
そんなに使うこともないだろうけど、心に留めときます

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

>>785
ありがとう。なるほどそういう書き方もあるのか。確かに書き換わるので&mutの方が適切ですね
欲しいのはアドレスなのだからと単にアドレス演算子&を付けていました

unsafe外から任意のアドレスにあるデータへアクセスするにはその部分を関数化するようなのかな
一般的に言うプロパティの読み書きをプログラマブルに出来れば綺麗に書けるけど無理なんだろうなぁ
()無しの関数呼び出しとも言えるけどこれが出来る言語は少ない

**デフォルトの名無しさん** · 2018/06/30(土) 23:04:00.05

相変わらず驚き最大の言語だな

**デフォルトの名無しさん** · 2018/07/01(日) 07:43:42.19

>>805
例えば何に驚いてんの？
Rustの目的はシステム言語だが、目的から乖離してるとこって何？

**デフォルトの名無しさん** · 2018/07/01(日) 08:30:53.21

マルチパラダイムの場合、驚き最小の原則の法則に反するかどうかは実装者の責任じゃないだろうか

**デフォルトの名無しさん** · 2018/07/01(日) 08:46:31.97

抽象的なことしか言わなくなったんだよ
機械語のレベルと相性が悪いし

**デフォルトの名無しさん** · 2018/07/01(日) 11:50:23.63

>>807
半分はその通りだが、それならc++で良くね？になるぞ。

**デフォルトの名無しさん** · 2018/07/01(日) 13:30:01.00

日本語でこんなに議論が行われてることに驚いた

**デフォルトの名無しさん** · 2018/07/01(日) 13:37:40.54

恥ずかしくて外国人には見せられない掲示板だ

**デフォルトの名無しさん** · 2018/07/01(日) 13:54:17.46

そもそもcの呼び出しはメモリ管理モデルのギャップがあるんだから
どうあがいてもc++のが簡易にできるのは当然なんだよ。

**デフォルトの名無しさん** · 2018/07/01(日) 15:26:57.84

>>810
このスレは英語推奨だぞ

**デフォルトの名無しさん** · 2018/07/02(月) 01:23:28.76

>ローカル関数だと外部変数キャプチャできないし、クロージャだと再帰できないし、
ここに関してはクロージャでないものをクロージャと呼ばなければ誰も驚かなかっただろうな。
javaは似非クロージャのことはラムダ式と呼んでるし。