C++ vs Rust

**デフォルトの名無しさん** · 2021/04/24(土) 08:04:49.48

競え

**デフォルトの名無しさん** · 2021/11/28(日) 21:43:21.57

>>491
お前はアホか。
リンクリストの場合は、乗算が入らないんだよ。

>>493
ミス訂正:
配列の場合は、
mov ebx,index　;添え字番号
imul ebx,配列のバイト数
mov eax,[ebp+ebx+32]　　　;32はスタックの中での位置

従って、リンクリストの方が一般的にはアクセスが速い。
リンクリストは、1クロック位、配列の場合は、要素が一般のバイト数の場合は、
14～36クロック位。

**デフォルトの名無しさん** · 2021/11/28(日) 21:47:47.53

>>494
>Rust で insert, remove 操作を O(1) で実装可能かどうかが論点ですよね？
そうじゃない。
Rustでも、insert, remove 自体は、標準実装でも O(1)で行える。
ところが、アクセスが、標準実装では、借用規則のために複数の
読み書きポインタを永続的に保持することが出来ないので、ノードの位置を
先頭からの通し番号で覚えておいて、アクセスするたびに毎回先頭から
辿る必要があるため、O(N)かかる。

特殊な独自実装をすると、アクセスがオーダー的にはO(1)で出来るが、
特殊実装な故に、>>493 の後半のようになってしまい、
20～50クロック位かかる。

**ハノン** ◆QZaw55cn4c · 2021/11/28(日) 21:49:24.66

>>494
読みました
私の場合は双方向リストを循環させ、始点のみをポイントすることとしましたが、結果として記述はあまり簡単にはならなかったですね、うーむ

**デフォルトの名無しさん** · 2021/11/28(日) 21:56:03.25

すまんが、馬鹿に何言っても理解されない。
疲れるだけだということが分かった。

**デフォルトの名無しさん** · 2021/11/28(日) 21:56:11.42

すまんが、馬鹿に何言っても理解されない。
疲れるだけだということが分かった。

**デフォルトの名無しさん** · 2021/11/28(日) 21:56:13.54

すまんが、馬鹿に何言っても理解されない。
疲れるだけだということが分かった。

**デフォルトの名無しさん** · 2021/11/28(日) 21:57:51.47

remove メソッドにバグがあった (head, tail を更新していなかった) ので一応修正。
https://wandbox.org/permlink/GlDCsezlcix3aJvi

>>496
なるほど。アクセス時に通し番号的な物が必要になるのであれば
insert, remove 操作時にもその通し番号を振り直す必要があるので、O(1) では実現できない気がします。

>>497
双方向リンクリストは始点と終了をペアで持つという固定観念があったので、その発想はなかったです。

**デフォルトの名無しさん** · 2021/11/28(日) 22:02:54.87

>>501
>なるほど。アクセス時に通し番号的な物が必要になるのであれば
>insert, remove 操作時にもその通し番号を振り直す必要があるので、O(1) では実現できない気がします。
先頭や末尾では無い途中のinsert、removeであれば、あなたの言うとおり。
追加する直前のノードにたどり付くまでに一般的にはO(N)の時間が掛かる。
ただまあ、末尾追加や先頭追加と、末尾削除、先頭削除なら、RustでもO(1)で
出来るだろう。
なお、Cursorを使えば、よくあるケースだけは高速に行えるようになっているかも知れないが。
あくまでも良くあるケースだけは、unsafeを使って特別対応しているだけ。
複雑な一般的なケースでは、やはり、O(N)かかってしまう。
その意味で、あなたの言っていることは正しい。

**デフォルトの名無しさん** · 2021/11/28(日) 22:13:58.18

いつまで例のVecを使った謎LinkedList実装にこだわっているのだろう

**デフォルトの名無しさん** · 2021/11/28(日) 22:17:12.75

>>503
こだわっているというか、あれは、オーダー的にはCと同じく、ほとんど全ての
動作をO(1)で出来てしまうリンクトリストをRustでも出来ているから、
注目に値する。
ただし、O(1)と言っても、実際には遅い。
また、Read After Delete、ダングリングポインタに相当するものがRustでも
生じる。たとえ、safeモードで書いても。

**デフォルトの名無しさん** · 2021/11/28(日) 22:20:39.78

なんでRustだけsafe前提なんすか？

**デフォルトの名無しさん** · 2021/11/28(日) 22:21:32.31

>>504
要素追加でバッファ超えると配列全体をコピーするけどO(1)なんだ？
いいのかそれで？

