結局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/24(月) 14:44:47.56

C++とRustのコード相互呼び出しはこんな風に自動化されてる
https://cxx.rs/
https://i.imgur.com/ffKzJ3n.png

**デフォルトの名無しさん** · 2023/04/24(月) 14:53:54.93

Rustは余り普及しないのでは。

**デフォルトの名無しさん** · 2023/04/24(月) 14:59:09.48

>>498
おまえバカだろ
CPUの例外とC++の例外からして仕組みもレイヤも全く異なる

**デフォルトの名無しさん** · 2023/04/24(月) 15:09:12.38

おいおい馬鹿はお前w

レイヤが異なろうがどんなに泥臭かろうがシステム言語の宿命
Rustはシステムプログラミングの何たるかを言語設計の初期段階で考慮していない
CPU例外(≒非同期例外)を構造的にキャッチ出来ない出来損ないシステム言語w

**デフォルトの名無しさん** · 2023/04/24(月) 15:28:07.95

>>502
RustはCPU例外も割り込みも扱えます
Rustは組み込み用途やOS作成などシステムプログラミングにも使えるように設計されています
Rust(やGoなどの言語)がエラーハンドリングの例外機構を非効率なものとして排除していることとは全く無関係です

**デフォルトの名無しさん** · 2023/04/24(月) 15:31:17.42

Rustは設計段階ではシステム言語のつもりじゃなかったのでは？
言語構文で非同期例外を扱えないのは野暮ったいし

**デフォルトの名無しさん** · 2023/04/24(月) 15:40:24.08

>>503 RustはCPU例外も割り込みも扱えます... エラーハンドリングの例外機構を非効率なもの
まあPythonですら扱えます、と言うだろうし、非効率ってw？
なんか色々と498が意味するところの理解が追いつかないようだね
講釈するつもりはないから自分で調べてね

**デフォルトの名無しさん** · 2023/04/24(月) 16:01:06.96

C++の例外は実は途中の関数の各スタックフレームを全て処理してから実行されるため非常に遅い
なぜそうしているかというと途中の各関数で全てデストラクタ処理をしないと正しい継続動作ができないため
結果的に例外といっても各関数で早期リターンするのと同じだけの各処理を行なっている
そして各関数で例外が下からやってくることに備えて対処するコードが余分に必要となっている
そのため例外で返すと速く処理されそうなイメージとは真逆で現実のC++の例外は遅く非効率なものとなっている

**デフォルトの名無しさん** · 2023/04/24(月) 16:08:44.38

まあ初めはシステム言語のつもりはなかっただろうな。
ガベコレのパフォーマンスへの影響が気に入らないけどC++のメモリ管理におけるエラーはきつい
てのがRustの動機だろうし。

**デフォルトの名無しさん** · 2023/04/24(月) 16:09:33.04

そこんとこは、たまに、吐き出されてるバイナリを確認する習慣がほしいとこだね

**デフォルトの名無しさん** · 2023/04/24(月) 16:17:07.56

途中(503,506)から手抜きしてChatGPT的な文が続いているからディフェンスラインは諦めてると思う

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

>>506
GC言語ならデストラクタを呼ばなくていいから速い例外を作れるけど、
C++は飛ばす部分で必要なデストラクタを漏れなく呼び出す必要があるのか。
C++の例外重すぎだろ。

**デフォルトの名無しさん** · 2023/04/24(月) 16:31:03.25

>>506
設計思想的には、C++の例外機構は、エラーなどの
「例外的に起きる(=滅多に起きない、レアケース)」
の場合のためのものなので、「例外が起きた時」の速度はほとんど考慮
されていない。ただし、誤解無きように捕捉しておくと
「例外が起きなかった時」のコストは配慮されている。

**デフォルトの名無しさん** · 2023/04/24(月) 16:32:38.06

>>510
えぇっと、Rustはdrop漏らしちゃうの？

**デフォルトの名無しさん** · 2023/04/24(月) 16:32:44.46

