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

前スレ
オブジェクト指向はオワコン？
https://mevius.5ch.io/test/read.cgi/tech/1721393540/

どうやら分かったぞ
変数extentはLispの方言らしい
他ではlifetime
だからISOやJISなど公式はlifetimeになってるとのこと

C、C＋＋、C＃ などの言語で、extent も life timeもしばしな使われる
しかしどっちが公式用語だと定義した公式文章は
目にしたことはない

それを知らない人が「extentと言わない」と言っているだけ
以上だ

>>785
既に公式ソースでlifetimeと示されてるのだからあきらめなされ

変数のextentはLispの方言か？ - Google 検索
https://www.google.com/search?q=%E5%A4%89%E6%95%B0%E3%81%AEextent%E3%81%AFLisp%E3%81%AE%E6%96%B9%E8%A8%80%E3%81%8B%EF%BC%9F&hl=ja&source=hp

違います。変数のエクステント（extent）は、Lispの方言ではなく、プログラミング言語一般で使われる「変数の生存期間（メモリ上に存在し続ける時間）」を表す専門用語です。 [1, 2]
多くの場合、空間的な有効範囲である「スコープ（scope）」と対比して使われます。 [3, 4]
## スコープとエクステントの違い

* スコープ (Scope): 変数名がコード内のどこから見える（アクセスできる）かという空間的な範囲（有効範囲）
* エクステント (Extent): 変数がメモリ上で存在し続ける（値が保持される）時間的な長さ（生存期間／ライフタイム） [1, 2, 4, 5]

## 主なエクステントの種類

* 動的エクステント (Dynamic extent): その束縛を作ったフォームや関数を実行している期間だけ存在するもの
* 実質的無限エクステント (Indefinite extent): 関数を抜けた後も、データが参照され続ける限りメモリに残り続けるもの（クロージャなど） [5, 6, 7]