**デフォルトの名無しさん** · 2021/11/28(日) 22:26:36.40

>>505
Rustはそれを売りにしてるからだよ。
C/C++は最初から諦めてる。

>>506
その指摘は正しい。
平均的にはO(1)だが、スパイク状に(不定期に)O(N)のコピー動作が入ってしまう。

**ハノン** ◆QZaw55cn4c · 2021/11/28(日) 22:29:15.25

>>501
私のやり方でよかったことは、prev/next の無矛盾性のチェックが簡単に書けることくらいでした、他は複雑になってしまった…

**デフォルトの名無しさん** · 2021/11/28(日) 22:50:50.98

>>507
売りにしてるいうても結構厳しい制限だからデータ構造に直結するようなコードはsafeのみじゃ無茶だぞ
連結リストのようにユーザ側もダングリングとか多重参照とか気をつけなきゃいけないタイプのものは、
safeの範囲じゃ回りくどいことやるハメになるか、そもそも本当に無理になるかだ

**デフォルトの名無しさん** · 2021/11/28(日) 22:53:17.54

>>496
>ところが、アクセスが、標準実装では、借用規則のために複数の
>読み書きポインタを永続的に保持することが出来ないので、ノードの位置を
>先頭からの通し番号で覚えておいて、アクセスするたびに毎回先頭から
>辿る必要があるため、O(N)かかる。

そうなんだ
でもこれってC/C++でもメモリ安全で、スレッドセーフとかにしたら同じにならん？

**デフォルトの名無しさん** · 2021/11/28(日) 22:59:54.62

自分はがんばって数学の勉強をしてきたので自分の考えは絶対に正しい、間違うはずがないと思いこむ。
そうなると一度間違った考え(リンクドリストの任意の要素にO(1)でアクセスできる)を持ってもそれを間違った考えとは気づかずにその間違いを補強するようなチグハグな考え方をするようになる。
反ワクチンのようなトンデモ科学にはまっちゃう人に周囲の人がいくら正しい科学知識で説得しても自分の考えに疑問を持つどころか、自分の考えは絶対に正しい、周りのやつらは頭がおかしいと思いこんでしまう。

自分の考えが間違うこともあるのではないかと謙虚になることも重要だということだね。

**デフォルトの名無しさん** · 2021/11/28(日) 23:00:17.08

まずポインタで持てば1クロックは明らかに嘘
今後はクロックという言葉を使うのはやめなさい

次にポインタで持てばリンクリストはO(1)も明らかにおかしい
例えばハッシュテーブルもバイナリツリーもO(1)になってしまう

**デフォルトの名無しさん** · 2021/11/28(日) 23:03:08.30

>>510
Cの場合、リンクリストは経験的に言えば、簡単に扱えるので結構安全。
すっきり分かり易いので安全になる。動作が素直だし。

むしろ、途中削除、途中挿入した場合、配列の方が扱いが難しい。
リンクリストは他のノードのアドレスが変わらないのでポインタの値は
変化させなくて良いが、配列の場合は操作をしたノードより後ろに
有るノードの添え字番号がずれてしまうため、そのたびに
管理番号を付け替えるようなことが必要になってしまい、
データ構造が複雑な時に管理がとても大変になる。
リンクリストだとそのような手間が要らないので便利。

ただし、(配列, 添え字) <--> (リンクリスト, アドレス) の双対関係
は常に念頭に置いておく必要がある。後者は基本的には決して
添え字(通し番号)を使ってはいけない。なぜなら、それは後者においては、
ID値としては使えないから。

ただそもそも配列は、添え字はID値としては不十分というか、配列には絶対不変の
ID値が存在しない。リンクリストはアドレスが絶対不変のID値として使える。

**デフォルトの名無しさん** · 2021/11/28(日) 23:04:35.17

>>511 >>512
まずは、
(配列, 添え字) <--> (リンクリスト, アドレス)
の双対関係を理解しよう。

これが理解出来て無い人は、リンクリストの本来の性能も、本来の使い方も
出来ない。

**デフォルトの名無しさん** · 2021/11/28(日) 23:05:48.98

>>511
俺は頑張って勉強したから数学が得意だったのではない。
テキトーにやってただけで、出来た。

**デフォルトの名無しさん** · 2021/11/28(日) 23:05:52.69

そういうの双対って言わないから……

**デフォルトの名無しさん** · 2021/11/28(日) 23:08:15.36

じゃあハッシュテーブルもエントリーアドレスでアクセスできるからO(1)と言い出す気か？

