C++ vs Rust

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

競え

**デフォルトの名無しさん** · 2021/11/23(火) 19:59:41.90

いまどきC++使ってるのは老害でしょう。
すぐにRustを始めるべきです。

**ハノン** ◆QZaw55cn4c · 2021/11/23(火) 20:09:04.33

あわしろ氏って、もしかして馬鹿ぁ？

**デフォルトの名無しさん** · 2021/11/23(火) 21:01:08.57

低能が何か申しておりますｗ

**デフォルトの名無しさん** · 2021/11/23(火) 21:24:52.33

>>364
俺は調査目的で調べてるだけで、実用的に使うつもりはないからな。

**デフォルトの名無しさん** · 2021/11/23(火) 22:01:53.34

>>368
たまに見かける使いこなせなくて脱落したケース？

**デフォルトの名無しさん** · 2021/11/23(火) 22:12:56.79

あわしろって誰？調べても出てこない

**デフォルトの名無しさん** · 2021/11/23(火) 23:01:49.38

>>369
使う必要性を感じない。

**デフォルトの名無しさん** · 2021/11/24(水) 07:30:28.98

>>368
であれば、批判する資格はないな

**デフォルトの名無しさん** · 2021/11/24(水) 10:47:07.21

>>372
有る。

**デフォルトの名無しさん** · 2021/11/24(水) 10:49:35.25

仮に泡白という人物が実在したとしても
ここで連呼されるのは本人も迷惑してるんじゃないかな

**デフォルトの名無しさん** · 2021/11/24(水) 11:15:10.51

Ubuntu Linuxや OpenOffice系の洋書の翻訳家に、
「あわしろいくや」という人物がいるようだ。

**デフォルトの名無しさん** · 2021/11/24(水) 11:21:34.63

しかもRustやC++の専門家のようには見えんけども…

**デフォルトの名無しさん** · 2021/11/24(水) 17:09:21.00

>>373
CとRustそれぞれでコードを書いてみることをおすすめします
計算量オーダーが変わるアルゴリズムレベルの検討ならともかく
コンパイラの最適化でいくらでも性能が変わりうる実装の詳細についてはまず性能測定するのが常識だと思います

**デフォルトの名無しさん** · 2021/11/24(水) 17:29:56.67

リンクリストで頑張るより配列のほうが色々捗る場面も多々あるよな
キャッシュが効いてるとこ読むときの速度は目を見張るもんがある
ヒープで飛び飛びになったデータ構造はその点で恐ろしく不利
それを知ってる人は実測した結果で語る

**デフォルトの名無しさん** · 2021/11/24(水) 19:53:47.71

21世紀にもなってC++使ってるのは頭がおかしい。

**デフォルトの名無しさん** · 2021/11/24(水) 19:54:39.96

Linusは20世紀の頃からC++は駄目だと言ってた。
天才。

**デフォルトの名無しさん** · 2021/11/24(水) 22:30:18.26

Rustは言語が汚い。

**デフォルトの名無しさん** · 2021/11/24(水) 22:43:39.16

linusのc++否定ってのは当時の実装のバギーさとオブジェクト指向に対する否定だな。
関数型流行ってる今から見ると割と普通のこと言っとるわ。

**デフォルトの名無しさん** · 2021/11/24(水) 23:59:24.30

>>381
むしろ綺麗な方

**デフォルトの名無しさん** · 2021/11/25(木) 01:15:43.82

>>381
言語が汚いってのはよくわからないけど例えばどういうところが汚いと感じたの？

**デフォルトの名無しさん** · 2021/11/25(木) 01:47:48.10

でもLinkedList版sliceみたいなのって実現できないのかね

**デフォルトの名無しさん** · 2021/11/25(木) 02:58:46.76

ここまでのまとめ
(1) ほとんどの用途でLinkedListよりVecの方が有用
(2) Rustの標準ライブラリにはLinkedList型もVec型もどちらもある
(3) もしLinkedListやVecを使っても実現できないならまずはそのRustコードを示すべき
(4) 仮に超レアケースがあったとしてもRustでは自分で自由に必要な型を作ればよい

**デフォルトの名無しさん** · 2021/11/25(木) 07:50:48.33

>>381
アセンブラとチューリングマシン語以外の言語は汚い

