オブジェクト指向はオワコン？ 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/

>>435
この分類はオブジェクトのlifetimeの分類であって変数のextentの分類ではない

>>446
じゃあ分類してみろよ

区別できないやつ多すぎじゃね？

クロージャに閉じ込めた変数のextentが尽きるタイミングが定まらないいい加減な言語とかもな
その状況だと分類は論外

>>446
合致すると思います

それは気のせいでしょう

static char s[SIZE];

auto char *sp = s;

for (register char *p = s; p - s < SIZE; p++)
　*p = 'a';

Q: s, sp, p の lifetime は？

static char *s = malloc(SIZE);

auto char *sp = s;

for (register char *p = s; p - s < SIZE; p++)
　*p = 'p';

Q: s, sp, p の lifetime は？

Cの変数のlifetimeつまりextentは単純
グローバルとstaticはstatic lifetime
それ以外はautomatic lifetime

>>454
ざっくりいうとそうとも言えるね
変数のextent(lifetime)が(基本的に)lexcal scopeに綺麗に対応するのがCの美点だったし
それまであった言語FORTRAN 66等からの大きな進化だった。

C,C++の｢変数｣にdynamic lifetimeというものはないの？

変数のlifetimeは結論出てる通り
参照のlifetimeはmallocすればdynamic lifetime

ID:KHkfRTGT 変数とメモリオブジェクトの混同 しつけぇｗ

>>456
>>445

>>453
変数sのlifetimeはプログラム終了まで存続するstatic lifetime
参照sのlifetimeはfreeで解放すれば消えるdynamic lifetime

>>459
じゃあ>>453の最後に数行追加してsを下記のように使いまわしたらｓはdynamic?

static char *s = malloc(SIZE);

auto char *sp = s;

for (register char *p = s; p - s < SIZE; p++)
　*p = 'p';

static char t[SIZE];
s = t;
s[…] = …

sはstatic変数のpinterなのにdynamicとはこれ如何に

既に何度も出てきただろ
参照(ポインタ)は関数へ受け渡したり他の変数へ格納することができる
格納する変数側も別の参照へ切り替えることができる
別の参照に切り替えれば参照のlifetimeは変わる

static変数のlifetimeが何をpointしているかによって変化する？
こらまた陳説が飛び出してきたな

そしたらGC言語ではメモリオブジェクトのlifetimeがreference０になるかそのあとGCで回収されるまでのpermanentなので
メモリオブジェクトにbindする変数はすべからくpermanentということになってしまうぞ
どうすんのこの矛盾ｗ

>>461
君だけ変数のlifetimeと参照のlifetimeの区別を理解してないようにみえる

じゃあLispにはdynamic bindingなどというモノはなかったということになるなｗ
論文書けｗ 論文書いて世に出して世界中の笑いものになれｗ

>>465
文もう？
混同してる人に区別すべきだと話をしてるんだが

>>466
dynamic binding
↓
dynamic extent

>>466
Lispのdynamic bindingはスコープを超えてグローバルに作用するシャドーイングのことだぞ
混乱の元なので推奨されない
スコープに従うレキシカル・バインディングいわゆるシャドーイングが推奨される

入籍してなければ単に彼氏では

>>469
だから誤記だって。
>>468で直したろ。bindingとextentの対比などに話がそれるともっと難しくなって凡百がついてこれなくなるので話そっちに向けたくない

>>468で話が出ちゃったけどshadowingは典型的なdynamic extentの一例。
そしてリスクも伴うため、言語によっては禁止またはwaringになるが、言語によっては許容している。

Common lispは許容している。Perl Pythonも。gcc,CLANGもデフォで許容（warnig optionつけると検出可）
Javaは確かWarningが出た希ガス。C#は禁止。Rustはshadowｉｎｇの設定次第

Common lispが許容するにはチャント理由がある。マクロでのconlit回避や
関数型プログラミングにおける再定義上書き回避などの理由による

>>471
warning
conflict