**デフォルトの名無しさん** · 2021/11/28(日) 23:11:15.41

>>514
[補足]
要は、「配列の世界」と「リンクリストの世界」では、世界自体が別物なので、
要素/ノードを識別する手段も違い、前者は添え字番号、後者はアドレスが基本量となる。
従って、リンクリストでは、ノードを識別するには、必ずアドレスを使うことが基本。
それが最も自然であり、高速であるから。
いつまでも、添え字番号で識別する方法しか理解できない人には、言っている意味が理解できない
だろう。

電気と磁気にもさまざまな双対関係がある。世界がある種の対称になっているから、
その際に、正確に対応する量を入れ替えてやら無ければならない。リンクリストでは
通し番号ではなくアドレスを使う。
そうしないと公平ではない。

**デフォルトの名無しさん** · 2021/11/28(日) 23:11:50.99

>>516
双対の定義は、独自に決めてよい。

**デフォルトの名無しさん** · 2021/11/28(日) 23:13:05.79

>>517
はあ？
ハッシュテーブルは、実質的にO(1)にとても近い速度で検索できるから
使われているんだが。

**デフォルトの名無しさん** · 2021/11/28(日) 23:16:38.50

>>514
それは嘘だと誰でもわかる
リンクリストの個別要素のアドレスに対応するものは配列の個別要素のアドレスでありハッシュマップの個別要素のアドレスである
そしてアドレスを持てばO(1)とトンデモを言い出すならば全てのデータ構造がO(1)となる
つまりリンクリストのO(1)は嘘

**デフォルトの名無しさん** · 2021/11/28(日) 23:18:09.73

>>513
>Cの場合、リンクリストは経験的に言えば、簡単に扱えるので結構安全。
>すっきり分かり易いので安全になる。動作が素直だし。

そんなに簡単だとかいうなら、試しに実装を見せてほし・・・

**デフォルトの名無しさん** · 2021/11/28(日) 23:25:05.70

>>521
お前が生徒だったら0点つけてやる。

そもそも、動的配列は要素数が内部容量を超える時にアドレスが時々変わって
しまうから、ID番号として基本的にアドレスは使えない。
それをすると、末尾追加するだけでも、定期的にID番号が変わってしまうので
その際にID番号として使っているアドレスを全部修正しないといけなくなるから。
しかし、アプリ内のID番号を全部修正するのは、効率免で良くない。
だから、配列だと要素の一番ましなID番号は添え字番号。

一方、リンクリストで最も効率の良いID番号は、アドレス。
しかも、リンクリストの場合、任意の場所への挿入、任意のノードの削除を
行っても、他のノードのアドレスは変わらないので、アドレスをID番号
として用いている限り、どんな操作をしてもID番号の修正が不要となる。
こんなによいID番号はないわけで、敢えて添え字番号をID番号に使うのは
不適切。

**デフォルトの名無しさん** · 2021/11/28(日) 23:26:21.97

>>522
Cの入門書で、リンクリストについて書いてあるもの読んで理解して、
頭が悪くなければ、そう自然に解釈できる。
根本的に馬鹿な人には無理かも。

**デフォルトの名無しさん** · 2021/11/28(日) 23:38:14.43

rust は safe じゃなきゃ意味がない論者の人かな

**デフォルトの名無しさん** · 2021/11/28(日) 23:43:54.48

>>525
Cでは生ポインタ一個に対して、Rustは参照関連だけでも、20種類は下らないほど
色々な複雑な仕組みがあるのは、全て safe のためであるのに、safeでなくなったら
それこそCの圧勝になるが。

**デフォルトの名無しさん** · 2021/11/28(日) 23:48:12.68

>>526
コーディングはゲロのようにめんどくさくなるが、
速度面では別にCにそう負けるもんではない
多分最適化しきれなくてほんのちょっと遅くなる部分はありそうだが

**デフォルトの名無しさん** · 2021/11/28(日) 23:48:45.22

>>477
それは、実はリンクリストも十分に局所性が有る。
というのは、追加するときには、リンクリスト全体のごく一部にバースト的に
挿入することが多いからだ。
そしてその時、ノードのアドレスは等間隔に並ぶ傾向が有るから。

**デフォルトの名無しさん** · 2021/11/28(日) 23:49:16.38

>>527
いや、今回の例では劇的に遅くなるケースがあるといってるんだ。

**デフォルトの名無しさん** · 2021/11/28(日) 23:51:28.85

