結局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/25(火) 22:09:05.21

563がRcとRefCell使ってるのはgitのバージョン管理ツリーみたいなデータ構造を作りたかったのかな
set_lastで要素を追加するlistの参照に敢えてmutを付けないあたりに強いこだわりを感じる力作

**デフォルトの名無しさん** · 2023/04/25(火) 22:59:52.83

力作でもなんでもなくRcとRefCellの基本にすぎないな
もちろんRcとRefCellを使わずにmutの普通のリンクリストも作れる
一長一短あるので用途に合わせて使い分け

**デフォルトの名無しさん** · 2023/04/26(水) 00:23:36.32

単純にノード単位で共有する感じか
なんか逆方向に枝分かれしながら伸ばしてツリー状のグラフを作るイメージをしてしまった

**デフォルトの名無しさん** · 2023/04/26(水) 01:08:26.72

>>567
めちゃくちゃいい加減なこと言ってんなｗ

**デフォルトの名無しさん** · 2023/04/26(水) 01:10:35.86

>>564
LinkedListを単独で使う前提でVectorと比べればそりゃ大半の用途で遅くなる
そういう使い方は普通しない
CS101で習う内容

**デフォルトの名無しさん** · 2023/04/26(水) 01:21:03.37

LinkedListは要素の挿入や削除が頻繁に行われる用途で使うものだと思うけど
vectorはそんな用途には向いていない

**デフォルトの名無しさん** · 2023/04/26(水) 01:30:48.26

LinkedListでVectorより効率的に挿入や削除を行うためには
どこに挿入するかどの要素を削除するかをピンポイントで事前に把握できてる必要があるよ

**デフォルトの名無しさん** · 2023/04/26(水) 01:45:09.49

RustにもSTLのstd::listみたいなのくらいあるやろ?
自作して何がうれしいのかな?

**デフォルトの名無しさん** · 2023/04/26(水) 01:48:47.01

>>575
意外に思うかもしれないけど
リンクリストは挿入削除の位置までリンクをたどるコストが実は非常に高い
たどった分の個数の読み出しが発生しているためベクター利用でシフト挿入削除の方が速いこともある
理由としては読み出し発生の個数は平均して両者でほぼ同じだがシーケンシャルなベクター利用が速くて勝ち
ベクター利用はそこにシフト書き込みが発生するけど御存知のようにCPUサイクルは読み込みサイクルと比べて書き込みサイクルが超高速

**デフォルトの名無しさん** · 2023/04/26(水) 01:50:34.41

LinkedListを自作するとRustのOwnershipルール/Rerefernceルールや
Rc<RefCell<T>>みたいな頻出パターンを苦労しながら学べる(らしい)
まあ学べてない人もいるけど

**デフォルトの名無しさん** · 2023/04/26(水) 01:53:24.45

>>579
コンパイラとの取っ組み合い用かw くだらねー

**デフォルトの名無しさん** · 2023/04/26(水) 02:12:38.44

>>573
その>>567のアドバイス通り
ブロックを終わらせたらborrow()のロックが解放されて動くようになったよ

if let Some(ref next) = list.0.borrow().next {
set_last(next, value);
return;
}
list.0.borrow_mut().value = value;

結局アドバイス二つ目のborrow_mut()だけを最初から使う方法にしたよ

let mut node = list.0.borrow_mut();
if let Some(ref next) = node.next {
set_last(next, value);
} else {
node.value = value;
}

**デフォルトの名無しさん** · 2023/04/26(水) 02:20:44.73

参照は適当なところで死んでくれるのにRefはそうじゃないのがだるいって言ってんの

**デフォルトの名無しさん** · 2023/04/26(水) 02:37:31.30

そんな事例あるか？
Hoge(ref x) = y と
Hoge(x) = &y は完全に同じだろ
複数マッチングなどrefしか使えないこともあるから参照はrefで受けるのが好ましい

**デフォルトの名無しさん** · 2023/04/26(水) 02:54:29.50

refじゃなくてRefだよ

**デフォルトの名無しさん** · 2023/04/26(水) 03:11:17.63

RefCellが返すRefやRefMutはロックガードの一種
他のロックを使うときと同じ利用方法でOK
一時利用が終わるかブロックを抜ければ自動解放され快適

