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/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は似非クロージャのことはラムダ式と呼んでるし。

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

Haskellの「外側のシンボルを参照することによる暗黙的な部分適用」はクロージャと呼ばれてるから
アレが許されるなら少なくともJavaのはクロージャと呼んでいい

**デフォルトの名無しさん** · 2018/07/02(月) 22:14:52.04

>>815
javaのアレは元々クロージャ導入するつもりが、
仕様と実装でクソ揉めて妥協案としてクロージャ
じゃないものとしてラムダ式を作ったんやで。
だから意図的な"クロージャではないモノ"よ。

メモリ管理にgc使うからエンクロージャの束縛の解放に
制限ないから実質クロージャだし第一級関数だけど。

**デフォルトの名無しさん** · 2018/07/02(月) 22:54:50.18

hyper使って簡単なwebアプリ描いてみたけどわりと素直に書けるのね

**デフォルトの名無しさん** · 2018/07/03(火) 16:24:59.60

>>803は本当に満足してるのだろうか
>>802のやり方だとパラメータ増えてるじゃん
こういうのは既存のシグネチャに合わせられないと
単にひとつの関数を小洒落た書き方にしてみましたってだけにしかならないのでは

**デフォルトの名無しさん** · 2018/07/03(火) 17:05:40.29

連投になって申し訳ないが、環境をRefCellで持ち出す例を見つけた
ttps://wandbox.org/permlink/hkwccgD2oXp0fTm7
組み合わせて、802の2番目の例のstructを更にRefCellに入れたらシグネチャ変えずに行けるかな

**デフォルトの名無しさん** · 2018/07/03(火) 17:29:45.80

>>818
一応満足してるよ
スッキリ書けないことがわかったから、素直にループで書くか、ローカル関数作って引数で渡そうと思えた
Rustは関数型じゃなくて手続き型だし、特に不満ではない

**デフォルトの名無しさん** · 2018/07/03(火) 17:31:22.43

>>819
RefCell使うなら、Rustで書く意味ないだろ

**デフォルトの名無しさん** · 2018/07/03(火) 18:19:36.75

>>820
すまん、クロージャでないとできない用途(環境をキャプチャーして高階関数に渡す等)を想定していると
勝手に気を回してしまったみたいだ

**デフォルトの名無しさん** · 2018/07/03(火) 21:26:26.07

クロージャじゃないとできない用途って具体的にどういうものなの
想像つかなかったので単純な興味本位

**デフォルトの名無しさん** · 2018/07/03(火) 21:32:07.93

例えば最適化ライブラリなどに目的関数を渡す場合などで
引数以外からパラメータを注入する必要がある場合。

**デフォルトの名無しさん** · 2018/07/03(火) 22:38:00.99

>>822
キャプチャ自体はクロージャで出来るから別に困ってないかな
たまたま再帰させたくなったときがあっただけだから

**デフォルトの名無しさん** · 2018/07/03(火) 23:58:54.50

クロージャじゃなきゃできないことじゃなくて、
クロージャの再起呼び出しじゃなきゃできないことを聞きたかった
引数以外のパラメーターを差し込む場合、普通は再起は必要ないよね

**デフォルトの名無しさん** · 2018/07/04(水) 00:52:48.93

風雲再起ぃ～！！

**デフォルトの名無しさん** · 2018/07/04(水) 01:08:42.88

1.28はrustdocするときソースコードのlintするようになったんの？
deny属性に違反するソースコードがドキュメント生成時にエラー投げる。

>>822
クロージャがある言語は普通、関数とクロージャ区別しないからその感覚はおかしくないと思う。
でもクロージャの実装上の制約とかライフタイムとかでループで書いたほうがいいと思うコードはある。

**デフォルトの名無しさん** · 2018/07/04(水) 09:35:17.80

>>826
それは、てっきり最初の>>800がキャプチャと再帰を同時に使いたいことがあったんとばかり

**デフォルトの名無しさん** · 2018/07/04(水) 20:54:21.49

>>826
ある種の動的なtree構造に対して探索、実行を繰り返すとか。。
やっぱ具体的じゃねーな。。

**デフォルトの名無しさん** · 2018/07/04(水) 21:42:58.93

最近rustの勉強始めたものです
この言語ってstatementなのかexpressionなのかをどういう方針で決めてんでしょう？
ifがexpressionなのはわかったけど、letはなぜstatementなんだろ？
他の関数型言語のようにexpressionでもよかろうに、と思った

**デフォルトの名無しさん** · 2018/07/04(水) 21:53:13.67

KCX

**デフォルトの名無しさん** · 2018/07/04(水) 23:31:21.37

古いCで良く在る if ( (let a = f()) != 0 ) {} みたいなのが嫌だったんだろう。
そもそも、変数束縛が値を持つ必然性は無いよね。

**デフォルトの名無しさん** · 2018/07/04(水) 23:32:39.47

>>833
あ、ごめん。大嘘だった。
if let なんてのあったのね…

**デフォルトの名無しさん** · 2018/07/05(木) 00:07:01.10

他の関数型言語のletは随分来歴が違うイメージ。
let x = ... in expはラムダ式の糖衣構文の一種なので関数型なら容易に実装できて便利に使えるのに対し、
rustのletは手続き型の変数宣言の方が近い

schemeのletとdefineが全然意味が違うのを知ってると違和感無い

**デフォルトの名無しさん** · 2018/07/05(木) 00:16:12.98

>>831
この辺読めばいいかと。
https://rust-lang-ja.github.io/the-rust-programming-language-ja/1.6/book/functions.html#%E5%BC%8F%E5%AF%BE%E6%96%87

letは所有権移動だけど、返り値を認めちゃうと
束縛先と返り値のどちらに移動すべきか分からない、ということかな。

**デフォルトの名無しさん** · 2018/07/05(木) 00:52:35.42

>>836
それは let a = (let b = c) がだめな理由にはなるけど
>>831の言ってる関数型言語風の let a = (let b = c in d) がだめな理由にはならないよね

**デフォルトの名無しさん** · 2018/07/05(木) 01:22:02.41

えっ、毎回コピーすんの？
それ無駄じゃね？