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/04/01(日) 11:14:37.02

>>286
Rustできちんとコード書ける実力あるなら
CやC++でもセキュリティホール作り込まないプログラミングできるだろって話な

**デフォルトの名無しさん** · 2018/04/01(日) 11:17:57.70

てか｢一応読み書きはできるようにはなったけどC/C++の落とし穴を知らないせいで危ないコード書いてる初心者｣こそRustやるべきだよな
>>56みたいな

>>56がなんでエラーになるのか理解できないって事はC/C++でもvectorへの参照を何も考えないで使い回してたりするって事だし

**デフォルトの名無しさん** · 2018/04/01(日) 11:21:05.39

ああそれはあるかもな
実用というより教育目的な言語としては確かにアリだ

**デフォルトの名無しさん** · 2018/04/01(日) 11:36:26.93

>>288
>Rustできちんとコード書ける実力あるなら
>CやC++でもセキュリティホール作り込まないプログラミングできるだろって話な
出来ないからC++ではValgrindとかのツール使ってチェックしてるんだろ
じゃあツールを必ず使うようにすればいいじゃんって話にはなるが…

**デフォルトの名無しさん** · 2018/04/01(日) 11:39:14.42

そもそもValgrindみたいなメモリリークをチェックする類のツールって
Rustのボローチェッカと比べるとどの程度信用できるのかね？

**デフォルトの名無しさん** · 2018/04/01(日) 11:47:08.80

あまり信用出来ない
スマートポインタを(適切に)使ってればそもそも解放忘れはしないし
配列に確保しっぱなし系のリークは検知してくれない

**デフォルトの名無しさん** · 2018/04/01(日) 11:55:47.66

>>293
>あまり信用できない
>配列に確保しっぱなし系のリークは検知してくれない
そっか、やっぱりRustのボローチェッカには劣るか
>スマートポインタを(適切に)使ってればそもそも解放忘れはしない
「適切に」ってところがポイントだよね
たとえ熟練のC++erがどれだけ注意してコーディングしてたって
「うっかりミス」はいつか絶対に起きるんだし

**デフォルトの名無しさん** · 2018/04/01(日) 12:42:04.82

C++でボローチェッカをエミュレーションできないの？

**デフォルトの名無しさん** · 2018/04/01(日) 12:44:43.78

C++ちゃんとかけるならRustも楽勝でしょ。

**デフォルトの名無しさん** · 2018/04/01(日) 13:57:47.26

>>288
できないよ、人間だもの

**デフォルトの名無しさん** · 2018/04/01(日) 14:16:47.69

valgrind使うと実行時間とてつもなく遅くなるし実行時間長いプログラムだと辛い
ASANでも2倍くらい遅くなるので辛いのは同じ
コンパイル時に静的に分かる方が嬉しいし、たまにしか通らないパスもチェックされるのでより安全

**デフォルトの名無しさん** · 2018/04/01(日) 19:22:10.86

まあ結局unsafe部分はチェックできないけどね。
その場合でもコンパイル通ったからと主張しだす輩で溢れてる。

**デフォルトの名無しさん** · 2018/04/01(日) 19:26:04.60

どこに溢れてるの？

**デフォルトの名無しさん** · 2018/04/01(日) 19:51:17.12

脳内

**デフォルトの名無しさん** · 2018/04/01(日) 21:39:06.35

C++20では生ポが非推奨になるらしいけど
unsafeはチェックできないのと同様に意味がないですね

**デフォルトの名無しさん** · 2018/04/01(日) 21:53:26.11

他言語呼んでもメモリリーク起きないとかこのスレでも喚いてた輩がいたわけだが。
drop trait を明示的に書かなっきゃならんとかそいつら全く理解してないだろ。

**デフォルトの名無しさん** · 2018/04/01(日) 21:55:16.18

>>302
非推奨になるってどういうこと？
rustみたいにunsafeブロックみたいなのを導入するってこと？
C++は基本的にはCとの互換があるから無理だと思ってたんだけど…

