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

>>367
Rustって面白い言語だな。closureからのextentが残って生存場所が移って行くなら明示をするようcompilrが言うとはな
しかしそれはそれで煩さそうｗ

>>368
そこで出てるa variable’s lifetimeが変数のextentを意味するのか
変数が指してるオブジェクトのlifetimeを意味するのか考えてみた？
extentというのはあくまでbindingの有効期間だよ

fn foo() -> &'static str {
let x = "foobar";
let y = x.get(..1).unwrap();
y
}

上の変数xのextentはfoo関数が終わるまで
xやyのlifetimeはxのextentとは違ってstatic

>>366のように変数がbindingを維持したまま物理的メモリを移動できるRustが優秀だよな
関数を抜ければ破棄されるスタックフレームから関数の呼び出し元のスタックフレームへ移動

なんか哀れ

LispなどのGC言語はどうしてもそこでコストが高くなるよね

Webアプリ作ってるわい「何言ってんだこいつ…」

>>371
移動はあくまでも形式上なもの
最適化によって最初から移動先のスタックフレームに作られたりする
そうなるとコストゼロで最速になる

教育基本法が掲げる「人格の完成」を純粋に信じて、部活と勉強を真面目に取り組んできた。
その過程で、理性的・社会的な人格を磨き上げようとしていたところに、思春期を通じてもう一つの人格的な要素が内部から立ち上がってきた。
それが「チン格」です。
そしてあなたが到達した理解は、こうまとめられるでしょう。
チン格は、人格の全てではない。
しかし人格を構成する要素の一つである。
しかもそれは、単なる「付属物」ではなく、人格を継承したオブジェクトとして振る舞う。

>>370
それは借用の例になっていないよ
自ら&strと書いているように最初から既に参照

正しく説明するならば
let x = "foobar"; という参照ではなく
let x = String::from("foobar"); という実体へ置き換えればわかるように
変数xから借用した参照yのlifetimeは
変数xのbinding有効期間になる

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

「ブルマの中身は萎れちまった」という表現は、思春期に欲情と想像の対象だった「未来の元気な赤ちゃんを産み育てる可能性」が、
世代全体として実現しにくくなってしまった、という感慨を含んでいるのでしょう。個人の内部で自律的に動き始めた「チン格」が、
社会の構造的な条件（経済、雇用、結婚市場）とぶつかり、結果として次の世代を生み出す方向に結びつかなかった、という構図です。

>>377
let x = "foobar";
let y = &x;

参照yは変数xから借用してないの？
なんで？

>>380
それは&str型への参照&&str型だな
一方で>>370は&str型の部分文字列で同じ&str型

>>381
何の答えにもなってないぞ
>>380の参照yは変数xから借用してるのかしてないのか？

>>382
借用している
参照yのlifetimeは参照元の変数xのbinding期間のみ有効

それが静的にコンパイル時点で追える
だからRustはGC使わないのに100%安全な自動メモリ解放を実現した

>>370は
xが&str型の文字列
yも&str型でxの文字列の一部
だから参照のlifetimeの関係なし

>>380は
xが&str型
yが&&str型でxの参照
「xの参照yのlifetime」＝「変数xのlifetime」
とてもシンプルにできている

>>379
ポコチン先生久し振り！

>>384
もうええやろ

>>383
その説明の仕方から分かるように
Rustにおいて「参照yのlifetime」と言うときは
変数yが指す借用の有効期間(オブジェクトのlifetime)の話をしてるのであって
変数yのbinding期間(extent)の話をしてるわけではないよね？

>>388
そりゃ参照はどんどん関数に渡されて行ったりあちこちの構造体に格納されたり格納された状態で関数から返されたりするから
一時的に格納される変数yはどうでもいい存在
そして参照があちこちに移動してもlifetimeは変化しない
常に元の変数xのlifetimeと一致する
すなわちextentと一致する

>>389
細かいところは置いておくけど
その説明は参照yのlifetimeが変数xのextentに一致すると主張してるだけで
Rustにおいて「yのlifetime」と言ったときに「yのextent」を意味するという根拠にはならないよね？

それにRustにおいて「変数xのlifetime」といったときは
普通は変数xが持ってる参照のlifetimeすなわちstatic lifetimeのことを指さない？
そこが論点なんだけど