**デフォルトの名無しさん** · 2021/11/25(木) 09:50:29.78

LLVM最強ですね判ります

**デフォルトの名無しさん** · 2021/11/25(木) 16:04:22.18

>>386
嘘を書くな。

**デフォルトの名無しさん** · 2021/11/25(木) 16:33:56.78

>>389
特に嘘はないと思うけど
stdのLinkedListがちょっと融通利かないところはあるけど

**デフォルトの名無しさん** · 2021/11/25(木) 16:34:58.88

>>386
様々な言語の中でRustだけ linked list の任意の要素にO(1)でアクセスできないというのは嘘だった
も追加で

**デフォルトの名無しさん** · 2021/11/25(木) 20:15:57.40

macro記述と言語がまるで別言語、いちいちウザいアトリビュート。letは固定を意味するのではなく式展開
何種類もある「文字列」、それに生えている似たようで意味が違ういっぱいのfn（これはトレイトのせい）
わざと敷居を高くしてるとしか思えん

**デフォルトの名無しさん** · 2021/11/25(木) 20:31:51.42

>>392
> letは固定を意味するのではなく式展開

letは常に成功する構造パターンマッチングにすぎないよ
if letは成功か失敗か不明な構造パターンマッチング
今どきの言語ならば左辺値にパターンが書けるのが普通

> 何種類もある「文字列」

文字列はヒープにあり伸縮可能なStringとそうでないstrの2種類しかないよ
ヒープを意識する言語なら2種類ある
あとは文字列の参照として&strがあってその本体はヒープにあろうがなかろうが同じ扱いできるだけ

**デフォルトの名無しさん** · 2021/11/25(木) 20:38:50.41

CString
CStr
OsString
OsStr

**デフォルトの名無しさん** · 2021/11/25(木) 20:58:33.97

>>394
それはRustの文字列ではなく単なるFFI
通常のプログラミングでは登場しない

**デフォルトの名無しさん** · 2021/11/25(木) 21:05:41.06

>>391
「任意の」
の定義をしないと無意味な主張

**デフォルトの名無しさん** · 2021/11/25(木) 21:16:25.34

じゃあ何種類もあるじゃない、全部が汚いことへの言い訳にしか聞こえない

**デフォルトの名無しさん** · 2021/11/25(木) 21:25:33.18

まとめ
・どの言語でもリンクリストでk番目を得るにはO(n)かかる
・そのk番目を配列で持てばO(1)だがそれはリンクリストではなく配列アクセスのコスト
・リンクリストのk番目を保持する配列を維持するには削除挿入のたびにO(n)の移動が生じる
・これらは言語に依存しない

**デフォルトの名無しさん** · 2021/11/25(木) 21:33:37.11

>>397
言語の汚さというよりもOSなどの環境が抱える複雑さをそのまま見せたらそうなったのでは

**デフォルトの名無しさん** · 2021/11/25(木) 21:38:29.78

それが低いレイヤーをやるってことだわな。
それを他の言語のせいにするrust野郎はクソってことだよ。

**デフォルトの名無しさん** · 2021/11/25(木) 22:13:10.27

誤解している人が居るようなので正しい情報
・Rustの通常のプログラミングでCStrやOsStrが出てくることはない
・そこでファイルやディレクトリやソケットを操作してもCStrやOsStrは出てこない
・つまりRustで使う文字列はstrとヒープのStringの2種類しかない
・CStrやOsStrはFFIを書く人のみが用いるのでほとんどの人には無縁

**デフォルトの名無しさん** · 2021/11/25(木) 22:18:29.72

「通常」の定義は？

**デフォルトの名無しさん** · 2021/11/25(木) 22:30:32.62

>>402
Rustで未だ対応していない未知のものが出現した時にその対応する人だけがCStrやOsStrを用いる
その時のその人を除き、全ての人はCStrやOsStrなんか知らなくてもRustでプログラミング可能

**デフォルトの名無しさん** · 2021/11/25(木) 23:14:44.56

>>401
Pathの操作してるとOsStrは普通に出てくるのでFFIでしか出てこないというのは嘘

**デフォルトの名無しさん** · 2021/11/25(木) 23:16:52.42

他の言語がごまかしている箇所を正確に扱えるのがrustの強みでもありめんどくさいところでもある