**デフォルトの名無しさん** · 2018/04/02(月) 11:44:35.64

生ポインタ使えることがC++の唯一のメリットなのに
それを非推奨にするなら別の言語使ったほうがマシだろ

**デフォルトの名無しさん** · 2018/04/03(火) 12:33:46.66

RustがC++に実用面で勝ってることなんかある？

**デフォルトの名無しさん** · 2018/04/03(火) 13:06:14.98

勝っているかどうかは知らんが
cargo/crates.io相当のものがないから
新規アプリをC++で書く気はしなくなってしまった。
もしかして最近は便利になってたりするんだろうか。

**デフォルトの名無しさん** · 2018/04/03(火) 17:54:07.91

全称命題にするからすぐ反論される

**デフォルトの名無しさん** · 2018/04/03(火) 21:15:38.01

ペチパーのわしでも書けるのが勝ってる

**デフォルトの名無しさん** · 2018/04/03(火) 21:18:30.15

しかしインスタンスを変に共有しなけりゃ解放タイミングを
いちいち気にしなくていいって発想は面白い。

**デフォルトの名無しさん** · 2018/04/03(火) 23:40:54.16

いや、それ当たり前のことだから。

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

RustでWebブラウザ作ってる人いるね

https://twitter.com/uint256_t/status/952818644433555456

**デフォルトの名無しさん** · 2018/04/07(土) 01:03:26.54

参照カウントガベージコレクションにもスマートポインタにも興味ないrust信者すごいね

**デフォルトの名無しさん** · 2018/04/07(土) 06:53:26.51

GCに興味ないのはともかく
BoxとかRcとかモロにスマートポインタだから興味ないとか以前の問題なんだが？

**デフォルトの名無しさん** · 2018/04/07(土) 07:02:17.22

というかなんで今になって参照カウンタGCなんて超素朴なGC実装を引き合いに出すのかが分からん
Goですらそんなもん使ってねえぞ

**デフォルトの名無しさん** · 2018/04/07(土) 07:10:17.71

……まさかとは思うがC++のshared_ptrのことを指して参照カウントGCと称してないよな？

RustではRcとかArcがそれに該当するから、この文脈でも完全に的はずれになるが

**デフォルトの名無しさん** · 2018/04/10(火) 11:37:36.43

>>315
Swiftは参照カウント方式のGC採用していたような気がするが
ARCってやつ

**デフォルトの名無しさん** · 2018/04/12(木) 01:27:42.33

久しぶりに見に来たらアンチが帰ってきてるじゃん。
せっかくだから、おれも反論レスを書き込むことにする。

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

>>288
こんなこと言っちゃってる時点でセキュリティに気を使ってないのバレバレだよね
セキュリティ関係に詳しくなくて分からないんなら素直に分からないって言いなよ

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

>>299
unsafeなんてC FFIしようとか考えない限りあまり使うことないよ
tokio-coreとかhyperとかhtml5everとかのソースコード見てきなよ
unsafe使ってる箇所なんて10箇所あるかないかってところだから。
コード全域に気を配らなきゃならないのか、たった10箇所程度に気を付けてれば良いのか、
どちらが楽(安全)なのかは火を見るよりも明らかだよね

**デフォルトの名無しさん** · 2018/04/12(木) 01:30:08.73

>>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トレイト使って一体何する気だったのか…？

**デフォルトの名無しさん** · 2018/04/12(木) 01:30:27.15

Rustのアンチするのは一向に構わんが、せめて嘘をつくのはやめようね。

**デフォルトの名無しさん** · 2018/04/12(木) 03:23:54.50

C FFIとやらを使うためにはRustの知識だけでなくCの知識も必要
Rustだけ学べばいいなんてことはない

**デフォルトの名無しさん** · 2018/04/12(木) 06:41:03.77

>>323
cの関数呼ぶんだから当然だろ

**デフォルトの名無しさん** · 2018/04/12(木) 09:05:15.80