書きなぐると誤記増えるなｽﾏｿ

>>468
dynamic extent宣言するとlispコンパイラがその変数をスタック上に置く最適化ができるんだよ
言語によって意味が変わるから言語を超えた話で用いると混乱して難しいね

うん。この辺の話は意外と難しいんだよね。
でもプログラミング言語の基礎であり原理
それを勉強しない、正しく理解せずに感覚や慣れで変な持論を信じたり
漫然とコーディングしている人、いかに多いかってことだよね。
そういう人たちがコンピューターサイエンスやソフトウエア工学の基礎をないがしろにした
不適切なオブジェクト指向の流行した土壌になっていたのかなと
最近では思っている
ま、ソフトウエアを作るってことのすそ野がそれだけ広がったともいえる。
でもそれも生成AIの発達で大きく様変わりしそうだが

スタック上に置くということは
Lispのdynamic extentは>>435の分類だとautomatic lifetimeになるね

いろいろな言語に話を展開すると、autoのextentは解釈としてdynamicにカテゴライズされるのが一般的だと思うけどそれがなにか

auto変数は本来Lispの様な言語に必須のものではないんだけれど、
lexcal変数を扱う処理のsemanticsが維持できればcomplierの最適化によって生成コードではstack上に(auto変数領域)に割り付けられる
こ・と・も ある

>>476
厳密に言うと、auto変数というよりも、auto変数が割付られたメモリオブジェクトへのbindingというべきかな
ﾏﾝﾄﾞｸｾ

広義ではどちらもdynamic lifetimeだけど区別すべき大きな違いがある
automatic lifetimeはブロックや関数を抜ける時に解放してよいメリットがある
狭義のdynamic lifetimeはいつ解放してよいのかわからないためGCに任せるかC言語のように手動管理になってしまうデメリットがある

やっぱりlifetime（メモリm部ジェクト）とextent(変数・シンボルbingind)は分けて考えたほうが話が明快になると思うけどな

レジスタに乗せる数値がどこから来たかって分ける必要あるもんなの？
アドレスとメモリならまだわかるが変数って広くない？

lifetime respect

>>479
lifetime（メモリオジェクト）とextent(変数・シンボルbingind存続期間)

>>480
値渡しか参照渡しかによるんじゃね？

乱暴に言うけど言語仕様でスタックとかで引き回す値のことを変数とするみたいな感じ？

に・日本語で…

レジスタに何の値を入れたいか？を意識してるときメモリと変数は違うってことだよね？

役割が違うから区別しましょうということ何だよね？

グローバル変数Xの値とグローバル変数Y[]の配列
ここで区別つけなきゃいけないのはグローバル変数X ,Yのアドレスを収納してるメモリとそのアドレスがさすメモリ
これは区別つけなきゃならないもの
ってこと？

っ 子ども電話相談室

えー子供にも教えてよ

なんで区別つけなきゃいけないのかがわからん

小学校にもあるんじゃないの？プログラムの授業

まあ教える気はないというのは伝わった

とても重要と思ってるようだから気になるんだよなあ

なに言ってんだかいまいちわかりにくいし
この人に教え始めると一から延々・長々色々説明にゃならなくなりそうで�_
しかも途中で頓珍漢な質問や反論喰らったり道草しそうだし
いつ果てるともない

そこまでの時間と労力を持ち合わせていない

これ見てでもいいよ、短かったりAIに、要約してもらえるようなものだとありがたい
というか説明が大変な概念というのも伝わった

479って、何のことってAIに聞けばいいのかな、やってみるか

せめて質問の内容を明確にしないと
何も言えないじゃん