**デフォルトの名無しさん** · 2021/11/25(木) 23:45:28.39

Rust擁護マンでも標準の文字列（String/str）以外がFFIのみというのはさすがに筋悪に見える
Rustで標準の文字列をUTF8のバイト配列（ヌル文字終端不採用）としたことによる弊害って側面が割と強い
でも他言語みたいにそこしっかりしないとなるとそれはそれでめんどくさいから結局のところトレードオフ

でもOsStrめんどいわ

**デフォルトの名無しさん** · 2021/11/26(金) 00:54:57.87

文字列エンコードを規定しないとそれはそれで移植性に問題あるし難しいところ
WTF-8なる概念必要になったりとにかくWindowsが悪いという気はする

**デフォルトの名無しさん** · 2021/11/26(金) 03:23:02.14

>>391
嘘を書くな。
正しくは、Rustは配列を使って独自実装しないとO(1)には出来無い事が明らかに成った。
参照だと借用規則で出来なくて、配列の添え字番号だと単なる整数なので借用規則の
適用範囲外だからできる。添え字番号をポインタの代わりに使って、独自に
リンクトリストを実装することで初めて、O(1)になる。
しかし、O(1)になっても、「係数」が大きくなり、1アクセスに20クロックくらいかかる。
配列の範囲チェックと、配列アクセスのための乗算と加算が追加で必要になるため。

一方、C、C++、C#、Javaではそんなことしなくても最初からO(1)。

**デフォルトの名無しさん** · 2021/11/26(金) 03:24:19.18

>>398
お前みたいなやつは、一度殴ってやりたい。
匿名掲示板だからと言って、でたらめを書くな！！
ばか者！

**ハノン** ◆QZaw55cn4c · 2021/11/26(金) 03:25:10.11

>>408
C/C++ のリンクリストがどうして O(1) なんですか？

**デフォルトの名無しさん** · 2021/11/26(金) 03:33:50.05

>>398は、数学できない。
細かい点が全然分かって無い。
リンクリストでは、「k番目にアクセスする」と言っても、次の二種類ある。
1. (乱数などで)整数 k を与えられて、ノードを探す。
　この場合、どうしても、O(N)、O(k)の時間がかかる。
2. 既に追加したノードを、もう一度アクセスする。
　これには、C、C++、C#、Javは、O(1)しかかからない。
　しかも、C、C++だと 1 クロック。
　Rustだと配列と添え字番号を使って独自実装しなければ、
　基本的にO(N)、O(k)かかる。独自実装した場合、
　O(1)ではあるが、20～50クロックくくらいかかる。
　

**デフォルトの名無しさん** · 2021/11/26(金) 03:34:37.06

>>410
>>411を読め。
俺は正直に言っている。また、数学が昔から良くできるので、間違ってない。

**デフォルトの名無しさん** · 2021/11/26(金) 03:40:28.33

>>411
[補足]
実際、>>257 の独自実装は、Rustでも、任意の場所のノードをO(1)で
アクセスできるが、1アクセスあたりに一般的なノードサイズでは
20～50クロック掛かる。

悪いが、QZが出てくると話がややこしくなる。
かわいそうだが、単刀直入にいえば、QZは頭が良くないので、
レベルが全体に下がってしまう。
ようは、レベルが違う人は、教室を分けないとめちゃくちゃに成る。
レベルというのは熟練しているかどうかではなく、生まれつき決まっていて、
直すことが出来ない。
すまん。

**デフォルトの名無しさん** · 2021/11/26(金) 03:46:37.90

>>398
>・どの言語でもリンクリストでk番目を得るにはO(n)かかる
これは間違いである事は何でも説明した。例えば>>411。

>・そのk番目を配列で持てばO(1)だがそれはリンクリストではなく配列アクセスのコスト
これも間違いで、C、C++、Java、C#では、配列で持たずに、直接、ポインタや参照
で持っても、O(1)でアクセスできる。
Rustでは、借用規則が邪魔して、複数の読み書き参照を同時に永続的に保持できないので、
「k」のような番号でしか場所を維持できないため、そんな風になってしまうだけ。
だから、配列と番号を組み合わせてやっとO(1)にできる。
C、C++、Java、C#では、ポインタや参照を永続的にいつまでも保持できるので
配列を使わなくても O(1)でアクセスできる。
その際、「シーク」動作は必要ない。つまり、先頭から k 番目までを辿る必要が
なく、いきなり、k番目に 1 クロックでアクセスできる。
Rustでは、それが、一般的には出来ない。Rustでも、
局所的に1個のノードだけに限定すれば出来る。