>>321
Rustで確保したリソースをCに渡す場合は確かにdropいらないけど、
C側で確保したリソースについては必要では？
Cから何かハンドルが帰ってきて最後にCでcloseするパターン。

**デフォルトの名無しさん** · 2018/04/12(木) 11:33:57.87

>>325
Rust側でDropしないためにDropの実装を上書きする必要があるということ？

**デフォルトの名無しさん** · 2018/04/12(木) 12:23:34.05

>>326
Cの関数内で確保したリソースは
当然Rustデフォルトのdrop実装では解放されないから
自分でdrop実装して解放する必要がある、という話。

**デフォルトの名無しさん** · 2018/04/12(木) 13:14:59.37

>>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を使わないから詳しくはないので、間違ってたら指摘して下さい)

**デフォルトの名無しさん** · 2018/04/12(木) 15:11:14.26

>>328
メモリリークに限定するとしても
CでmallocしたポインタがRustに渡ってきた場合
Rustが勝手に解放するわけにはいかないから
drop実装してfreeを呼ぶ必要がある。

**デフォルトの名無しさん** · 2018/04/12(木) 17:39:03.84

>>329
ちょっと言ってる意味がわからない
Cでmallocされたものであっても所有権ごと渡されていれば解放の責任はRustにある
ていうか、Rust側で勝手に解放しちゃいけないと言ってるのに
Dropトレイトの実装でfreeしたらやっぱりRust側で勝手に解放しちゃってるじゃん
言ってること矛盾してない？

CとRustで型のメモリレイアウトが一致してればあとはBox型に任せるだけだよ

Cから渡されてくるポインタの型のメモリレイアウトが公開されていなければ
(つまりvoidポインタだったりオペーク構造体(オペークポインタ)だったなら)話は別だけど。

その場合はRustはハンドルをもらうだけでいかなる操作(メモリの解放(free)も含む)もC FFIでC側に
頼むしかない(メモリレイアウトがわからない限りはRust側ではどうあがいても何も出来ない)ので
Dropトレイト実装してdrop時にC側にメモリの解放処理も頼む必要がある

**デフォルトの名無しさん** · 2018/04/12(木) 18:12:43.26

FFIの場合jemallocかシステムのmallocかの違い問題になることありそう

**デフォルトの名無しさん** · 2018/04/12(木) 21:02:25.76

>その場合はRustはハンドルをもらうだけでいかなる操作(メモリの解放(free)も含む)もC FFIでC側に
>頼むしかない(メモリレイアウトがわからない限りはRust側ではどうあがいても何も出来ない)ので
>Dropトレイト実装してdrop時にC側にメモリの解放処理も頼む必要がある

だからDropトレイトを意識的に実装せにゃならんと始めから言ってるだろうに。
このタイプは絶対仕事でモメるわ。

**デフォルトの名無しさん** · 2018/04/12(木) 22:43:32.09

>>322
だったら「Rust側からはメモリレイアウトが分からないようなvoidポインタや
オペーク構造体がC側から渡された場合は」という前提条件をきちんと書け。
条件を何も書かずに「drop trait を明示的に書かなきゃならん」とだけ書かれれば
全ての場合で必要だと言っているようにしか見えない。

あと、>>321で「全く」と書いてしまったことは悪かったと思っている
>>321を書いてる時点は上記のような可能性に気づいていなかった…申し訳ない。

お前みたいに「特定の条件下でしか適用されないこと」に対して条件を書かずに結論だけ書いて
「自分はきちんと伝えた」とか思っちゃってるキチガイとの仕事とかこっちの方から願い下げだから。

**デフォルトの名無しさん** · 2018/04/12(木) 22:50:55.21

>>331
そこは自分も同じことを思った。
mallocとjemallocの実装の中身とか見たことないけど、混在してても問題ないのかな？

**デフォルトの名無しさん** · 2018/04/12(木) 22:54:07.42

>>333 訂正
>>322 → >>332

**デフォルトの名無しさん** · 2018/04/12(木) 23:08:05.77