Lisp（特に[Common Lisp](https://ja.wikipedia.org/wiki/Common_Lisp)など）の仕様書（ANSI Common Lispなど）で「スコープとエクステント」が明確に定義されて詳細に解説されているため、Lisp特有の概念のように誤解されやすいですが、元々は計算機科学の一般的な用語です。 [5, 8]
より詳しく知りたい内容はありますか？

* Common Lispでの厳密な定義と解説
* 他の言語（CやPythonなど）での生存期間との比較

知りたいアプローチを選んで教えてください。

（リンク略）

せめてさ、無知の知にくらい至れよ

そうじゃないとサル以下の知性だぞ

自分がサル以下の知性だと示すのに
何でこんなにレスを長引かせるかな

>>785
あともう一点
extentとは言わない、と言われてるのではなくて
変数を伴わなければextentにそんな意味はない、でしょ
そこを改変したらダメよ

少なくともC++で動的extentと言ったら配列などの要素数が実行時に決まること
std::dynamic_extentとして公式に定義されてます

>>790
またいい加減なことを
そしたら「Storage Extent bound from a symbol」とか普通に言うけど
どうすんのよ

>>791
あれは名前で誤解を受ける人が多いと今回思った

何であんな名前にしたんだろう
由緒を知らん

CもC++も規格で決まっていてISO/IECとJISになってるよ
もちろん公式にlifetime

extentに生存期間の意味はないため
lifetimeが公式になってるようだな

c++のそれらの企画書では時間的な長さ（生存期間）をlifetimeまたはstorage durationとよび
std::dynamic_extent は空間的なサイズ（要素数）に用いて使い分けているな

C言語の標準規格（ISO/IEC 9899）においては、配列のサイズを extent とは呼んでいないようだな

>>796
意味は持っているよ
なんでさ、知らないことを「ない」っていうの？
変なあたましてるな

>>797
そうだよ
時間的な方はlifetimeと呼ぶのが正しい

英英辞典で調べてもextentに生存期間の意味はない
lengthやsizeの意味はある
だからC++のstd::dynamic_extentが配列などの長さやサイズの意味で用いてることは正しい
つまり動的extentは動的サイズ

英英辞典には載っていないだろうなｗ

C/C++/C#の規格書はlifetimeなんだな
あとは規格や公式でextentを用いるプログラミング言語があるのかどうか

Rustは規格書がないようだが公式でlifetimeと言ってるな

C++では、C++11以降の標準ライブラリや、C++20/C++23で追加された新しい機能において、
配列などの「（各次元の）要素数、あるいはデータの広がり（長さ）」を指す用語として extent という言葉を使っている。

とのことだ

なお、Cで配列などの空間サイズにextentというコトバを使うことはない

なるほど
変数などの生存期間はlifetimeと呼んだほうが良いわけか

>>805
C++ではサイズにextentを使うようになっちゃったので、
時間の方はlifetimeを使い分けるのが無難ってことだな

時価だ空間だ書いているとまた場の理論のおじさんが
妄想を爆発させそうだなｗ

>>806
使い分けはその通り
経緯は先にCの標準規格書としてlifetimeの用語が定まった
C++も同じく標準規格書としてlifetimeの用語が定まった
後にC++20の時にdynamic extentを動的なサイズの意味で配列などの要素数に用いた
std::dynamic_extent

>>808
サイズ面でextentをつかうよになったのは割と新しめのＣ++か

結局話の発端の

>659
>動的extentって何だ？
>例えばC++のdynamic_extentはオプション指向と関係ないように
>概念を話すときに特定の言語でのみ通用する用語は使わないでほしい

とは何だったのか。

相手する値打ちの無い輩だったということか…

なぜC++で空間サイズに関してextentが使われるようになったか大体分かった
--
C++の標準ライブラリでは、配列のサイズや広がりを表現するために extent（複数形は extents）という言葉が使われるようになりました。

* std::extent (C++11〜)
* 配列型の「指定した次元の要素数（サイズ）」をコンパイル時に取得するための機能です。
* 例えば int arr[3][5]; に対座して、std::extent_v<decltype(arr), 1> とすると、2次元目の広がりである 5 が取得できます。 [2, 3]
* std::span (C++20〜)
* 連続したメモリ（配列や std::vector など）を指し示す軽量な覗き窓（ビュー）です。
* このクラスのテンプレート引数やメンバ定数として、要素数を表す extent が定義されています。ここで要素数が実行時になるものを std::dynamic_extent と呼びます。 [4, 5]
* std::mdspan / std::extents (C++23〜)
* 多次元配列を扱うための機能です。
* C++23からは、多次元配列の「次元の数」を rank、「各次元の要素数（サイズ・広がり）」を extent と明確に呼び分け、それを管理する std::extents というクラスも登場しました。 [1, 6, 7]

## 2. なぜ size や length ではなく extent なのか？
C++において size() や length() は、コンテナにある「すべての要素の総数（合計カウント）」を返すものとして長年使われてきました。 [8]
しかし、多次元配列（例えば、縦3 × 横5 の行列）を扱うようになると、以下のような混乱が生じます。

* 「この行列の size は？」と言われたとき、全体の個数である 15 なのか、縦の長さ 3 なのか、横の長さ 5 なのか区別がつきにくい。

そのため、近代C++では以下のように言葉を使い分けるようになりました。

* rank（階数・次元数）: 配列が「何次元」あるか（例: 2次元配列なら 2）。
* extent（境界・広がり）: 各次元における「要素の長さ・サイズ」（例: 1次元目の extent は 3、2次元目の extent は 5）。
* size（総サイズ）: すべての次元の extent を掛け合わせた「全要素の総数」（例: $3 \times 5 = 15$）。 [1, 6, 7]

## 結論
C++では、配列の「要素の数」や「各次元のサイズ」といった空間的な広がりを公式に extent と呼びます。 [1, 2]

extentはLisp用語
空間的なscopeと対比することでextentを時間的な意味でLisp用語にした
本来のextentは時間的ではなく一般的な範囲を示す
Lisp用語としてのみextentが生存期間の意味で使われている
それがLisperによって広まった

一方でC/C++など他の言語から見ると
Lisp用語extentは相応しい用語に見えない
わかりやすいlifetimeが採用された
それでもLisp用語extentを使う人が一部残った
一方でC++はextentを本来の意味で使うことにした
std::dynamic_extentはその本来の意味に沿っている

>>813
sizeにを使う用になった言語は
０x１１以降のc++の他になにかある？

>>814 extentが抜けた

sizeにextentを使う用になった言語は
０x１１以降のc++の他になにかある？

そんな、必死で検索して探さなくていいよ
もう寝なよ

>>744を使えばもめることも誤解されることもなくて平和だよん

extentを時間的要素に用いるのはかなり一般的じゃ無いって事でOK

オブジェクト指向でプログラム書いてるけどエクステントの言葉は知らなかった
スコープから外れたオブジェクトはいずれGCされるとだけ思ってプログラム書いてるしそれで問題ない
エクステントを意識して書かれたプログラムは何かが良くなるとかそういうのは別にないんでしょ
プログラムの動作を説明するときに役立ちそうではあるけどね

>>819
GCも完璧じゃ無いんだよなぁ
まあ、完璧じゃないのは使う側の勘違いがほとんどだけどさw

マネージドヒープで管理できないものはあるからね
ネイティブメモリはローンパターンとかリソースモナドっぽいものを拵えて管理してるわ

誰も真のオブジェクト指向でプログラムできないからねぇ
それっぽい機能使ってるけどforループで回して手続き型プログラムやってる
関数や配列の強化版としてしか使えていない

>>822
誰もできないなら真のオブジェクト指向があると考えてる人がバカなんじゃないの？ 違うの？

CのlifetimeとLispのextentとRustのlifetimeは
何かしらの生存期間/有効期間を表現しているという意味では同じだけど
肝心の「何かしら」の中身が違うので同じものとして取り扱わないほうがいい

>>783
エクステ爺さんは悪魔の証明の意味も知らんのかｗ
「例を出せ」と「無いと証明しろ」を同一視するとか頭おかしいだろ

>>822
真のオブジェクト指向でプログラム出来ないとかw
道具を道具として使えない奴の言い訳にしか聞こえないなw
んなもん道具なんだから頭でウジウジ考えて真のオブジェクト指向目指すより
テキトーに道具として使った方が勝ちだ

つまり用途がないんだよオブジェクト指向にはな

世の中の実業に求められてるのは手続き型プログラムってことよ

機能分割くらいに考えて使えればいいんだよ
グダグダ屁理屈並べてああでもないこうでもないで何日も時間潰しても
結局最後は設計が悪かったになるんだからw

手続き型とオブジェクト指向は地続きなものだしなあ
手続き型でプログラム書いて必要になったときにオブジェクト指向でまとめるくらいでちょうど良い

手続きは地続き

データとそれを処理する関数をまとめたカプセル化は良いと思う。
細々したことをさらけださなくいいから。

C++ならテンプレートだな。まあ、会社では使用禁止だろうけど。

テンプレートやマクロって、公的に利用されてるもの以外は混乱の元なんだよね

>>656
>クラス(カプセル化)、動的インスタンス(動的extent)、継承、多態といったもので
>プログラムを現すモデルとして実は適していなかったおそれがあると思う

これやっぱりCOBOLのような手続き型を想定した話だったのか
さすがおじいさん

東工大の大学院出てそうだなwww

なぜそう思った？

この使い分けも難しい
ニブル (nibble)
テトラード (tetrade)
カルテット (quartet)

>>835
気分はstatic!だから

えらい勢いあるねこのすれωωω

不毛なことって延々と続くからね

スキー用具が冬季オリンピックの開催国で使われる名称になるみたいな差だからいいんだよw

>>833
エクステじいさんが言いたかったことは>>29の内容だろうな
その>>29自体も何かと意味不明だが

>>29
>>・extentが独立な状態変数は、どうしてもそうしなければならないもの以外、なるべく状態変数にしない

このextentが独立はlifetimeが独立の意味？
生存期間が独立って表現おかしくない？
生存期間が静的と言いたいのかな？

>>特にextentとscope。
>>C言語で明確化された、ネストしたシンプルで分かりやすく
>>そしてextentと対応付きやすいscopy

ネストしたと書かれているから
おそらく多段ブロックスコープの話っぽい
でもextentはscopeと対応しないから意味を持つよね
extentを敢えて出す意味は？

馬鹿しかいない

ほんとそう思った

>>599 java
https://ideone.com/pC1BHy
・委譲でなんとかするやつ
・継承でなんとかするやつは>>758

>>599 java
https://ideone.com/nx3a5x
・委譲でなんとかするやつ
・継承でなんとかするやつは>>758

>>345
マジックナンバーがわかった
-1431655765 = (2^33 + 1) / 3 を符号付き32bit
1431655766 = (2^32 + 2) / 3

staticおじさんは
staticおじいさんに進化しました

>>758
乙。

地獄やな…

オブジェクト指向はその仕組みが元凶で悪というよりも
自由度が高かったり色々な(変な・凝った)書き方が出来てしまい
それを使う人間が上手く律し利点だけを引き出すような使い方が結局できない
思い込みと自己流で変な流用の仕方をしがちだった

使う人間側にも問題があったのではないかと最近では思う
それをそれを制限する仕組みをオブジェクト指向は備えていなかった

で、制限する言語が最近出て来た

オブジェクト指向言語自体は洗練されてるからねw
提供されてるライブラリのクラスメソッドの出来の良さよw

>>845
JavaってDictionaryやTupleってないの？
あとintかstringを返す場合はObjectを返す以外にない？
最初の数行で気になって

delay()を初心者に教えるとその先が壁になって
いつまでもシングルタスクのまま進歩しないのと同じだな

>>852
自分で調べろ

>>599 Pythonで書いた例。正直ちょっとわかりづらいので、本当はコメントが必要かも。
https://www.ideone.com/tGe3is

>>855
specって何？ specが気になってぜんぜん頭に入ってこない

satisfied_countってなんやねん！

つか、なんでみんなダラダラ条件分岐書き連ねるの？

>>858
他に良いやり方あるんけ？ おーん？

まあ、バカがループ禁止にしたからかな？

とりあえず出力ができるものということで書いたので、粗があるのは許してちょ。specは、〜specの並びを見れば、意図するところは分かってもらえるかなと思ったんだけどね（>>593でも書いているし）。
woofルールがなければ述語関数を渡して判定させるという形で書けるのでまだ分かりやすかったと思うんだけど、今回は、woofルールもまとめて一本で書いたので正直分かりにくくなった面はあると思う。
ま、あくまでお試しで書いてみた例にすぎないので、その程度のものとして見てもらえれば。

>>859
辞書作って判定回せばデータ変えるだけだぞ

>>862
ほほんｗ それでやってみ、できないからｗ

エアプが妄想でこうやれば良いと言っててウケるｗ

>>863
え？
最初のルールから変わったんか？

>>855 のboom(7539）のところが実際にはboom(35)になっていたので、一応修正版。まぁ、出力は変わらないんだけど。
https://www.ideone.com/T80HCK

最小公倍数で回せなくなったのかw
あと変換後のスペル順番が違う…と
スペル変換をもう一つ噛ませればいいだけじゃん

いっその事、1万テーブルの変換表作って
ダイレクトに参照させた方がいいまであるなw

>>866
どこがオブジェクト指向なんだよ？
オブジェクトもなければメッセージパッシングもない

>>869
自分で作れ

>>869
そう？　組み込みクラスのオブジェクトの便利なメソッドを使うというのも十分にオブジェクト指向だと思うけど。
そういうネジ・クギレベルのことを超えて、ユーザー定義クラスみたいなのを作って色々やるのがいいかどうかは設計時の考え方次第だと思うよ。今回は関数で十分だと思ったから関数にしただけの話で。

>>871
どこにも見当たらないが
まさか関数呼び出しをオブジェクト指向と呼んでる？
C言語にも備わってる基本機能だぞ

>>868
その変換表をどうやって作るつもりなんだよｗ

>>873
ドキュメント見て作るさw
むしろ、特殊な文字出力する数字の場合だけデータ入れて、あとはnullとして通常ルール通りに処理させる分岐条件にするとかな

>>874
1万までの数字すべての期待結果がドキュメントに逐一書かれてるといいねｗ

>>872
ユーザー定義関数もオブジェクトだし、words.appendとか、''.joinとかは普通にメソッド呼び出しだけど。forループやリスト内包では、内部的にiteratorオブジェクトのメソッド呼び出しがされているわけだし。
インスタンスの生成構文みたいなのがないとオブジェクト指向ではないという感覚なの？

>>875
データ作るなんて簡単だぞw
こいつらの書いたコードの出力をまんま使えるからなw

>>877
自分のバカさ加減にようやく気付いたようで何よりですｗｗ

>>876
それは言語の機能だね
FizzBuzzをオブジェクト指向に実装する話とはレイヤーが異なるよ

>>872
C言語に備わっていたらオブジェクト指向じゃないといつから錯覚していた？

オブジェクト指向とはプログラムをわかりやすくする営みと知れ

オブジェクトを作ってそこへメッセージを投げることで動いていく
そのためのメッセージ送受をコーディングしていく
それがオブジェクト指向プログラミング
>>866は今回の目的のためにオブジェクトすら作っていない

>>882
そうだ、それで良い
必要ないオブジェクトを作るのはオブジェクト指向ではない