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/03/30(金) 00:24:21.95ID:IN/IsR4/
やまもといちろう、清水亮、津田大介あたりだな
2018/03/30(金) 00:59:44.92ID:YF4CHAi5
やまもといちろうのしったか芸は凄いｗ
2018/03/30(金) 12:34:16.32ID:IN/IsR4/
ニコ生ってたしかRust使ってるんだっけ？
Rust江添の今後に期待
2018/03/30(金) 14:08:12.82ID:82JQsmMo
>>230
だからニコニコごときが選択したってことは使えん技術ってことだろ
ネトフリとかが採用したら考えるが
2018/03/30(金) 14:10:51.95ID:82JQsmMo
Rust採用事例
ニコニコ←負け組
火狐←負け組
Mercurial←負け組
泥箱←個人情報お漏らし

採用する気にもならん事例のオンパレード
2018/03/30(金) 14:13:18.93ID:82JQsmMo
顔本もテストプロジェクトかなんかで使ってた記憶があるが、
そういやここもお漏らししたっけな
2018/03/30(金) 14:14:12.95ID:XUq2/9hV
【悲報】Packt出版より出る予定だった Rust Blueprints が出版取消されました。
2018/03/30(金) 14:16:08.36ID:82JQsmMo
>>234
資源の無駄だからな。当然の結果
236デフォルトの名無しさん
垢版 |
2018/03/30(金) 18:11:51.70ID:2SqbRzP3
また来たのかよ
2018/03/30(金) 18:23:23.77ID:IN/IsR4/
Rustってキラーアプリあんの？
2018/03/30(金) 18:37:40.08ID:ksXSxVO9
ErlangとScalaもディスってるんだ
https://github.com/dwango
2018/03/30(金) 21:33:06.96ID:35t2qqJ0
セキュアプログラミングとかいって締め付ければ締め付けるほど
インシデントが増えるw
本質はそういうところじゃないってことがよくわかる。
240デフォルトの名無しさん
垢版 |
2018/03/30(金) 22:18:13.79ID:lc3QGxh+
>>239
じゃあ本質はどこにあるんだよ？
自分には分からないからってだけが理由でそうじゃないと決めつけるのは勝手だけど…
2018/03/30(金) 22:28:24.32ID:35t2qqJ0
開発効率やランタイム速度を気にしなけりゃ既存の言語でも安全に作るなんてのは
簡単なんだよ。
そのトレードオフをどれだけ解決できるかが本質。
2018/03/30(金) 23:00:52.49ID:OoWw053g
開発効率やランタイム速度を気にしないことが本質？
2018/03/30(金) 23:58:55.57ID:dpNxQVLw
おぉっとここで日本語の分からないバカが登場〜
244デフォルトの名無しさん
垢版 |
2018/03/31(土) 00:49:07.16ID:q0ZQKkqb
>>241
安全に作るのが簡単ねぇ…
簡単だったらGoogleがバグ(セキュリティホール)の発見に
多額の報奨金を出すのはおかしいとか考えないのかね？
君にとっての"安全"の基準が分からないんだが…
2018/03/31(土) 07:55:27.02ID:9+5jHACw
>>244
グーグルにとってみたらそっちのがよっぽど楽、つまり開発効率がいいからでしょ。
理解不足の人がいるようなのでもう一度言うけどトレードオフの問題だっつーの。
2018/03/31(土) 09:33:15.73ID:q0ZQKkqb
>>245
極論だな
開発効率を無視するなら安全に作ることは可能ってことだろ
開発効率を無視するってのはつまり開発期間が無限大と仮定するってことだぞ
開発期間が無限大でなければ安全に作ることが不可能なら
それは実質、安全に作ることは不可能って事と同義だからな