メモリオブジェクトのlifetimeとそれにbindする変数のextentは異なる概念なのか？ - Google 検索
ttps://www.google.com/search?q=%E3%83%A1%E3%83%A2%E3%83%AA%E3%82%AA%E3%83%96%E3%82%B8%E3%82%A7%E3%82%AF%E3%83%88%E3%81%AElifetime%E3%81%A8%E3%81%9D%E3%82%8C%E3%81%ABbind%E3%81%99%E3%82%8B%E5%A4%89%E6%95%B0%E3%81%AEextent%E3%81%AF%E7%95%B0%E3%81%AA%E3%82%8B%E6%A6%82%E5%BF%B5%E3%81%AA%E3%81%AE%E3%81%8B%EF%BC%9F&&hl=ja&source=hp

はい、メモリオブジェクトの「ライフタイム（Lifetime：寿命）」と、それにバインドする（結びつく）変数の「エクステント（Extent：存続期間 / 記憶域期間）」は、異なる概念です。
これらは混同されがちですが、前者は「データ（メモリ領域）そのものがいつまで存在するか」を表し、後者は「変数名（識別子）がいつまでそのメモリを指し示しているか」を表します。
その違いと関係性を整理して解説します。
------------------------------
## 1. 二つの概念の定義

* 変数のエクステント (Extent / Storage Duration)
* プログラムの実行中、その変数名（識別子）がメモリ上の特定の場所（オブジェクト）に有効にバインドされている期間のことです。
* 例えば、関数のローカル変数は「関数が実行されている間」だけエクステントを持ちます（自動記憶域期間）。
* メモリオブジェクトのライフタイム (Lifetime)
* メモリ領域（オブジェクト）そのものが確保されてから、解放（破棄）されるまでの実際の期間のことです。
* この期間中、そのメモリは有効なデータとして保持され、アクセス可能です。

------------------------------
## 2. なぜ異なる概念なのか（不一致が起こる例）
多くの場合、変数のエクステントとオブジェクトのライフタイムは一致しますが、これらがズレる（異なる）ケースを考えると違いがよく分かります。
## �@ エクステントが終わり、ライフタイムが続くケース（メモリリーク / 迷子オブジェクト）
C言語やC++の動的メモリ割り当て（malloc や new）でよく起こります。

void create_object() {
int* ptr = (int*)malloc(sizeof(int)); // メモリ（オブジェクト）を確保
*ptr = 42;
// ここで関数が終了する
}


* ポインタ変数 ptr のエクステント： 関数 create_object の実行終了とともに消滅します。
* オブジェクトのライフタイム： free() が呼ばれていないため、関数が終わった後もメモリ上に存在し続けます（ライフタイムは継続）。
* 結果： 変数（名前）がないのに、メモリ領域だけが残る「メモリリーク」が発生します。

## �A ライフタイムが終わり、エクステントが残るケース（ダングリングポインタ）
確保していたメモリが先に解放されたにもかかわらず、変数（ポインタ）がまだその場所を指している状態です。

int* ptr = new int(10);delete ptr; // オブジェクトのライフタイムはここで「終了」
// ptr という変数（名前）のエクステントはまだ続いているif (ptr != nullptr) {
// *ptr = 20; // ライフタイムが終了したメモリへのアクセス（未定義動作）
}

* 変数は存在しており、特定のメモリ番地を指し示し続けていますが（エクステント内）、その先にあるオブジェクトはすでに消滅（ライフタイム終了）しています。

## �B 1つのライフタイムに、複数のエクステントが関わるケース
C++の参照（Reference）や、Pythonなどの参照カウント言語が分かりやすい例です。

def process():
a = [1, 2, 3] # オブジェクト（リスト）のライフタイム開始
b = a # 同じオブジェクトに別の変数 'b' をバインド
# 'a' や 'b' のエクステント（スコープ）が切れても、
# 参照がどこかに残っていればオブジェクトのライフタイムは続く

ひとつのメモリオブジェクトに対して、複数の変数名がそれぞれ異なるエクステント（存続期間）を持ってバインドされることがあります。
------------------------------
## 3. まとめ（比較表）