>>529
今回の例が何のことか把握してないが（QZが絡んでいるレスは読みづらすぎる）、
配列がどうたらとかの話なら別に配列なんていらんよ

**デフォルトの名無しさん** · 2021/11/28(日) 23:52:03.44

結局この全員の合意とは無関係な些末な話ばかりだな

＞まとめ
＞・C/C++で記述できることは同じ安全度合いで常にRustでも記述できる
＞・そのうちほとんどのケースではRustだとメモリ安全性を保証する形で記述できる
＞・つまり言語としてC/C++よりもRustの方が優れている

**デフォルトの名無しさん** · 2021/11/28(日) 23:53:36.07

>>531
デタラメを何度も書くな。

**デフォルトの名無しさん** · 2021/11/28(日) 23:55:06.43

>>532
もし反論があるならしてみたら？

**デフォルトの名無しさん** · 2021/11/28(日) 23:58:27.96

極論だけど各メンバをUnsafeCellにしてunsafe使いまくれば、
shared XOR mutableルールぶち破れるから、
C/C++でできることはコーディングめんどくさくなるし安全性が結構悲しいことになるけど（でもCとかと同程度）
Rustでも不可能ってことはない

なんならCコードをRustコードに自動変換するやつすらあったような
成熟度は知らんが

**デフォルトの名無しさん** · 2021/11/28(日) 23:58:30.48

>>533
全て書いてるのに理解力が無いから理解できないだけ。
Rust信者は馬鹿ばかり。

**デフォルトの名無しさん** · 2021/11/29(月) 00:02:50.56

>>507
>Rustはそれを売りにしてるからだよ。
>C/C++は最初から諦めてる。

自分で C/C++ は安全じゃないから、って書いてるじゃん
それが結論でしょ
同じ安全性にしたら、同じになるだろ

**デフォルトの名無しさん** · 2021/11/29(月) 00:05:09.36

>>536
同じ安全性にする必要がない。

**デフォルトの名無しさん** · 2021/11/29(月) 00:15:16.20

前から別の人が指摘しているけど、
リンクドリストとは別に配列を用意してリンクドリストの要素へのアドレスを保持するからリンクドリストの任意の要素にはO(1)でアクセスできる
と主張しているが
そのリンクドリストに追加または削除するたびに配列の要素も追加か削除しないといけなくなる。
リンクドリストの任意の位置に追加/削除するのはO(1)だけど、配列の任意の位置に要素を追加/削除するのはO(1)じゃない。
だからリンクドリストと配列を組み合わせて使うとリンクドリストのメリット(任意の位置への追加/削除がO(1))が無くなってしまう。

その配列に静的配列を使うならリンクドリストの最大サイズを予想してあらかじめ大きな配列を用意しないといけない。
動的配列を使うな要素を追加したときにときどきヒープの再確保がおきる。

**デフォルトの名無しさん** · 2021/11/29(月) 00:21:59.31

>>528
実際のメモリレイアウトがどうなるかは言語処理系のランタイムやlibcに依存すると思うのですが
例えばどの言語のどの処理系のどのランタイムを使使えばそうなることが確認されているのですか

**デフォルトの名無しさん** · 2021/11/29(月) 00:23:38.13

>>538
配列 + リンクリストの代わりに、リンクリスト + リンクリストにすれば解決するぞ。

**デフォルトの名無しさん** · 2021/11/29(月) 00:24:11.08

>>539
malloc()の仕組みから言ってそう考えられる。

**デフォルトの名無しさん** · 2021/11/29(月) 00:30:08.36

>>534
Rustはもっと単純
生ポインタを使えばC言語と全く同じ状態となる
fn main() {
　let mut a: i32 = 123;
　let raw_pointer = &mut a as *mut i32; // aの生ポインタを得る (unsafe不要)
　let b = &a; // bがaの参照を借用
　// a = 456; // これは借用ルールによりコンパイルエラーとなり書き換えできない
　unsafe { *raw_pointer = 456; } // 生ポインタを使えば自由自在に書き換え可能
　assert_eq!(a, 456); // 借用ルールを逸脱して書き換わっている
　assert_eq!(*b, 456); // 借用している参照bから見ても当然書き換わっている
}

じゃあUnsafeCellなどはいつ使うの？と思うだろうけど
それはRustで安全な型を提供するための部品として用いる
例えばRefCellやOnceCellなどの安全な型は部品としてUnsafeCellを用いている

**デフォルトの名無しさん** · 2021/11/29(月) 00:39:59.63