結局言いたいことは"開発効率・ランタイム速度"と"安全"がトレードオフの関係にあり、
それをいかにして解決するかが本質ってことだろ
で、その"解決"が何を指すのかっていう一番肝心な部分が抜け落ちてるぞ
"トレードオフの均衡点をどこに置くべきかを探る"のが解決なのか
それとも"トレードオフの関係自体を壊そうとする"ことが解決なのか
あるいはその両方か

あと、Googleは開発効率を優先して報奨金を出してるわけじゃないだろ
そもそもリリースした後のものは開発ではなく保守なんだから
あれは完璧に安全なものを作るのは不可能だから苦肉の策として行ってるだけ

てゆーか、ツッコミどころが多すぎるんですけど…
2018/03/31(土) 10:29:59.95ID:E8qTp8R8
>>238
もちろん
Erlangは状態中途半端にブッ壊すだけだし
Scalaなんてもはや新規で使うところどこにもねえだろ
2018/03/31(土) 10:36:16.41ID:E8qTp8R8
>>246
バカじゃね？
Rustがその解決になってるかって観点がどこにもない

トレードオフの落としどころとしてRustにはなんの実績もないし、CやC++と周辺ツール合わせた環境に勝る性質もなにもないって言ってんの
ValgrindやCoverityみたいなツールに比べた優位性あるの？
ただ書きにくい言語がひとつ増えただけじゃん
2018/03/31(土) 11:03:18.18ID:wLUR9MAo
お前が元気で帰ってきてくれてよかったよ

職は見つからなかったんだね
250デフォルトの名無しさん
垢版 |
2018/03/31(土) 11:12:27.60ID:q0ZQKkqb
>>248
"解決"が何を指すのかを聞いているのにそれには答えずに
Rustは"解決"していないとだけ答える…
会話が噛み合わない…どうすればいいのか…
251デフォルトの名無しさん
垢版 |
2018/03/31(土) 11:39:17.36ID:q0ZQKkqb
実績がないって言うのもFirefoxの一部は既にRustで置き換えられてるのに
君がそれを実績として認めないってだけだろ
ブラウザを一から実装しなおして、それが大きなバグを出すこともなく
Chromeと同レベルの実行速度を実現してるってだけでも充分に実績として認められると思うが。
Chromeに比べればシェアは少ないがそれでも世界中で数百万という人間がFirefoxを使ってるんだぞ
252デフォルトの名無しさん
垢版 |
2018/03/31(土) 11:41:20.61ID:D1vbg0pQ
そこは何億人ものって言わなきゃｗ
253デフォルトの名無しさん
垢版 |
2018/03/31(土) 11:43:55.45ID:q0ZQKkqb
>>252
数百万はかなり適当に発言した
実際はどれくらいなんだろうな？
2018/03/31(土) 11:46:03.70ID:0efq0OdT
3億人くらい？
2018/03/31(土) 13:24:58.66ID:yT2VCMNA
Javaなんて30億のデバイスで動いてんだぞ！
2018/03/31(土) 14:14:44.03ID:ApL2p8x0
>>251
せめてchromeと同じシェア取ってから言って欲しいもんだ
2018/03/31(土) 14:32:47.34
Write once, run anywhere なんていう開発プラットフォームがあるらしい
Electronって言うんだって
2018/03/31(土) 14:34:08.51ID:NaIZlBM+
native modules はい論破。
2018/03/31(土) 15:26:33.15ID:tztr1ir/
chromeメモリ食いすぎなのでfirefox59に乗り換えたよ
260デフォルトの名無しさん
垢版 |
2018/03/31(土) 15:27:50.28ID:q0ZQKkqb
>>256
"せめて"でChromeと同じシェアなのかよ。ハードル高すぎだろ
そんなのどんな言語使ったって数年じゃ無理だわ
もちろんChromeと同じC++を使って作り直しても無理だわ
どうやら君の御眼鏡にかなう言語はこの世のどこにも無さそうだな
2018/03/31(土) 16:10:13.77ID:ApL2p8x0
Rustで書き直したら安全で高速なプログラムが簡単に書けるんだろう？