| 概念 | 焦点を当てている対象 | 意味 |
|---|---|---|
| 変数のエクステント | 変数（名前 / 識別子） | その変数名が、いつまでメモリと結びついているか（言語仕様・スコープに近い） |
| オブジェクトのライフタイム | メモリ（データ実体） | そのメモリ領域が、いつからいつまで有効に確保されているか（システム・実行時の状態） |

Rustなどのモダンな言語では、この2つのズレ（ダングリングポインタやメモリリーク）を防ぐために、コンパイラが「所有権（Ownership）」や「ライフタイム（Lifetime）」を厳密にチェックする仕組みが導入されています。
------------------------------
さらに具体的なプログラミング言語（C++、Rust、Java、Pythonなど）における挙動の違いや、「スコープ（Scope）」との違いなど、詳しく知りたい部分はありますか？

AIさん子供電話相談室としても優秀だなあ
全てが理解できたわ

あ、ありがとう

次からは金取ろうかな…ｗ

479側の「概念を分離しないから議論が混乱している」という指摘は正しい。
特に、
pointer変数
≠
pointerが指しているobject
なのに両方を「参照のlifetime」「変数のlifetime」などと曖昧に呼んでいる部分への批判は妥当です。
ただし479自身の
lifetime → メモリオブジェクト
extent → 変数・symbol binding
という二分法も、普遍的な正式定義として採用するには少し単純化しすぎています。
より安全なのは、
┌─ scope
名前 / binding ──┤
└─ extent

storage ─────────── storage duration

object ──────────── lifetime

reference / borrow ─ Rust等では独自のlifetime概念
とすることです。

このスレを読むための「翻訳機」
今後このスレで誰かが、
「変数のlifetimeが～」
と言ったら、頭の中で即座に、
「変数の何？ 名前のscope？ bindingのextent？ 変数objectのlifetime？ storage duration？」
と問い直してください。
また、
「参照のlifetime」
なら、
「pointer変数自身？ pointer value？ 指されているobject？ Rustのborrow？」
と分解します。

翻訳機ありがたい

なんだ、結構わかってんじゃｎ坊ちゃん。
つかＡＩの回答抜粋？

そうだよ子供電話相談室に聞いたよ

よし、いい子だ。小遣い上げる。
っ �I

>>499
>変数のエクステント (Extent / Storage Duration)
Storage Durationはメモリオブジェクトのライフタイム (Lifetime)のほうだろ

RUSTの借用中は所有権をmoveできないという仕様を知って謎は全て解決したわ

※複おじ流の使い分け
「変数pのlifetimeが〜」と言ったらbindingのextent
「ポインタpのlifetimeが〜」と言ったらポインタが指すオブジェクトの存続期間

無理があるわな

ポインタじゃなくてRustの参照になるとまた話が変わるのか
ややこしいな

Rustは公式に変数のlifetimeと参照のlifetimeの2つしか出て来ないからシンプルだよ
しかも参照のlifetimeは参照先を所有している変数のlifetimeと同じ

それがRustがGC使わずに安全に自動解放できる理由だよ
つまり静的に参照のライフタイムを追うことができて
所有者の変数のlifetimeが終わる時に所有している領域が解放されるためlifetimeが同じになる
(正確にはRc/Arc使用時に他の共同所有者がいれば全員いなくなるまで解放が先延ばしされる)

それってreference countとどう違う？

CGとreference contに頼らず頑張りましたっ!!!
ってところが違うんだろうな。

Javaも
基本データ型（プリミティブ型）：int, double, boolean, char などの変数は
スタック領域に割り付けられるが

参照型：String、クラス、配列、インターフェースなどについては
データの実体はヒープ領域に作られ、変数にはその場所が記録される

したがってメモリ安全性という観点からみると、
C,C++あたりを除けばみんなどの言語も大差ないんよ

>>516
そのままreference countの略だよ
ただしreference countのGCとは二つの点で異なってる

1つ目は所有者が複数必要になる時のみ使う
一番わかりやすい例だとマルチスレッドで共有する場合どのスレッドが先に終えるか保証できない時に各スレッドに所有者が必要
全ての所有者がいなくなると解放