>>541
最初の初期化時に（あまりフラグメンテーションが発生していない状態で）複数要素追加する以外に追加がほとんど発生しないっていう前提ならそうかもね
でも一般にそうじゃないから連結リスト使うんじゃないの？

**デフォルトの名無しさん** · 2021/11/29(月) 00:42:22.65

さすがにおちょくって遊ぶのを見るのも飽きてきたが

**デフォルトの名無しさん** · 2021/11/29(月) 00:45:55.70

あわしろ氏もC++は危険と言ってる。

**デフォルトの名無しさん** · 2021/11/29(月) 00:55:31.86

>>541
参照局所性高めたいなら個々の要素ごとにmallocするのではなくarena的に割り当てすべきなのでは
>>543の言うとおり、フラグメンテーション発生してると何も保証できなくなる

**デフォルトの名無しさん** · 2021/11/29(月) 00:59:52.29

>>542でコードを示したように
C/C++で記述できることは同じ安全度合いで常にRustでも記述できる
したがって以下の合意事項は正しい

＞まとめ
＞・C/C++で記述できることは同じ安全度合いで常にRustでも記述できる
＞・そのうちほとんどのケースではRustだとメモリ安全性を保証する形で記述できる
＞・つまり言語としてC/C++よりもRustの方が優れている

**デフォルトの名無しさん** · 2021/11/29(月) 01:00:10.18

しかし、配列の場合は、内部バッファのサイズが拡張される時には全コピーが
発生するから、キャッシュが大規模に乱れてしまうがな。
その点、リンクリストは乱れたとしてもそこまででは無い。

**デフォルトの名無しさん** · 2021/11/29(月) 01:03:19.07

>>547
unsafe付けたら全体の安全性も失われるが。
メモリーの間違いには局所性がなくて原因箇所が分かりにくいからこそ、
Rustはメモリー安全に固執しているんだが。
逆にCはそもそもそれをユニットテストなどで徐々にテストしながら開発を進める
ことで確保する方針を採っている。

**デフォルトの名無しさん** · 2021/11/29(月) 01:10:35.89

リンクリストでのキャッシュの乱れと言っても、アドレスが大幅に異なるものが入り混じっても、
必ずしもペナルティーが増えるわけでは無いぞ。
例えば、2つの大幅にアドレスが異なるノードを交互にアクセスする程度では
キャッシュの読み込み直しは通常の連続アドレスにアクセスした場合に比べて
特に追加発生はしない。
キャッシュメモリ1種類の連続メモリブロックしか収められないわけでは無いからな。
限界はあるが、いくつかのメモリブロックなら同時に収めることが出来るからな。

**デフォルトの名無しさん** · 2021/11/29(月) 01:12:27.10

>>550
逆にキャッシュ制御せずにmemcpy()みたいなもので大きなメモリーをコピーした
場合、キャッシュが全フラッシュしてしまう可能性も有る。
動的配列の場合はそこに注意が必要。

**デフォルトの名無しさん** · 2021/11/29(月) 01:17:45.41

>>550
図を書いておこう。2つのメモリー領域A, B があったとして、
リンクリストが
AAAAAAAAAAA
の状態の途中にノードを5つ追加して、
AAAAABBBBBAAAAAA
のようになっていてもそれほどキャッシュミスは起きない。

さらに、もし、
AABCBBACDBBAABBDBCCC
みたいになっている程度でも、そんなにキャッシュミスは起きない。
なぜなら、A,B,C,D の4箇所くらいならキャッシュにどれも収まるから。

**デフォルトの名無しさん** · 2021/11/29(月) 01:20:38.16

>>549
それはウソ
Rustは標準ライブラリの内部に至るところに多数のunsafeがあるのは事実だが
それにより全体の安全性に影響を与えることはない形でのみ提供している

まずunsafeの使用方法は大きく2つに分けられる
(1)影響が局所的に限定される場合
(2)影響が大域的に起き得る場合
つまりunsafeを用いたRustの様々な型やその操作インタフェース等は(1)が満たされている

つまりそれらを利用するプログラムには内部がどう実装されていようと影響をもたらさない
したがってRustのプログラム自体がコンパイラによって安全性を保証することが可能となっている

**デフォルトの名無しさん** · 2021/11/29(月) 01:21:24.40

ベンチも取らずにキャッシュヒット率の話するの時間の無駄すぎない？
あとVecに対するLinkedListの優位性の話されても誰もそんなことは問題にしてないぞ？

**デフォルトの名無しさん** · 2021/11/29(月) 01:26:01.98