**デフォルトの名無しさん** · 2021/11/26(金) 04:02:58.56

例えばこういうことだ。
リンクリストに、
ハンバーガー、りんご、みかん、ドーナツ、パイナップル
の5つを追加したとする。
C、C++、Java、C#では、追加した時に、どこかの5つの変数にこれらの
ポインタを残しておけば、あとから好きなタイミングで、どの
食べ物にも、一瞬でアクセスできる。C、C++では、1クロック。
1番目: ハンバーガー
2番目: りんご
3番目: みかん
4番目: ドーナツ
5番目: パイナップル

3番目のみかんにアクセスするのも、1クロック。
その後に、1番目のハンバーガーにアクセスするのも、1クロック。
その後に、4番目のドーナツにアクセスするのも、1クロック。

例えば、こうだ:
LinkedList ll;
p1 = ll.append("ハンバーガー");
p2 = ll.append("りんご");
p3 = ll.append("みかん");
p4 = ll.append("ドーナツ");
p5 = ll.append("パイナップル");

**デフォルトの名無しさん** · 2021/11/26(金) 04:03:19.69

>>415
[続き]

cout << p3->name; // 1 クロックで3番目のノードのみかんにアクセス。
p3->name="orange";　// 名前を英語に直す。アクセスには1クロックしかかからない。
cout << p1->name; // 1 クロックで1番目のノードのハンバーガーにアクセス。
p1->name="hamburger";　// 名前を英語に直す。アクセスには1クロックしかかからない。
cout << p4->name; // 1 クロックで4番目のノードのドーナツにアクセス。
p4->name="donuts";　// 名前を英語に直す。アクセスには1クロックしかかからない。

書き込みも変更も、アクセスには1クロックずつしか掛からない。
これが、Rustでは借用規則に引っかかるために出来ない。
その結果、標準実装では、k番目のノードに「シーク」する必要があるため、
O(k)や、O(N)の時間が掛かってしまう。
例えば:
cout << seek(ll, 3)->name; // O(N)の時間が掛かる!!
seek(ll, 3)->name="orange";　// O(N)の時間が掛かる!!

**デフォルトの名無しさん** · 2021/11/26(金) 04:10:09.81

>>411
＞2. 既に追加したノードを、もう一度アクセスする。
これカーソルでO(1)でできるって何度も言われてるやんけ
書き換え可能なカーソルを複数持つコードを書くのがめんどくさいってならわかるが

**デフォルトの名無しさん** · 2021/11/26(金) 04:12:10.51

>>416
[補足]
cout << aaa;
は、分かりにくいが、aaa の内容を表示する、という意味だと思って欲しい。
他の言語だと、print aaa; と書くことが多い。この点 C++ は異質であることは
認める。

**デフォルトの名無しさん** · 2021/11/26(金) 04:15:36.11

>>417
Rustでは、標準 Cursorでは、読み、書き、削除を出来る参照を同時に持つことは出来ない。
C、C++、Java、C#では、
ll.RemoveAt(p2);　// p2 のノードを削除。
もアクセス自体は1クロックで出来るし、今示したコードの好きな場所に
追加しても何の問題も無い。
p2は削除されているからアクセスできなくなるだけで、
他のポインタの値は変更されないので、それ以外は何もしなくても
そのままで良い。

**デフォルトの名無しさん** · 2021/11/26(金) 04:16:36.76

>>417
良く確認してくれ。
RustのCursorは、順番に辿ることはできるが、読み込みと書き込みと削除が
出来るタイプの参照を同時に複数記憶することは出来ない。

**デフォルトの名無しさん** · 2021/11/26(金) 04:18:59.29

>>419
標準(std)のLinkedListならそれはそう

前にも言ったような気がするが、
自前で作って内部構造にunsafecellを使えば、
不変参照を複数持っている状態でも書き換えが可能になる
例えば要素の追加時にそういうことをするカーソルを返せばよい
実装がめんどくさすぎるのは認める