ならchromeのシェアを奪うのなんてすぐじゃないか
本当にRustにそれだけの性能があるなら
262デフォルトの名無しさん
垢版 |
2018/03/31(土) 16:22:16.04ID:D1vbg0pQ
Chromeは昔のIEと同じくらい危険なブラウザになってきたよな。
やはり危険度はシェアで決まるんじゃないだろか。
そもそもあれだけ複雑で奇怪で大きなソフトウェアにバグが無いわけないし。
いやもちろん、HaskellやJavaやJavascriptのような安全な言語で書かれていれば一切のバグは無いんだろうけどさ。
263デフォルトの名無しさん
垢版 |
2018/03/31(土) 16:22:59.14ID:D1vbg0pQ
ここRustスレだったかｗ
じゃあ、Rustのような安全な言語で書かれてればバグは無いんだろうけどさ。
264デフォルトの名無しさん
垢版 |
2018/03/31(土) 16:25:50.13ID:D1vbg0pQ
Chromeの開発者がRustで書き直したいと書き込んでるのは見たことあるけどな。
でも、書き直すったってそもそも発祥がKHTMLだしな。
Googleは出来損ないのブルドーザーみたいなもんだ。
2018/03/31(土) 16:37:28.69ID:ApL2p8x0
HaskellはともかくJSやJavaは安全なのかね？
まあスレチだが
266デフォルトの名無しさん
垢版 |
2018/03/31(土) 16:52:02.69ID:q0ZQKkqb
>>261
>Rustで書き直したら安全で高速なプログラムが簡単に書けるんだろう？
誰もそんなこと一言も言ってないだろ。勝手に曲解しないでほしいな
C++よりはRustの方が設計が良いってだけ
そう言ったら次は"C++より良いって言うんならC++で書かれてるChromeより
Rustで書かれたFirefoxのシェアが少ないのはおかしい"って言い出すんだろ
既存資産はC++のほうが何十倍もある。資産が少ないってのはそれだけで不利だ
言語設計はダメだが資産の多いC++か、言語設計は良いが資産の少ないRustか、
どちらを選ぶかは人によって意見が変わるところだろう
資産の問題に関しては時間が解決してくれるかもしれない…希望的観測に過ぎないが…

>ならchromeのシェアを奪うのなんてすぐじゃないか
すぐなわけないだろ。
ブラウザを選ぶ基準なんて数え切れないほど色んな要素が絡み合ってるんだよ
その中には"なんとなく、みんなが使ってるから"なんてしょうもない理由も多く存在する
全ての人間が合理的な判断を下すわけじゃないんだ。そんな単純に事が運ぶわけがない

だから、ツッコミどころが多すぎるんだって…
267デフォルトの名無しさん
垢版 |
2018/03/31(土) 16:58:36.90ID:D1vbg0pQ
Boostはオナニーし過ぎのグロマンコみたいなもんだが使わざるを得ないって話か。
268デフォルトの名無しさん
垢版 |
2018/03/31(土) 17:01:22.81ID:D1vbg0pQ
Javascriptのお勉強をした結果、GCは何の解決にもならないことが分かった。
むしろ危険。
ライブラリがリークについて何も考えていないんだもん。
269デフォルトの名無しさん
垢版 |
2018/03/31(土) 17:02:54.36ID:D1vbg0pQ
なんでだろ〜なんでだろ〜と検索した結果、あの有名な企業のブログで解決策を発見。
曰く、ライブラリがリークするようにできてるから、一定時間で再起動とか。
そんなのが多すぎた。
2018/03/31(土) 18:56:11.43ID:ApL2p8x0
ぐだぐだ言い訳してるのを総合すると
「モノは良いけど使い手が少ないせいで流行らない」ってか？
使い手が少ないのはものが悪いってことだろ。残念でした
2018/03/31(土) 18:58:11.61ID:ApL2p8x0
Go言語見てみろ
モノはいろいろと微妙だがCやC++と比べて強烈な利点があるから、リリースがRustと同じか遅いくらいなのに流行ってるだろ