設計思想としては、C++の例外機構は関数からの戻り値を返す目的には設計されてない。
なので、その目的でも使おうと思えば使えるが、速度面の配慮がされてない。

**デフォルトの名無しさん** · 2023/04/24(月) 16:44:40.41

あまり詳しくないけどバイナリ出力はLLVMの守備範囲だと思うから
LLVMが対応しないシステムはRustも対象外ってことでいいんだよね

>>510
GC言語でも必要な時はちゃんとfinallyでdisposeすることをお勧めします

**デフォルトの名無しさん** · 2023/04/24(月) 16:45:19.17

>>513
簡潔に言えば、C++の例外機構は、エラー発生時のためのもので
アプリの正常走行時には一度も利用されない設計思想になっている。

**デフォルトの名無しさん** · 2023/04/24(月) 16:50:59.79

>>512
Rustにtry throw catchの例外はないのでその話はRustに無関係
代わりにResult返しと？オペレータになって普通にdrop処理もされる
C++のような例外対処コードの付加は必要ない
途中関数で必要に応じて自動エラー型変換も可能だからC++より便利

**デフォルトの名無しさん** · 2023/04/24(月) 16:59:10.31

>>516
Rustは非同期例外が発生しない謎保証をしてるの？
まさかdrop漏らしちゃうの？システム言語失格だよ？

**デフォルトの名無しさん** · 2023/04/24(月) 17:05:38.54

>>515
その正常走行時の意味合いがプログラミング言語によっても変わるし分野によっても変わる
つまりエラー時の意味合いがバラバラで役立たない

例えば指定ファイル複数が一つも存在してなかったら作成して見つかれば内容を返すとしよう
あるファイルが一つ存在しなくても正常走行だが存在しないと例外を出す文化もある
指定ファイル複数全て見つからなくても作成する正常走行だが例外を出す設計する人もいる
エラーとか異常とかの意味するところが色んな人で違ってる

結果としてC++でも例外を使いまくる関数やライブラリがあったり
全てをエラー値として返すライブラリもあったりする
そしてC++の例外は負荷コストがかかる
Googleのように例外使用禁止ルールを設けているところも多い

**デフォルトの名無しさん** · 2023/04/24(月) 17:16:16.97

>>517
Rustならばasync関数からの返り値もResultとなり異常時も受け取れる
Rustは付加コストのかかるtry例外機構を必要としない

**デフォルトの名無しさん** · 2023/04/24(月) 17:25:55.51

0点、ChatGPT？

そりゃRustはシステムプログラミング言語って標榜するしかこの先生きのこることが
出来ないと考えてるのなら必死ですよね

**デフォルトの名無しさん** · 2023/04/24(月) 17:28:30.42

C++は例外対応をオプションでOFFにできるおなじように、safe/unsafeもできるようにはやくなってくれ

**デフォルトの名無しさん** · 2023/04/24(月) 18:06:06.65

>>506
ローカル変数のデストラクタを呼び出すこと自体はC++で例外投げてもRustでErr返しても同じなので
そこは別にRustのアドバンテージではない

その調子でC++の勘違い名言集の量産お願いしますよ

**デフォルトの名無しさん** · 2023/04/24(月) 18:08:15.36

>>519
C++は非同期呼び出しでも例外を投げたり受けたりできるけど、
ライブラリが一旦catchして、値として渡して、再びthrowするからコストは非常に高いな。

**デフォルトの名無しさん** · 2023/04/24(月) 18:13:22.35

>>522
C++の例外がコスト高いと言われているのは、デストラクターを呼び出すこと自体ではなくて、
例外が関数を通過するときに適切にデストラクターを呼び出せるように、そのテーブルやコードを用意することだと記憶してるが。

**デフォルトの名無しさん** · 2023/04/24(月) 18:14:58.99

>>524
そりゃそうだろう。
デストラクタ自体は、Rustでも意味的に似たようなものを呼び出す必要があるわけだから。

**デフォルトの名無しさん** · 2023/04/24(月) 18:15:34.58