**デフォルトの名無しさん** · 2021/11/26(金) 04:19:23.54

>>420
もっと言えば、C、C++、Java、C#の LinkedListは、
p2 の直後に「じゃがいも」ノードを追加した後、
p4 の直前に「トマト」ノードを追加するなどと言ったことも、
O(1)で出来る。しかも、O(1)と言っても、極限的に速くて、
C、C++の場合は、アクセスには1クロック。

こういうことが、Rustでは、Cursorを使っても出来ない。

**デフォルトの名無しさん** · 2021/11/26(金) 04:23:10.27

>>421
>>257のように、遅くするつもりなのか。
1ノードのアクセスに20～50クロックくらい掛かるが。
しかも、ダングリングポインタ、つまり、削除後にアクセスしてしまう
減少を防ぐことが出来なくなってるぞ。

**デフォルトの名無しさん** · 2021/11/26(金) 04:25:26.12

>>423
アンセーフ前提だから>>257とは全然違う
ダングリングも当然防げない（でもそれは他言語でもそう

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

>>424
>>257 の実装でもそうだが、まだノードAに対する参照がどこかに残っている状態で、
ノードAの中身を削除できて、ノードAが使っていた要素を新規作成ノードのために
使用されてしまうね。

**デフォルトの名無しさん** · 2021/11/26(金) 04:42:30.98

>>420
[RustのCursorの補足]
・書き込み用のCursorを1個でも作ると、読み込み用のCursorは作れない。

はずだ。難しすぎてちゃんと理解して無いことは認める。

**デフォルトの名無しさん** · 2021/11/26(金) 04:49:17.40

>>421
std::cell::UnsafeCell なるものがあるのか。
Rustの参照は種類が多すぎ。
学んでも学んでもキリが無い。
しかも、1つずつをちゃんと理解するのが難しい。

**デフォルトの名無しさん** · 2021/11/26(金) 09:55:21.11

>>404
Pathといってもこちらから使うだけならAsRef<Path>だからStringと&strでも全く問題なくOsStringの存在すら知らなくていい
したがって出てくるのはDirEntryのみとなる
それも周り全てUTF8環境ばかりなのでinto_string()で全てSome(String)になるため結局OsStringを扱ったことは一度もない

**デフォルトの名無しさん** · 2021/11/26(金) 10:08:20.18

ミスったｗ
ResultのOk(String)ね

**デフォルトの名無しさん** · 2021/11/26(金) 12:12:39.51

>>428
いやいやせっかく標準ライブラリがWindowsでも動くよう苦労してくれてるのにそれを台無しにするなよ
個々のアプリで雑に対処するならともかくRust擁護派がRustの強みを否定してどうする

あと Path::file_name も Option<&OsStr> 返すしこれは利用頻度高い

**デフォルトの名無しさん** · 2021/11/26(金) 20:45:27.01

>>430
Rustはちゃんと考えられてるね
ただし自分はWindowsを使うことは100%ないから path.file_name().unwrap().to_str().unwrap() 等でいいし
他にも use std::os::unix::fs::MetadataExt して metadata.uid() 等することもある

**ハノン** ◆QZaw55cn4c · 2021/11/26(金) 21:02:52.31

>>411
リンクリストや広く一般的なデータ構造の空間的・時間的オーダーを語る場合には
ノードの追加
ノードの検索
すでに取得している指定ノードの削除

あたりを考えるのが普通ですが、

「一度取得したノードの再アクセスコスト」を特に取り上げて考えるというのは、確かに rust の特殊性を示しているものといえそうですね…

>>413
生まれてきてすみません…

**デフォルトの名無しさん** · 2021/11/27(土) 13:14:46.65

>>432
また、話を混乱させている。
指摘していることが、全く的を外しているから。

**デフォルトの名無しさん** · 2021/11/27(土) 13:16:38.57

ちゃんと正確に議論されているのに、最後の最後でQZがめちゃくちゃな
ことを言い出す。それが最後に書かれたことによって、このスレに
後から来た人には「まとめ」の様に見えてしまうから、大迷惑。
全くまとめになってない、でたらめなことを書くから。

**デフォルトの名無しさん** · 2021/11/27(土) 13:19:47.46