Rustはどうなんですかねえ？
272デフォルトの名無しさん
垢版 |
2018/03/31(土) 20:27:06.89ID:PqROMcrp
つまりPHPが最良の言語ってわけか
273デフォルトの名無しさん
垢版 |
2018/03/31(土) 20:42:09.87ID:oZoT3jkC
わざわざRustスレまできて延々粘着アンチとかかまってほしい爺さんみたいで見苦しいからやめろ
274デフォルトの名無しさん
垢版 |
2018/03/31(土) 20:45:48.24ID:D1vbg0pQ
>>273
かまってほしい爺さんに、かまってほしい爺さんみたいとかやめてくんない？
あんた人の心あんの？
2018/03/31(土) 21:14:47.08
かま爺
2018/03/31(土) 21:55:49.66ID:dXOBbz7B
いくらモノがクソでも流行ってるって一点で考慮に入れる必要はあるし、
逆にどんなに良いものでも流行ってなければ選外になるのは事実よね

PHPが流行ってるのは時代的に残念な背景があるとはいえ、
Goが流行るのは明確な理由があるんじゃないか？
277デフォルトの名無しさん
垢版 |
2018/03/31(土) 22:11:12.54ID:7TTU0i1a
それについて掘り下げる意義はないと思いますよ
2018/03/31(土) 22:16:22.26ID:dXOBbz7B
まあ確かにないな
せめて日本語で本が出る程度には流行って欲しいが……

今のRustに足りないものってなんだろうな
RubyのRailsみたいに、ある領域のキラーフレームワークみたいなのが欲しいが
Rustがそれを作れる領域って今のところWebAssemblyくらいしかないんだよな
しかもそのWebAssemblyも、GCが入ったらGoとの立ち位置が逆転するし
279デフォルトの名無しさん
垢版 |
2018/04/01(日) 07:31:46.82ID:QnuEAtVo
それはgoが流行っている理由を語るのと同義ではないですか
2018/04/01(日) 07:36:32.82ID:nW/fPqLD
Goこそブランドの影響だと思うけどなｗ
Googleって会社も初期メンバーこそキレキレの人間だったのかもしれんが
ブランドイメージが先行しだしたころから
そこにはそこに憧れて集っちゃった凡人がうじゃうじゃだということを忘れてはならない
2018/04/01(日) 08:59:01.17ID:aM38sJCa
rustは
ゼロ抽象化みたいな機能ブランドに憧れて集まっちゃった凡人がうじゃうじゃだよね
2018/04/01(日) 09:02:36.32ID:N/JoH072
機能ブランドってなに？中身ないの？
2018/04/01(日) 09:31:03.82ID:r/SQKbFj
ないよ。あったらもっと人集まってるよ
2018/04/01(日) 09:41:07.81ID:r/SQKbFj
RustはCやC++を書くのに疲れた人のための言語という位置付けなのに
Rustを書ける奴は別にCやC++書くのに困らないって
イカれた習得難易度に作ってしまったのがそもそもの失敗

Rustのターゲットは別にRustなんて使わなくてもいいかそもそもRustを使えないかの二択
ドンピシャなターゲットが存在しないから流行りようがない
285デフォルトの名無しさん
垢版 |
2018/04/01(日) 09:51:30.48ID:QnuEAtVo
rustを書ける人でcやc++で困らないと結論した人が沢山いるということですか？
286デフォルトの名無しさん
垢版 |
2018/04/01(日) 10:13:31.75ID:9alzQdGn
>>284
>RustはCやC++を書くのに疲れた人のための言語という位置付け
これは事実だけど、C++より簡単に書けることを目指して作ったわけじゃなくて
ポインタ周りのバグ(特にバッファオーバーフローなどが原因のセキュリティホール)
に悩まされてきた人間のために作られた言語だからな
セキュリティを考えてない奴からすれば無用な長物にしか見えないんだろう
287デフォルトの名無しさん
垢版 |
2018/04/01(日) 10:21:58.94ID:9alzQdGn
>>286
訂正：無用な長物→無用の長物
2018/04/01(日) 11:14:37.02ID:r/SQKbFj
>>286
Rustできちんとコード書ける実力あるなら
CやC++でもセキュリティホール作り込まないプログラミングできるだろって話な
2018/04/01(日) 11:17:57.70ID:FEh/C/xR
てか｢一応読み書きはできるようにはなったけどC/C++の落とし穴を知らないせいで危ないコード書いてる初心者｣こそRustやるべきだよな
>>56みたいな