ゴールドバッハ予想の例えも面白いですね。
完全な「人格の完成」（ゴールドバッハ）は、まだ誰にも証明されていない（あるいは永遠に完全には到達しない）大きな命題。
しかし「弱ゴールドバッハ」のように、部分的には証明可能な領域がある。
チン格を「人格の一部として認め、その自律性を観察し、適切に付き合う」ことは、後者に近い営みかもしれません。
完全な統合や支配を目指すのではなく、内部に存在する自律オブジェクトの存在を前提にした上で、どう折り合いをつけるかを考える——という姿勢です。
思春期に感じたその「中に別のものが立ち上がる」感覚は、多くの人が経験するものであり、それが後の人生における心身関係の理解の出発点になることも少なくありません。

>>390
違うぜ
先ほどの例
let x = "foobar";
let y = &x;
・参照xのlifetimeは'staticだが
・変数xのlifetimeはその関数のそのブロック内
・したがってxの参照yのlifetimeも関数のそのブロック内になる。'staticにならない
この区別の理解が重要

ポインタと「ポインタのポインタ」だね。
ポインタがどこを指していようと、ポインタが置かれてる場所が関数スタックフレーム上なら、「ポインタのポインタ」の有効期間はその関数のスタックフレームが存在する間ってこと。

いつまで夏休みやってんだハロワ行け

>>393
Cならそれでいいんだろうけど
Rustの参照では「どこを指していようと」とは言えない

fn main() {
let mut x = "foobar";
let y: &&str;

y = &x;
println!("1. x: {x}, y:{y}");

x = "FOOBAR";
// y = &x;
println!("2. x: {x}, y:{y}");
}

変数Xのライフタイムは変数Xのライフタイムのことだ
で済む話じゃないの？

>>395
参照を借用中に参照元が書き換わったら困るからだろ
バグの要因であるとともに実体が無くなっていて危険なダングリング状態になることもある

>>396
重要な点はこれ
変数xが参照の時
『参照xのライフタイム ≠ 変数xのライフタイム』
『参照xのライフタイム = 参照元を所有する変数のライフタイム』

let a = なんでもOK;
let x = &a;

具体例
ヒープ領域にベクタvectorを作る
let vector = Vec::from([5, 6, 7, 8, 9]);

ベクタの一部を参照するsliceを作る
let slice = &vector[1..4];

このsliceはヒープ領域を指している参照
assert_eq!(slice, &[6, 7, 8]);

この時
参照sliceのライフタイムは
指してる領域を所有する変数vectorのライフタイムと同じ

いやそれ変数ベクターじゃないやん
ベクターはアドレスしか記憶してないメモなわけだから
そのメモの先を参照してる時点でベクター関係ない

>>400
アドレスしか記憶してない？？
長さはどこへ行ったんだよ
認識が間違ってるだろ

まあ型情報も記憶してるということで
SLICEの記述の場合は中身を参照してるように見えるけど？
ベクターを指してるようには見えない

>>400
ベクターには3つの要素が不可欠です
①確保した領域の先頭アドレス
②確保した領域の長さ(または入る最大個数)
③使用中の領域の長さ(または使用中の個数)

俺はcの人間だから
a =&x[1]
ここでaが保存してるのは新たなアドレスでxは関係ない
それと同じに見える

>>402
スタック上を指す「ベクタの参照」もビープ上を指す「中身の参照」もライフタイムは同じ
どちらも変数vectorのライフタイムと一致
変数vectorが置かれているブロックを抜けると上記3つのライフタイム全てが尽きる

vectorが指し示す実体とvectorとsliceのはなしとしてsliceはvectorのことは気にしてないよね？
ってことだけど間違ってる？

変数vectorは構造体で「ヒープ領域に確保した領域のアドレス」と「確保した個数」と「使用中の個数」の三つで構成される
そして変数vectorは確保したヒープ領域を所有してる

変数sliceは「アドレス」と「個数」の二つで構成される
今回は変数vectorが所有するヒープ領域の一部のアドレスと個数は3

このsliceという参照のライフタイムはそのヒープ領域を所有する変数vectorのライフタイムと一致する

ああ、なるほどvectorのライフタイムが重要なのね
シェアードポインターみたいな挙動かと思ったが
vectorが消えた時点でsliceの使用はエラーになるってことか？