**デフォルトの名無しさん** · 2023/04/26(水) 03:13:46.65

>>581
いやいやｗ
ロックじゃありませんからｗ

**デフォルトの名無しさん** · 2023/04/26(水) 03:33:09.04

>>566
それはあなたの使い方が間違っているから。
576, 578 の人も同様。
LinkedListでは、場所のラベルとして、index ではなく pointer を使わなければならない。
それを守ればとても高速。

**デフォルトの名無しさん** · 2023/04/26(水) 03:37:05.06

>>586
RefCellはmultiple readers or single writerのロックをして参照や可変参照を借用できる型
RwLockと同じように読み出しは複数可だが書き込みは単独独占となる
同じようにロックガードが消えればロックは自動解放される
ただしRwLockとは異なりスレッド間では使えない

**デフォルトの名無しさん** · 2023/04/26(水) 04:05:00.19

>>587
君の主張には無理があるな
君の主張通り、各ノードへの直接の各ポインタを保持するならば、それらポインタ群リストを格納する場所はどこか？
その格納場所はベクターか別のリンクリストとならざるをえない
君の主張だと二重管理となりさらに遅くなる
現実には>>578の解説のように挿入や削除ですらリンクリストよりベクターが速くなりうる

**デフォルトの名無しさん** · 2023/04/26(水) 05:12:35.92

>>589
全然違います。
特定の要素を覚えるのはアドレス(ポインタ)を番号として用います。
また、そこから隣に移動したい場合は、右隣は、pNextで、左隣は、pPrev
辿っていくことが出来ます。これらはそれぞれ1クロックしかかからないので、
idx++ と同じ速度なので、効率は最高に良いです。
ほとんどの場合、ポインタを覚えるのに別の集合は必要ありません。
もし、必要な場合は、配列の場合でも index を覚えるために別の集合が
必要になるような場合です。
しかし、それは稀です。なので、LinkedListの場合も稀です。

**デフォルトの名無しさん** · 2023/04/26(水) 06:31:44.27

>>590
他の方々はそのような特殊な使い方のみを前提としていない比較だと思いますが、その特殊な場合で比較してみましょう。

前後の要素へポインタを移すために、ptr++とptr--だけで済むのは配列やvectorです。
実際には最大アドレスまたは最小アドレスとの比較も必要ですが、この値もレジスタに持っておくので、比較と増減で2サイクルで済みます。

一方でlinked listの場合、前後の要素へポインタを移すためには、ptr = ptr->nextとptr = ptr->prevそして0との比較になります。
キャシュがヒットしなかったとして、メインメモリから読み出すとすると、100～数百サイクルかかります。
もちろんキャッシュに乗ればマシになりますが、linked listは予想ができません。
このようにポインタの移動だけでも、メモリアクセスが生じるlinked listは非常に不利です。

各要素の内容自体の読み込みは、どちらも同じなりそうですが、少しだけ違ってきます。
vectorならば次々とシーケンシャル読み出しとなり、確実にL1キャッシュに乗りますので、読み出しは4クロック程度で済みます。
linked listはnext/prevを読み出すときに多大なコストを払っているので、内容自体の読み込みはキャッシュに乗ってるでしょう。
しかし、キャッシュに乗ってもnext/prevのサイズ分だけ早くキャッシュから外れるため、やや不利となります。

したがって、前後の要素へのポインタの移動でも、要素の内容読み出しでも、vectorが速くなり、linked listは遅くなります。

**デフォルトの名無しさん** · 2023/04/26(水) 08:16:17.35

またその話...
状況次第なので
二人ともLinkedHashMapの場合で持論を展開してください

**デフォルトの名無しさん** · 2023/04/26(水) 08:21:46.43

なんでも測ってみないとダメってばーちゃんが言ってた
勉強になるからいいけどｗ

**デフォルトの名無しさん** · 2023/04/26(水) 09:51:14.24

コンパイラ通せば終わり（キリッ）っていうバカを助長させてるだけだな。

**デフォルトの名無しさん** · 2023/04/26(水) 11:35:48.60

自己紹介乙

**デフォルトの名無しさん** · 2023/04/26(水) 12:00:07.23

