C++ vs Rust

1 名前：デフォルトの名無しさん mailto:sage [2021/04/24(土) 08:04:49.48 ID:nPKzA798.net] 競え 267 名前：デフォルトの名無しさん mailto:sage [2021/11/22(月) 21:26:20.75 ID:7gi7NmEv.net] >>257 独自のLinkedListで、実装としては配列を持っていて、 ノード間が参照でリンクされておらず、添え字番号でリンクしており、 get(), set()が添え字番号を返して配列要素を返しているので ゼロコストではないね。 struct LinkedList<T> { 　first_idx_a: Option<usize>, 　first_idx_b: Option<usize>, 　elems: Vec<Elem<T>>, } struct Cursor { 　a_idx: usize, } fn get(&self, elem: Cursor) -> &T { 　&self.elems[elem.a_idx].data } fn set(&mut self, elem: Cursor, data: T) { 　self.elems[elem.a_idx].data = data; } 268 名前：デフォルトの名無しさん mailto:sage [2021/11/22(月) 21:27:13.68 ID:7gi7NmEv.net] >>261 ゼロコストが謳いなのに、ゼロコストで無い。 269 名前：デフォルトの名無しさん mailto:sage [2021/11/22(月) 21:27:14.40 ID:5egSOJea.net] >>257 それで実装も動作も良いけど _bはどちらも不要 _a.0と_a.1はそれぞれprevとnextと書いたほうが読みやすい 270 名前：デフォルトの名無しさん mailto:sage [2021/11/22(月) 21:33:11.94 ID:fRCpO7Rh.net] >>264 _b は単一の要素が複数のリストに属するという要件に対する実装ですね 面倒だったのでメンバーだけ用意して実装はしてないですが タプル使ってるのも構造体定義が面倒だったため というかできるできないを実証するための例なので細かいところは適当です お好きなように修正してください >>263 >>245 の > C/C++/Java/C#/JS/Ruby/Python など多くの言語では可能だが、Rust だけが不可能 > なので、Rustだけが仲間はずれであり、他の言語でできる事ができない。 というのはほかの言語ではゼロコストで実装できることを意味していますか？ それともRustでも実装できることを認めた上でのただの負け惜しみですか？ はたまたこれを書いたのは自分とは別の人と主張されるのでしょうか 271 名前：デフォルトの名無しさん mailto:sage [2021/11/22(月) 21:34:40.04 ID:fRCpO7Rh.net] >>262 ゼロコストを定義してください 272 名前：デフォルトの名無しさん mailto:sage [2021/11/22(月) 21:37:06.49 ID:7gi7NmEv.net] >>265 後半のあなたの主張、おかしくないか。 Rustの参照では無い独自の参照風の様な構造を添え字番号で実装してしまって、 C言語より速度を落としているのだから、ゼロコスト性に反してる。 273 名前：デフォルトの名無しさん mailto:sage [2021/11/22(月) 21:38:01.88 ID:7gi7NmEv.net] >>266 参照に関しては、参照がC言語の生ポインタと同じ速度で扱えること。 274 名前：デフォルトの名無しさん mailto:sage [2021/11/22(月) 21:38:56.97 ID:fRCpO7Rh.net] >>267 あらゆる言語の中でRustだけが実装できないという主張は撤回されて CにRustは劣るという主張へと変更されるのですね？ 275 名前：デフォルトの名無しさん mailto:sage [2021/11/22(月) 21:49:14.11 ID:EEj8G+es.net] >>257 elements_aはinto_iterにしたらあかんの？と思ったけど 2つ持った時の前半用として用意した意味なのかw 276 名前：デフォルトの名無しさん mailto:sage [2021/11/22(月) 21:56:48.89 ID:7gi7NmEv.net] >>269 1. データを格納している場所が配列になっているが、動的に長さを長くしようとすれば 　動的配列と同様のコピー動作が生じてしまうから、その実装は、本来のLinkedListの 　性質とはかなり異なる。リンクリストは速度的に安定である事が重要なのに、 　この性質により、動的配列と同様に、時々大規模コピーが生じて、スパイク的に 　速度が遅くなる減少を伴うことになってしまう。このようなスパイク的な 　速度低下は、twitterかFacebook のどちらか忘れたが、どっかのSNSでも問題 　になっていた。 2. アクセスするときに、番号を配列のアドレスに変換する動作を毎回行っている。 277 名前：デフォルトの名無しさん mailto:sage [2021/11/22(月) 22:00:19.83 ID:7gi7NmEv.net] >>271 [補足] 誤解を招いて議論に混乱を来たしそうなので捕捉しておくと、 271の2で書いた「番号」は、リンクリストの先頭からの通し番号の事ではなく、 今回示されたリンクリスト風のコードで、内部で用いられている配列の添え字番号 のことで、リンクリストの先頭からは、辿っていっても、連続した番号には成ってないもの。 278 名前：デフォルトの名無しさん mailto:sage [2021/11/22(月) 22:05:48.24 ID:fRCpO7Rh.net] >>271 あらゆる言語で実装できないがRustでは実装できない 他の言語だと O(1) だが Rustだと O(N) になる という主張を撤回されたと理解しました そういうことでしたら私の方から言うことはなにもありません またアロケーションについてはVecを実装が工夫されたコンテナ型に変えることで対応できそうですね 実装詳細のないまま議論してもしょうがないトピックなのでこれ以上こちらからレスを重ねることはやめます ありがとうございました 279 名前：デフォルトの名無しさん mailto:sage [2021/11/22(月) 22:10:00.62 ID:7gi7NmEv.net] >>271 [追加] 3. そこにさらに削除メソッドを実装したとしよう。 　削除したノードに対する番号が、どこかのCursorの中にまだ生きた状態に 　なっている場合、ダングリング参照と似た現象が起きる。 　削除したノードの中を参照できてしまうのだ。 280 名前：デフォルトの名無しさん mailto:sage [2021/11/22(月) 22:15:27.68 ID:7gi7NmEv.net] >>273 その主張、Rustの中に超軽量のインタプリタの様なものを載せておいて、 そのインタプリタの中ではランダムアクセスがO(1)のリンクリストが 完全に実装できることを示しただけだね。 しかも、追加すると、時々、大規模なメモリーコピーが生じるし。 newやmallocではそのようなメモリーコピーは生じない。 ノードを追加しても、リンクリスト中の他のノードの本当のマシン語レベルでの 線形アドレスが固定で変化し無いし。 あなたの実装では、それが変化してしまう。相対アドレスは変化しないが。 ベースアドレスが変化している。 281 名前：デフォルトの名無しさん mailto:sage [2021/11/22(月) 22:19:00.36 ID:fRCpO7Rh.net] >>274 generational arenaという手法を利用することでダングリングポインタ的アクセスを検知してハンドリング可能になります 282 名前：デフォルトの名無しさん mailto:sage [2021/11/22(月) 22:19:03.44 ID:7gi7NmEv.net] >>274 [補足] 実質的なダングリング参照が起きるということは、Rustのもう一つの柱である ところのメモリー安全性が部分的に壊れてしまってるということだ。 283 名前：デフォルトの名無しさん mailto:sage [2021/11/22(月) 22:23:12.75 ID:7gi7NmEv.net] >>276 動的コストを掛けていいなら、C++でも安全性の高いものは作れるぞ。 ポインタも正しいメモリーブロックを指していることを動的に確認した後で 実際に参照するようなことは、C++でも出来るから。 Rustも配列の範囲チェックはやっているが、配列以外のアドレスでも、動的に チェックしようと思えばいろいろなチェック法はある。 その一つの方法が、アドレスではなく、あなたが書いたような配列の中の 番号方式にしてしまうこと。 番号に対する配列要素がNULLになっていれば、動的にエラーを出力して アプリを停止させる、などの方法が有る。 284 名前：デフォルトの名無しさん mailto:sage [2021/11/22(月) 22:25:32.33 ID:fRCpO7Rh.net] >>278 Rustの zero-cost abstraction はあなたの期待するような物ではありませんでした 残念でしたね 285 名前：デフォルトの名無しさん mailto:sage [2021/11/22(月) 22:36:23.68 ID:7gi7NmEv.net] >>265 >> 286 名前：C/C++/Java/C#/JS/Ruby/Python など多くの言語では可能だが、Rust だけが不可能 >> なので、Rustだけが仲間はずれであり、他の言語でできる事ができない。 >というのはほかの言語ではゼロコストで実装できることを意味していますか？ >それともRustでも実装できることを認めた上でのただの負け惜しみですか？ 分かった。ゼロコストで無くて良いなら Rustでも実装できるということだね。 なるほど、今回の実装法のような裏技の発想は無かったよ。それは認める。 でも、ゼロコストでなくなるということは、RustがC/C++の代替になるという 説には反することになるね。 それと、C++, Java, C# では最初から標準ライブラリ的なもので最初から実装済み なのに対して、あなたのやり方は、少なくとも標準のLinkedListではないね。 Cursorも標準のものとは別。 [] [ここ壊れてます] 287 名前：デフォルトの名無しさん mailto:sage [2021/11/22(月) 22:37:35.24 ID:0LbM6y2O.net] 結局何がしたいのよ ノードへの参照を持ったままリストを変更したいの？ 288 名前：デフォルトの名無しさん mailto:sage [2021/11/22(月) 22:44:50.09 ID:7gi7NmEv.net] >>281 何がしたいって、C/C++/C#/Javaでは、LinkedListへのアクセスがO(1)で 自由自在に出来るのに、標準のRust実装では出来ないことが問題なんだ。 それに、今回示された実装法では、内部では配列で実装されているから、 ノードを追加してい言って、配列の要素数を超える時には、新しい配列を コピーして内部でコピー動作が生じる。これは、C++のnewよりも遥かに 遅い動作になってしまうし、スパイク的に時々生じるから速度的な安定性 が求められるソフトでは好ましくない現象。 また、実質的なダングリング参照的が生じることも指摘した。 結論は、このやり方で、C/C++などと同じO(1)にはなったものの、安全性も失われ、 ゼロコスト性も失われ、C/C++の実装に比べて速度的に不安定でありスパイク的に 遅くなるということだ。 289 名前：デフォルトの名無しさん mailto:sage [2021/11/22(月) 22:51:04.06 ID:0LbM6y2O.net] >>282 「LinkedListへのアクセスがO(1)で自由自在に出来る」 が正確にはどういう意味かと聞いているんだ >>257の実装は忘れなさい 290 名前：デフォルトの名無しさん mailto:sage [2021/11/22(月) 22:52:27.47 ID:7gi7NmEv.net] >>281 >ノードへの参照を持ったままリストを変更したいの？ もちろん、それもある。 291 名前：デフォルトの名無しさん mailto:sage [2021/11/22(月) 22:56:03.63 ID:qBbb57Hy.net] デマを流すのはゼロコストなんだから相手にした時点で負け 292 名前：デフォルトの名無しさん [2021/11/22(月) 22:57:09.11 ID:7gi7NmEv.net] >>283 >「LinkedListへのアクセスがO(1)で自由自在に出来る」 >が正確にはどういう意味かと聞いているんだ Cの場合、ポインタでアクセスすれば、O(1)でリンクリストの ノードを参照できるし、削除も出来る。 削除しても、他のノードのアドレスは変化しないから、ポインタも 書き換える必要も無い。 配列だったら、削除するとそれより後ろのノードの番号が全て 変化してしまうので、書き直さなくてはならない。 リンクリストでも、先頭からの通し番号を識別番号に している場合には、同様にそれ以後のノードの全ての番号を書き換えないといけない。 リンクリストのノードにO(1)でアクセスするというのは、ポインタでアクセスすれば 当たり前の事で、どう説明していいのか分からない。マシン語では、間接参照の [アドレス] だけの話だから。 コンピュータの基礎から学び直してもらわないと理解してもらえないかも知れない。 マシン語を学んで欲しい。 293 名前：デフォルトの名無しさん mailto:sage [2021/11/22(月) 22:57:21.67 ID:0LbM6y2O.net] コンテナと各要素の&mutと&が同時に取れない件はsplitして借用の単位を分けるべし Vec::split_at_mutと同様の発想 294 名前：デフォルトの名無しさん mailto:sage [2021/11/22(月) 22:59:22.03 ID:0LbM6y2O.net] >>286 だからそれだけならCursorMutでできるんだって でもダメなんだろ？ それはなぜ？ 295 名前：デフォルトの名無しさん mailto:sage [2021/11/22(月) 23:01:06.85 ID:7gi7NmEv.net] >>285 どっちがデマだと思ってるのか知らんが、俺のはデマじゃないぞ。 実際に、今回の実装を示した彼は、俺の言ってることはある程度正しく理解していた。 つまり、基本的にデマじゃないということを理解した人がいるということだ。 ただし、彼は、ゼロコスト安全性である、ということを無視して独自実装したり、 参照を独自に修正したものを勝手に導入した誤魔化しがあったのが残念であった だけだ。 つまり、俺の主張自体は、彼は本当は理解している。 理解しているが、悔し紛れに詐欺めいた独自実装をしたことだけが残念なだけだ。 296 名前：デフォルトの名無しさん mailto:sage [2021/11/22(月) 23:01:57.98 ID:7gi7NmEv.net] >>288 1つのリンクリストに対して、書き込み参照や読み込み参照を同時に複数持てない。 297 名前：デフォルトの名無しさん mailto:sage [2021/11/22(月) 23:13:17.79 ID:5egSOJea.net] >>290 デマを流すのはそろそろやめとけよ RustはRefCellもあるし複数からポインタで指しつつ書き換えもできるぞ 298 名前：デフォルトの名無しさん mailto:sage [2021/11/22(月) 23:14:41.21 ID:7gi7NmEv.net] >>291 そもそも、RefCellは、動的チェックが入るからゼロコストではない。 C には存在しないコストが新たに導入される。 299 名前：デフォルトの名無しさん mailto:sage [2021/11/22(月) 23:15:37.93 ID:WXoW4mOX.net] unsafe で生ポインタ使えばCと同じ実装は確実にできるが 300 名前：デフォルトの名無しさん [2021/11/22(月) 23:15:41.59 ID:NDd1353W.net] リンクトリストな？ 301 名前：デフォルトの名無しさん mailto:sage [2021/11/22(月) 23:16:05.08 ID:5egSOJea.net] >>292 何を言ってるんだ？ そういうコストかけずにどうやって排他制御するんだよ？ 302 名前：デフォルトの名無しさん mailto:sage [2021/11/22(月) 23:18:27.46 ID:WXoW4mOX.net] >>295 そこはCだとプログラマが気をつけることで排他制御してるんだと思うよ unsafe Rustでも同じだけど 303 名前：デフォルトの名無しさん mailto:sage [2021/11/22(月) 23:18:40.37 ID:7gi7NmEv.net] >>295 C++と同じ事が出来るのに「ゼロコスト」で「安全」、と謳ってるのが間違いだと 言ってる。 間違いというより、デマや誇大宣伝。 304 名前：デフォルトの名無しさん mailto:sage [2021/11/22(月) 23:21:22.25 ID:0LbM6y2O.net] >>290 そうだ、最初からそう言えばよかったんだ 蓋を開けてみればO(1)なんかまるで関係無いじゃないか でそれに対して>>287という策があるわけだがどう思う？ 305 名前：デフォルトの名無しさん mailto:sage [2021/11/22(月) 23:22:12.49 ID:7gi7NmEv.net] >>295 「排他制御」とは、マルチスレッドプログラミングで使う用語なのだが、 本当にその意味で使ってるか？ 306 名前：デフォルトの名無しさん mailto:sage [2021/11/22(月) 23:22:18.49 ID:EEj8G+es.net] >>292 ゼロコストって他のことでもそうだけど全くコストがかからないってことではない 必要最低限のことのみでそれ以外はゼロコストってこと 今回のRefCellならば並行プログラミングの時の書き換え競合が起きないことを保証する RefCellはゼロコスト ゼロコストでないと主張するならば他の対処方法を述べよ 307 名前：デフォルトの名無しさん mailto:sage [2021/11/22(月) 23:24:19.66 ID:7gi7NmEv.net] >>298 「策」があるっていうが、どんどん複雑化し、コストも増えているだろ。 308 名前：デフォルトの名無しさん mailto:sage [2021/11/22(月) 23:28:31.00 ID:7gi7NmEv.net] >>300 俺も正直言うとRefCellとか出てくると複雑すぎてよくわからなくなってくるが、 RefCellは内部可変性に対するものだから、並行プログラミングを使わない時 にも使うことがあるはずだが。 309 名前：デフォルトの名無しさん [2021/11/22(月) 23:28:31.66 ID:NDd1353W.net] Rustは安全性を追求した言語でC++と比較する物ではない。 比較するならRubyが妥当。 310 名前：デフォルトの名無しさん mailto:sage [2021/11/22(月) 23:30:51.55 ID:7gi7NmEv.net] >>303 つまり、CやC++の代替には成りえない。 アプリレベルであってもC/C++の全てをカバーすることは出来ない。 311 名前：デフォルトの名無しさん mailto:sage [2021/11/22(月) 23:33:19.88 ID:WXoW4mOX.net] コンパイラに安全性を保証してほしければ実行時のコストを払ってRefCellを使えばいいし、 そのコストを払いたくなければunsafe 使って自分で安全性を保証すればいいって話なんだが 312 名前：デフォルトの名無しさん mailto:sage [2021/11/22(月) 23:35:15.39 ID:4Q+A1yLL.net] 必要最低限のunsafeを使うのは大前提で、 それでもリンクリストがどうたらって話じゃなかったっけ・・・？？ 313 名前：デフォルトの名無しさん [2021/11/22(月) 23:36:31.09 ID:NDd1353W.net] だからリンクトリストな？ 314 名前：デフォルトの名無しさん mailto:sage [2021/11/22(月) 23:38:22.71 ID:5egSOJea.net] >>299 シングルスレッドマルチタスクでも競合は起き得る そのため書き込み権限がある者がある瞬間に複数存在しないことを保証する(排他制御)ためにRefCellがある マルチスレッドの場合は並列に起き得るからもっと厳しくてRefCellではダメでMutexやRwLockを使う 315 名前：デフォルトの名無しさん [2021/11/22(月) 23:39:08.56 ID:NDd1353W.net] Rustは安全性を追求した言語でC++と比較する物ではない。 比較するならVBAが妥当。 316 名前：デフォルトの名無しさん [2021/11/22(月) 23:40:06.95 ID:NDd1353W.net] RustがC++をライバル視してきて非常にウットオシイ。 貴様のライバルはJavascriptだろ。 317 名前：デフォルトの名無しさん mailto:sage [2021/11/22(月) 23:41:22.24 ID:7gi7NmEv.net] >>291 LinkedListの中のノードへの参照を10個持っている状態で、 その参照を使って1個のノードを削除しようとしてコンパイルは通るか？ 318 名前：デフォルトの名無しさん mailto:sage [2021/11/22(月) 23:42:38.96 ID:0LbM6y2O.net] >>301 safeであるためには必要なコストだと思うけどね mutabilityが前後のノードに影響するデータ構造だから仕方がない 319 名前：デフォルトの名無しさん mailto:sage [2021/11/22(月) 23:44:32.43 ID:5egSOJea.net] >>311 それCでもC++でもダングリングポインタ発生の駄目プログラマーパターン 320 名前：デフォルトの名無しさん mailto:sage [2021/11/22(月) 23:49:43.35 ID:7gi7NmEv.net] >>313 そんなことないぞ。 vectorと勘違いして無いか。 321 名前：デフォルトの名無しさん mailto:sage [2021/11/22(月) 23:55:11.62 ID:4Q+A1yLL.net] >>311 参照先自体を削除するんじゃなくて、参照先からさらにnextとかprevたどってどっかのノードを削除するってこと？ 参照先自体を削除するのはRustに限らず問題でるよね 322 名前：デフォルトの名無しさん mailto:sage [2021/11/22(月) 23:58:04.28 ID:7gi7NmEv.net] >>315 参照先を削除するのは普通なことで、安全に行えるぞ。 参照とは、つまり、識別番号の代わりに使うものだからな。 参照はオブジェクトに付けられた名前みたいなもんだから、 逆に言えば、参照先を削除できないなら、削除する方法がほぼ無い。 323 名前：デフォルトの名無しさん mailto:sage [2021/11/23(火) 00:00:50.13 ID:1c3aeddQ.net] 何の話についてもまずは具体的なC言語のコードを示すべきじゃないかな そうすればRustのコードを2種類みんなが出してくれるよ 　・1つは元のC言語と同じ安全度で場合によってはunsafeを用いて実装 　・もう1つはメモリ安全性を保証してunsafeを使わずに実装 つまり「C言語で出来ることはRustで必ず出来る」＋「Rustではメモリ安全性を保証した実装も可能」 明らかにC言語よりもRustの方が能力も高く優れている 324 名前：デフォルトの名無しさん mailto:sage [2021/11/23(火) 00:00:51.12 ID:16zHq7La.net] >>314 残り9個の参照はそのノードが削除されたことを知る術がないからダングリングポインタになるってことだろ 325 名前：デフォルトの名無しさん mailto:sage [2021/11/23(火) 00:08:02.67 ID:xJBrssBV.net] >>318 本来は、明らかに別のノードであれば問題ない。 C++では普通に安全にそれが行える。 リンクリストの中に、A, B, C という名前の人のデータが入っていて、 それぞれに対して1つずつそれぞれ、ポインタ pA, pB, pC が存在している時に ポインタ pA を介してAを削除しても、B, C へのポインタ pB, pC は残っていて、 値も変更されることも絶対に無いから完全に安全。 Aさんのデータを削除する場合にはこのようなことが起きるが、その時には、 delete pA の後、pAを捨ててしまうだけで全く安全。 pB, pC は何事も無くまったく安全に残せるし、何のバグも入らない。 こんな単純なロジック、何の問題も無い。 326 名前：デフォルトの名無しさん mailto:sage [2021/11/23(火) 00:15:34.94 ID:8Ju98kPx.net] 同一のノードに10個の参照って意味ちゃうん？ 327 名前：デフォルトの名無しさん mailto:sage [2021/11/23(火) 00:16:47.17 ID:1c3aeddQ.net] >>319 それだと>>311の条件を満たしていないのでやり直し 　・いずれにせよC/C++で書けるコードはそのままの形でそのままの安全度で必ずRustでもunsafeを用いて書ける 　・更にRustでは安全性を保証する形でunsafeを用いずに実装することもできる C/C++よりもRustのほうが明白に能力が高い 328 名前：デフォルトの名無しさん mailto:sage [2021/11/23(火) 00:20:07.35 ID:xJBrssBV.net] >>320 1つのリンクリストの異なる10個のノードに対する10個の参照。 329 名前：デフォルトの名無しさん mailto:sage [2021/11/23(火) 00:21:41.44 ID:/rTkTwIT.net] >>319 C++でノードへのポインタは実装依存な方法でしか取れないよ pAその他は本当にポインタ？イテレータではなく？ 330 名前：デフォルトの名無しさん mailto:sage [2021/11/23(火) 00:21:54.64 ID:xJBrssBV.net] >>321 何度もしているが、それはフェイク。 Cできることのうち、Rustでは追加コストを掛けずにはsafeモードで出来ないことはたくさん有る。 unsafeモードを使いまくれば別。 しかしそれではRustを使う意味が無い。 331 名前：デフォルトの名無しさん mailto:sage [2021/11/23(火) 00:22:40.62 ID:xJBrssBV.net] >>323 C++ではなく、Cのリンクリストで考えよう。C++は別の複雑さを入れ込んだから。 332 名前：デフォルトの名無しさん mailto:sage [2021/11/23(火) 00:22:46.42 ID:s6k3uLQ1.net] >>324 なぜRustを使う意味がないのですか 333 名前：デフォルトの名無しさん mailto:sage [2021/11/23(火) 00:25:21.42 ID:xJBrssBV.net] >>326 Rustの売りはゼロコスト+安全性にあるからだよ。 どちらが掛けても意味が無い。 ゼロコストで無いなら既にC#やJavaがある。 安全で無いなら既にC++がある。 334 名前：デフォルトの名無しさん mailto:sage [2021/11/23(火) 00:26:18.34 ID:6/+wazXE.net] ああ、なるほど 安全性を考慮していないCのLinked Listと、安全性が保証されたRustのLinked Listを比較して、 Rustは遅い、できることが少なくて不便だ、みたいなことを述べてたわけか Cでもメモリリークしないようにして、スレッドセーフにするとかしたら、途端に大変になりそう 335 名前：デフォルトの名無しさん mailto:sage [2021/11/23(火) 00:26:36.02 ID:s6k3uLQ1.net] >>327 違いますよ 336 名前：デフォルトの名無しさん mailto:sage [2021/11/23(火) 00:27:06.93 ID:8Ju98kPx.net] >>324 リンクトリスト内のメソッドでunsafeを閉じ込めることできると思うんだけどそれではだめなのか 337 名前：デフォルトの名無しさん mailto:sage [2021/11/23(火) 00:28:01.20 ID:8Ju98kPx.net] なんなら>>330は「基本的な操作のメソッドは」ってしてもいいけど 338 名前：デフォルトの名無しさん mailto:sage [2021/11/23(火) 00:31:19.33 ID:xJBrssBV.net] >>330 複数のノードへの読み書き自由なアクセスの速度をO(1)を保ったままで、 RustではunsafeをLinkedListのメソッド内には閉じ込めることが基本的に 出来ない。基本的に、と言ったのは、先ほど彼が示したリンク先の独自 実装の様に、ゼロコストであることを諦めてコストを掛ければできる ようになるから。ただし、その場合、スパイク的にO(N)の時間でコピー 動作が発生してしまう。 339 名前：デフォルトの名無しさん mailto:sage [2021/11/23(火) 00:32:59.52 ID:xJBrssBV.net] >>332 [補足] スパイク的なコピーの発生だけでなく、普段からコスト増加もある。 ベースアドレス + 相対アドレスでアクセスするから。 340 名前：デフォルトの名無しさん mailto:sage [2021/11/23(火) 00:38:03.01 ID:1c3aeddQ.net] >>262 その人が作ったLinkedList実装がポインタではなく格納配列のインデックスを使っているだけだよ Rustの標準ライブラリのLinkedList実装ではポインタを使っています std::collections::LinkedList https://doc.rust-lang.org/std/collections/struct.LinkedList.html 341 名前：デフォルトの名無しさん mailto:sage [2021/11/23(火) 00:39:30.31 ID:xJBrssBV.net] >>334 それは分かってる。 で、標準の方は、ノードのアクセス速度に問題がある。 342 名前：デフォルトの名無しさん mailto:sage [2021/11/23(火) 00:43:10.08 ID:qrGqDm2c.net] >>335 RustはLinkedListでも問題を感じたことがないですが何を根拠に？ 343 名前：デフォルトの名無しさん mailto:sage [2021/11/23(火) 00:49:14.22 ID:xJBrssBV.net] >>336 1つのリンクリストの異なる10個のノードに対する10個のmut参照を同時 に持ち事は出来ないので、O(1)でアクセスできないからだ。 344 名前：デフォルトの名無しさん mailto:sage [2021/11/23(火) 01:04:38.76 ID:qrGqDm2c.net] >>337 意味がわからないので具体的に意味のあるCコードを書いて 345 名前：デフォルトの名無しさん mailto:sage [2021/11/23(火) 01:08:49.01 ID:8Ju98kPx.net] Rustだと確かに複数個所のノードへの可変参照を得るのはunsafeメソッドになるだろうね そのノードが全部別々であることが保証できないから でもそれは他の言語でも同じで、例えば1のノードに複数の可変参照があって、 1の参照がノード消したらまずことになる そしてunsafeを許すのなら、内部実装でUnsafe Cell使えばコンパイラからの見た目は不変参照になるから、 オーバーヘッドなしでそういうのは実装可能（ただしstdのLinkedListはそのようにはなっていない） んで、複数個所のノードへの可変参照を得るというのは相当レアな操作なはずなので、 それはunsafeにしてもAPIの使い勝手としては全然問題はない 346 名前：デフォルトの名無しさん mailto:sage [2021/11/23(火) 01:37:22.61 ID:1c3aeddQ.net] あるC/C++コードがあった時 (A) 常にRustではC/C++コードと同じ安全度で(必要時はunsafeを用いて)実装できる (B) ほとんどのケースでRustでは安全なコードを(unsafeを用いずに)実装できる つまりRustの能力はC/C++を上回っている 言い換えると C/C++を捨ててRustを使えば (B) ほとんどのケースで安全性を保証する形で実装できる (A) 残りのレアケースでもC/C++と同じ安全度で実装できる したがってC/C++を用いずにRustを用いたほうがよい 347 名前：デフォルトの名無しさん mailto:sage [2021/11/23(火) 05:32:01.67 ID:RKGfozTd.net] 安全性よりも、 とにかくパフォーマンスや使用リソースが最重要な用途がある そういう所でC/C++が使われる C/C++は少なくとも今後20年は使われ続ける 348 名前：デフォルトの名無しさん mailto:sage [2021/11/23(火) 05:47:19.80 ID:qrGqDm2c.net] >>341 RustはC/C++と同じパフォーマンスを出せます >>340を読みましょ C/C++からRustへ移ったほうが誰の目にも得です 349 名前：デフォルトの名無しさん mailto:sage [2021/11/23(火) 07:27:06.42 ID:RKGfozTd.net] 本当に良いことばかりなら ここで宣伝しなくても自然に広まるはず 350 名前：デフォルトの名無しさん [2021/11/23(火) 13:48:55.03 ID:VKZug2mU.net] いや、あわしろ氏もC++は窓から投げ捨てろと言ってる。 351 名前：ハノン mailto:sage [2021/11/23(火) 14:00:24.39 ID:A++o7U7T.net] >>344 その、あわしろ氏とやらは、では、なにを推薦しているのでしょうか？ 352 名前：デフォルトの名無しさん mailto:sage [2021/11/23(火) 14:20:23.73 ID:BTZW3nye.net] ほんとRust気持ち悪いなｗ リンクリストのような単純な構造でSTLでもboostでもそれ自体が「安全でない」ことはめったにない。 バグや脆弱性を作りこんでしまうのは多くは固定長のバッファに対するパース処理などで、確かに各種の *nixコマンドなんかはRustで書いて貰ったほうが良い場合があるが、C/C++の数msが致命となる世界で Rustが一般的となることはない。そんな布教をやってるから嫌われるんだよｗ 悔しかったらOpenSSLとか書き直して”安全なコード”で出してみろよ？WebkitにC/C++を排除させて Rustだけにさせてみろｗ 353 名前：デフォルトの名無しさん [2021/11/23(火) 14:29:53.22 ID:VKZug2mU.net] いまさらC++やってるようでは時代についていけない老害という評価しかない。 354 名前：デフォルトの名無しさん mailto:sage [2021/11/23(火) 14:45:56.12 ID:CrSl9z1L.net] Linusも老害だしChromeコミッターも全部老害、気持ち悪さNo1のRustたちが敵を作りまくる自己評価で あらゆるスレで暴れてる 355 名前：ハノン mailto:sage [2021/11/23(火) 14:49:30.08 ID:A++o7U7T.net] >>348 linus を老害呼ばわりするとは… 356 名前：デフォルトの名無しさん mailto:sage [2021/11/23(火) 14:56:32.81 ID:s6k3uLQ1.net] >>346 usじゃなくてmsなのか... 357 名前：デフォルトの名無しさん mailto:sage [2021/11/23(火) 14:57:43.30 ID:2khltGI7.net] twitterでも、RustはHaskell程度にしか発言されて無い。 一方、C 言語 で検索すると一日分でも見ることが不可能なくらい大量に 発言されてることが分かる。 twitterでは「C++」というキーワードでは検索できないので推定するしかないが、 C 言語以上であろう。 358 名前：デフォルトの名無しさん mailto:sage [2021/11/23(火) 15:54:02.42 ID:hMtNqdGd.net] >>340 >つまりRustの能力はC/C++を上回っている ダウト。 安全面に置いては上回っているが、効率面では下がるケースがかなりある。 359 名前：デフォルトの名無しさん [2021/11/23(火) 16:13:02.54 ID:hMtNqdGd.net] ・速度を落として安全性を高めたものは、既にJavaやC#がある。 ・Rustが仮に速度面ではCに比べて余り遅くならないケースが多いと 　仮定しても(この仮定には嘘があるのだが)、使いこなすのがJavaやC# 　に比べると難しい。 特に参照関連だけでも、Option, Box, Rc, Arc, Cell, RefCell, Cursor, ref, & の理解が必要な他、mut &'a などの表記、 let mut a : mut &:T = mut& b や Option<Rc<RefCell<T>>> a; new Box<T>( T {・・・} ); のような解読が難しいシンタックスも多い。 このような複雑な表記は、JavaやC#には存在しない。 また、& と * の違いもあれば、& と ref の違いも有る。 let文ですらパターンマッチング方式になっているので Cのポインタの 10倍理解が難しい。 つまり、普通IQ者には理解が難しい。 逆に高IQ者は、C++でも安全に使えるし、C++を安全面では余り問題を感じて無い人が多い。 360 名前：デフォルトの名無しさん mailto:sage [2021/11/23(火) 16:19:09.75 ID:hMtNqdGd.net] >>353 さらに言えば、 ・「自動参照外し」は便利だとされるが、逆に勝手に参照が外れることで、 　他人の書いたコードの理解が難しいことがある。明記してるコードと 　省略してるコードが同じことを意味してるのが理解しにくいので。 ・&の意味が、let文の左辺ではパターンマッチング、右辺では参照、 　の意味になっているので混乱しやすい。左辺では参照をはずす意味 　になってしまう。 ・＆は、reference(参照)演算子と呼ばれるのに、ref という演算子もあるが、 　これは、意味がかなり違うため、混乱し易い。 ・nullポインタを代入するポインタは、Option<Box<T>> のように長くなる。 ・ライフタイム注釈が発展途上中なのか、特に構造体に関するライフタイム注釈 　のドキュメントが少なく、例で説明されるだけで、根本的な意味を書いた 　ドキュメントが存在して無い。 361 名前：ハノン mailto:sage [2021/11/23(火) 16:26:18.07 ID:A++o7U7T.net] >>353 IQの定義は？ 362 名前：デフォルトの名無しさん [2021/11/23(火) 18:18:27.96 ID:VKZug2mU.net] LinuxはRustを第二言語と位置づけ、カーネル開発に積極利用する計画です。 363 名前：デフォルトの名無しさん mailto:sage [2021/11/23(火) 18:21:55.09 ID:1c3aeddQ.net] C/C++/Rustをやってきた人ならRustが圧倒的にプログラミングしやすいことで一致している 調査結果でもRustが連続1位を続けていることからも客観的に明白 364 名前：デフォルトの名無しさん [2021/11/23(火) 18:23:28.79 ID:VKZug2mU.net] あわしろ氏もC++は終了する言語と言っています。 365 名前：デフォルトの名無しさん mailto:sage [2021/11/23(火) 19:08:31.54 ID:s6k3uLQ1.net] >>353 例示してるシンタックス全部間違ってるし釣りだろこれ 366 名前：デフォルトの名無しさん mailto:sage [2021/11/23(火) 19:22:32.43 ID:4h9SSBVx.net] >Rustが圧倒的にプログラミングしやすい うんこ嘘つき野郎 367 名前：デフォルトの名無しさん mailto:sage [2021/11/23(火) 19:25:27.46 ID:1ymEsXZx.net] >>359 let mut a : mut &T = mut& b Box<T>::new( T {・・・} ); だったかも知れんな。 複雑すぎるし、C++との違いが大きすぎて覚えてない。 C++ だと、new クラス名で、Rubyだと確か、クラス名.new。 Rustは、後者に近い書き方だから、書き方だけを見てもRustはC++とはやはり遠い。

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef