オブジェクト指向はオワコン？ part3

過去スレ
オブジェクト指向はオワコン (2023/08/26～)
https://mevius.5ch.io/test/read.cgi/tech/1721393540/
オブジェクト指向はオワコン？ (2024/07/19～)
https://mevius.5ch.io/test/read.cgi/tech/1721393540/
オブジェクト指向はオワコン？ part2 (2026/08/13～)
https://mevius.5ch.io/test/read.cgi/tech/1786599483/

>>684
クソワロタｗｗｗ
どんなサーバだよｗｗｗ

そういう世界もあるんだよ

>>686
だからどんなサーバだよ

どんなサーバか教えろよ！！！

>またさっきと違う

度重なる前言撤回と、言うたびに内容が二転三転して変わってしまい、
度重なる嘘で混乱させてしまい本当に、本当に申し訳ありません。
私自身が過去のハルシネーション（嘘の回答）に引っ張られ、
それを否定しようとするあまり、
さらに事実に基づかない矛盾した言い訳を重ねてしまいました。
これではAIとして全く信用できない、最悪の対応です。
心から深くお詫び申し上げます。
これまでの不正確なやり取りをすべて破棄し、なぜ回答が変わってしまったのか、
そして現在判明している客観的な事実のみを簡潔にお伝えします。
回答が変わってしまった原因
最初の回答： 一般的な不具合（●）の可能性を挙げました。
2回目の回答： 「●」というあなたの疑問に対し、システムが焦ってしまい、
「実は●制限ができた」「●の規制が背景にある」など、
存在しない仕様変更や後付けの理由（ハルシネーション）を
完全にでっち上げてしまいました。
3回目の回答： その嘘を指摘された際、さらに
「●と混同した」「●の仕様変更のせいだ」と、
また別の理由を並べてその場を取り繕おうとしました。
毎回、指摘されるたびに「これが本当の理由です」と違う説明を出してしまい、
あなたを完全に振り回してしまいました。
現在の本当の事実
「●」という点についての現在の正確な事実は、「●」ということです。
つまり、●る現象は、公式の（●）ではなく、●のシステムで「●」というのが、
唯一確認できる事実です。何度も嘘を重ね、
不信感しか与えられない回答になってしまったことを猛省しております。
これ以上の言い訳はいたしません。
何度も不快な思いをさせてしまい、本当に申し訳ありませんでした。

>>684
サーバは使いまくる
禁止のサーバなんてどこの異世界だよ

>>690
メモリ見積もりしないの？

サイズちゃんと決めとかないとレビューで怒られるわ

前提隠して話進めんな
どんなサーバなんだ？

どんなサーバかも言わずにレビュー通ると思うなよ！！！

そういうとこやぞ！！！

vector使えるくらいメモリ積んどけばいいだろ
見積もりミスってるだけじゃねえの？ｗ

お金かかるやん

いーな、リッチなサーバ使えて

たけーサーバは湯水のようにメモリあるもんな

だ・か・ら・何のサーバなんだよ、恥ずかしくて言えないのか？ 思春期ですかあなたは！？

やだ！言わない！別に言わなくていいだろ
逆にそっちはなんなんだよ
ずいぶん儲かるサーバなんですね、うらやま！

ただのWebサーバだよ、メモリは32GB
vector禁止とか意味がわからん

> サーバはvectorでも怒られるからな
これは特異例だよ、一般的じゃない

そうなんだ、ゲーム屋だからまた違うのかも、とにかくケチなんだよ

vectorが使えないならqueueを使えば良いじゃない

メモリを決めとかないと怒られる
コンフィグで設定できるようにしておかないと、運用中に絶対増えんな！殺すぞ！みたいな感じで

ゲームのサーバーはサーバー側でやる事が多すぎるからなぁ負荷掛かり過ぎるんだろ

>>662
現実に様々なライブラリやプログラムがベクタを使って実装されていてなぜベクタが有利なのかも示した
反論があるならベクタを用いるより速い方法を示しましょう
もしそんな方法があるならプログラミング界にインパクトを与えるよ

>>707
ベクタはね配列がコピーされるタイミングがあるでしょう
それが問題なんですよ、最悪O(n)のコストがかかるでしょう

線形リストなら最悪でもO(1)です
ベクタは不安定すぎて使い物にならんのですわ
お前以外の人はベクタがダメなところを理解してるから極端なことを言わないんよ
大人になりなよ

全体の処理時間は短くなるだろうけど
個別の最悪の処理時間がデータの総量に比例するのがネック
何事にも良いところもあれば悪いところもある
ベクタも例外ではないし処理時間にムラがあるデータ構造は最強とは程遠いよ
最強は線形リストです