>>502以降の流れの非同期例外ってたぶんasync/awaitじゃなくて割り込みやシグナルのことだと思うんですけども……

**デフォルトの名無しさん** · 2023/04/24(月) 18:19:00.14

あと、勘違いしてる人がいるかもしれないので念のため言っておくと、
C++のデストラクタは関数の一種に過ぎないので、デストラクタの呼び出しは、
本質的に関数 call と同じものである。そして、C/C++ の関数 call は
比較的高速であり、簡単な場合であれば数クロックで呼び出せる。
なので、本質的にデストラクタの呼び出しコストは、ほとんど 0 に近くて、
本質的にはデストラクタの中身で処理時間が決まる。

**デフォルトの名無しさん** · 2023/04/24(月) 18:31:14.27

>>523
もちろん非同期で例外を使ったら大きく負け
同期でも自分で例外を投げたら負け
余分な見えないコードなどのコストがかかるだけでなく
例外自体の有無が把握しづらくドキュメントとコードのレビューコストがかかる
下から例外が来るのかどうか把握
それら例外を上へもらしてないか把握
必ずエラー値で返すコード規約にして見える化してるところは賢い

**デフォルトの名無しさん** · 2023/04/24(月) 18:33:19.55

ところで、
Rust で Vec に要素を追加した場合にメモリー不足になったかどうかを検出
するのはどうしたらよいんでしたっけ？

**デフォルトの名無しさん** · 2023/04/24(月) 18:41:55.56

C++との比較に関係しない質問はこっちで受け付けます
https://mevius.5ch.net/test/read.cgi/tech/1514107621/

**デフォルトの名無しさん** · 2023/04/24(月) 18:45:07.77

すげーのびてるけど中身のあるレスが一つとしてなかった
さすが隔離スレ

**デフォルトの名無しさん** · 2023/04/24(月) 18:57:04.81

>>526
割り込みやシグナルは例外とは別物

割り込みハンドラやシグナルハンドラが発生したその場で小さい処理でデータを得るか何もせずにフラグを立てる
プログラム本体には影響を与えない
そしてそのフラグなどのチェックはハンドラとは別にプログラム本体のどこかで任意の形で任意のタイミングで自由にチェックする
そこで例外を投げるか否かも自由であり直接関係はない

例外はプログラム本体やライブラリやOSなどが投げる
するとキャッチとの間の関数すべてが飛んでプログラム本体は影響を受ける

**デフォルトの名無しさん** · 2023/04/24(月) 19:27:10.65

>>531
ねーよ

雑スレだぞ、中身なんかないｗ

**デフォルトの名無しさん** · 2023/04/24(月) 19:36:13.19

言語の機能だけが重要ではない
エコシステムとコミュニティが同じくらい大事なんだよ

**デフォルトの名無しさん** · 2023/04/24(月) 22:48:09.25

>>526
そのRust叩きをしている彼がデタラメを言ってる
C++の例外は同期例外なので仮に彼の主張が正しいならばC++もアウトになる

C++の例外は呼び出した関数の中でthrowが投げられてその呼び出し側でのみcatchできる同期例外
関数呼び出しが深くなっても全て同期となる時のみC++は例外をサポートしている
スレッド間など非同期となるときはC++は例外を投げられないのでcatchしてデータとして渡して再びthrowするしかない

**デフォルトの名無しさん** · 2023/04/24(月) 22:51:49.29

つづき
そしてC++のような同期例外は例外を廃止することも可能
例外を値として関数からのリターン値の一つにすることで例外を無くせる
これを実際に行なっている言語がGoやRustであって例外を廃止してエラー値の一つとして返している
C++でも自主的に同じことが可能であってコーディング規則により例外を返すことを禁じているところもある
例外を使うべきでない理由が複数あるためだ

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

でも、どちらも一長一短があり、好みの差が出て来そうだ。

**デフォルトの名無しさん** · 2023/04/25(火) 07:01:02.99