>>553
それはそうかもしれないが、リンクリストの場合、ノードの識別に
アドレスを使うのが、双対原理によって標準なので、その標準手法を
Rustで使おうとすると、unsafeをアプリ本体で使う必要が出てくる。
つまり、ライブラリの中にunsafeを閉じ込めることが不可能。
これは間違いないはずで譲れない。

**デフォルトの名無しさん** · 2021/11/29(月) 01:26:35.85

>>554
ほとんどのケースではLinkedListよりもVecを用いた方が有利
だから使用する言語に関わらず特殊なケースを除けばリンクリストではなくベクターが使われている

**デフォルトの名無しさん** · 2021/11/29(月) 01:32:54.07

>>556
それが間違いなんだって。
そんな思想だから、ChromeではHTMLもtextareaへの文字列の末尾追加ですら遅いんだな。
計算量が理解出来て無い。
VisualStudioも異常に遅いし。
それに比べて日本人の作るVzEditor, WzEditor は速い。
それはなぜかというと、LinkedListも使っているから。

**デフォルトの名無しさん** · 2021/11/29(月) 01:44:20.89

LinusもC++は糞言語と言ってる。

**デフォルトの名無しさん** · 2021/11/29(月) 01:44:27.36

古いけどこんなのみつけた
https://baptiste-wicht.com/posts/2012/12/cpp-benchmark-vector-list-deque.html

insert/removeはO(1)なlistの方が速そうなものなのに要素サイズが小さいと10万要素でもvecの方が速いんだね

**デフォルトの名無しさん** · 2021/11/29(月) 01:47:20.54

システムコールの実装によるのでは？

**デフォルトの名無しさん** · 2021/11/29(月) 01:50:31.36

>>559
Push Front を見たら圧倒的に list が速い。
それにC++のライブラリの list はへたくそな実装になっている。

**デフォルトの名無しさん** · 2021/11/29(月) 01:52:56.70

>>561
deque無視しないでよ
先頭への追加削除が高速なvectorだよ
クラフをログスケールにするとわかるけどlistより速い

**デフォルトの名無しさん** · 2021/11/29(月) 01:53:14.65

沢山実験して、LinkedListの方が性能がいいことが分かってるからLinkedList
を使ってる。
ベンチマークは、ベンチマークを作る人が正しく理解してなければ、正しい
テストプログラムを書けないから、正しい結果が出ない。
CPUのベンチマークも実際の体感速度に比例しているとは限らないのと同様。

**デフォルトの名無しさん** · 2021/11/29(月) 01:54:51.63

list の実装の仕方や使い方に問題があるだけだ。
何度も言ってるように、listは、双対原理から言って、添え字番号ではなく
アドレスを用いなければ成らないことをベンチマークプログラムを作ってる
人が理解出来て無いから、遅く出てることが多い。

**デフォルトの名無しさん** · 2021/11/29(月) 01:56:39.58

2017年版あったからこっち見た方がよさそう
https://baptiste-wicht.com/posts/2017/05/cpp-containers-benchmark-vector-list-deque-plf-colony.html

>>563
あなたのワークロードではそうなんですね、なるほど

**デフォルトの名無しさん** · 2021/11/29(月) 01:57:29.30

>>557
ついにGoogleとMicrosoftを批判しだしたのか

>>561
C++擁護派なのにC++のライブラリまで批判しだしたのか

君が間違っているとは考えないのね？

**デフォルトの名無しさん** · 2021/11/29(月) 02:04:18.84

>>565
要素サイズが128バイトや4096バイトの時には、listの方がvectorより速い。

それに、NonTrivialの時こそ list が効率がいいはずなのに結果が逆になって
いたり、listは、安定なはずなのに、trivial 128 で list のグラフが
途中で直線になってないこともおかしい。
listは、どんなときでも速度が変化しにくい性質があるはず。
何かそのテストはおかしい。

**デフォルトの名無しさん** · 2021/11/29(月) 02:05:00.82

>>566
俺はCと言っていたが。
C++のSTLには設計に問題が有ると行っているぞ、昔から。

**デフォルトの名無しさん** · 2021/11/29(月) 02:07:29.41

実際に自分で実験したこそが無いのに、誰かが実験したものを信じるな。
実際に一般的なケースでは、vectorとlistでは、listの方が速いことが多い。

**デフォルトの名無しさん** · 2021/11/29(月) 02:09:04.94

>>569
ほとんどの用途でベクターが速い
だからほとんどのケースではリンクリストではなくベクターが使われている

**デフォルトの名無しさん** · 2021/11/29(月) 02:12:28.28

