結局C++とRustってどっちが良いの？ 2traits

**デフォルトの名無しさん** · 2023/04/02(日) 00:42:57.53

「C++の色々配慮してめんどくさい感じは好きだけど、実務になったらメモリ安全性とか考えて今後Rustに変わっていくんかな」
「うだうだ言ってないで仕事で必要なのをやればいいんだよ、趣味なら好きなのやればいい」

っていうスレ。

前スレ: 結局C++とRustってどっちが良いの？
https://mevius.5ch.net/test/read.cgi/tech/1677286186/

**デフォルトの名無しさん** · 2023/04/29(土) 01:18:03.83

そうじゃなくて頭から最後まで要素を一回走査して挿入削除する場合は一回当たりのコスとはvectorより有利
何度も何度も繰り返し頭から走査する条件下では不利
ここでのベンチ結果は後ろのパターンばかりで不利になるのは当然

コード書いてる人が意図的に間違えてるのかセンスがないかのどちらか
アルゴリズムの意味が理解できてないと言う話

**デフォルトの名無しさん** · 2023/04/29(土) 01:21:50.87

コードを書く人間として常識的に考えればわかる
挿入時に一部だけ鎖つなぎなおすのが低コストか
毎回全部後ろまでずらすのが低コストか

削除時に一部だけ鎖つなぎなおすのが低コストか
毎回全部後ろの要素を前へずらすのが低コストか

**デフォルトの名無しさん** · 2023/04/29(土) 01:28:22.06

ほっといて勘違いしたままにしとけばいいのに

**デフォルトの名無しさん** · 2023/04/29(土) 01:52:27.12

実際に色んな仕事をしたことある人たちがvector派という感じ
現実は挿入することが目的ではなくその後に使うところが本場でvectorが有利
稀に比較挿入が主たる場合もあるけど効率の悪いlinked listではなくbinary treeなどを使う

**デフォルトの名無しさん** · 2023/04/29(土) 02:46:40.88

メモリに余裕があるなら
hash一択だな

**デフォルトの名無しさん** · 2023/04/29(土) 06:10:16.91

>>705
> 頭から最後まで要素を一回走査して挿入削除する場合は一回当たりのコスとはvectorより有利

そのような走査して挿入する利用で最も多いのが何かの順序に並べるケース
その場合は結果的にソートをしていることになるがオーダーO(n^2)となり効率が悪い

効率が良い方法はvectorを利用してまずは順序関係なく要素を追加してしまい
その格納された各要素へのポインタを対象に一気にO(n·log(n))の速いソートするとよい
ソートを必要とする多くのデータ処理はそのようにvectorを利用する形になる

**デフォルトの名無しさん** · 2023/04/29(土) 06:57:32.23

なんでソート済みのなかに挿入するのにまたソートするの？
頭悪そう。

**デフォルトの名無しさん** · 2023/04/29(土) 06:58:38.69

