Rust Part5

■ このスレッドは過去ログ倉庫に格納されています
1デフォルトの名無しさん
垢版 |
2018/02/11(日) 20:07:24.54ID:ri7dLd1B
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(水) 21:01:38.86ID:IGU3gLqH
>>727
オライリーの原著は去年12月に発売、今年8月に訳本

今日発売された英語の本は公式ドキュメント(第2版)の印刷版
版元はno starch press
2018/06/28(木) 01:06:21.38ID:cJz1WTLf
>>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.46ID:YYPKz5qu
rustやるのにあったほうがいい前提知識ってどれくらい?
c++とhaskellがまともに出来ないときつい?
731デフォルトの名無しさん
垢版 |
2018/06/28(木) 06:30:25.53ID:fobuFGlz
そんなわけないだろw
どっちかてと根気が必要だ
2018/06/28(木) 07:54:11.40ID:1UW06GNd
いや最低限c++のコンストラクタ、デストラクタの動くタイミングくらいは知っとかないと無理だろ。
2018/06/28(木) 08:12:22.16ID:MOChRiis
>>729
一応deriveでCopy(とClone)を実装すればいいらしいと言うところまでは確認しているのですが
1.std::os::raw::c_voidへ追加で実装できるのか未確認(できたとしてもモンキーパッチになってしまう)
2.別名の型を新規に作る(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.92ID:bLMLowda
>>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では借用して呼び出し後に返してもらえばいいっぽいけど。
735デフォルトの名無しさん
垢版 |
2018/06/28(木) 10:18:12.24ID:MyWFnKdA
>>732
えーなんで?rust書いてる人の大半は知らないでしょ
2018/06/28(木) 10:38:48.43ID:LheEK93m
こりゃC++まだ覚えてない人はrustなんか勉強してる場合じゃないねw
2018/06/28(木) 12:56:07.56ID:rDWw9n99
c++といってもRAIIとスマートポインタくらいで良いのでは
知らなくてもtrplなど読めばなんとかなるとは思うが
代数的データ型なども同様

あとは用途次第だけどFFIやるならCのメモリレイアウトくらいは押さえておいた方がよい
2018/06/28(木) 13:32:58.62ID:LheEK93m
そんないい加減なことでいいのだろうか?
ちゃんとC/C++一から十まできちんと理解した方がよいのでは?
それからじゃないとそこがいい加減でRustなんて本当に使えるようになったと言える?
2018/06/28(木) 14:08:04.32ID:QGaIyydK
C++完全に理解した人間なんて世界中に何人いるやら
2018/06/28(木) 14:14:44.86ID:rY43/kt0
Cはともかく、C++に時間を割く必要はないじゃろ
2018/06/28(木) 14:20:27.58ID:61gzDvUq
むしろCすら知らないほうが変な先入観とか無くて所有権とかライフタイムとか素直に理解しやすそうな気もする
742デフォルトの名無しさん
垢版 |
2018/06/28(木) 14:28:13.71ID:MyWFnKdA
必要という理由が分からない
言語なんて使いながら覚えていくもんでしょ
2018/06/28(木) 15:28:41.63ID:a2wUxb0k
>>738
RustはC/C++分かってないと書けない
→C/C++を分かるまでやる
→C/C++がわかってしまえばそもそもRustなんて不要だと気づく
→Rustを捨てる
2018/06/28(木) 16:07:41.79ID:cJz1WTLf
>>730
確かにC++とHaskellが出来きればRustの習得にはそれほど苦労しないだろうとは思う
ただ、理解できるまでにかかる時間量の問題であって、それがないとキツイってわけじゃない
むしろ、Rustの学習するためにC++とHaskellを先に学習するとか時間の無駄
The Bookが懇切丁寧に解説してくれるので前提知識はなくても全く問題ないと思う
ただし、Goみたいな言語と違ってサンプルコード読めばある程度理解できて
何となくで書けてしまうような言語ではないのでThe Bookの熟読は必須
それと、FFIする場合はある程度のCの知識は必要だよ
2018/06/28(木) 16:49:45.85ID:Z76aQv2+
FFIしたいけどCは知らん、とかレアケースだから
そんな心配はせんでいい
2018/06/28(木) 16:53:35.27ID:rY43/kt0
別にRustは大して関数型言語じゃないし、Rustのために他の関数型言語から、っていうのは本末転倒すぎるな
2018/06/28(木) 16:59:30.65ID:Z76aQv2+
全然モナドってないし、関数型言語フレーバーぐらいでしょ
2018/06/28(木) 17:13:53.31
C++は速いがコーディングストレスで禿げる
Rustで若干のパフォーマンスを犠牲にしてでも、いかに毛髪を守れるかがテーマ
2018/06/28(木) 17:18:23.47ID:GP5sTNn0
>>748
C++程度で禿げてたらRustのコンパイル通らん

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

つまりRustは実用にならん。C++er養成ギプスって話ならわかる
2018/06/28(木) 17:41:56.51ID:BmtmAhz0
結論: やっぱりC++からしっかりやったほうがよい
2018/06/28(木) 17:46:58.11ID:GP5sTNn0
>>750
違う違う、そもそもRustは不要って結論な

C++勉強してC++そのまま使い続ければいい
2018/06/28(木) 17:47:09.81ID:tKvy+NRw
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
753デフォルトの名無しさん
垢版 |
2018/06/28(木) 17:56:38.73ID:MyWFnKdA
なんだコンパイルできないおじさんか。。
2018/06/28(木) 18:32:36.30ID:f0Ft93Jb
>>746
単純に最初期のRustコンパイラはOcamlで組まれてたからって事情でないの
2018/06/28(木) 18:34:20.70ID:f0Ft93Jb
>>749
C++より潜在的なメモリ管理バグを減らせるってのは十分有用な話では
2018/06/28(木) 18:54:33.03ID:frbOjHXy
リストとリスト操作をなんで組み込んでくれなかったのかな?
::とか@とかあるだけでだいぶ捗るよね(一部の人にとって)
2018/06/28(木) 19:41:35.09ID:Z76aQv2+
パフォーマンス面だけで言えば、リンクトリストは問題外だからじゃない?
2018/06/28(木) 20:19:23.05ID:X+ujNNAX
コンパイルできないおじさんのコードもNLL有効にしたらコンパイルできたから
来年にはrust書けるようになるよ
2018/06/28(木) 20:29:59.05ID:1UW06GNd
別にどの言語だろうと所有権を考えるってのは普遍的に必要だとは思うぞ。
rustだろうとc++だろうとはたまた動的言語でもメモリ以外にも資源管理なんて
問題はどこにでも出てくるわけで。
2018/06/28(木) 20:30:03.07ID:rY43/kt0
consとかが使えないのはmutとの兼ね合いもあるんじゃないの
あれ完全にイミュータブルリスト向けだもんよ
2018/06/28(木) 21:16:31.35ID:YYPKz5qu
https://www.reddit.com/r/rust/comments/8ub964/microsoft_announces_using_rust_to_build_some_of
MSもRust使ってるんですか
やるしかない
2018/06/28(木) 21:22:26.06ID:MOChRiis
>>734
なるほど。c_voidの正体はそれでしたか

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

*mutを使うコードを検討していて気がつきましたがRustの生ポインタにfunc1が返すアドレスを入れると
Cと同じ危険を抱えますよね。func3でアドレスがNULL=0になりますからその後に触ると当然クラッシュします
2018/06/28(木) 21:27:33.58ID:wCMJyKP8
NLLいまだに理解できなくて使えない
2018/06/28(木) 21:36:28.71ID:cJz1WTLf
>>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.19ID:CykyBbY/
MSは英語なので、大目に見てもらえる
766デフォルトの名無しさん
垢版 |
2018/06/28(木) 22:08:43.56ID:fobuFGlz
> Please never sell Rust to Microsoft!

ちょっとわらった
2018/06/28(木) 22:56:56.15ID:mQsBu3Yx
言語に関してはMSがオーナーになるのは大勝利だろ
2018/06/28(木) 23:58:14.47ID:aJbqINcy
ではここからはC# おじさんどぞー
2018/06/29(金) 00:13:26.39ID:9NU4CCEP
MSには新しいプログラミング言語のQ#があるから

Q# 【量子プログラミング】
https://mevius.5ch.net/test/read.cgi/tech/1513059627/l50
2018/06/29(金) 00:20:17.66ID:1B/tcpoY
汎用言語でないからRustと競合はしないな
2018/06/29(金) 05:02:04.02ID:HciN/Bk/
Visual StudioでRustサポートされないかな
rlsが不安定すぎるのでMSが作り直して欲しい...
772デフォルトの名無しさん
垢版 |
2018/06/29(金) 07:15:45.03ID:pVbM0h49
rlsもracerもポンコツよね
あんまり力入れてないのかな
2018/06/29(金) 10:18:57.05ID:azKeAftH
intelliJ使えばええやん
インテリじゃない人もタダで使えるよ
774デフォルトの名無しさん
垢版 |
2018/06/29(金) 11:21:37.40ID:eINaY/I2
支援機能だけ考えるとそうなんだけどさ
手に馴染んだemacsから離れるのは簡単じゃない
2018/06/29(金) 12:06:31.66ID:1B/tcpoY
ワイもIDE使いこなせない
2018/06/29(金) 12:09:37.82ID:l0U/js7n
intellijをつかうのです…
vsなんかよりよっぽどいいですよ…
2018/06/29(金) 12:09:46.01ID:ZOJKMSLg
>>763
従来のborrow checkerの制約が緩くなるだけだから従来の理解してれば不自由なく使えるはず
2018/06/29(金) 12:27:36.55ID:1B/tcpoY
intelij買ったけどemacs使っちゃうのよね。コード書くのにmouseが必要になるのが受け付けないみたい。
2018/06/29(金) 18:17:46.77ID:HciN/Bk/
intellijちゃん自力でパースしてるのアホでしょ
CLionもclang使わず自力でやってるけどリリースから随分経つのに初歩的なバグ残ってるみたいだし
2018/06/29(金) 18:55:33.43ID:abdfGqyU
>>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.91ID:jUvi1FZV
英語は多めに見るおじさん、今頃rustについて必死で勉強して弱点探してるのかな
2018/06/30(土) 01:38:16.37ID:bJf+PXWq
>>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.49ID:bJf+PXWq
func1のxはu8だからunsigned charかuint8_tだね
2018/06/30(土) 01:59:30.31ID:VVUAg8sI
>>782
func1の引数はRustのコンパイラにその型を使えと言われたから
func2の引数はfunc1の返値に合わせた
func3の引数はfunc1が返したアドレスが格納されているアドレス。Cで言うポインタのポインタでABC **z
自分も詳しいわけではないので勘違いしているかもしれないが一応動いている
2018/06/30(土) 05:09:23.98ID:bJf+PXWq
>>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.70ID:6fEIEQu0
ダブルポインタはあんま想定してなさげな気はする。
俺だったらもう一枚、インターフェイスかましてもう少し楽なインターフェイスにしてから
rustと繋げるわ。
2018/06/30(土) 11:27:27.95ID:BB0BPsjY
結局C/C++ある程度わかってないと話にならないよね。
経験ないやつはいきなりrust勉強してる場合ではない。
788デフォルトの名無しさん
垢版 |
2018/06/30(土) 12:46:04.79ID:gEYLih9T
コンパイルできないならまずプログラミングを勉強しなおしたほうがいいよ
2018/06/30(土) 14:28:27.26ID:d1l1Trl+
FFIの話をrust全体の話に主語をでかくしてるおっさんがおるな
2018/06/30(土) 16:28:11.02ID:oxrLiD+S
FFIもrustの魅力の一つなのですが?
C/C++知らないやつはいつまでたってもrustを全て分かったことにならない
半人前のまま
別に必要なとこだけ使うスタンスでもいいけど半人前のクセにいっぱしのrustプログラマーヅラしないでね
2018/06/30(土) 16:34:04.77ID:WiulWXxB
昔はアセンブラ知らずにC++語るなとか言われてたが時代は変わったもんだな
2018/06/30(土) 16:40:34.19ID:jlw7G6p9
結局どの言語を選べばいいのかわからなくなった
C++?Go?
2018/06/30(土) 17:06:44.52ID:NH6TT+Fu
Coqを選べばいいと思うよ
794デフォルトの名無しさん
垢版 |
2018/06/30(土) 17:07:23.25ID:QJJEkoJ9
目的に合ったもの
やりたいものをやればいい
2018/06/30(土) 17:07:54.55ID:5+sKgUjT
迷うならGoでいいんでは。
2018/06/30(土) 17:10:05.48ID:CMs/fWc6
Prolog
797デフォルトの名無しさん
垢版 |
2018/06/30(土) 17:38:54.49ID:RHrrdh8p
rustを視野に入れながらgoという選択はない
kotkinかswiftかgoかってなら分かるけど
2018/06/30(土) 17:52:45.29ID:5+sKgUjT
分からないなら無理してrust使わなくていいって意味じゃろ
2018/06/30(土) 18:08:54.39ID:9Q6R3Qzj
腐ってないでお前らも俺と一緒にRustで競技プログラミングしようぜ!

https://yukicoder.me/submissions?submitter=5971
2018/06/30(土) 18:21:37.09ID:UB7qEnEv
クロージャで再帰が出来ないのって所有権的な問題?
2018/06/30(土) 18:24:45.75ID:cH9c2bse
rustは競プロには向かない
https://users.rust-lang.org/t/rust-for-competitive-programming/17682
2018/06/30(土) 18:38:35.11ID:cH9c2bse
クロージャの再帰ってこれのこと?

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.58ID:dTg1EP/S
>>802
おー、できた
ありがとう
ローカル関数だと外部変数キャプチャできないし、クロージャだと再帰できないし、
同時にしたいときどうすんのかなーって思ってたから
そんなに使うこともないだろうけど、心に留めときます
2018/06/30(土) 22:59:14.25ID:pdhum8J2
>>785
ありがとう。なるほどそういう書き方もあるのか。確かに書き換わるので&mutの方が適切ですね
欲しいのはアドレスなのだからと単にアドレス演算子&を付けていました

unsafe外から任意のアドレスにあるデータへアクセスするにはその部分を関数化するようなのかな
一般的に言うプロパティの読み書きをプログラマブルに出来れば綺麗に書けるけど無理なんだろうなぁ
()無しの関数呼び出しとも言えるけどこれが出来る言語は少ない
2018/06/30(土) 23:04:00.05ID:BB0BPsjY
相変わらず驚き最大の言語だな
2018/07/01(日) 07:43:42.19ID:XZ+Fcjv4
>>805
例えば何に驚いてんの?
Rustの目的はシステム言語だが、目的から乖離してるとこって何?
2018/07/01(日) 08:30:53.21ID:vf9gJxu2
マルチパラダイムの場合、驚き最小の原則の法則に反するかどうかは実装者の責任じゃないだろうか
2018/07/01(日) 08:46:31.97ID:E4o6QfBe
抽象的なことしか言わなくなったんだよ
機械語のレベルと相性が悪いし
2018/07/01(日) 11:50:23.63ID:YY7LPhac
>>807
半分はその通りだが、それならc++で良くね?になるぞ。
2018/07/01(日) 13:30:01.00ID:TGjVBuJr
日本語でこんなに議論が行われてることに驚いた
2018/07/01(日) 13:37:40.54
恥ずかしくて外国人には見せられない掲示板だ
2018/07/01(日) 13:54:17.46ID:YY7LPhac
そもそもcの呼び出しはメモリ管理モデルのギャップがあるんだから
どうあがいてもc++のが簡易にできるのは当然なんだよ。
2018/07/01(日) 15:26:57.84ID:HnzLcrw0
>>810
このスレは英語推奨だぞ
2018/07/02(月) 01:23:28.76ID:5g9b1rVY
>ローカル関数だと外部変数キャプチャできないし、クロージャだと再帰できないし、
ここに関してはクロージャでないものをクロージャと呼ばなければ誰も驚かなかっただろうな。
javaは似非クロージャのことはラムダ式と呼んでるし。
2018/07/02(月) 01:51:37.55ID:v1kLQBFZ
Haskellの「外側のシンボルを参照することによる暗黙的な部分適用」はクロージャと呼ばれてるから
アレが許されるなら少なくともJavaのはクロージャと呼んでいい
2018/07/02(月) 22:14:52.04ID:KKQokwkO
>>815
javaのアレは元々クロージャ導入するつもりが、
仕様と実装でクソ揉めて妥協案としてクロージャ
じゃないものとしてラムダ式を作ったんやで。
だから意図的な"クロージャではないモノ"よ。

メモリ管理にgc使うからエンクロージャの束縛の解放に
制限ないから実質クロージャだし第一級関数だけど。
817デフォルトの名無しさん
垢版 |
2018/07/02(月) 22:54:50.18ID:F0SAJ301
hyper使って簡単なwebアプリ描いてみたけどわりと素直に書けるのね
2018/07/03(火) 16:24:59.60ID:ZNPbo2Ku
>>803は本当に満足してるのだろうか
>>802のやり方だとパラメータ増えてるじゃん
こういうのは既存のシグネチャに合わせられないと
単にひとつの関数を小洒落た書き方にしてみましたってだけにしかならないのでは
2018/07/03(火) 17:05:40.29ID:ZNPbo2Ku
連投になって申し訳ないが、環境をRefCellで持ち出す例を見つけた
ttps://wandbox.org/permlink/hkwccgD2oXp0fTm7
組み合わせて、802の2番目の例のstructを更にRefCellに入れたらシグネチャ変えずに行けるかな
2018/07/03(火) 17:29:45.80ID:LuUToNY2
>>818
一応満足してるよ
スッキリ書けないことがわかったから、素直にループで書くか、ローカル関数作って引数で渡そうと思えた
Rustは関数型じゃなくて手続き型だし、特に不満ではない
2018/07/03(火) 17:31:22.43ID:nNrfrM83
>>819
RefCell使うなら、Rustで書く意味ないだろ
2018/07/03(火) 18:19:36.75ID:ZNPbo2Ku
>>820
すまん、クロージャでないとできない用途(環境をキャプチャーして高階関数に渡す等)を想定していると
勝手に気を回してしまったみたいだ
2018/07/03(火) 21:26:26.07ID:9JOKXkQl
クロージャじゃないとできない用途って具体的にどういうものなの
想像つかなかったので単純な興味本位
2018/07/03(火) 21:32:07.93ID:2DeV5pvZ
例えば最適化ライブラリなどに目的関数を渡す場合などで
引数以外からパラメータを注入する必要がある場合。
2018/07/03(火) 22:38:00.99ID:9ONgpSq2
>>822
キャプチャ自体はクロージャで出来るから別に困ってないかな
たまたま再帰させたくなったときがあっただけだから
2018/07/03(火) 23:58:54.50ID:6KvlcSKZ
クロージャじゃなきゃできないことじゃなくて、
クロージャの再起呼び出しじゃなきゃできないことを聞きたかった
引数以外のパラメーターを差し込む場合、普通は再起は必要ないよね
2018/07/04(水) 00:52:48.93ID:MQVza7QA
風雲再起ぃ〜!!
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。

ニューススポーツなんでも実況