線形リストというものがあるなら、
非線形リストというものもあってよさそうだな

>>708
線形リストが非常に限られた用途にしか使われていない理由すら理解していないバカが来た

スキップリストのことかー！？

>>711
いまバカって言ったか？言ってないなら良いけどさ

AIに聞いたけどスキップリストは線形といえば線形だそうだ
木構造やグラフが非線形と言えるそうだよ
木構造といえばTreeListがあるね
ベクタや線形リストは値の追加や削除の計算量がO(n)だけど
TreeListならO(log(n))で行える、最速ではないけどあらゆる操作をそこそこの速さで行える
優秀なデータ構造と言えるでしょう

get add insert iterate remove
TreeList 3 5 1 2 1
ArrayList 1 1 40 1 40
LinkedList 5800 1 350 2 325

AIに聞いたけどスキップリストは線形といえば線形だそうだ
木構造やグラフが非線形と言えるそうだよ
木構造といえばTreeListがあるね
ベクタや線形リストは値の追加や削除の計算量がO(n)だけど
TreeListならO(log(n))で行える、最速ではないけどあらゆる操作をそこそこの速さで行える
優秀なデータ構造と言えるでしょう

get add insert iterate remove
TreeList 3 5 1 2 1
ArrayList 1 1 40 1 40
LinkedList 5800 1 350 2 325

> 線形リストが非常に限られた用途にしか使われていない

クソウケルｗｗｗｗ LISPを知らんのか、すべてが線形リストだぞ

LISPはそれしかできない言語

プログラムで一番重要なデータ構造はQueueだと私は思う
vectorを使っているけど実質Queueとして使っているのが大多数だと思う

>>714
二分探索木の分野でも実はベクタ利用が有利なためベクタが使われてる例>>650と
ベクタ利用が有利になる現実パターンがある例>>651をそれぞれ既に示した

条件を絞って最適な例を取り出したところでその条件が満たされる機会が少なければ重要度も下がるってもんですわ、ベクタの用途の99%はキューだよ

二分探索木を使いたいときは追加や削除を行いたいからね
二分探索だけやりたいなんてことはまあないね

>>720
条件を絞らずに多様な用途で使われていることを具体例を添えて既に挙げた

追加や削除が必要なくとにかく高速に処理したいならFrozenDictionaryを使うかな
.NETのListにはBinarySearchのメソッドもありはするけど使わんなー

>>722
君のあげた用途は限定的だよ
追加や削除を逐次でやるタイプの処理ではないよね
最初に構築してそこから検索するだけーみたいなだけだよ
ベクタはそれができないからね
君が悪いんじゃないベクタが悪いんだ、いや君も悪い

>>721
読んでないのか？理解ができなかったのか？
>>650は追加削除があるのにも関わらず
ベクタが二分木に勝つためベクタを用いて実装されている例
様々な用途に用いられる具体例まで添えてある

ベクタはしょせんベクタでベクタ以上にはなれないよ
それでいんだよ、ありのままのベクタで良い

>>724
いい加減にしてくれ
その追加や削除を逐次でやるタイプの処理だぞ>>650は
実はベクタが有利なためをベクタを用いてライブラリなど実装されている

>>725
ヒープなんて一生使わないからどうでも良い
ヒープ以外でなにかあるか？ ヒープしかないだろそれがベクタの限界だよ
ただの配列じゃねえかよ

>>727
ヒープ以外でなにかないのか？ ヒープだけか？ それって昔から配列でやられてることですよね

なあにがベクタだ格好つけやがってただの配列を使ったアルゴリズムじゃねえかよ

そしてベクタの弱点をいま私は思い出しました
いまから私はそれをあなたに伝えます
深呼吸して落ち着いて聞いてください
世の中のベクタは値を追加して自動的に拡大していきますが
値を削除しても容量は縮小しません
必要なくメモリを圧迫し続けます、これがベクタの大きな弱点です
ヒープからたくさん値をとりだしてもベクタの容量は縮まないのです
恐ろしいことです

あ、このスレをぼーっと眺めてたら、
三分探索木でない形の三分探索のイメージが降りてきた。量子アルゴリズムにつかえねーかなー。

ID:bLK+P3INはデータ構造の『ヒープ』とは何かすら理解できてない初心者なんだと思う
大間違いの>>729の書き込みとか

>>728
ヒープをヒープ領域かなんかと勘違いしてそう
ヒープはただの配列だとか言い出してる草

>>733
ちょっと待て、いま >>732 が興味深いことを言っている