ようは、秀才達が集まっているクラスで、一人だけレベルの低い人がいて、
秀才達が大体理解したのに、「まとめ」として、レベルの人が全く
デタラメなことを話す。それがQZ。
クラスの場合、みんなの雰囲気でQZがレベルが低いことが分かるので呆れられ、
無視され、せせら笑いが聞こえるが、ネットだとそれが分からないから困る。
現実世界では言葉にしなくても、ひそひそ場なしや、せせら笑いなどで分かるが
ねっとではそのような言外のコミュニケーションが出来ないから。

**デフォルトの名無しさん** · 2021/11/27(土) 13:22:32.48

>>435
どうせ、QZは、この文書の誤字脱字を発見して馬鹿にするんだろう。

誤字訂正:
誤:レベルの人が全く
正:レベルの低い人が全く

誤:ひそひそ場なしや
正:ひそひそ話や

誤:ねっとでは
正:ネットでは

**デフォルトの名無しさん** · 2021/11/27(土) 17:31:40.13

4レスも使って成果物も作れない評論家様はそびえ立つクソだからなぁ。

>>432のまとめが嫌なら、中身のない4レスのうち1レスを使ってご立派なまとめぐらい書き込んだら？

**デフォルトの名無しさん** · 2021/11/27(土) 17:48:27.29

たしかに4レスも使って人格批判しかしてね～

**デフォルトの名無しさん** · 2021/11/27(土) 19:00:17.29

ID:Y9o/DNQu
こいつがまとめを書けば話は終わりだな

**デフォルトの名無しさん** · 2021/11/27(土) 19:39:40.61

あわしろ氏はC++は使わないほうが良いと言ってる。

**デフォルトの名無しさん** · 2021/11/27(土) 20:00:10.09

C++をあまり使用してなさそうなよくわからないあわしろ氏でなく自分の意見出しなよ

**ハノン** ◆QZaw55cn4c · 2021/11/27(土) 20:25:46.13

>>433
すみません

>>434-436
生まれてきてすみません…

**デフォルトの名無しさん** · 2021/11/27(土) 21:09:50.54

>>434 >>442
お二人方どちらでもいいから
具体的に削除でダングリングが発生しないCかC++のO(1)コードを示してよ
それが示せない限り机上の空論
もしコードが示されれば対応するRustのコードを出します

**デフォルトの名無しさん** · 2021/11/27(土) 22:07:53.33

オブジェクトのアドレスをハッシュテーブルで持たせて、双方向リストで実装。

**ハノン** ◆QZaw55cn4c · 2021/11/27(土) 22:11:02.52

>>443
＞具体的に削除でダングリングが発生しないCかC++のO(1)コードを示してよ

>>432
＞「一度取得したノードの再アクセスコスト」を特に取り上げて考える
という、他ではあまり聞いたことのない特殊な話ゆえに筋を深く追えていないのですが、

>>432
＞リンクリストや広く一般的なデータ構造の空間的・時間的オーダーを語る
において
①
＞すでに取得している指定ノードの削除
でいいですか？
②
データ構造は一方向リストでいいですか？

**デフォルトの名無しさん** · 2021/11/27(土) 22:20:41.20

>>445
一方向だと削除がO(1)じゃないから双方向が良いのでは

**ハノン** ◆QZaw55cn4c · 2021/11/27(土) 23:03:04.21

>>446
それは末尾または冒頭ノードの削除の話ですね
何が与えられていて、何を削除するのか、きちんと定義していただきたいです

**ハノン** ◆QZaw55cn4c · 2021/11/27(土) 23:04:36.52

>>446
失礼、あるいは特定ノードの上流ノードの探索の話もありますね
確かに双方向の方が楽チンですが、「ダブルポインタ」を使えば単方向でも処理できないわけではないです

**デフォルトの名無しさん** · 2021/11/27(土) 23:42:34.01

スマンが、余り言いたくないことだが、QZが出てくると話がとてもややこしくなる。

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

まだやってたのか

**ハノン** ◆QZaw55cn4c · 2021/11/28(日) 02:32:25.17

>>449
当然でしょう

>>432
＞リンクリストや広く一般的なデータ構造の空間的・時間的オーダーを語る場合には
＞ノードの追加
＞ノードの検索
＞すでに取得している指定ノードの削除
＞
＞あたりを考えるのが普通