C++で例外を使うデメリット
・値返しの時よりもコードサイズが増える
・値返しの時よりも実行速度が遅くなる
・どちらもRAIIに基づく自動デストラクタは通過関数で呼ばれるが、それ以外で何かしてると例外時にメモリリークする
・各通過関数で例外が通過するのかどうかがわからず、関連する全てのコードを追う必要があり保守性が悪い
・例外を誰もcatchしない処理忘れが起きやすい
など多数

**デフォルトの名無しさん** · 2023/04/25(火) 07:42:43.52

複おじ頻出単語「デタラメ」

**デフォルトの名無しさん** · 2023/04/25(火) 08:52:43.77

C++の例外の利用を禁止しているプロジェクトも多いし
C++の例外は要らない子

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

Nim 派の漏れだが
おまいらが執拗に Rust 薦めるから
使っても居ないのに批判はするべきでないと思って
Rust 使って観たがやはり君らの言う通り面倒な言語だ
C/C++ に対するメリットが面倒さを上回っていない
Nim に戻るわ

**デフォルトの名無しさん** · 2023/04/25(火) 09:35:36.87

面倒と言ってるのは使いこなせていないダメな連中ばかりな点が面白い
どの言語でも使いこなせるようになった時点同士で比較しないと意味がない
Rustは少なくともC++よりは開発効率も保守性も良く手間も時間も節約になる

**デフォルトの名無しさん** · 2023/04/25(火) 09:36:03.71

>>529
cargo で build 中に HDD 容量不足になっても可笑しな動きするぞω

**デフォルトの名無しさん** · 2023/04/25(火) 09:49:25.88

>>542
うん
だから C/C++ を批判して Rust 推してる連中も
C/C++ を使いこなせてないんだということも同時に悟った
ホントありがとう

**デフォルトの名無しさん** · 2023/04/25(火) 09:58:33.05

ストレージは事前に確保しとけよw

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

C++はコンパイル時点でエラーを出してくれない事項が多くて、言語仕様により静的解析ツールでも限界があるため、コードレビューを増やして、さらに実行して動的解析やデバッグツールと、手間暇かかってたことが、Rustでコンパイル通すだけで済むようになったのがうれしいです

**デフォルトの名無しさん** · 2023/04/25(火) 10:08:12.19

良くも悪くもRustはそれなりに受け入れられるだろうね。
ここ数年の流れはJavaの出だしの頃に非常に似ている。
Rust認定試験全盛になり、Rust採用枠が雨後のタケノコの如く大量に出来て、
Rustリプレースの経済的嵐が来るね。

そしてやがてはJavaやPHPやVBみたいにドカタ言語だと罵られる。
最期は銀行のシステムにも使われて不祥事起こすニュースまで見える。

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

5年先をいってるアメリカの状況を見てくるといいよ

**デフォルトの名無しさん** · 2023/04/25(火) 10:57:04.79

俺もRustに手を出したばかりの頃は
難しい、面倒だ、ウザい、と思っていた時期もあったよ
しかしそれは単にまだ無知で慣れていなくて色んなやり方を知らない超初心者なだけだったな
だから、難しい、面倒だ、ウザい、と書き込みしてる人のアドバイスは全く役に立たないよ

**デフォルトの名無しさん** · 2023/04/25(火) 11:00:14.12

なんか
・良い物は自分らで書く
・クソどうでもいい物は他人に書かせる
という前提で話を進めている人がいる気がする

標準ライブラリで書け勢というのも他人に書かせた物を利用しない勢だよな

**デフォルトの名無しさん** · 2023/04/25(火) 11:10:21.23