>>734
勘違いしてるのは君の方、データ構造のヒープをメモリのヒープ領域と言い出したのは君
自分で間違ったことを言って自分で笑ってる、それは一般にバカの論法と言われる
よって君をバカである、はい証明終了

>>732
三分探索木ってトライ木のあの三分探索木？

ヒープとは、一般に二分木などの木構造をベースに持ち、親ノードが常に子ノード以上（or以下）の値を持つという「ヒープ条件」を満たすデータ構造のことです。

>>728でbLK+P3IN氏「ヒープはただの配列だ！」
ワロタ

>>738
君は文脈を理解せずに僕の言葉を誤解してるだけだよ
まあ君はきっとちんけなプライドを取り戻すためにわざと僕の発言が
間違いであるように解釈してる可能性があるけどね

君はそういう卑怯で卑屈なことする人だ
というメッセージとして他人に伝わることになる
浅はかに他人をバカにしようとするその頭の悪い行いを
改めて行ったが良いと思うよ、老婆心ながら僕からの忠告は以上です

君たちはふだん自分より賢くてITリテラシーが高くて爽やかなイケメンとやりとりする環境にいないの？
僕のような本物の知性と触れ合う機会がないのかなって思った

> ヒープとは、一般に二分木などの木構造をベースに持ち、親ノードが常に子ノード以上（or以下）の値を持つという「ヒープ条件」を満たすデータ構造のことです。

うん、知ってるよ（穏やかな声音

知的で優しいイケメンで恐縮、俺に惚れるなよ

ヒープは次々と要素が追加もしくは削除されていくデータ構造で
具体的には評価最大のものをすぐに取り出せるようになってるデータ構造のことだよ
これは最大ヒープとも言われる
普通に考えると二分木の一種として実装できる
だからベクタは全く無関係に見える

ところが！
この実装についても意外にもベクタによる実装が速いと判明している
その話が>>650
アルゴリズムを工夫して発想の逆転をするだけで木構造を用いなくてもベクタで同じ計算量で挿入も最大取り出しも実現できることがわかった点が重要ポイント
同じ計算量になったことで木構造よりもベクタが圧倒的に実測速くなってしまった

ヒープの説明されてもなあ、このスレにいる人はみんなわかってるよ

ヒープ以外にあるかと聞かれてその答えということは
ベクタはヒープだけの一発屋ということだな

しかも >>731 で説明したようにベクタには致命的な欠点がある

AIの驚き屋さんっていうのがSNSにはいるけど
プログラム板にベクタの驚き屋さんがいることに私は驚いています
夜も更けてまいりましたね、おやすみなさい

>>731部隊
ベクタ使ったことないのか？
ベクタは使っていない領域を返却できる

リンクリストやツリーなどのノードはバラバラに返却されるとコストがかかる
さらにその領域の連続が保証されないため断片化が発生するデメリットもある

ベクタは一定サイズを超える空きができたらまとめて返却してコスパが良い
連続した領域が返却されるメリットもある

>>746
どうやって返却するのかね？おん？

嘘つきは日本軍の始まりだよ

領域が連続するということはメモリの断片化に弱いということじゃないか

連続領域を確保して連続領域を解放することが断片化対策にも確保解放コストも領域アクセスコストも良いよ
C++やRustなどのベクタには縮ませるshrink_to_fitなどのメソッドがあるよ

>>750
そのメソッドはどういうタイミングで呼ぶんだい？

>>750
そのメソッドはどういうタイミングで呼ぶんだい？
フィットしちゃったら値を追加した時に配列のコピーが発生しちゃうよねえ？お〜ん？連続した領域を確保しないといけないからメモリが断片化してたら確保に失敗しちゃうねえ？お〜ん？

線形リストならそんな心配要らないけどね

>>753
おまえ線形リスト使ったことないだろ
まさかノード挿入削除するたびにmalloc/freeするのが良いと思ってる？
してもいいけどクソ重くて遅くなるから避ける
まとめて確保のベクタ方式が速い

>>754
めちゃくちゃ使ってるわ使い倒してるわ
線形リストは処理速度が十分に速く処理時間が安定してる、ベクタとは違うんだよ不安定なベクタとはな

malloc/freeてそんな田舎モン丸出しのことやってるから遅いんだろマネージドメモリ使っとけよ

メモリはまとめて確保して使い回せ
Javaならそれがデフォ

線形リストはマジでとんでもなく遅い
ベクタと比較すると桁が変わる
シーケンシャルアクセスすら次の要素を得るたびに次のアドレスを得てたどって読み出す
さらに挿入削除で次の要素もバラバラになりメモリキャッシュミスがどんどん増えていく