だってほら、ソート済みのオブジェクトをひっかきまわす別スレッドがあったり?ｗ (ひっかきまわし

**デフォルトの名無しさん** · 2023/04/29(土) 07:43:01.19

Linked Listをソートに使うのはアホ
計算量オーダーを知らないアホ
既に順に並んでるところへ挿入していくから速そうだと勘違いするアホ発見器

**デフォルトの名無しさん** · 2023/04/29(土) 08:07:10.82

>>703
節約できてねーよw

**デフォルトの名無しさん** · 2023/04/29(土) 08:11:13.42

>>706
そこはみんなわかってるよ
挿入時や削除時に挿入位置と削除位置を見つけるために
LinkedListの走査が必要な使い方をしたら
性能的にはLinkedListを使う価値がなくなるという話をみんなしてるんだよ

**デフォルトの名無しさん** · 2023/04/29(土) 10:06:18.64

VectorとlinkedListってどっちが良いの？スレでやってください

**デフォルトの名無しさん** · 2023/04/29(土) 10:27:01.32

Rustユーザは何も書かないのな
こういうのには感心がない人達なのかな?

**デフォルトの名無しさん** · 2023/04/29(土) 10:31:22.19

自分の無知を知らずシッタカするド素人と
自分の無知を察して慎重にシッタカするド素人
自分の無知を察して口をつぐむ慎ましいド素人

三番目なのがRustユーザ

**デフォルトの名無しさん** · 2023/04/29(土) 11:02:19.50

QiitaなんかでRustポエムがいいね入れ食いなのから察するに
Rustユーザは>>563みたいな数独パズル状態でどん詰まり傾向かな？

**デフォルトの名無しさん** · 2023/04/29(土) 11:12:39.77

結局、ここに溜まるような奴はみんな、やれといわれたら(どっちもちゃんと)やる人間だろうしね

でも好きずきはあるやっぱ俺はC++が好き

**デフォルトの名無しさん** · 2023/04/29(土) 11:22:17.96

いやmoveを分かってないレベルのRustユーザがいる
おそらくQiitaでRustポエムをいいねしてる？

一方、C++ユーザは実動コードやらベンチ結果を晒して議論するのを面白がってる様子
どっちも無知でも、どっちが成長するのか目に見えてるなw

**デフォルトの名無しさん** · 2023/04/29(土) 11:34:15.28

>>717
スレタイがアホ過ぎるので興味持って貰えんだろｗ

**デフォルトの名無しさん** · 2023/04/29(土) 11:36:22.20

言語としてはある種似てるとは思うわ
言語仕様としてではなくてね
HaskellとC++とRustはいっしょのカテゴリに入ってる
シッタカしたいタイプのド素人がドヤるための言語
JavaとかPHPをドカタ言語といって蔑むのといっしょ
女さんが自分を飾るブランドを選ぶのといっしょ

**デフォルトの名無しさん** · 2023/04/29(土) 11:42:46.52

>>710
違うよ
何かを順番に並べるケースは実際はランダムアクセスなんだよ
そんな簡単なこともわからないの？

**デフォルトの名無しさん** · 2023/04/29(土) 11:49:34.55

>>724
おまえ数学できないだろ
計算量のオーダーを算出してみろ

**デフォルトの名無しさん** · 2023/04/29(土) 11:52:16.10

>>710
＞　そのような走査して挿入する利用で最も多いのが何かの順序に並べるケース

頭から走査する回数が増えるとlinkedlistが極端に不利になるって常識的に分かるよね
そういう条件でソートをlinkedlistでやるやつは馬鹿だろ
それなのに何で頭から操作繰り返すアルゴリズムを選ぶのか？
意味分かってないのか？

**デフォルトの名無しさん** · 2023/04/29(土) 11:59:53.23

>>725
結果見れば分かるだろ

結果から見るとlinkedlistで単体の件で条件マッチするまでソートはランダムソートのコスト＋比較だから

a[x] で仮に条件が合うのがｋだとしてそこまでは実際ランダムアクセスでそこまで行ってるのと変わらない
数学の素養がないのは君なんだけど…

多分これを書いても理解できてないよね…

**デフォルトの名無しさん** · 2023/04/29(土) 12:00:11.90

>>710
O(n log n) のコムソートはlinked listと相性悪くないよ。

**デフォルトの名無しさん** · 2023/04/29(土) 12:01:45.44

>>718-723
Rustユーザはもういなのでは?www
ユーザが少ないし仕方ないか...

**デフォルトの名無しさん** · 2023/04/29(土) 12:02:00.77

結局linkedlistが役立つケースは非常に限定的に限られるわけだ

**デフォルトの名無しさん** · 2023/04/29(土) 12:03:17.50

ランダムアクセスが苦手なのに挿入のたびに実質ランダムアクセスさせられてる
それに気が付いてない人の多いこと

全件を一度走査するのと実質ちまちまランダムアクセスを繰り返す挿入ソートの違いが理解できない馬鹿頭

数学が出来ない人間と話をしても無駄なんだよな…
馬鹿は水掛け論だと誤解してるから…

**デフォルトの名無しさん** · 2023/04/29(土) 12:04:14.42

論理的思考が出来ない馬鹿がプログラムを語るな

**デフォルトの名無しさん** · 2023/04/29(土) 12:06:39.68

>>728
コムソートは離れたm番目とn番目の要素の比較を頻繁にするからlinked listで不利

**デフォルトの名無しさん** · 2023/04/29(土) 12:07:03.97

何がしたいの

**デフォルトの名無しさん** · 2023/04/29(土) 12:07:35.56

ここまで書いてもまだお前ら理解してないだろ？

**デフォルトの名無しさん** · 2023/04/29(土) 12:11:44.15

ようやく理解できた
局所的に見るとlistが速い部分もあるんだけど
作業全体で比較するとvectorが速くなるってことか

**デフォルトの名無しさん** · 2023/04/29(土) 12:13:24.42

変な話だけど多分この議論の勝者は俺なんじゃないかな
数学的素養のない人間に衝撃を与えてる

**デフォルトの名無しさん** · 2023/04/29(土) 12:13:33.38

自転車置き場の議論が酷すぎますね

**デフォルトの名無しさん** · 2023/04/29(土) 12:16:18.44

>>733
nとmの2つのポインタを持って隣に一つずつ走査するだけ。

**デフォルトの名無しさん** · 2023/04/29(土) 12:19:38.06

リスト使うのに挿入時に探索やソートするのは設計ミスってる

**デフォルトの名無しさん** · 2023/04/29(土) 12:25:50.80

ちょっと再帰型の例として単方向連結リストが出ただけでここまで話を脱線させることができる集団

**デフォルトの名無しさん** · 2023/04/29(土) 12:35:51.92

>>735
他の人たちの説明はほぼわかったけど
きみの説明だけわからんかった
具体的なコードを出してみたらどう？

**デフォルトの名無しさん** · 2023/04/29(土) 12:36:29.75

集団ひとり

**デフォルトの名無しさん** · 2023/04/29(土) 13:08:56.23

>話を脱線させることができる集団

やっぱり、LinkedListの無理問答は脱線の仕掛けだったんだ

**デフォルトの名無しさん** · 2023/04/29(土) 13:33:17.72

論理的思考というワードを見るとなぜかテンションが上がる
所有権複製と同じぐらい

プログラムが論理的かどうかを判断するだけなら思考を研究しなくていい
最近のAI界隈が脳科学の研究をしないのと同じ

**デフォルトの名無しさん** · 2023/04/29(土) 13:39:38.26

問: 何からの話題そらしなのか考察せよ

ヒント1: 専ブラの勢いグラフ

**デフォルトの名無しさん** · 2023/04/29(土) 14:41:05.09

>>745
>プログラムが論理的かどうか
論理もへったくれもないこと言ってんな
どんなにトチ狂った論理でも論理は論理だし
プログラムには論理以外何も無い
何が言いたいんだこいつは

**デフォルトの名無しさん** · 2023/04/29(土) 14:43:15.45

糖質感じるワードサラダ

**デフォルトの名無しさん** · 2023/04/29(土) 16:48:28.13

本質的に雑スレなので、C++ vs Rust みたいな話題が好きそうな人が好きそうな話題ならなんでもいいや

**デフォルトの名無しさん** · 2023/04/29(土) 16:53:25.69

どんな暴言でも論理は論理ーとはならんだろ

**デフォルトの名無しさん** · 2023/04/29(土) 17:04:51.89

正直リンクドリストなんて一生使わないので興味ないのは図星

**デフォルトの名無しさん** · 2023/04/29(土) 19:05:39.22

>>739
そのコムソートのためにnとmの2つのポインタを持って、
双方向リストでmとnの入れ替えをしようとしたら、
ノードの入れ替えだけでとんでもないコストになった。
読み出しが4回と書き込みが8回もかかる

# mの前後がnを指すようにする
読　m_prev = m->prev
書　m_prev->next = n
読　m_next = n->next
書　m_next->prev = n

# nの前後がmを指すようにする
読　n_prev = n->prev
書　n_prev-> next = m
読　n_next = n->next
書　n_next->prev = m

# mがnの前後を指すようにする
書　m->prev = n_prev
書　m->next = n_next

# nがmの前後を指すようにする
書　n->prev = m_prev
書　n->next = m_next

リストのノードの入れ替えがこれだけ高コストだと、
ノードを入れ替えずに格納している要素の入れ替えをしたほうがよくて、
要素のサイズが大きければポインタのみ収容したほうがよくて、
ベクタが有利になるポインタのみ収容に行き着いてしまう？

**デフォルトの名無しさん** · 2023/04/29(土) 19:15:52.32

>>752
ベクタの値の交換とどっちが高コストかはその値のサイズによるでしょ。
値の交換はリンクトリストでもできるわけだからコストの低い方を選べばいい。

**デフォルトの名無しさん** · 2023/04/29(土) 19:31:19.50

ベクタでソートする時は要素を動かす必要はなく各要素を指すポインタをソートする
リストでも同じ方法が可能だがリンクを毎回たどる分だけ不利
領域分割のクイックソートなどもリストでは使えない

**デフォルトの名無しさん** · 2023/04/29(土) 19:41:23.91

なんでソートする必要のあるデータを連結リストにぶち込もうと思ったんですか？

**デフォルトの名無しさん** · 2023/04/29(土) 20:12:09.35

>>754
リンクを毎回たどるって何のことを言ってんの？>>739のように現在指している要素の隣の要素を参照するだけだよ。

>領域分割のクイックソートなどもリストでは使えない

クイックソートもインデックスでランダムアクセスが必須じゃないからリンクトリストでもいけるみたい。
最初のピボット選択に不利なくらいで。

**デフォルトの名無しさん** · 2023/04/29(土) 20:20:23.48

>>755
「おれじゃない。あいつがやった」と登場人物全員が思ってるから

**デフォルトの名無しさん** · 2023/04/29(土) 20:34:27.32

>>755
sort用途も不利となると
linked listの使い途がますます無いな

**デフォルトの名無しさん** · 2023/04/29(土) 20:58:27.38

もうないよ
Lispが持っていた機能が延々と引き継がれているだけ

**デフォルトの名無しさん** · 2023/04/29(土) 21:28:35.35

最悪計算量がO(1)の両端キューがどうしても欲しい場合にでも使えばいいんじゃないでしょうか

**デフォルトの名無しさん** · 2023/04/29(土) 21:36:10.77

まあ、linked list でいっかあ、ってとき。簡単なのはメリット。
おいおい、ちゃんとしたコンテナに替えてもよし。

**デフォルトの名無しさん** · 2023/04/29(土) 21:52:36.29

両端キュー(deque)はリストではなくベクタ系による実装の方が好まれて使われる
std::dequeue、JavaのArrayDequeue、RustのVecDequeなど

**デフォルトの名無しさん** · 2023/04/29(土) 22:13:48.24

chatgptにlinked listがいい例を挙げてもらった
テキストエディタ、ジョブスケジューラ、メモリ管理、ハッシュテーブル

**デフォルトの名無しさん** · 2023/04/29(土) 22:15:45.27

>>756
>リンクを毎回たどるって何のことを言ってんの？>>739のように現在指している要素の隣の要素を参照するだけだよ。
LinkedListでリンクをたどらずどうやって隣の要素を参照するのか教えてくれるかな？

**デフォルトの名無しさん** · 2023/04/29(土) 22:23:38.61

>>755
ベクタ/リストをソートするのに計算量的な差は特にない。
ソート済みのものに要素を挿入するのは一長一短あるが一般にはリストが有利な場合が多いな。
挿入自体のパフォーマンスに特化するなら場合はヒープのような木構造を使うのがベストだろうが。

**デフォルトの名無しさん** · 2023/04/29(土) 22:25:57.31

>>764
リンクで隣の要素をたどるだけならなんも不利なことないじゃん。

**デフォルトの名無しさん** · 2023/04/29(土) 22:26:27.79

>>763
ハッシュテーブルでもリンクリストを使うチェーン法はリンクをたどるコストが無駄なので避けられる
現実的に効率の良いオープンアドレス法が好まれておりベクターが使われている

**デフォルトの名無しさん** · 2023/04/29(土) 22:39:43.93

なんか偶然ソートの話になってるけど
流れを読んでからこれ書いたんじゃなくて
「ところでインサーションソートなんてベクタじゃ苦しいだろうけど
リストならすごく効率がいいんではないか？　を確かめようとしたら
list::sortがおそらくすでに十分に効率的に書かれてることが分かって
インサーションソートを自分で実装する気が萎えた
（いちおう拾ったコードは乗せてあるけどクッソ遅い）」という別の話

https://ideone.com/D9ljA7
function asc desc shuf
std::sort(v) 16 13 72
list::sort 43 60 332　←十分早い
std::qsort(v) 47 45 144　←参考

**デフォルトの名無しさん** · 2023/04/29(土) 22:50:51.62

>>766
リンクをたどらず隣の要素を参照することはできないのね
チューリング賞ものの新アルゴリズムでもあるのかと思って期待しちゃったよ
数学的に

**デフォルトの名無しさん** · 2023/04/29(土) 22:57:10.41

>>769
>>765はそのリンクをたどることがどう不利になるのかを聞いたんだが？

**デフォルトの名無しさん** · 2023/04/29(土) 22:58:20.16

>>756か。

**デフォルトの名無しさん** · 2023/04/29(土) 23:51:59.24

Senior Microsoft exec says Windows 11 kernel will soom be booting with Rust inside

https://www.neowin.net/news/senior-microsoft-exec-says-windows-11-kernel-will-soon-be-booting-with-rust-inside/

うおおおおおお！！

**デフォルトの名無しさん** · 2023/04/30(日) 00:02:56.42

Microsoft's adoration of Rust does have limits.
"Rewriting Windows in Rust probably isn't going to happen anytime soon," said Weston,
"so while we love Rust, we need a strategy that also includes securing more of our native code."

**デフォルトの名無しさん** · 2023/04/30(日) 00:09:47.59

コンパイラはどうすんのかな?
社内に自社製のがあるのかな?

**デフォルトの名無しさん** · 2023/04/30(日) 01:22:44.98

>>769
LinkedListにおいて、キャッシュに載っていれば隣の要素は、1クロックで
辿れるから何の問題もない。アセンブリコードは、
mov rbx,[rbx + pNext]
みたいになり、キャッシュに載っていれば1クロック。
多くの場合、キャッシュに載っていることが多い。
乗っていない場合は、prefetch 命令で載せることができる。

**デフォルトの名無しさん** · 2023/04/30(日) 01:28:36.62

Stroustrup氏は、キャッシュミス時のハードウェアによる自動 prefetch が
数百クロックかかると書いていたが、それは過去の話で、
現在の DDR4-SDRAM だと、15クロックだと聞いた。
だから、キャッシュに載ってなくても15クロックのペナルティーで済む。
また、pNext を読む前に prefetch 命令で pNext の部分をキャッシュに読み込ます
ようにしておけば、ペナルティーは 1 クロック以下に近くなる。
「以下」と書いたのは、いまの CPU は複数命令の同時命令実行機能が有るので
prefetch命令自体は0クロックで実行できることがあるから。

**デフォルトの名無しさん** · 2023/04/30(日) 01:38:31.10

ほんと頭悪すぎだろ
数学的に

**デフォルトの名無しさん** · 2023/04/30(日) 01:38:51.52

なお、LinkedListでも多くの場合は、次のノードは、アドレスがほぼ隣接しているので
キャッシュに載っている確率が高い。ほぼ連続的なアドレスを次々に辿っていくので
ほとんどの場合、LinkedListのノードは読み込み時にキャッシュに載り続けている。
10万個の要素があった時、その内、2つの要素を10回交換したとしても、
キャッシュの乱れは、40回程度。10万要素の内の40回程度、キャッシュ
ナルティーが生じるだけ。
それぞれが15クロックほど遅くなるだけだから、10万個の要素を辿っても、
全体として、600クロックほど、キャッシュ読み込みの時間が追加されるだけ
のはず。ただし、キャッシュミス時の自動prefetchの時間が15クロック
かどうかは不明。
なお、ソフトウェア的にprefetch命令をマシン語で書いておけば、他の命令を
実行中にprefetch動作が入るので、キャッシュペナルティーを実質0クロック
にできる。

**デフォルトの名無しさん** · 2023/04/30(日) 01:39:45.77

>>777
俺の方があんたより数学的才能に恵まれてると思うぞ。

**デフォルトの名無しさん** · 2023/04/30(日) 01:44:17.33

ここの人は何か勘違いしてるようだが、LinkedListで隣のノードに辿るのは、
C で書くと
pNode = pNode->pNext;
という1行で書けるが、アセンブリだと、
mov rbx,[rbx + (pNextのオフセットアドレス)]
という 1命令になって、1クロックに過ぎない。
一方、配列の場合の、++ptr は、
add rbx,(1要素のバイト数)
という1命令で書けて、これも1クロック。

なので、キャッシュミスがない限り、LinkedListも配列と同じ速度で
ノードを辿っていける。

**デフォルトの名無しさん** · 2023/04/30(日) 01:48:48.78

>>754
QuickSortは、LinkedListではとても不利。
ただし、QuickSortと同じ速度のソートを俺は発見している。
なお、俺は数学的な天才だから、あなた達には無理なんだろう。

**デフォルトの名無しさん** · 2023/04/30(日) 01:49:24.07

1クロックw
数学的だねェ

**デフォルトの名無しさん** · 2023/04/30(日) 01:54:42.21

1クロックが何MHzだった時代のお話ですか？

**デフォルトの名無しさん** · 2023/04/30(日) 01:58:54.26

LinkedList指向アーキテクチャを使ってるんだろ

**デフォルトの名無しさん** · 2023/04/30(日) 01:59:20.86

>>778
>キャッシュの乱れは、40回程度。10万要素の内の40回程度、キャッシュ
>ナルティーが生じるだけ。
>それぞれが15クロックほど遅くなるだけだから、10万個の要素を辿っても、
>全体として、600クロックほど、キャッシュ読み込みの時間が追加されるだけ
>のはず。
訂正します。
実際には、AAAABAAACAAADAAA・・・
のようになるので、「行き」はキャッシュミスが生じますが、「帰り」は
キャッシュに載っているものを再度使うだけなので、キャッシュの乱れは
20回程度となり、キャッシュロードに掛かる追加時間は、全体で300クロックで
済むと考えられます。

**デフォルトの名無しさん** · 2023/04/30(日) 02:00:53.22

>>784
LinkedListでも効率の良い新しいソートアルゴリズムを独自に発見してます。

**デフォルトの名無しさん** · 2023/04/30(日) 05:06:03.85

>>786
高速なソートアルゴリズムを新たに発見するとは
天才すぎる
これでLinkedListの逆転勝ちかあ

>>780
1クロックで読み込みできるとは
ハードウェアでも天才すぎる
LinkedListの時代が到来だあ

**デフォルトの名無しさん** · 2023/04/30(日) 07:14:18.58

>>772
貼るんなら極力元ネタにしようぜ字幕でおｋ
https://youtu.be/8T6ClX-y2AE?t=3100

ブートローダはプログラムであって、ライブラリじゃないんだよな
はやくAPIをRust化してほしいそうすれば、C++も恩恵を受ける

**デフォルトの名無しさん** · 2023/04/30(日) 07:28:55.12

AIにコードを書いてもらえないかってのが研究されだして久しいけど、
Rustは(書いてもらうのに)向いてるかもね

Rustは人の仕事を奪うかもよ?ｗ

**デフォルトの名無しさん** · 2023/04/30(日) 09:22:37.96

ただの人を目標にしているから月に行けなくなった

**デフォルトの名無しさん** · 2023/04/30(日) 09:46:01.58

クリックベイトかな？と思ったら速攻で出ていた

>>772-773
>>788

> Microsoft's adoration of Rust does have limits.
> "Rewriting Windows in Rust probably isn't going to happen anytime soon," said Weston,
> "so while we love Rust, we need a strategy that also includes securing more of our native code."

**デフォルトの名無しさん** · 2023/04/30(日) 09:55:02.85

隣へたどる方法比較
https://ideone.com/sVvoxX
p++ 28
v ++it 29
v next(it) 30
l next(it) 151

最初の三つに数字の上では差が付いてるが本質的ではない
書いてる最中にここの数字入れ替わったりしてるので誤差
リストは遅いっちゃあ遅いけど致命的に遅いわけでもない
リストにとっては有利なメモリ配置にはなってると思うけど

**デフォルトの名無しさん** · 2023/04/30(日) 10:14:47.83

中立ぶってリストを擁護する人も、中立やめてリスト推しになるかといえば
ならないだろう
結局、誰も推してないのに誰かが推しているように偽装することを
中立という綺麗事で正当化しているだけだ

**デフォルトの名無しさん** · 2023/04/30(日) 10:19:43.94

>>792
ideoneはコンパイラバージョンが古いしマシンも古いと思う
ただしWS級だからメモリ帯域は大きそう(オンザフライ数が大きい)
vectorならDT級マシンでもHWプリフェッチがうまくやってくれる

p++ 6
v ++it 6
v next(it) 6
l next(it) 241 <- 致命的に遅い、よね？

**デフォルトの名無しさん** · 2023/04/30(日) 10:21:32.29

>>768
偶然ソートの話になってるんじゃなくて誰かが書いたコードが
linkedlistに不利なソートを取り上げてたから荒れてるだけなんだ
原因はその誰かなんだ

上に書かれてるように挿入ソートは実質ランダムアクセスよりlinkedlistに不利になるんだから
そういうのをテーマに選んだ時点でちょっとセンスがないと思う

**デフォルトの名無しさん** · 2023/04/30(日) 10:24:45.00

原因はどうでもいい
因果関係に縛られた機械では人間に勝てない

**デフォルトの名無しさん** · 2023/04/30(日) 10:27:36.27

人間も因果に縛られてるんだから、巨視的にはどっこいどっこいかもよｗ

**デフォルトの名無しさん** · 2023/04/30(日) 10:53:23.23

>>792,794
もう面白くないからやらないけど補足すると、一昨日のlistのscanがイイ感じだったのは
Arena使っているからchunk毎にリニアアクセスだったからなんだ

>>792,794はdefault allocatorで、Cacheから出たらnext(it)ですら遅いよ

**デフォルトの名無しさん** · 2023/04/30(日) 10:56:20.23

bindgenでC/C++のheader変換させると
warning: type `ho_ge` should have an upper camel case name
help: convert the identifier to upper camel case: `HoGe`
みたいな余計な御世話なメッセージが出捲るんだが
これを抑制する方法って無い？

**デフォルトの名無しさん** · 2023/04/30(日) 11:30:23.83

>>794
（´･∀･`）ﾍｰ
これは致命的に遅いね

>>798
勉強になります

**デフォルトの名無しさん** · 2023/04/30(日) 14:46:52.74

.to_string() とか
.to_str() とか
.to_str().expect("やりなおせ") とか
.to_str()? とか
.as_str() とか
一貫性がないな

**デフォルトの名無しさん** · 2023/04/30(日) 14:50:03.03

>>799
抑制する方法もエラーメッセージに出てなかったっけ？

**デフォルトの名無しさん** · 2023/04/30(日) 16:01:15.73

#![allow(non_snake_case)]
#![allow(non_camel_case_types)]
#![allow(non_upper_case_globals)]
で出来たけど
#[allow(non_snake_case)]
#[allow(non_camel_case_types)]
#[allow(non_upper_case_globals)]
にしろって書いてあるサイトもある
どっちなんだろ

**デフォルトの名無しさん** · 2023/04/30(日) 16:11:01.60

2つ以上のC/C++のprojectから
bindings1.rs
bindings2.rs
みたいに造って同時にinclude!()すると
定義の衝突とか出るけど
header1.hとheader2.hのどっちにも
#include <iostream>
みたいなの書いてあるとそうなるんかな
面倒だな