>>56がなんでエラーになるのか理解できないって事はC/C++でもvectorへの参照を何も考えないで使い回してたりするって事だし
2018/04/01(日) 11:21:05.39ID:r/SQKbFj
ああそれはあるかもな
実用というより教育目的な言語としては確かにアリだ
291デフォルトの名無しさん
垢版 |
2018/04/01(日) 11:36:26.93ID:9alzQdGn
>>288
>Rustできちんとコード書ける実力あるなら
>CやC++でもセキュリティホール作り込まないプログラミングできるだろって話な
出来ないからC++ではValgrindとかのツール使ってチェックしてるんだろ
じゃあツールを必ず使うようにすればいいじゃんって話にはなるが…
292デフォルトの名無しさん
垢版 |
2018/04/01(日) 11:39:14.42ID:9alzQdGn
そもそもValgrindみたいなメモリリークをチェックする類のツールって
Rustのボローチェッカと比べるとどの程度信用できるのかね？
2018/04/01(日) 11:47:08.80ID:jrLYAFkE
あまり信用出来ない
スマートポインタを(適切に)使ってればそもそも解放忘れはしないし
配列に確保しっぱなし系のリークは検知してくれない
294デフォルトの名無しさん
垢版 |
2018/04/01(日) 11:55:47.66ID:9alzQdGn
>>293
>あまり信用できない
>配列に確保しっぱなし系のリークは検知してくれない
そっか、やっぱりRustのボローチェッカには劣るか
>スマートポインタを(適切に)使ってればそもそも解放忘れはしない
「適切に」ってところがポイントだよね
たとえ熟練のC++erがどれだけ注意してコーディングしてたって
「うっかりミス」はいつか絶対に起きるんだし
2018/04/01(日) 12:42:04.82
C++でボローチェッカをエミュレーションできないの？
2018/04/01(日) 12:44:43.78ID:BOTWSFOl
C++ちゃんとかけるならRustも楽勝でしょ。
297デフォルトの名無しさん
垢版 |
2018/04/01(日) 13:57:47.26ID:QnuEAtVo
>>288
できないよ、人間だもの
2018/04/01(日) 14:16:47.69ID:1ng3UkJB
valgrind使うと実行時間とてつもなく遅くなるし実行時間長いプログラムだと辛い
ASANでも2倍くらい遅くなるので辛いのは同じ
コンパイル時に静的に分かる方が嬉しいし、たまにしか通らないパスもチェックされるのでより安全
2018/04/01(日) 19:22:10.86ID:aM38sJCa
まあ結局unsafe部分はチェックできないけどね。
その場合でもコンパイル通ったからと主張しだす輩で溢れてる。
300デフォルトの名無しさん
垢版 |
2018/04/01(日) 19:26:04.60ID:QnuEAtVo
どこに溢れてるの？
2018/04/01(日) 19:51:17.12ID:Vaw8NqEv
脳内
2018/04/01(日) 21:39:06.35ID:N/JoH072
C++20では生ポが非推奨になるらしいけど
unsafeはチェックできないのと同様に意味がないですね
2018/04/01(日) 21:53:26.11ID:aM38sJCa
他言語呼んでもメモリリーク起きないとかこのスレでも喚いてた輩がいたわけだが。
drop trait を明示的に書かなっきゃならんとかそいつら全く理解してないだろ。
304デフォルトの名無しさん
垢版 |
2018/04/01(日) 21:55:16.18ID:9alzQdGn
>>302
非推奨になるってどういうこと？
rustみたいにunsafeブロックみたいなのを導入するってこと？
C++は基本的にはCとの互換があるから無理だと思ってたんだけど…
305デフォルトの名無しさん
垢版 |
2018/04/02(月) 11:44:35.64ID:z3JOGYz+
生ポインタ使えることがC++の唯一のメリットなのに
それを非推奨にするなら別の言語使ったほうがマシだろ
2018/04/03(火) 12:33:46.66ID:GZlQK3q7
RustがC++に実用面で勝ってることなんかある？
2018/04/03(火) 13:06:14.98ID:cmHjEB2c
勝っているかどうかは知らんが
cargo/crates.io相当のものがないから
新規アプリをC++で書く気はしなくなってしまった。
もしかして最近は便利になってたりするんだろうか。
2018/04/03(火) 17:54:07.91ID:lesCWZwY
全称命題にするからすぐ反論される
309デフォルトの名無しさん
垢版 |
2018/04/03(火) 21:15:38.01ID:zqNShNDp
ペチパーのわしでも書けるのが勝ってる
2018/04/03(火) 21:18:30.15ID:BzNmSsTz
しかしインスタンスを変に共有しなけりゃ解放タイミングを
いちいち気にしなくていいって発想は面白い。
311デフォルトの名無しさん
垢版 |
2018/04/03(火) 23:40:54.16ID:K5huRztI
いや、それ当たり前のことだから。
2018/04/04(水) 00:15:13.34ID:e/ecM7t7
RustでWebブラウザ作ってる人いるね