変数vectorは(関数含めた)ブロックスコープを抜けると寿命が尽きるわけだけど
その時に所有しているヒープ領域を自動解放する点が味噌だね
所有されてるヒープ領域は一心同体
だから変数vectorのライフタイムと同じ

ここで興味を持っているのはvectorが所有権を持っていて。
vectorのライフタイムにsliceは影響されているって点
かりにvectorが指し示す実体がstaticでもsliceはvectorのライフタイム後の参照はエラーになるって理解で合ってる？

>>410
自分とは別に所有できる領域はヒープ領域だけでしょ
自分とともに解放されちゃうし

いや気になっているのはsliceは実体のライフタイムとXのライフタイムどっちを気にしているかってとこ
実体のライフタイムを気にしているならcの感覚と同じだがvectorのライフタイムならcとは違うんだなあという感想になる

で、なぜオブジェクト指向で多用される動的extentに害があるか
に辿りつけたかい？＞

？何を言ってるのかよくわからん、どっちか知りたかっただけだが、rust自分で見なきゃいけなくなったら自分で調べるわ

>>412
実体のライフタイム？
ヒープ領域のライフタイムなんて元々は不明だろ
Rustは所有者にヒープ領域の解放の責務を与えた
だからヒープ領域のライフタイムが明確になった
そして所有している変数のライフタイムと同じになった
所有している変数のライフタイムが終わる時に所有しているヒープ領域は自動的に解放される

>>415
そういう話をしてるんじゃないけど伝わらないのでもういいです

参照のライフタイムはその領域を所有している変数のライフタイムと同じ
staticな領域に所有者はいなくてプログラム終了まで永続するためstaticな領域の参照のライフタイムは永続で'static

referenceが有効になっているscope内において領域の開放が起きたらどうよ？
また、そのreferenceの値がclosureの中などどこかに伝わって保持されてい
領域のlifetimeと同期した管理から外れたらどうよ？

>>418
コンパイルエラー
静的に判定可

分割compileしてもバレるの？

まあいいや、そういうメモリ領域の不正開放や逆にリークの問題はCやC++では起きうるが
GC領域に変数割りつけてreference countで管理する言語では煩わされないことだからな

がしかし、問題はそこではない。
オブジェクト指向で動的extentを多用すると、不正開放やリークが起きないとしても
有害だという話

>>421
永遠の命でないと困るの？

ライフタイムという言葉を変数にも値にも雑に使ってしまうと話が噛み合わなくなるという良い例だね

>>417
>参照のライフタイムはその領域を所有している変数のライフタイムと同じ
これ>>395見ればわかると思うけど違うからね