なのに、

>>445
＞＞「一度取得したノードの再アクセスコスト」を特に取り上げて考える
＞という、他ではあまり聞いたことのない特殊な話

を延々とやっていることに噛み付いているのですから

さて実装実装…

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

それがこのスレの目的ですから

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

ある特定のエントリーを持つ変数はプログラム中に複数存在しうると議論中にも出ていたから
リファレンスカウンタは必須になるな

重要な点としては
コンストラクタやデストラクタやスマートポインタに隠れて曖昧にならないように
それらを使わずに実装すべきだ
そもそもC言語でもO(1)という話なのだから
まずはC言語かつ標準ライブラリのみ使用が今回のコード条件

**ハノン** ◆QZaw55cn4c · 2021/11/28(日) 04:07:17.98

>>453
ん？アンカーで示してください
今回はリファレンスカウンタは実装に含めないつもりです、まあ C で書くつもりですけど

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

もうソース出せって意地悪言わないで、無視しときなよ
配列に格納し直すのが彼のアイデアの全てなんだから、つついても面白い話は出てこないよ

O(1)で追加・削除できる配列も作れる！って言い出したら、多分リンクリストを使うってことだよ

**ハノン** ◆QZaw55cn4c · 2021/11/28(日) 14:56:23.04

>>443
https://mevius.5ch.net/test/read.cgi/tech/1434079972/105
これでいかがでしょうか？

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

>>443
C/C++では、ダングリングが発生するのを防ぐのはプログラマーの仕事だ。

**ハノン** ◆QZaw55cn4c · 2021/11/28(日) 17:39:38.36

>>443
引き続いて双方向リストの場合
https://mevius.5ch.net/test/read.cgi/tech/1434079972/106
これでいかがでしょうか？

>>444
＞オブジェクトのアドレスをハッシュテーブルで持たせて、双方向リストで実装。

では C で実装願いますね
私は宿題を片付けましたので、ちゃんちゃん

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

>>451
>>432では、あなた、そういうこと書いてなかったよね。
こういう議論でははっきり言わないと分からないよ。

でも、あなたの観点は間違ってる。
C/C++/Java/C# においては、リンクリストで、一度作成したノードのアドレスは
ずっと保存するのが基本で、「先頭からの通し番号」で「辿る」ということは効率
が悪すぎて特殊なケース以外ではしないから。

**ハノン** ◆QZaw55cn4c · 2021/11/28(日) 17:47:22.55

>>459
もうリンクリストなんか不要で、最初からハッシュテーブル一本でやっていくべきなのでは？
なんでリンクリストとハッシュテーブルを両方使うのですか？

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

>>460
ハッシュテーブルなんて全く使って無いぞ。
あなたはポインタの仕組みを理解して無いのか？

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

QZは、ポインタが 1 クロックでどんな場所にもたどり着けることを理解出来て無い
のではないか。
アドレスさえ分かっていれば、1クロックであらゆるオブジェクトにたどり着けるぞ。
基本的にハッシュ構造とは全く関係無い。

**ハノン** ◆QZaw55cn4c · 2021/11/28(日) 17:58:02.00

>>461
失礼、>>444 とは別の方なんですね

でも、

＞C/C++/Java/C# においては、リンクリストで、一度作成したノードのアドレスは
＞ずっと保存するのが基本で、「先頭からの通し番号」で「辿る」ということは効率
＞が悪すぎて特殊なケース以外ではしないから。

それはそうです、リンクリストを頭から舐めるのは効率がイマイチなのはおっしゃるとおり、単純な構造だからそれはしかたがない
しかし、

＞リンクリストで、一度作成したノードのアドレスはずっと保存する

って、どこにどういう形で保存するのです？

**ハノン** ◆QZaw55cn4c · 2021/11/28(日) 17:59:56.44

>>462
＞QZは、ポインタが 1 クロックでどんな場所にもたどり着けることを理解出来て無い
＞のではないか。
>>456, >>458 で示した程度には理解しているつもりです

＞アドレスさえ分かっていれば、1クロックであらゆるオブジェクトにたどり着けるぞ。
で、そのアドレスをどのように管理するのですか？どのような形でどのようなデータ構造に格納するのですか？C/C++ で説明いただくと助かります