>>576
使い方次第では？
頭から順番にイテレートさせて条件にマッチした場合に不要要素削除や追加する場合は普通に便利だろ？
君がそういう用途を思い浮かべられないんだろ？

**デフォルトの名無しさん** · 2023/04/26(水) 12:25:39.79

>>594
バッドノウハウが溜まればどのみちコーティング規約とlintが必要になる。

**デフォルトの名無しさん** · 2023/04/26(水) 12:41:46.92

>>596
自分も昔はそう思い込んでた
しかし現実のほとんどの用途はvectorでまとめて処理するのが速いと分かった

**デフォルトの名無しさん** · 2023/04/26(水) 13:29:30.45

LinkedListはリストの先頭とか要素自身のインデクスを知らなくても前後に要素を差し込んだり自身を削除したりできるから
サイズが不定だったり大きかったりする要素を数珠つなぎにする場合に使える
Linuxカーネルのページ管理でそういうことしてたと思う（今現在は知らないけど）
小さい要素を大量に保持するなら挿入、削除があってもキャッシュしやすいvectorが強そう

**デフォルトの名無しさん** · 2023/04/26(水) 16:36:01.06

>>591
嘘か書かないで。

**デフォルトの名無しさん** · 2023/04/26(水) 16:37:03.22

591の人はイマジネーションが不足している。

**デフォルトの名無しさん** · 2023/04/26(水) 16:37:48.41

591の人を始め、ここの人には、図を書いて考えてみることをお勧めします。

**デフォルトの名無しさん** · 2023/04/26(水) 16:47:25.16

小学校の算数かよ

ごめん俺、小学校の算数躓いた勢だったわｗｗ
ちょっと算数系の学習障害はいってるんかもしれん

**デフォルトの名無しさん** · 2023/04/26(水) 16:48:15.43

月面着陸船が落っこちたそうだが
Rustで書いてれば成功したはず
それにしてもローバーは活躍出来ず流産乙

**デフォルトの名無しさん** · 2023/04/26(水) 17:01:55.60

>Rustで書いてれば成功したはず
↑この発想がそのまま↓なんだと言う自覚ゼロ
>コンパイラ通せば終わり（キリッ）っていうバカ

**デフォルトの名無しさん** · 2023/04/26(水) 17:17:57.85

>>600
嘘書かないで

**デフォルトの名無しさん** · 2023/04/26(水) 18:28:24.85

>>600
どこの場でも同じだけど
正しい指摘ができずに
嘘！違う！とだけ言い出したら
その人は負けなんですよ
>>591に書かれていること自体は正しいと思いますよ

**デフォルトの名無しさん** · 2023/04/26(水) 18:39:00.36

>>607
最後、頭の良さが無い人に教えることは不可能。キリが無いから。

**デフォルトの名無しさん** · 2023/04/26(水) 18:42:01.34

言葉ではなく、脳内に画像的なイメージを描かないと駄目ですよ。
全然それが出来てない。

**デフォルトの名無しさん** · 2023/04/26(水) 19:01:03.33

この人はvector内にガチのclassやstruct入れてるんだな

**デフォルトの名無しさん** · 2023/04/26(水) 19:04:57.37

>>596
便利だと思うのは自由だけど
頭から順番にイテレートしてから挿入・削除するような使い方だと
Cache Localityの違いによってVectorより性能が劣る

性能が重要ならLinkedListは挿入・削除時にイテレートが必要ないようにして使う
HashMapとLinkedListを組み合わせたLRUキャッシュとかね

**デフォルトの名無しさん** · 2023/04/26(水) 19:11:34.98

>>611
ヒープに要素があってvectorがキャッシュされない状態だと要素のメンバーの条件によって削除挿入するなら
vectorの方が不利だよね？
それは理解出来る？

**デフォルトの名無しさん** · 2023/04/26(水) 19:12:21.18

vectorが　は間違えて入ってる

**デフォルトの名無しさん** · 2023/04/26(水) 19:38:13.57

>>612
メモリキャッシュ自体はヒープもスタックも関係ないが
もちろんスタック上は常にキャッシュに載るから
上限値が決まっているならば全てスタック上に載せたほうが有利
ヒープは確保と解放のコストもかかるから大きく不利