2つ目は所有者が増減する時しかカウンタが増減しない
各所有者から参照を得る時は通常と同じでカウンタは増減しない
つまり付加コストは最小限

フラグメントを解消する手段がなさそうなので、
領域の作成や解法を繰り返すとメモリ使用効率が劣るんだろうな

C++もRustもベクタなど長さが大きくなる時はヒープ領域上で使用領域をお引越しするぜ
ちゃんとアドレスが変わる

じゃあ実質GCと同じようなもんじゃん

それはそういうコンテナを使用したらだよね
言語仕様とは別の話じゃない？

だよな、坊ちゃん

仮想アドレス＋ページングと小規模メモリアロケーターで解決できない断片化はそっちでなんとかしてってことで
フラグメントを解消するという重い処理はやらないよってところが特徴なんだし

ベクタは各言語の規格書相当に存在するから言語仕様でしょ

まあ言語仕様でもいいけどコンテナも色々アルゴリズムがあるからまあアロケーターも色々アルゴリズムがあるしおんなじもんか

しょうがないよ旧日本軍は中国人を3500万人虐殺したんだからさ

全くだ世の中ママならんね

ベクタ等の確保領域移動はメモリのバルク転送だけだからGCと違ってコストもかからないね

※大きい領域が少数個数の場合はね

Vectorは使わない！絶対にだ！
ぐらいの勢いで作れば大丈夫だよ実際必要なことはない
パフォーマンス第一なら

そいや数年前のJava18の話だけど
24365運用のシステムでずっと実行中のJavaプログラム、
まれに停止したようになってた希ガス

ベクタの移動コストはO(1)なので無視できる
2^nが満員になると2^(n+1)へ転送するだけ
高は

まあお願いベクターでメモリ見積もり誤魔化すときはあるけど
罪悪感はある

ベクターでヤバいのはC++のこれ
こんな単純なコードでも大変なことが起きてしまう

void vector_test() {
std::vector<int> v{0, 1, 2, 3, 4, 5, 6, 7};
int& fifth = v[5];
v.push_back(100);
std::vector<int> w{8, 8, 8, 8, 8, 8, 8, 8};
fifth = 555;
std::cout << "v[5] = " << v[5] << std::endl;
std::cout << "w[5] = " << w[5] << std::endl;
}

Rustなら大丈夫だよ

だれかRustの弱点晒したれや!!

>>537
RustとAIは信者の絡みがキツい時がある

基地外がいなくなるだけで過疎ｗ

>>535が指摘されたら消えたな

真のオブジェクト指向言語Javaなら問題ないよ

Javaが何故、多重継承をサポートしていないのかを考えたことがあるのか？

>>541
＞真のオブジェクト指向言語Javaなら問題ないよ

親子は別人なので銀行口座を明確に分離する——こうした「責任と境界をはっきりさせる必要があるシステム」では、多重継承を排したJava的な設計が適しています。曖昧さを許さず、単一の責任と明確な所有関係を強制する方が、安全で運用しやすい。
一方で、クリントンの「不適切な関係」はまったく異なる構造を示しています。
同一人物の中に「別のクリントン」が暴れている、という状況です。社会的・公的なクリントンと、ムスコ（チンポ）を通じて勝手に振る舞いを決めてしまうクリントンが、同じ身体の中に共存している。上位の意志がどれほど強くても、その内部オブジェクトの自律的な動きを完全には止められない。

>>542
荒らすなカス

>>541
Javaはそのオブジェクト指向でどう解決しているの？

>>535はベクタvに新たな要素がpushされたら確保していたヒープ領域を超えたので大きなヒープ領域を新たに取り直してそこへ移動した
その後にベクタwが作られて旧ベクタvの領域が割り当てられた

参照fifthの立場としてはベクタvの5番目を指していたのに知らぬ間にベクタwの5番目を指していた

>>544
ポインタを無くした