>>330
「勝手に」の部分が曖昧だったので正確に書くと、
Rustはメモリ解放すべきタイミングは知っている
（すなわちCから受け取ったポインタのlifetimeが切れたとき）
Rustはメモリ解放の方法は知らない
（なぜならCのmallocがシステムのmallocなのかjemallocなのか別の何かなのか知るすべがないから）
なので方法について教えるためにdropを実装する。
（このdropでCのfreeを呼べば、mallocと同じメモリアロケータが保証される）

ちなみにメモリアロケータ間の互換性はないので、
例えばlibcでmallocしてjemallocでfreeすると多分SEGVする。
コード例は以下でもどうぞ。
https://stackoverflow.com/questions/31486519/how-do-i-free-a-char-allocated-via-ffi-in-rust

**デフォルトの名無しさん** · 2018/04/12(木) 23:35:57.15

>>336
マジか…mallocとjemallocは混在できないのか…
そうなると、C側でmallocされてれば必ずC側にfreeしてもらうしかないということか…
じゃあ今まで俺が書いた方法じゃダメなケースもあるじゃん…すまん。
自分の無知を晒す羽目にはなったが、むしろ今知れてよかったわ。
でも、そうなると新たな疑問が…

**デフォルトの名無しさん** · 2018/04/13(金) 00:47:00.07

jemallocじゃなくてシステムのアロケーター使うオプションだかfeatureだか使えば良いかな

**337** · 2018/04/13(金) 01:19:50.99

>>336
間違いの指摘と情報提供のお礼言うの忘れてた。Thanks!

あと、これってRustでのC FFI に限った話じゃないよね？
C同士でさえもアロケータに何を使ってるか次第で同じ問題が発生する。
Cは時々使ってたのに(しかも仕事で)これを知らなかったのはヤバいな…
恐らく今まではたまたま同じアロケータを使ってたから問題が起きてなかっただけか…
戻り値で文字列(char *)が来た時とかこっちで勝手にfreeしてたぞ…(^_^;)
まあ、どのアロケータ使ってるかなんて誰も気にも留めてなかったし大丈夫だろうけど、
今後は気を付けないとな…

**デフォルトの名無しさん** · 2018/04/13(金) 01:26:39.63

すべての有用なライブラリがRust製にならない限り
Rustだけを学べばよいという状況は訪れずCやC++の習得も必須

**デフォルトの名無しさん** · 2018/04/13(金) 02:09:57.24

>>339
どういたしまして。

C同士の場合は普通glibcへの動的リンクだし
LD_PRELOADとかでjemallocなんかに差し替えても
プログラム全体で差し替わるから特に問題にはならないかと。
もしメモリアロケータを静的リンクしたライブラリとかを使っていればまずいはず。
ただそういう場合はリソースハンドルっぽいAPIになりがちなので
そのままfreeしようとは思わないかもしれない。

**デフォルトの名無しさん** · 2018/04/13(金) 02:17:49.88

>>340
そりゃそうだろ、なにいってんだ

**デフォルトの名無しさん** · 2018/04/13(金) 02:33:17.17

やくに立たねー結局cか。rustって趣味だな。

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

C/C++だけ覚える
or
RustとC/C++を覚える

学習コスト高すぎRust

**デフォルトの名無しさん** · 2018/04/13(金) 10:22:17.48

>>343
趣味でモジラの栄養やるとかどんなドマゾだよ

**デフォルトの名無しさん** · 2018/04/13(金) 10:26:05.50

今の会話見るだけでもRustがいかに欠陥言語かわかるのに
それでもRust使うって言うんだからなあ
全部C/C++で書く方が遥かに効率いいしバグも出んわ

**デフォルトの名無しさん** · 2018/04/13(金) 11:29:35.51

C覚えるの必須当たり前ってんなら構文もっとC系に寄せれば良かったのに。

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

今までの流れからその結論は極端すぎるだろ
もう少し工夫しろ

**デフォルトの名無しさん** · 2018/04/13(金) 12:27:54.41