そのためベクター型でもスタックを利用するものを使うとさらに速くなる
例えばRustはスタックをなるべく多用するために3種類のベクター型が使い分けられている
(1) ArrayVec は上限値を定めてスタックのみを使うベクター型
(2) SmallVec は上限値を定めてその範囲内ならスタックのみを使って超えたらヒープを使うベクター型
(3) Vec はヒープを使うベクター型
それぞれコストとわずかに特性が異なる

**デフォルトの名無しさん** · 2023/04/26(水) 20:22:03.82

https://ideone.com/hqXsfu
シャッフルされた数列を昇順にinsertした
{
std::vector<int> xs;
auto b = std::chrono::system_clock::now();
std::for_each(v.begin(), v.end(), [&xs](int x) {
auto pos = std::find_if(xs.begin(), xs.end(), [x](int y) { return x < y;});
xs.insert(pos, x);
});
auto e = std::chrono::system_clock::now();
std::cout << std::chrono::duration_cast<std::chrono::milliseconds>(e - b).count() << std::endl;
}
{
std::list<int> xs;
auto b = std::chrono::system_clock::now();
std::for_each(v.begin(), v.end(), [&xs](int x) {
auto pos = std::find_if(xs.begin(), xs.end(), [x](int y) { return x < y;});
xs.insert(pos, x);
});
auto e = std::chrono::system_clock::now();
std::cout << std::chrono::duration_cast<std::chrono::milliseconds>(e - b).count() << std::endl;
}

**デフォルトの名無しさん** · 2023/04/26(水) 20:41:37.78

>>614
イメージが違うな
シーケンシャルに要素が詰まってるんじゃなくてヒープに乱雑に詰まってる大きめの要素だとキャッシュに乗りにくいだろ
vectorはそのインデックス

**デフォルトの名無しさん** · 2023/04/26(水) 20:45:35.28

要素としてintが並んでるだけの実際にはないようなパターンの話をされても困るだろ
何らかのオブジェクトが大量にヒープのあちこちに詰まっててvaetorはそのポインタが入ってる

**デフォルトの名無しさん** · 2023/04/26(水) 20:47:03.66

前にrustスレをずっと荒らしてたおじいさんなのかな？

**デフォルトの名無しさん** · 2023/04/26(水) 20:51:22.56

>>616
大きなデータだとそういう二段階データ構造にする場合もあるというだけだろう
例えばソートは実体を移動させるよりもインデックスだけ移動させる新たなベクターを設ける
しかしその元の実体もベクターに格納したほうが有利なことが多い
ヒープに乱雑に格納するケースはかなり限られてくる

**デフォルトの名無しさん** · 2023/04/26(水) 20:56:32.56

>>615
実測いいね
リンクリストが遅い結果になるのは予想できたけど
ベクターの方が10倍以上も速いとは驚いた

**デフォルトの名無しさん** · 2023/04/26(水) 20:57:54.91

限られてはいないだろ
インサート、デリートを乱雑に繰り返して格納するケースだらけだろ

普通に要素数が分からないし、生成時期も分からないものを突っ込むことが多いんだから

**デフォルトの名無しさん** · 2023/04/26(水) 20:59:39.02

横から
>>610
何か問題でも?

**デフォルトの名無しさん** · 2023/04/26(水) 21:01:40.35

アプリ作ったことないの？

**デフォルトの名無しさん** · 2023/04/26(水) 21:01:40.98

>>621
vectorの方がインサートも速い
比較計測>>615の結果を見ろ

**デフォルトの名無しさん** · 2023/04/26(水) 21:02:25.41

>>624
intのvector比べて何になるんだよ

**デフォルトの名無しさん** · 2023/04/26(水) 21:03:19.22

intじゃなくて256byteぐらいのデータでやってみると逆転したり

**デフォルトの名無しさん** · 2023/04/26(水) 21:06:10.27

マンデルブロ画像の描画が速いと言ってるのと変わらない無意味な比較

**デフォルトの名無しさん** · 2023/04/26(水) 21:08:39.08

とても大きなデータならば
もう一つインデックス用vectorを用意すればよい
vectorのインサートは速いままだ

**デフォルトの名無しさん** · 2023/04/26(水) 21:32:20.97