>>570
数理に弱いアメリカ人。
だから、VisualStudioも激オソなんだな。
アメリカ人の作るものは何でもでかくて速度が遅い。
車もでかくて燃費が悪い。

**デフォルトの名無しさん** · 2021/11/29(月) 02:15:22.14

>>567
NonTrivialはMovableな要素だから追加削除時には要素あたりポインタ数個分のデータがコピーされるだけで小サイズと同じ特性になるのは不思議ではないのでは

listについては要素サイズの変化に対して他のコンテナよりも安定的に見えるけど
さすがに要素のコピー分のコストはかかるから要素サイズ変わっても全く同じという訳ではないけど

**デフォルトの名無しさん** · 2021/11/29(月) 02:21:21.41

こういうベンチマークには、ファクトチェックが必要だ。
今までネットのこういう変な結果のベンチマークを見てきたが、
ソースを見てみると変なことをしてることが多かった。
多かったというより、結果がおかしいと思って調べてみたら全て変なことしてた。
秀才以外が行ったベンチマークは信用できない。
まだ、雑誌は信用できることが多いが、ネットのベンチマークはおかしい。

**デフォルトの名無しさん** · 2021/11/29(月) 02:23:11.00

『リンクリスト vs. ベクター』のスレ立ててそこでやったら？
少なくともこのスレでやることではない

**デフォルトの名無しさん** · 2021/11/29(月) 02:25:44.21

ではどうぞ、ファクトチェックしてくださいまし
https://github.com/wichtounet/articles/blob/master/src/vector_list_update_1/bench.cpp

**デフォルトの名無しさん** · 2021/11/29(月) 02:29:42.73

誰かこのベンチマークをRustに移植してみてよ

**デフォルトの名無しさん** · 2021/11/29(月) 02:44:22.88

作業時間が発生するものを持ち込まないで欲しい。
こっちはボランティアに馬鹿に説明してやってるだけなんだから。
ソースを出せ、と言ってくるのは抽象的理解が出来ないから。
とても簡単なことを言ってるだけなのに、少しでも抽象的(symbolic)
な言葉で語ると全然理解できない。
数学とは抽象性(symbolic)な学問であるから、数学が出来ない人は
コードを示さないと理解できないらしい。

**デフォルトの名無しさん** · 2021/11/29(月) 02:59:57.67

ベンチマークとかはどうでもいいが、
CだろうがRustだろうが実装可能って話にしか見えん

**デフォルトの名無しさん** · 2021/11/29(月) 07:57:57.28

>>538
これな。
結局のところ実体へのポインタの配列であればリンクトリストになってなくても話は同じなんじゃないかな。

**デフォルトの名無しさん** · 2021/11/29(月) 08:02:08.66

実体へのポインタの配列だけでいいよなｗ
それで実体にはすべて到達できるもんｗ
ある実体の次も、前も、それも両方分かるしｗ

**デフォルトの名無しさん** · 2021/11/29(月) 10:19:47.16

抽象はabstract

**デフォルトの名無しさん** · 2021/11/29(月) 11:26:03.41

>>579
違う。
リンクトリスト + 配列だと >>538 が指摘している現象が生じてしまうが、
リンクトリスト + リンクリストだと生じない。

こういっても、数学力の無い人は理解できないだろうな。
数学力は数学という学問だけの能力ではなくて、脳内のワーキングエリアや
イマジネーションなどに関係しているから、生まれつきの影響が大きい。

**デフォルトの名無しさん** · 2021/11/29(月) 11:29:51.75

>>582
[補足]
抽象的理解が難しい人に具体的に書いておいてやろう。
LinkedList ll;
ArrayList al;　//自動伸張方式の動的配列だと仮定する
al[0] = ll.append("りんご");
al[1] = ll.append("みかん");
al[2] = ll.append("バナナ");
だと >>538 が指摘しているような不具合が起きる。しかし、
LinkedList ll;
LinkedList ll2;
ll2.append( ll.append("りんご") );
ll2.append( ll.append("みかん") );
ll2.append( ll.append("バナナ") );
だと起きない。

**デフォルトの名無しさん** · 2021/11/29(月) 11:36:08.77

>>583
中身が同じリストを二個用意しても意味がないのでもう少し実践的な例の方が理解のためにはよろしいのでは
スキップリストみたいな構造とは違うのですか？

**デフォルトの名無しさん** · 2021/11/29(月) 11:36:25.33

