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

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

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
そうだ、それで良い
必要ないオブジェクトを作るのはオブジェクト指向ではない

オブジェクトを最小限にすることもオブジェクト指向である

Pythonは数値さえもオブジェクトだったりするんだよな
Pythonで書かれたプログラムはすべてオブジェクト指向の賜物

メッセージパッシングがーと言ってるやつは自分で書いてみろ
できないんだったらメッセージパッシングによるオブジェクト指向は
現実では使い物にならないことの証拠である

オブジェクト指向でプログラミングすること
言語の機能やライブラリがオブジェクト指向で実装されていること
この二つは異なる
違いがわからない人はいないと思うが

>>887
同じですね、オブジェクト指向エアプか？

オブジェクト指向がなかったらライブラリも構築できないんだから
オブジェクト指向のライブラリを使うこともオブジェクト指向プログラミングだよ

オブジェクト指向で構築されたライブラリを使ってプログラム書いてオブジェクト指向ではありませんは無理がある
濃厚セックスしておきながら私エッチなことに興味ありませんけどみたいな顔してる女みたいなもの

オブジェクト指向以前からベテランの開発者は優れたデータ構造を選んでコードがシンプルにせよと言ってたんだよな
そのように考えるとオブジェクトは言語機能の代替と考えてそれらを使ってロジックを手続き型や関数型でシンプルに書くのがオブジェクト指向の良いプログラムといえるのではないだろうか

誤：コードがシンプルにせよ
正：コードをシンプルにせよ

>>866はオブジェクト指向プログラミングの要素が1つもないな

>>893
そんなに他人のコードに文句があるなら自分で書きなよ
自分が思う最高のオブジェクト指向プログラムってやつをさ

手段の目的化の極み

>>866
読んでみた
糞コードだと思った点の一つはCallable
それは非常に古い使い方でオブジェクト指向に対応していないC言語などで用いる方法
オブジェクト指向プログラミングに対応した言語はその点を解決している