>>615
リンクリストが唯一勝てそうなinsertまで敗北かよ
知らんかったわ
リンクリストの負けが確定だな

**デフォルトの名無しさん** · 2023/04/26(水) 21:39:12.36

データ構造の操作に限ればキャッシュにのるかのらんかで全然違うよな
まあ、リストでもスタック内で作ればいつものるけどね

**デフォルトの名無しさん** · 2023/04/26(水) 21:40:47.62

チョコチョコやっててもキリがないけどとりあえず少しだけ…
これ以上グズグズやってもうざいやろからこれで最後ね

>>626
> intじゃなくて256byteぐらいのデータでやってみると逆転したり
https://ideone.com/8p2nq0
struct foo {
int value, a[(256 / 4) - 1];
foo(int value) : value(value) {}
};
352　←ベクタ
296　←リスト
ちな128bytesだとまだベクタが速かった

>>617
> 何らかのオブジェクトが大量にヒープのあちこちに詰まっててvaetorはそのポインタが入ってる
https://ideone.com/8bwMkQ
上記の生ポインタ版。
53　←ベクタ
245　←リスト

**デフォルトの名無しさん** · 2023/04/26(水) 21:42:50.60

このスレを　リンクリストで抽出してレスしてる人を見ると1人を除いて多分ほぼ同じ人だと思うわ

**デフォルトの名無しさん** · 2023/04/26(水) 21:43:32.25

部分列が外から捕捉される場合があって、その場合はメインのリストから取り除かれて以降も長生きして欲しくて、それでRcRefCell使ってるという事情があるんだがなあ
そもそも目的は高速な反復処理じゃなくて状態の管理だし
>>581とかも勝手に途中のノードまでborrow_mut()して平気な顔してるし

まあそういう可能性を考えられない人は単純な構図にして勝ちを取るのに必死なんですね
ご自分の制作物にその知恵が生きるといいですね

**デフォルトの名無しさん** · 2023/04/26(水) 21:49:09.99

>>630
どちらもヒープで比較してるからスタックか否かは関係ない
linked listは本質的に遅い

**デフォルトの名無しさん** · 2023/04/26(水) 21:58:07.18

moveコンストラクタが働けばサイズ関係ないのでは?

**デフォルトの名無しさん** · 2023/04/26(水) 22:02:01.47

>>631
よく見たらコードへんじゃない？
linkedlistが不利になるだろそれｗ

**デフォルトの名無しさん** · 2023/04/26(水) 22:13:00.95

前提条件や用途を限定せずに性能議論しても無駄ではある
超長い配列に挿入したり探索したりが同時に発生する場合や
挿入順序維持して末尾に追加したいだけの場合はlinkedlist

**デフォルトの名無しさん** · 2023/04/26(水) 22:16:05.39

これで収束かな
おじいさん沈黙したから

**デフォルトの名無しさん** · 2023/04/26(水) 22:18:45.74

>>634
ベクタだとまとまってるからヒープでもキャッシュにのりやすくね？

**デフォルトの名無しさん** · 2023/04/26(水) 22:36:48.98

>>637
> 挿入順序維持して末尾に追加したいだけの場合はlinkedlist
https://ideone.com/6plvA3
172　←ベクタ(push_back(foo(i)))
107　←リスト(push_back(foo(i)))
74　←ベクタ(reserve(n), push_back(foo(i)))
64　←ベクタ(reserve(n), emplace_back(i))
105　←リスト(emplace_back(i))

こんな実測チマチマしてっても意味ないのは同意なのでもう寝ます
性能は状況状況に応じて各自が把握してたら十分と思います

**デフォルトの名無しさん** · 2023/04/26(水) 22:41:35.56

>>640
さっきのバグレベルのlinkedlistのコードは修正しないで寝るのか
残念

**デフォルトの名無しさん** · 2023/04/26(水) 22:46:15.95

のんびりまったりやれよ
Rust勢はめんどくさい、とか言われたいかｗ

C++は、テスト通りゃいいんだよまであるぜ
いろいろと自由だからねはよunsafe来いｗ

**デフォルトの名無しさん** · 2023/04/26(水) 22:55:15.76