https://twitter.com/uint256_t/status/952818644433555456
2018/04/07(土) 01:03:26.54ID:T+RwBbo7
参照カウントガベージコレクションにもスマートポインタにも興味ないrust信者すごいね
2018/04/07(土) 06:53:26.51ID:k/xupSTU
GCに興味ないのはともかく
BoxとかRcとかモロにスマートポインタだから興味ないとか以前の問題なんだが？
2018/04/07(土) 07:02:17.22ID:sb7KGbUH
というかなんで今になって参照カウンタGCなんて超素朴なGC実装を引き合いに出すのかが分からん
Goですらそんなもん使ってねえぞ
2018/04/07(土) 07:10:17.71ID:sb7KGbUH
……まさかとは思うがC++のshared_ptrのことを指して参照カウントGCと称してないよな？

RustではRcとかArcがそれに該当するから、この文脈でも完全に的はずれになるが
2018/04/10(火) 11:37:36.43ID:pRwunYlM
>>315
Swiftは参照カウント方式のGC採用していたような気がするが
ARCってやつ
318デフォルトの名無しさん
垢版 |
2018/04/12(木) 01:27:42.33ID:JdbozTc/
久しぶりに見に来たらアンチが帰ってきてるじゃん。
せっかくだから、おれも反論レスを書き込むことにする。
319デフォルトの名無しさん
垢版 |
2018/04/12(木) 01:28:00.22ID:JdbozTc/
>>288
こんなこと言っちゃってる時点でセキュリティに気を使ってないのバレバレだよね
セキュリティ関係に詳しくなくて分からないんなら素直に分からないって言いなよ
320デフォルトの名無しさん
垢版 |
2018/04/12(木) 01:28:37.08ID:JdbozTc/
>>299
unsafeなんてC FFIしようとか考えない限りあまり使うことないよ
tokio-coreとかhyperとかhtml5everとかのソースコード見てきなよ
unsafe使ってる箇所なんて10箇所あるかないかってところだから。
コード全域に気を配らなきゃならないのか、たった10箇所程度に気を付けてれば良いのか、
どちらが楽(安全)なのかは火を見るよりも明らかだよね
321デフォルトの名無しさん
垢版 |
2018/04/12(木) 01:30:08.73ID:JdbozTc/
>>303
これに関しては自分がC FFIのコードを滅多に書かないから「そうだったっけ？」くらいにしか考えなかったけどよく考えたら全然違うよね。
まず、値渡しなら引数・戻り値ともに何の問題もない。そのまま渡せばいい。
ポインタ渡し(Box<T>)だった場合はCの関数の引数が所有権か借用のどちらを欲してるのかを確認して、
所有権を欲しがってるならBox::into_raw(x)で所有権を渡せばいいし、
借用が必要ならx.as_ref() as *const _ もしくはx.as_mut() as *mut _で渡せばいい。
戻り値の方ではC側から所有権が渡されてるはずだからBox::from_raw(px)でBox<T>に戻せばOK。
文字列(String)の場合はCStringに変換してから後はBox<T>と同様にinto_raw, from_raw使えばいいだけ。
Vec<T>とかを渡そうとする場合はx.as_ptr()またはx.as_mut_ptr()と場合によってはmem::forget(x)が必要になるんじゃないかな？
受け取る場合はVec::from_raw_parts(px, len, cap)を使えばいいはず。(前述のとおりC FFIはあまり詳しくはないので間違ってたら指摘して下さい)
unsafeの中に何を書けば良いのかはC側のどんな関数を呼ぶのか次第で変わってくるけど、少なくともDropトレイトに関しては全く必要ない。
Box<T>やVec<T>等にあらかじめ実装されてるDropトレイトに任せればいいだけ。むしろ君はDropトレイト使って一体何する気だったのか…？
322デフォルトの名無しさん
垢版 |
2018/04/12(木) 01:30:27.15ID:JdbozTc/
Rustのアンチするのは一向に構わんが、せめて嘘をつくのはやめようね。
2018/04/12(木) 03:23:54.50ID:XYZqcSuW
C FFIとやらを使うためにはRustの知識だけでなくCの知識も必要
Rustだけ学べばいいなんてことはない
2018/04/12(木) 06:41:03.77ID:1NMGlh89
>>323
cの関数呼ぶんだから当然だろ
2018/04/12(木) 09:05:15.80ID:IekpLPdE
>>321
Rustで確保したリソースをCに渡す場合は確かにdropいらないけど、
C側で確保したリソースについては必要では？
Cから何かハンドルが帰ってきて最後にCでcloseするパターン。
2018/04/12(木) 11:33:57.87ID:6MGFsFO1
>>325
Rust側でDropしないためにDropの実装を上書きする必要があるということ？
2018/04/12(木) 12:23:34.05ID:IekpLPdE
>>326
Cの関数内で確保したリソースは
当然Rustデフォルトのdrop実装では解放されないから
自分でdrop実装して解放する必要がある、という話。
328デフォルトの名無しさん
垢版 |
2018/04/12(木) 13:14:59.37ID:JdbozTc/
>>325
>>303は「メモリリーク」って書いてあるからヒープに確保されたメモリの解放に関しては
Dropトレイトを実装する必要性なんか全く無いってことを>>321で説明してる。

>>325の言ってる「リソース」ってのはファイルとかソケットとかのことを言ってるんだよね
そっちはメモリリークとはまた別の話になるので状況によるんじゃないかな…
ただ、OSが提供してるリソース(ファイルやソケット)くらいなら、File, TcpListenerとかには
Windows用とUnix用にそれぞれinto_raw_xxx(), from_raw_xxx(), as_raw_xxx()とかが用意されてるから
それを使えば後のことはFile, TcpListenerのdrop実装に任せてしまって問題ないはず。
C側(ライブラリ)で独自に実装されてるリソース(close等の後処理が必要な実装)の場合は
close部分をRustのDropトレイトの実装として移植する必要はあるだろうね。
(もう一度言うけど、自分は普段はC FFIを使わないから詳しくはないので、間違ってたら指摘して下さい)
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況