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

過去スレ
オブジェクト指向はオワコン (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/
オブジェクト指向はオワコン？ part3 (2026/08/26〜)
https://mevius.5ch.io/test/read.cgi/tech/1787712923/

動的ディスパッチをインライン化できないと思っているのはRustを使っている人たちのあいだでだけ蔓延しているガセネタだよねってこと

>>683
アセンブラでやってたことを高級言語で使いやすくしただけだからな。

>>684
ならば予め型ごとに飛び先き決めとけばいいんだね？
関数テーブルだって飛び先決まってるんだから静的に出来るよね？
推論型変数使わなければ良いのかなぁ？

>>681
条件分岐はCPUのジャンプ命令
まずそれまでの演算結果がCPUのフラグに反映されてる
そのフラグが条件を満たした時のみジャンプして分岐する
過去の分岐傾向をCPUがハード的に持つことで分岐するかしないかを予測して先読み実行してる
それら全てはCPUの中の話

一方で動的ディスパッチはコンパイラが>>683のテーブルを各型毎に作る

>>687
静的ディスパッチとは普通の関数呼び出しのこと
そこには条件分岐すら存在しない

PGO（profile guided optimization）って、たとえば仮想関数テーブルの飛び先がA, B, Cの3つで実行時に90%とか95%はAに飛ぶみたいな偏りがある場合に、BやCのケースについては条件分岐でガードした上で、Aの飛び先のコードをインラインで埋め込むみたいなイメージでしょ。
部分的なインライン化ではあるのでインライン化による最適化の概念に含まれるといってもいいとは思うが、条件分岐が追加される点でインライン化といったときにばっと思いつくイメージとはちょっと違うかな。

分岐後の部分には動的ディスパッチが存在しないからインライン最適化できるのは当たり前
それを動的ディスパッチでもインライン最適化できると主張するのはペテン師

Rust は struct+Trait でオブジェクト指向するより
enum でオブジェクト指向した方が良い
class指向ではなくenum指向言語
どうせ部分コンパイル分割コンパイルしたくても
ほとんどのケースで全体再コンパイルになる糞言語Rust

>>692
classやstructやtupleは代数的データ型の直積型
Rustのenumは代数的データ型の直和型
性質が真逆なものであり互いに代わりになれない

性的ディスパッチと書くと途端に椎名林檎臭が漂うな

>>689
いやそれ、局所的に見たらそうだけどさw
コード上で条件分岐で書くとどうだろって話だからな

>>691
深呼吸して冷静になって聞いてもらいたいんだけど、最適化うんぬんいぜんに君が言ってることは論理的に間違ってる

> 分岐後の部分には動的ディスパッチが存在しないからインライン最適化できるのは当たり前
> それを動的ディスパッチでもインライン最適化できると主張するのはペテン師

・動的ディスパッチが存在することをDと置く
・インライン最適化できることをOと置く

> 動的ディスパッチが存在しないからインライン最適化できる

¬D⇒O

> 動的ディスパッチでもインライン最適化できると主張するのはペテン師

D⇒¬O

¬D⇒Oが真であってもD⇒¬Oが真になるとは限らないので
推論として妥当ではないんよ

¬D⇒OとD⇒¬Oの関係は一般に「裏」と言われる
「元の命題が真でも、裏が真とは限らない」
と覚えて帰ってください

プログラマで論理が苦手な人は珍しいね

いや動的ディスパッチでもインライン化できるはペテン師じゃん
誇大広告じゃん

プログラム言語上は(1)動的ディスパッチであってもJITを含むコンパイラでインライン化されたものは「静的ディスパッチ化」されてるので(2)動的ディスパッチではないってことになってんだろ

ペテン師は(1)と(2)をわざと区別しない

やっぱり静的ディスパッチに書き換えられるんだなw

>>698
1. 静的ディスパッチ→インライン化 (Rustがコンパイル時に行う最適化)
2. 動的ディスパッチ→インライン化 (JITが実行時に行う最適化)
3. 動的ディスパッチ→静的ディスパッチ化 (JITが実行時に行う最適化)

の3つがあってRustでは1.しかできないから
インライン化には静的ディスパッチ化が必要なんだと思ってるんでしょ？
君の認識は完全に間違ってる

動的ディスパッチはインライン化できないことのソースを示すことはできる？
何を根拠に君がそう言ってるのか教えてもらえればコメントするよ

>>699
> やっぱり静的ディスパッチに書き換えられるんだなw

へぇ、今日一意外な言葉
君は自分が憶測で物事を語っていることを自分で認識できる人なんだね、意外だった

>>699
動的ディスパッチを静的ディスパッチに書き換えることは絶対にできない

>>700
＞ 3. 動的ディスパッチ→静的ディスパッチ化

これは不可能

ああ、人間ハルシネーションの人とは別人か

型が決定すればいいんでしょ？

RUSTもPGO使えば1,2,3できない？

動的ディスパッチ自体は必要だけど使い方次第ではコストがかかるんだから
オブジェクト指向のために使うってよりはどこで動的ディスパッチをすると最も効率よい処理ができるかで考えたいわ
だからクラスは嫌い

PGO（profile guided optimization）を用いても
どんな言語でも動的ディスパッチを静的ディスパッチにすることはできません
動的ディスパッチを跨がるインライン最適化もできません

まあif文もだめよってことならそうだろう
インライン化ならif文は許されるイメージが一般的なんじゃないか、俺はif文も少なくしたいけど、少ないに越したことはない

そもそもif文すら許されないなら否ディスパッチじゃない？

動的か静的化さかってvtable見るか見ないかの違いじゃないの？

そもそもメソッドを呼ぶごときにいちいち選択を強いるオブジェクト指向ってどうなのよ？ってのがデータ指向派の主張だけど

>>713
多くのケースで単相化により静的ディスパッチにすることができるため最大限のインライン最適化が可能
それをどこまでやるかはプログラミング言語によって異なる

>>714
ジェネリックならそうだろう、それはC++でも同じ
でもそれってオブジェクト指向なん？

選択をさせないなら関数のオーバーロードでええやん
クラスなんていらん構造体でよい

型判定はしかるべきタイミングで行う
それはコントロールが必要なことだから

静的に決まらない型を使うからいけないんだろ？

オブジェクト指向ってプログラムコード量を減らして可読性を上げるためのもので実装はいろいろあって良いんだよ。
ただそれでメモリバカ食いで爆遅になったら嫌だという人のためにC++とかの中途半端な言語が存在してる。

>>709
動的ディスパッチでもインライン化できるということは納得したみたいだね

JITコンパイラがインライン展開後の分岐除去とか定数伝播まで面倒見てくれるならOK
静的ポリモーフィズムでコンパイル時に時間使った方がいいとは思うけど

>>720
動的ディスパッチはインライン最適化ができないよ
動的ディスパッチの前後で必ず分断されちゃう

まだやってらw
動的ディスパッチも分解して分岐にしたらいいんだろ？

静的だろうが動的だろうがメソッドの呼び出しと何のメソッドを呼び出すかの判定は別の話
そこを一緒にまとめようとするのはよくないねえ

分岐先アドレスをプログラムコードから取得するのとメモリから取得するのとでどれだけ速度差が出るのかねえ。
特にx86プロセッサは高いメモリアクセス頻度に対応した造りになってるから。

>>723
動的ディスパッチは大量分岐が起こるから各型用のメソッド関数アドレステーブルを見に行く仕組み

メリヤスパッチの股引を履いてそうだな

>>725
各オブジェクトがメソッド関数ポインタ配列のvtable相当へのポインタを持っているんだよ
データとしてやってきたオブジェクトから順に辿って行く

>>695
i に 0 と 1 が入ってるとき
let hoge = if i == 0 { false } else { true }; が条件分岐
let hoge = [false, true][i]; が関数ディスパッチ

現実には多数の候補があるから
オブジェクトにvtableへのポインタを持たせてる
vtableは各メソッド関数のアドレスの配列テーブル
そうすることで各オブジェクト毎にポリモーフィズムの正しいメソッド関数が呼ばれる

データとしてくるからデータキャッシュを汚す

そもそもメモリを読むってのはクソ重い

お前らなんで最適化の話しかしてないんだｗ
早計な最適化は諸悪の根源だぞと

最適化というより構造的弱点
俺はメソッドの選択はデータ側の都合に合わせるのがプログラムでは良いというデータ指向派

あと抽象化はプログラム言語にはもういらないというイーロン・マスク派

たしかにねえ、抽象化は人間が物事を理解した気になるためのものでしかない気がするわ、抽象化に拘ると伸びしろがなくなるような気はしている

>>733
速度の話は単純で安直に取り組み易いからな
目的や実際の効果は横に置いておいて手段が目的になる典型なんだよ

抽象化がいらないってことはないが、まあその手のモジュールはもうそろってるって状況ではあるかもね

抽象化なんて、動いた気になるだけの危うい技法だもの

>>733
話がされている最適化はコンパイラが全てやってくれる
プログラミング言語によってピンキリだが

コンパイラのために人間が頑張る言語
それがRust

>>741
それはC/C++
Rustは他の言語と同じくメモリ自動解放

両方ともしんどい言語だろ
人間には優しくない

Rustはめっちゃ楽

class原理主義プログラマーにとってclassのない言語はどれも難しく感じるらしいよ
class継承が使えないとプログラミングできない重症な人たちまでいるみたい

Rustは参照カウントとか循環参照とかを知っていて慎重にプログラムを組まないとListを安全に実装できないがJavaは何も考えずに実装してもメモリリークすることがない、そういう意味ではRustはしんどい

Javaでネイティブメモリを使うコードのメモリ管理をやろうとするとtry-with-resourceを使って慎重に実装しないといけないがRustは何も考えずに実装しても解放漏れがない

何事も一長一短

>>745
クラスとかそういうの関係なく君は何かプログラム書ける人なの？

構造化すら無いイニシエのBASICユーザーだけど
クラスあんのは本当に書きやすいよ

>>741
だよな
漏れのある抽象化だらけだもんな
asyncは特に悲惨

>>749
pollすれば進むから他より自然に理解しやすい

>>745
javascriptのprototypeもあれはあれで良かったが結局class導入されちゃったし馬鹿しか使わないんだろうな

ダメなプログラマーかどうか判別しやすい
クラスを持たない言語が多数派だけどそれらを使えない患者

そんなの判別してどうすんだよ──

オナニーのオカズにでもすんだろ
変態の考えは理解できん

クラス継承が問題児なだけであってクラス自体は中立なんだよ

自分は悪くない道具が悪い！

>>746
Rustでも循環リストはもちろん循環グラフも簡単に安全に扱えてメモリリークしないですよ
例えば有向グラフ

fn main() {
let nodes = Arena::new();
let node0 = nodes.new_node(123); // ノード作成
node0.add_adj(node0); // 自分自身を指して自己循環
let node1 = nodes.new_node(456);
node0.add_adj(node1);
let node2 = nodes.new_node(789);
node1.add_adj(node2);
node2.add_adj(node0); // node0 - node1 - node2 - node0 長さ3循環
}

なんでそんなにRust推しするのか
不思議な心理だ

読み書きしやすくて速いからでしょ

>>757
AIによるとその実装はメモリがArenaで管理されてArenaが破棄されるまですべてのノードのメモリがアリーナで保持されるからノードの追加と削除を繰り返すとメモリ使用量が増え続けるそうだよ、ノードを削除してもメモリが解放されないならそれはもう緩いリークなんじゃないかな安全とは思えないな

>>760
プログラミングしたことないのかね？
どの言語でもノード削除するたびにメモリ解放なんて効率悪いことしない
まとめてメモリ解放する
そして解放されることをメモリリークと呼ぶ人はいない

>>761
Javaではオブジェクトのメモリは解放されるよ
>>757でいうとノードを削除したらノードのメモリがアリーナに返却されて使い回されるんよ

> まとめてメモリ解放する
> そして解放されることをメモリリークと呼ぶ人はいない

程度によるんじゃないかな、プロセスが終了したらメモリは解放されるわけだし
まとめて解放されるからメモリリークじゃないと言い出したら
メモリリークはこの世に存在しなくなる

不要になったメモリが意図せず残り続けることをメモリリークというなら
>>757は緩いメモリリークだよね

なぜGC言語はメモリ使用量が多いのかというと
そういう意味でのメモリリークをし続けているためだよ
たまに掃除GCするけど掃除のためにも余分にメモリを消費して使っていないメモリ領域が残る

不要になったメモリーが解放されない事をメモリーリークって言う
の間違いだよね？

>>764
厳密にはJavaではGCで回収されるまでタイムラグはあるけど
解放可能な状態になるってこと

>>757はArenaに返却可能な状態っていうのがないのよ
ノードが削除されてノードを使うことができなくなっても
ノードに割り当てられたメモリはArenaに返却されないから
別のノードに割り当てることができない、典型的なメモリリークです

おまえらアホだな
メモリはOSに返却しない限りメモリ管理ランタイムが保持し続けるんだぞ
解放したと思い込んでるだけで現実には未使用中フラグが付けられるだけだ

クラスと型の違いって何かな？
Rustにもスーパートレイトといった継承みたいなものがあるし、何を持ってクラスと型の違いとするんかな？

Rustではslabを使えば良いんだが
https://github.com/GallagherCommaJack/linked-slab/blob/master/src/lib.rs

> 慎重にプログラムを組まないとListを安全に実装できない

な、このとおりだろ

同じだよ

>>766
GCの有無に関係なくArenaをサポートしているプログラミング言語が多い理由は効率が非常に良いためです
Arenaでは部分返却はせずに使い終えるときに一気にメモリを解放します
GCよりもとても効率的なのでGC言語でもArenaをサポートしているのはそのためです

>>767
話を整理しよう

・OSのメモリ
・ランタイムのメモリ
・オブジェクトのメモリ
これらがあって

・OSのメモリがランタイムに割り当てられる
・ランタイムのメモリがオブジェクトに割り当てられる
という関係のときに

(A)オブジェクトのメモリがランタイムに返却されないこと
(B)ランタイムのメモリがOSに返却されないこと
があって

私は(A)をメモリリークと呼んでいる

サーバー系もArenaと相性良いんだよ
リクエストが来たらArena作ってそこで色んなメモリ使いながら色んな処理
最後にレスポンス返したらArenaまとめて解放がどの言語でも最も高速なの

>>771
RustになぜArenaがあるのかを私は疑問に思っていないのでArenaがサポートされている理由を説明されても「お、おぅ!」としか私は言えないわけですが、RustにはArenaもあればSlab、SlotMap、Rcもありますね、選択肢は多い、しかし、その選択肢の多さがRustにおいてListの実装を難しくしている面がありますね、プログラマが知識を持ってユースケースを適切に判断して正しい選択をしないと安全なプログラムを書くことができない

それがRustのしんどいところということです

ListはPythonでは伸び縮みする配列のことだけど自作するモノ好きはいないよ
Python以外でもライブラリにあるでしょ

Listはしんどいところがあることを説明するための例としてあげただけ
Listがあると言われても今日は気温が30℃になるそうだからみなさま体調にお気をつけてお過ごしくださいとしか思わないわ

>>769
そのslabを使った実装も解放されてないでしょ
compactを呼べば解放されるけどリストが壊れる

些細なことで揉めてるな
ガベージコレクションが始まるまでゴミ溜めたまま解放しない言語もあるんだぜ

>>761
人それをガベージコレクションと言う。

>>778
Rustの欠点なので些細なことにしたいのですね
その気持ちよくわかります
ただ>>757のようなゴミ実装と一般的なガベージコレクションを混同してはいけません

C言語ではアリーナ方式のメモリ管理が20世紀から使われてきていてメモリをまとめて確保して一気にまとめて解放は常識なんだが

人材にもガベージコレクションが必要ですよね

まともにメモリ管理のできないMS-DOSなんか使ってたらランタイムの方で何とかしないとまともに動かないからな。

>>780
アリーナ方式やリージョン方式と呼ばれるメモリの一括解放方式はRustが生まれる何十年も前から行なわれてる定番の方式ですよ