>>636
あなたは間違ってるとか嘘とか言うだけで反論として正しいコードや正しい説明を出せたことがありません
そんなことをしていてはまわりから信頼を失いますよ

**デフォルトの名無しさん** · 2023/04/26(水) 23:11:23.22

順序維持の追加だけだと>>640のようにベクタもリストもイーブン
しかし追加するだけで終わるわけはなくそれを使うことになる
そうなると結局ベクタが有利

特定の使い方で両端から取り出して使うだけならリストが有利でないか？との疑問はあるだろう
しかしその場合もリストではなく両端キュー(double-ended queue)つまりC++ではstd::dequeueを使う
その内部実装は配列やベクタを利用となっている

**デフォルトの名無しさん** · 2023/04/26(水) 23:17:21.42

>>643
誰と勘違いしてるのか知らないけど俺は一度も嘘とか言ってないよ

コード見ればわかるけどlist使ってるほうは条件にあった場所で挿入しなくて
また無駄に頭から挿入位置までiterしてるように見えるでしょ？

おじいさんはコードも読めない

**デフォルトの名無しさん** · 2023/04/26(水) 23:39:33.42

>>633
borrowもborrow_mutもコストは同じだが二度のコストは避けたほうがいいんじゃないか
RefCellはスレッド内部専用だから並行して他のコードがborrowを試みるとこもないしあってはいけない
だからそこはborrow_mutのみで済ませてよい

**デフォルトの名無しさん** · 2023/04/26(水) 23:59:51.46

>>646
呼び出し元がずっとRef掴んでたら死ぬが

**デフォルトの名無しさん** · 2023/04/27(木) 00:07:20.74

>>647
つかまない実現コードがあれば教えて

**デフォルトの名無しさん** · 2023/04/27(木) 00:16:45.43

他人のことは初心者呼ばわりしておいて自分の見落としも初心者レベルじゃん
誰とは言わんがさすが

**デフォルトの名無しさん** · 2023/04/27(木) 00:29:02.36

>>647
Refはロックガードにすぎない
ブロックスコープを抜ければ自動解放
掴んだままになることはない

**デフォルトの名無しさん** · 2023/04/27(木) 05:33:00.85

>>647
関数から返すようなことさえしなければ、関数呼び出しが終わるとつかみ続けることはできず、解除される
RAIIを勉強しなさい

**デフォルトの名無しさん** · 2023/04/27(木) 06:57:25.28

>>645
vectorもlistもその部分は同じコードだぜ

**デフォルトの名無しさん** · 2023/04/27(木) 08:53:10.05

>>640
(cacheにヒットするかとは別に)cold memoryと言う状態があってbenchmarkの場合は気を付けてください

一応今回のコードでは影響はないと思われます
https://ideone.com/lP1xkO
vector::push_back: 192
256
list::push_back: 113
vector::push_back: 194
reserve, vector::push_back: 81
reserve, vector::emplace_back: 63
list::emplace_back: 111

**デフォルトの名無しさん** · 2023/04/27(木) 10:17:01.26

>>653
手元でやったらvectorの完勝だった(clang-O3)
それとRamMapのあと何回か試すとcold memory?の影響も出たする

list::emplace_back: 101
vector::push_back: 74
256
list::push_back: 102
vector::push_back: 57
reserve, vector::push_back: 15
reserve, vector::emplace_back: 15
list::emplace_back: 97

**デフォルトの名無しさん** · 2023/04/27(木) 11:18:48.87

int value, a[(256 / 4) - 1];
この配列aはcopyもmoveもないので計測には意味がないのでは?

**デフォルトの名無しさん** · 2023/04/27(木) 11:58:43.55

ランダムアクセスの性能が重要な状況で
頭からリニアにアクセスする時点で終わってる

**デフォルトの名無しさん** · 2023/04/27(木) 11:59:27.22

敢えてdefaultを明示しても特段の変化ないけど、違う話？
foo& operator= ( const foo & ) = default;
foo ( foo&& other) noexcept{
*this = other;
}

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

vectorはcapacityが不十分なときにfooのcopy（move）を呼ぶ
fooのデフォルトのcopyもmoveも
aの要素をcopyもmoveもしないので
fooのメンバーにaがある意味がない