>>583
もっと具体的に書いてやろう。
リンクリストの中の追加した6つの果物の内、4つを他の配列やリンクリストの
中から参照する例を示しておこう。
これの応用としてリンクリスト内の1000個の品物の内、何らかの条件で選び取った10個を
別の配列やリンクリストから参照することが出来る。

1. リンクリスト + 配列
LinkedList ll;
ArrayList al;　//自動伸張方式の動的配列だと仮定する
al[0] = ll.append("りんご");
ll.append("みかん");
al[1] = ll.append("バナナ");
ll.append("すいか");
al[2] = ll.append("パイナップル");
al[3] = ll.append("ブドウ");

2. リンクリスト + リンクリスト
LinkedList ll;
LinkedList ll2;
ll2.append( ll.append("りんご") );
ll.append("みかん");
ll2.append( ll.append("バナナ") );
ll.append("すいか");
ll2.append( ll.append("パイナップル") );
ll2.append( ll.append("ブドウ") );

**デフォルトの名無しさん** · 2021/11/29(月) 11:36:55.60

>>584
>>585 を見ろ。

**デフォルトの名無しさん** · 2021/11/29(月) 11:39:40.44

>>585
これがどういう時に起きるかといえば、最初に1000個の品物の入った
リンクリスト ll がある時、条件に合う品物を1つ探してリンクリスト ll2
の末尾に参照を追加する。
それを10回繰り返した後に、実質的に生じる。

**デフォルトの名無しさん** · 2021/11/29(月) 12:08:42.24

>>587
queryに対する抽出結果をリストとして保持しておいて元のリストの更新に応じてquery結果も適宜更新されるイメージですか？

**デフォルトの名無しさん** · 2021/11/29(月) 12:10:54.78

一部のノードが2つのリストで共有されてんのこれ？

**デフォルトの名無しさん** · 2021/11/29(月) 12:15:46.59

l2のリストに入れる数によって変わるので結局O(N)の操作じゃね？

**デフォルトの名無しさん** · 2021/11/29(月) 12:42:23.24

>>590
正確にはll2のサイズN_ll2の半分に近づくね。
ll2のサイズが大きくなるなら、大きめに初期化するのが無難。スカスカならバランス木のmapかね。

**デフォルトの名無しさん** · 2021/11/29(月) 12:43:56.81

リンクリストを少し調べたところ様々な種類のものが使われているようで
様々な分類が生じるうち今回関係するノードの参照については以下の4種類あるようだ

(A) データを挿入しても作られたノード自体は返さない方式
実際にこの仕様でも困らない用途も多いようでこの方式も普通に使われている
もちろん問題は何も生じない

(B) データを挿入して作られたノードのポインタを直接返す方式
これは危険で最も推奨されない方式
ポインタを握っていても使う時にそのノードは削除されているかもしれない
削除で開放されてヒープに戻され更に再利用されているとデータの中身もnext辿りも滅茶苦茶になりうる
そしてデータの扱い次第で実際に削除は起き得るしUI人間や通信相手から発動ルーチンでの削除も有り得る

(C) データを挿入して作られたノードの(一般的な)スマートポインタを返す方式
これはshared_ptrなど安全とされているスマートポインタを返すためメモリ使用上は安全
しかしポインタ先がヒープへ戻されていないことしか保証がない
つまり(B)と同様にリンクリスト自体からの削除が起きている可能性がありそれを知る方法がない

(D) データを挿入して作られたノードを管理しているリンクリスト内部の何らかを返す方式
リスクの高い(B)や(C)と異なりこの方式は安全かつ整合性が維持される
もしノードがリンクリストから削除されていればそれに対して対応ができる
この返されたデータを用いて新たなデータをその位置に挿入する時に元ノードが削除されていた場合
(D)-1. 挿入はされず既に元ノードが削除されていると知らせる
(D)-2. 知らせずに削除された元ノードの次に有効なノードの位置に挿入する
などリンクリストの仕様や用意されたメソッドにより異なるようだ

以上まとめると現実的に安全に使える方式は(A)もしくは(D)となっている
例えばC++の標準リンクリストstd::listでもこの(D)方式を採用しており
insert()はリンクリスト上をその位置から順に辿っていくイテレータを返す

**デフォルトの名無しさん** · 2021/11/29(月) 12:52:17.03

>>585みたいなことできる連結リストって、
Rustでも作れると思うんですけど
Unsafe全振りにはなると思うけど

**デフォルトの名無しさん** · 2021/11/29(月) 13:00:24.04

>>593
rustだけはsafeじゃないとだめらしいですよ