いつのまにか、FFI使うことが前提になってる流れって、rustをdisりたい勢の必死さがうかがえて、ある意味、面白い。

**デフォルトの名無しさん** · 2018/04/13(金) 12:52:00.31

>>339
CのfreeはNULLなら何もしないと保証されてるけど
解放済みアドレスへのfreeはセグフォ発生するぞ

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

Cの資産に寄生しないとろくなもん作れないのに
そのCとの連携部分が腐ってるってことじゃん

使いもんにならねえって評価は妥当だと思うが？
それともPure Rustでまともなもん作れるつもりか？

**デフォルトの名無しさん** · 2018/04/13(金) 17:38:51.06

まずまともなもんを先に定義してくれ

**デフォルトの名無しさん** · 2018/04/13(金) 18:09:45.57

バグらない
動く
実用的
上記3点の実績がある

**デフォルトの名無しさん** · 2018/04/13(金) 18:37:13.42

実用的・実積も曖昧だな
どの程度を実用的で実積があると呼ぶのか具体例を提示してくれ

突き詰めていくと「バグらない」も程度によりけりだしな
Excelだってバグるときゃバグるし…

**デフォルトの名無しさん** · 2018/04/13(金) 18:48:56.96

本スレは相変わらず過疎だしまじ終わったなこの言語

**デフォルトの名無しさん** · 2018/04/13(金) 19:00:16.55

話に入れないからって「………結局駄目！」ってダサすぎない？

**デフォルトの名無しさん** · 2018/04/13(金) 19:21:19.79

jsのファミコンエミュレータをrustで実装し直したらパフォーマンス負けたらしいｗｗｗ

**デフォルトの名無しさん** · 2018/04/13(金) 19:27:43.59

>>357
JSに負けるとか草しか生えんなwwwwwww

**デフォルトの名無しさん** · 2018/04/13(金) 19:31:48.55

>>354
Linuxくらいバグらないならいいよ

**デフォルトの名無しさん** · 2018/04/13(金) 20:22:47.30

>>357
噂に尾ひれがつく瞬間を目の当たりにして草
多分これ↓のことだろ
http://blog.bokuweb.me/entry/2018/02/08/101522
誰かC x wasmで書き直してみろよ。きっと似たような結果になるから

>>359
ついにLinuxと同レベルじゃないと認めないとか言い始めたぞ…

**デフォルトの名無しさん** · 2018/04/13(金) 20:58:47.99

>>357,358
ブラウザ JS版 Wasm版
Chrome 63 4.36ms 5.68ms
Firefox 58 5.76ms 3.98ms
Safari 11 9.98ms 4.21ms

う～ん草しか生えんね草草草の草ァ！だね

**デフォルトの名無しさん** · 2018/04/13(金) 21:29:03.20

>>361
wasmじゃなくてRustと比べてから言えよ

**デフォルトの名無しさん** · 2018/04/13(金) 21:40:19.55

>>362
草しか生えんわｗｗｗ

**デフォルトの名無しさん** · 2018/04/13(金) 22:58:07.23

まあメモリの管理モデルが違う言語同士でやりとりすれば
色々苦労するのは当たり前なんだよね。
それなのに「rustは勝手に解放してくれる」とか言い張っちゃう信者が有害な訳だよ。
rustが悪いというよりか、こういう馬鹿が多いところが問題。

**デフォルトの名無しさん** · 2018/04/13(金) 23:04:17.07

Haskellは副作用が無いとか参照透過性があるって言った時に
C FFIを持ち出して反論するのと同様の不毛さを感じる

**デフォルトの名無しさん** · 2018/04/14(土) 07:00:49.94

不毛？現実によくあることなのにね。。
言語の一番下ではアセンブラが動いてるんだから、そことどう調和もしくは隠蔽させるかってのは
コンピュータ言語にとって本質でしょうが。

**デフォルトの名無しさん** · 2018/04/14(土) 07:18:52.94

は？何で一番下が機械語じゃなくてアセンブラなの馬鹿なの？