**デフォルトの名無しさん** · 2023/04/27(木) 12:33:19.96

>>658
C++に不慣れなRust使いさんですか？

fooもgooもmemcpyされてる
https://godbolt.org/z/xMxesqcss

>aの要素をcopyもmoveもしないので
これのソースは？

**デフォルトの名無しさん** · 2023/04/27(木) 13:29:59.90

>>659
あれ!? すまん
今の今までメンバーの配列は
デフォルトでcopyもmoveもしないのかと思ってた

**デフォルトの名無しさん** · 2023/04/27(木) 13:51:50.04

>>543
>>545
コンパイルしてみないとどれだけ容量食うか判らないのは可笑しいな
コンパイル前に今のcrates全部で3GB食うからそれ以上空けてないと
コンパイル開始しないで警告するようなオプション無いかな

**デフォルトの名無しさん** · 2023/04/27(木) 14:41:22.34

ポインタをちゃんと理解出来て無い人が、誤った使い方でLinkedListの性能
が悪いと思い込んでいるに一票。

**デフォルトの名無しさん** · 2023/04/27(木) 15:20:28.37

その件は、リニアでもランダムでも個別要素に総なめアクセスするだけの問題→vector+reserveサイズで悩むだけだな

それ以外の状況は千差万別だけど、データ構造を再発明してもしょうがない、知識をつけないとね
>>599みたいな状況→LRUCache→>>592のLinkedHashMap(listと配列のハイブリッド)みたいに

**デフォルトの名無しさん** · 2023/04/27(木) 16:24:47.29

>個別要素に総なめアクセスするだけの問題
なら、Arena方式がOKの場合としてstd::pmr::monotonic_buffer_resourceを使ってみた

vector::push_back: 53
256
vector::push_back: 52
reserve, vector::push_back: 15
reserve, vector::emplace_back: 15
list::push_back: 96
list::emplace_back: 94
list<foo,Arena>::push_back: 22
list<foo,Arena>::emplace_back: 22

**デフォルトの名無しさん** · 2023/04/27(木) 18:52:14.07

>vector+reserveサイズで悩む
見積を間違うとかえって遅くなるんだ(なんで?)
list+Arenaは使いどころがあるかもね

vector::push_back: 58
reserve, vector::push_back: 17 *
reserve, vector::emplace_back: 15 *
80% reserve, vector::push_back: 43 x
80% reserve, vector::emplace_back: 44 x
50% reserve, vector::push_back: 32
50% reserve, vector::emplace_back: 34
20% reserve, vector::push_back: 66 xx
20% reserve, vector::emplace_back: 66 xx
vector<foo,Arena>::push_back: 58
vector<foo,Arena>::emplace_back: 60
list::push_back: 94
list::emplace_back: 95
list<foo,Arena>::push_back: 22 *
list<foo,Arena>::emplace_back: 22 *

**デフォルトの名無しさん** · 2023/04/27(木) 19:26:23.25

個人的には思ってたより面白い展開だけど
Rustで手を動かして晒す人が出てくるまで
C++側は控えても良いんじゃないかな？

でないと>>604みたいなのが増えるだけや

**デフォルトの名無しさん** · 2023/04/27(木) 19:41:41.02

>>662
逆やろｗ
ポインタも知らず実測したこともない子が
listに対して過剰に期待寄せてるだけで
実際C++書いてるやつならもっと冷静よ

**デフォルトの名無しさん** · 2023/04/27(木) 22:08:12.11

データ構造の性能比べはスレ違いだからそろそろやめねえか

**デフォルトの名無しさん** · 2023/04/27(木) 22:18:15.37

データ追加の計測をしてるようだけど
実際にはその後にそれらデータを使うため
listは各ポインタをたどるところで不利になってしまう

vectorはreserve無しだと再配置コストがかかるけど
最大個数Mのときに再配置コスト累計はM～2Mで固定
使えば使うほど誤差になっていくので
パフォーマンスを気になるような使い方なら無視してよいかと

**デフォルトの名無しさん** · 2023/04/28(金) 00:29:13.98

ここの人達が馬鹿なのは、LinkedListだけ本来の使い方が出来てないこと。
ポインタの使い方が根本的に理解できてないことが分かる。