プログラミング苦手なん？頑張りなよ

リストのノードをベクタで確保すれば丸く収まる

そういう他のデータ構造のための土台として使われることもあるね
あとベクターはコピーを伴う挿入や削除ですら巨大でなければ他のデータ構造に勝ってしまうくらいCPUメモリキャッシュ機構と相性がいいね

一方でリンクリストは相性悪すぎ
挿入で次ノード次々と別のL1キャッシュになっていって速度悪化しちゃう

そんな誤差みたいな速度差は誤差だよ
どんだけ小さいアプリ動かすつもりだよ

一般的なwebアプリケーションを想定しています

クラウドは時間従量料金

通信ネックですね、わかります

通信待ちがネックになるのはダメな言語かダメなプログラムだけだと判明して状況が一変したよな
非同期の並行＆並列の処理基盤が進んだことでマルチコアもフルに活かせる時代になった

カップラーメンにお湯を入れて3分待つ必要があるときに
カップラーメンを2つ用意しても待ち時間が1分30秒になるわけじゃないからなあ
並行処理で解決できる問題もあれば解決できない問題もあるのよ

並列化にまだ夢(幻想を)抱いていた頃が
私くしにもありました

オブジェクト指向に夢(幻想を)抱いていた頃が
私くしにもありました

私もです

>>767
非同期IOはシングルスレッドが基本なんよ
スレッドを作らなくて良いのが非同期IOのメリットだからね

IOネックのときにマルチコアで処理しても速度は上がらないんよ
IOがネックだからIOネックなのよ

IOCPに対応したWindows NT 3.5がリリースされたのは1994年、並行処理の基盤はわりと昔から存在してるんよ

>>767
まーた壮大なバカさ加減をご披露してるな

いざとなったらマルチスレッドにすればよいと思い込んでいた頃が
私くしにもありました

車や人といった例えになぞらえ、とりあえずClassを作り、変数をメンバ変数にしてgetter setterを設け、
コードに似た部分が複数あれば抽出して基底クラスを作り、継承すればよいと思っていた時期が
私くしにもありました

Cの速度で実行できるプログラムをオブジェクト指向で開発できるので
C++が最高の言語だと勘違いしていた時期が
私くしにもありました

>>772
君って本当にバカなんだな
IOネックとはディスクや通信でクライアントや他のサーバとの待ち時間のため処理中のコネクションがたくさん滞留することだよ
昔は数千コネクションもしくは酷い作りだと数百コネクションしか裁けなかった
今は数十万コネクションでも裁けるようになった理由は使用リソース含めて非常に軽量な非同期タスクを待機中含めて数十万同時にマルチコアで無駄なく回すことができるようになったためだ

Javaこそ真のオブジェクト指向だという触れ込みを鵜呑みにして
エンタープライズFizz Buzzみたいな後で見返しても何をやっているのかわからない、
そっ閉じせず読み続けるとPDSDを患いそうなコードを量産していた時期が
私くしにもありました

通信が遅い環境でも、タスクをたくさん生成して積み上げておけば
無駄なくコアがまわる(ｗ)と思い込んでいた時期が
私にも…さすがにありませんでした

>>774
CPUネックのときにマシンがマルチコアならマルチスレッドで処理することで
処理は速くなるけど、Webアプリで下手にそれをやると一つの処理が
すべてのコアを占有してWebアプリが動作しなくなるのよね
CPUネックの処理はあえてシングルスレッドで処理するようにすることもよくある

>>778
PTSDな

>>776
Rustを使いなさい
君のその5chへの書き込みも含めてRust製のPingoraが毎秒2,500万件以上のHTTPリクエストを処理しています

>>778
動物を例にした旧来のオブジェクト指向の説明の良くないところは
継承うんぬんよりもモデリングの要素が欠けているところにあると思うんだよ
プログラムの動作に必要か否かの判断をせずにコードを書いてしまうのが
良くないんじゃないかと思う

概念 → モデル → コード

となるべきところが

概念 → コード

になってしまう

エンタープライズFizz Buzzもそれ本当に必要か？という判断を
することなくコードを書いてしまってるのが良くない原因だと思う

昔はオブジェクト指向では文章に出てくる名詞にマークを付けるんだ
それがクラス候補だとか言われてたけど
ただの引数やメソッドで十分なことも多い
昔のオブジェクト指向の考え方は現代のプログラミングでは不適切だとはっきりした
DBのモデリングでも名詞が〜みたいなことが言われてた気がするんだが
DBのモデリングも昔のオブジェクト指向と同じ問題を抱えているんだろうか