標準ライブラリで書けってのはあれかい、やたらunsafeで書くなってやつかい(ひっかきまわし

**デフォルトの名無しさん** · 2023/04/25(火) 11:16:45.20

真面目にRust使ってる人はrustcにマウント取られるので忙しいのです
ここでrustcの真似っこしてC++erにマウント取ってる人は、rustcにマウント取られたまま逃げて停滞している人なのです

**デフォルトの名無しさん** · 2023/04/25(火) 12:09:33.28

>>549
お前は超初心者なのでは？

**デフォルトの名無しさん** · 2023/04/25(火) 12:28:20.73

Rustのshared XOR mutableがウザくないというのは信じられん。
厳密性の観点から重要というのは理解できるが。

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

>>550
どゆこと？

**デフォルトの名無しさん** · 2023/04/25(火) 13:56:36.59

>>554
安全に書くのってこんなにウザかったんだと実感する

**デフォルトの名無しさん** · 2023/04/25(火) 16:23:28.59

https://www.youtube.com/watch?v=2uquJXO4scY#t=9m5s
まあ良い事も言ってるが
無駄な達成感で自己満の感じもする

**デフォルトの名無しさん** · 2023/04/25(火) 17:27:39.88

めんどくさい感が楽しいのは、C++で十分なんだよなあ (といいつつ、この点は互角

**デフォルトの名無しさん** · 2023/04/25(火) 17:40:59.19

lifetimeや所有権はうざいくらい
しつこく警告してコンパイル通さないのに
unsafeはなんぼ書いてもお咎め無しなのも面白い仕様な

**デフォルトの名無しさん** · 2023/04/25(火) 17:58:10.72

>>555
他人を信じない人がいる、というか他人のソースコードを読まない人がいるのかもね
読まないのも自由だからいいけど
他人が何を書いても自由だから、読む価値がありえないとは言えない

**デフォルトの名無しさん** · 2023/04/25(火) 18:06:32.83

>>547
>ここ数年の流れはJavaの出だしの頃に非常に似ている。
よく分からない。当時は本屋にJavaが並んだなと思ったら、既に大人気
状態だった気がする。人気と本のどちらが先に出たかの前後関係は良く知らない。

**デフォルトの名無しさん** · 2023/04/25(火) 18:23:59.84

>>559
lifetimeや所有権がうざいって、
あなたC++でも正しいコードを書けていないでしょ
所有権はC++もRustも同じ
lifetimeはC++で明記されないけど満たすように書かないとダングリング

**デフォルトの名無しさん** · 2023/04/25(火) 18:46:54.32

https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=fc5a23e24fd46feb0a4388c2f0161caf

はーうざいうざい
修正方法分かったけどあーうざいうざい

**デフォルトの名無しさん** · 2023/04/25(火) 19:38:05.27

lnked listなんてアクセス遅すぎて
ほとんどの用途はベクターの方が結局速い
残りの用途はバイナリーツリーなどになるが車輪の再発明してもよいことはなくライブラリを使うべき

**デフォルトの名無しさん** · 2023/04/25(火) 19:40:54.10

>>564
>lnked listなんてアクセス遅すぎて
>ほとんどの用途はベクターの方が結局速い
ダウト。

**デフォルトの名無しさん** · 2023/04/25(火) 19:57:48.42

リンクリストはマジ遅い
値の読み書きも挿入も削除もまずその場所を見つけたどるのにO(n)かかってしまう

**デフォルトの名無しさん** · 2023/04/25(火) 20:54:35.52

>>563
そのエラーを起こしているバグは所有権もライフタイムも関係ない
ロックをつかんだまま更にそのロックをつかもうとしている一般的なバグ
ブロックを分ければロックが解放されて解決する
初心者が一度は通る道だが二度目以降は一瞬で対応できるようになるだろう

ちなみにそのコードに限れば最初からmutロックを得る方法でも解決できる

**デフォルトの名無しさん** · 2023/04/25(火) 21:03:25.18

>>563
あと&nextの&は冗長で不要
その前の行もSomeで受けるときに右辺に&を付けるよりも左辺にrefを付けたほうが今後に一般的に対応できる

**デフォルトの名無しさん** · 2023/04/25(火) 21:07:31.77

>>563
IDをよく見たら「複おじ」連呼してる人か
単なる初心者だった

**デフォルトの名無しさん** · 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が強そう