**デフォルトの名無しさん** · 2018/04/14(土) 09:16:33.44

コンピュータ言語ｗ

**デフォルトの名無しさん** · 2018/04/14(土) 11:34:49.77

アセンブラと機械語は1:1で訳せるから…

**デフォルトの名無しさん** · 2018/04/14(土) 11:47:39.37

アセンブリやろ

**デフォルトの名無しさん** · 2018/04/14(土) 13:58:04.39

結局Rustはサーバ向けでもコマンドツール向けでもGUI向けでも組み込み向けでもない

って事実はほんと覆らんよ

**デフォルトの名無しさん** · 2018/04/14(土) 14:12:11.55

話に入れないからって「………結局駄目！」ってダサすぎない？

**デフォルトの名無しさん** · 2018/04/14(土) 14:55:11.55

jsのファミコンエミュレータをrustで実装し直したらパフォーマンス負けたらしいｗｗｗ

**デフォルトの名無しさん** · 2018/04/14(土) 15:21:13.70

>>372
悔しかったら反論してみたらぁ？

**デフォルトの名無しさん** · 2018/04/14(土) 15:23:55.88

>>372
メモリ管理みたいな重要なことについてデララメ振りまいて、
「理解しない奴がrust批判してる」とか言い出してる方が恥ずいわ。

**デフォルトの名無しさん** · 2018/04/14(土) 15:34:36.03

上の流れ素直に読んでも、
メモリ管理も全部C側で完結させるのが一番いいって結論にしかならんぞ？

Rustのいいところなんぞ皆無だ

**デフォルトの名無しさん** · 2018/04/14(土) 15:44:33.95

というかコンパイラにメモリ管理任せるのが無理だろ。FFIのためにいちいちDrop定義するとか非効率でしかない

メモリ管理はGCに任せるか完全手動にするかの二択なのに、無理矢理そこにヘンテコリンなソリューションもどき持ち込んで混乱引き起こしてるだけじゃん

**デフォルトの名無しさん** · 2018/04/14(土) 15:50:41.81

Rustの提案するエセソリューションは機械語のレベルと相性が悪い
CやC++のほうがまだまともなアプローチしてる

**デフォルトの名無しさん** · 2018/04/14(土) 15:53:50.88

>>377
うおっ!
ここにきてまさかのRAIIを否定し始めるとか予想外すぎたわ!
お前C++のスマポってなにか知ってる？

**デフォルトの名無しさん** · 2018/04/14(土) 15:55:07.64

>>379
ほとんどのコンパイラで採用されてない仕様書上にしかない機能なんざ知らんよ

**デフォルトの名無しさん** · 2018/04/14(土) 15:58:27.76

実際混乱引き起こしてるまともじゃない方法なのは上の流れで自明だろ

**デフォルトの名無しさん** · 2018/04/14(土) 16:02:24.43

>>380
よろしい。そんな君にはJavaがおすすめだ。そっちで元気にやりたまえ。

**デフォルトの名無しさん** · 2018/04/14(土) 16:05:01.76

以前も言われてたけど「ひまわり学級の子が普通の授業に出て暴れてる」って表現が実に的確で草

**デフォルトの名無しさん** · 2018/04/14(土) 16:07:01.72

間違ったものを間違った奴が流行らせようとしてるんだからそれには「違う」って言っとかないとダメだろ
話にならんと放置したらいずれ手遅れになるほど蔓延する
そうならないうちに叩いておくべきなんだよ

**デフォルトの名無しさん** · 2018/04/14(土) 16:10:39.48

混乱引き起こしてるのは違いないけどさ
「俺の頭の中で混乱を引き起こしてる」って正確に書こうよ

**デフォルトの名無しさん** · 2018/04/14(土) 16:11:44.32

>>385
上のFFI絡みの流れは俺じゃないけど？

**デフォルトの名無しさん** · 2018/04/14(土) 16:15:30.43

完全手動でメモリ管理するのは混乱起きないからいいよね～