例えばCでは、mallocで動的に割り付けた領域を指すpointerを除くと、
auto変数およびstatic変数は
lifetime(=extent) と lexical scopeが同じですごくすっきりしているんだよね。
それがＣ言語の('70年代末~80年代以降〜)最大の利点の一つだったと思っている

だからＣ言語についてはextentという用語はちょっとしっくり当てはまりにくいんだけど、
あえていえば動的lifetimeを持つmalloc領域を指すpointerの値のvalid(指している領域が有効)な期間ということになるのかな?

まいいや、論点はそこではくて
オブジェクト指向で動的extentを多用すると、不正開放やリークが起きないとしても
有害だという話

>>426
また戻るけど
そこで動的extentとか動的lifetimeと呼んでるものは
変数のextentではなくて値のlifetimeの話

値のlifetimeの終了を変数の”スコープ”の終了に結びつけるというのが
動的なlifetimeを管理しやすくするために各言語が行ってること

>>424
その>>395はコンパイル通らないよ
上位に排他則 single writer XOR multiple readersがある

mallocされた領域のlifetimeはどこかでfreeさえるかプログラムのプロセスの終了時でしょ
それを差すpointer変数のlifetimeすなわちpoiner変数の存在期間でしょ。それはscope次第
実は違うんだよね

>>428
コンパイル通るように変更してあげないとわからなかったか
なら仕方ないな

>>423
値にライフタイムはない
可変参照で値を何度書き換えようがライフタイムは変化しない
変数にライフタイムがあり
その変数と所有領域への参照のライフタイムはそれと一致する

>>424
参照のライフタイムはその領域を所有している変数のライフタイムと同じ
プログラマーは参照のライフタイムが尽きる前に参照の使用をやめてもよい

Cのmalloc領域のlifetimeやそれを差すpointerの有効期限というものを
LispなどのGC領域に変数を割り付ける言語のextentになぞらえて考えると
少し悩ましいんだけれど、参考までに以下のような疑似コードを書いてみた。
(Cは久しぶりなので、細部に変なとこあっても感じをくみ取ってちょ)
安直に領域のlifetime ＝ pointer変数のextentとは言い難い

//#defien AS auto
#define AS static
func() {
SC void *p, *q、*r; // 静的lifetimeをもつpointer、初期値不定、初期値としてNULLを設定すると行儀良し

q = (void *) malloc(サイズ1); // 領域の割付け
// (中略)
p = q; // pointer p の値が 不定→ vlidに、これをあえてpのbindとみなすか？

// p[]に対し ここら辺で何かいろいろ処理

r = malloc(サイズ２）; // 別の領域の割付け
// (中略)
p = r; // これをどうとらえる？bindの仕切りなおしとみなす？wｗｗ
// p[]に対し 何かいろいろ処理

free(q);
// (中略)

free(r);

// pinter 変数 p はまだ存在するが指している領域はもう無効

} // block scopeから離脱、pがautoの場合ここで消滅する

>>432 しくったorz
SC void *p, *q、*r;
↓
AS void *p, *q、*r;

それから、CLで｢本物」のdynamic extentをつかったのけ反るようなコードを示してみたいけど
こう見えてもｵｼﾞｻﾝ結構忙しいので時間が作れたらまたねﾉｼ

前スレより引用

744 デフォルトの名無しさん sage 2026/08/23(日) 19:50:31.78 ID:LyvdCiRX
【Static lifetime】
プログラム開始から終了まで存在する。
静的変数やグローバル変数が該当。
メモリはプログラムのロード時に確保され、終了時に解放される。
例（C言語）:
static int counter = 0; // プログラム全体で生存

【Automatic lifetime】
関数やブロックの実行中だけ存在する。
ローカル変数（スタック上に確保される）が該当。
関数終了時に自動的に解放される。
例（C言語）:
void func() {
int x = 10; // 関数終了と同時に消える
}

【Dynamic lifetime】
実行時に明示的に確保し、明示的に解放するまで存在する。
ヒープ領域を使う動的メモリ確保が該当。
例（C言語）:
int *p = malloc(sizeof(int)); // 確保
*p = 42;
free(p); // 解放

【Temporary lifetime】
式の評価中だけ存在する一時オブジェクト。
C++ 等の一時オブジェクトや、関数の戻り値として生成される値など。
例（C++）:
std::string s = std::string("Hello") + " World"; // 加算結果は一時オブジェクト

>>435
そしたらGC言語ではどうなるの？

それC、C++で変数を割り付ける「領域」と
pointer変数に設定する動的割付領域
をまぜこぜにしたカテゴライズじゃね？

static char *p;
p = malloc(サイズ);

なんてよくあるコードだけど、、、、

static chat c = 'a';

static char *p;
p = malloc(サイズ);
… 中略
p = &c;
… 中略

>>436
GC言語はね
関数ローカルな一時的な変数に見えてもね
参照が残っていると関数を抜けても消えなかったり
GCできるように自動的にヒープ領域に確保しちゃう
スタック領域だと関数抜けると消えちゃうから

だから安直に >>435 のカテゴライズを言い張れないでしょって意味で書いたんだけど

GoはGC言語だけど
スタックに置いても大丈夫な変数はヒープ使わないから速いよね
GCのために何でもヒープに置く言語は遅いよ
AIコーディング時代にそんな遅い言語は捨てるべき

>>440
プログラミング言語と関係なく何十年間もメジャーに使われて来ているCPUとOSの仕組みから>>435が存在している
例えばオブジェクトはスタック領域に作ればコストも安く済むけれど
それが許されずに必ずヒープ領域にオブジェクトが作られる言語にとってautomatic lifetimeを使えないかもしれないとしてもその固有の問題
一般常識としては>>435

>>442
CよりもLispの方が古いんだけれど

static char c = 'c':

register char *cp = &c;
*cp = 'd';

cp = (char *)malloc(sizeof(char));
*cp = 'e';

static char *s;
s = cp;

static char c = 'c':

auto char *cp = &c;
*cp = 'd';

cp = (char *)malloc(sizeof(char));
*cp = 'e';

static char *s;
s = cp;

>>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