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

>>1乙

訂正
オブジェクト指向はオワコン (2023/08/26～)
https://itest.5ch.net/mevius/test/read.cgi/tech/1693054853

このスレ要るか？

use feature 'current_sub';
@a = map{[split]} <DATA>;
($m, $n) = (20, 1);
sub {
　$s = '';
　map{0 == $n % $$_[0] and $s .= $$_[1]} @a;
　$s ||= $n;
　print "$s\n";
　$n++, goto __SUB__ if $n < $m;
}->(1);
__DATA__
3 fizz
5 buzz
7 Pop
11 Jazz


注) Perl の「goto 関数」は continuation

>>https://mevius.5ch.io/test/read.cgi/tech/1786599483/599 ocaml
https://ideone.com/eaBULr
・Java版のRuby移植のOCaml移植
・連結済文字列じゃなくて、文字列のリストを返すようにしたのは単に気まぐれ
　"FizzBuzz"じゃなくて["Fizz"; "Buzz"]を返してる

>>https://mevius.5ch.io/test/read.cgi/tech/1786599483/599 ocaml
https://ideone.com/Q1I3uT
・Woofの303がFizzFizzFizz版
・String.fold_leftは4.13以降
・今のideoneは OCaml (ocamlopt 4.05.0)

>>5
}->(1);
は1ｲﾗﾈ
}->();
でおｋ

>>5
お題がFizzBuzzのバリエーション6種類に対応できるコードを実装に変わってるよ
バリエーションに対応できつつコードの共通化で6倍のコードになるのを防ぐ感じ

対応すべきバリエーションはこれらしい
https://xapn.github.io/fizz-buzz/#fizz-buzz-variations
従来の割れるか classic
文字列化して含むか digits
割れるか含むか boom
割れると含む回数 woof
7と11を加えた popwhack
7,8,11,13を加えた zingchop

最大公約数の人がピンチ

120120通りの表を作れば行けるはず

場のオブジェクト指向おじさん星になる

バリエーションと圏論は相性良さそうな気がするけど出て来ないね

最小限の射へ分解

なんだろうね、素数だから数学的におもしろかったのに、
割れると含むとか入ってきて、
さらに８ってのはどこからでてきたものなんだか、2^3ということかな？
「場のオブジェクト指向」では、すべが計算済の「場」とするので、
どうやるかは量子計算での加法の扱いにかかってくる。考え中。まあ、
できたらフィールズとかノーベルとかのレベルだから考えて楽しんでいるだけ笑。
問題は、場の量子論で「加法」をどのようなものとして扱うか、ということ。

>>15
zingchopで8で割り切れる時を扱わなければいけなくなって場のオブジェクト指向は破綻したのか～

場のオブジェクト指向は考え中のものだから、破綻はしていない、むしろ、
今回のようなルールが無限に増える場合に対応するものとして構想している。
ルールに割れるだけはなく、含むが加わった。
しかも、どうやら指数すらも含まれるような感じ。
自然数を表現可能なすべての表記が入るのだろう。n進数も。
自然数限定だが表現論の問題になっている。

>>17
「含む」は10進数で表現した時すなわち文字列化した時に含まれるかどうかが今回の仕様だね
人間が扱う自然な仕様は10進数だけだろうけど

>>9
ざっと縦読み目を通したけどmethoc chainで呼んだ場合の処理とカ書いてあって
結局、各方式ごとの関数なりmethodが要るってことになるし
昨日関数間でコードの共通化できるとことはあんまりない感じだな

今回の件は全体が見やすいように3つの部分に分けるとプログラムはこれだけだね
type Count = fn(usize, usize) -> usize;
const DIV: Count = |t, n| (t % n == 0) as usize;
const IN: Count = |t, n| t.to_string().contains(&n.to_string()) as usize;
const DIV_OR_IN: Count = |t, n| (t % n == 0 || t.to_string().contains(&n.to_string())) as usize;
const DIV_AND_MULTI_IN: Count = |t, n| (t % n == 0) as usize + t.to_string().split(&n.to_string()).count() - 1;

type Rule<'a> = (Count, &'a[(usize, &'a str)]);
const CLASSIC: Rule = (DIV, &[(3, "Fizz"), (5, "Buzz")]);
const DIGITS: Rule = (IN, &[(3, "Fizz"), (5, "Buzz")]);
const BOOM: Rule = (DIV_OR_IN, &[(3, "Fizz"), (5, "Buzz"), (7, "Boom")]);
const WOOF: Rule = (DIV_AND_MULTI_IN, &[(3, "Fizz"), (5, "Buzz"), (7, "Woof")]);
const POP_WHACK: Rule = (DIV, &[(3, "Fizz"), (5, "Buzz"), (7, "Pop"), (11, "Whack")]);
const ZING_CHOP: Rule = (DIV, &[(3, "Fizz"), (5, "Buzz"), (7, "Pop"), (8, "Zing"), (11, "Whack"), (13, "Chop")]);

struct FizzBuzz<'a>(usize, Rule<'a>);
impl<'a> std::fmt::Display for FizzBuzz<'a> {
fn fmt(&self, f: &mut std::fmt::Formatter) -> std::fmt::Result {
let FizzBuzz(target, (count, list)) = self;
let mut is_done = false;
for &(number, name) in *list {
for _ in 0..count(*target, number) {
f.write_str(name)?;
is_done = true;
}
}
if !is_done {
write!(f, "{target}")?;
}
Ok(())
}
}

>>20のプログラムの検証
他のプログラムが通してる事例を参考にしました

fn main() {
use itertools::Itertools;
assert_eq!((1..=15).map(|t| FizzBuzz(t, CLASSIC)).join(" "),
"1 2 Fizz 4 Buzz Fizz 7 8 Fizz Buzz 11 Fizz 13 14 FizzBuzz");
assert_eq!((1..=15).map(|t| FizzBuzz(t, DIGITS)).join(" "),
"1 2 Fizz 4 Buzz 6 7 8 9 10 11 12 Fizz 14 Buzz");
assert_eq!(FizzBuzz(35, DIGITS).to_string(), "FizzBuzz");
assert_eq!((1..=15).map(|t| FizzBuzz(t, BOOM)).join(" "),
"1 2 Fizz 4 Buzz Fizz Boom 8 Fizz Buzz 11 Fizz Fizz Boom FizzBuzz");
assert_eq!(FizzBuzz(7539, BOOM).to_string(), "FizzBuzzBoom");
assert_eq!((1..=15).map(|t| FizzBuzz(t, WOOF)).join(" "),
"1 2 FizzFizz 4 BuzzBuzz Fizz WoofWoof 8 Fizz Buzz 11 Fizz Fizz Woof FizzBuzzBuzz");
assert_eq!(FizzBuzz(35, WOOF).to_string(), "FizzBuzzBuzzWoof");
assert_eq!(FizzBuzz(303, WOOF).to_string(), "FizzFizzFizz");
assert_eq!((1..=15).map(|t| FizzBuzz(t, POP_WHACK)).join(" "),
"1 2 Fizz 4 Buzz Fizz Pop 8 Fizz Buzz Whack Fizz 13 Pop FizzBuzz");
assert_eq!(FizzBuzz(1155, POP_WHACK).to_string(), "FizzBuzzPopWhack");
assert_eq!((1..=15).map(|t| FizzBuzz(t, ZING_CHOP)).join(" "),
"1 2 Fizz 4 Buzz Fizz Pop Zing Fizz Buzz Whack Fizz Chop Pop FizzBuzz");
assert_eq!(FizzBuzz(120120, ZING_CHOP).to_string(), "FizzBuzzPopZingWhackChop");
}

なぜかIDが変わってるけど
>>20の検証部分が>>21ね

>>19
それは仕様を言葉で説明すると曖昧になりやすいからの理由でしょう
その通りのまま実装してる人は誰もいないから大丈夫だよ

結局ルール辞書作ってぶん回すだけ

>>24
ルール辞書の作り方や構造が難問
様々な問題に対して自動的に汎化させることは難しい

>>9 ocaml
https://ideone.com/iRLbSx
・>>6から若干の改善
・判定につかってたcontains,countの実装が簡易的だったので整数比較版に差し替え
・結果のリストに対するinspect関数つくっといた
　to_s関数を`List xsに対応させてみたりしたけどなんか使い勝手が悪かったのでこっちにした

もしやこのコードは

>>26
let count m n =
let m, n = abs m, abs n in
let d = if n = 0 then 10 else int_of_float (10. ** (1.0 +. (floor (log10 (float_of_int n))))) in
let rec aux acc = function
0 -> acc
| m -> aux (if m mod d = n then acc + 1 else acc) (m / 10)
in if m = n then 1 else aux 0 m
let contains m n = 0 < count m n

今のところ前スレ>>938が一番まともやな
変換辞書と変換ロジックのセットとして扱ってればなお良かった

にしても不必要なcount変数やflag変数を導入するやつとか
ToString()にドメインロジックを全部突っ込むやつとか
おかしなやつが多いな

938を見たら145行もあった
動作確認printしてるmain関数8行を除いても130行以上ある

行数が多いとその分稼げるから

>>28
これは文字列化する課題だよね
みんなが文字列化の関数にドメインロジックを書いているのは当たり前だと思いますが

>>20
これはRust? OCamlかと思った

>>31
神クラスならぬ神toStringか

>>28
その938もToStringする関数にメインロジックを書いてるけど938をお気に入りな理由は何？

文字列にする関数とドメインロジックを分けることがそもそも可能なのかね？

javaのtoString()はデバッガでも表示に使用されるため、
オブジェクトの区別がつけられるユニークな内容のみで使用するのが望ましい。
できればデバッグ用以外には使用しない。
デバッグで必要となるため、
すべてのオブジェクトは、toString()でオブジェクトの文字列表現を正しく返すように実装すべき。

唐突に何だろ
そんなレベルの問題を起こしてるコードはこのスレで見たことない

extends is evilの潜在的バグはtoString()用法の間違いが一番多いので。

それは文字列化とデバッグ用を混乱しているJavaの問題
オブジェクト指向プログラミングとは無関係

いつもJavaの仕様や方針が足を引っ張ってるような

javaは単純化しようとしてかえって初心者には扱えないものになってしまった。
toString()の例は、オブジェクト指向（設計）の例で、
設計や、実装の段階では、指示しているオブジェクトが正しいつもりでも、
実際に実行してみると、想定とは異なったオブジェクトにメッセージを投げていたりする。
相手だけではなく、自分自身も設計・実装時に想定していた自分(this)とは違う自分(this)
になっていたりする。
手続き型の現物プログラミングやスクリプト言語ばかりやっていたりすると、
オブジェクト指向の抽象プログラミングでバグる。
設計が正しくても、実装する側が手続き型しか使ったことがなかったりすると、確実にバグが発生する。

「オブジェクト指向の抽象プログラミング」
「確実にバグが発生する」

「Javaによく慣れて精通していないと嵌る落とし穴のある言語だ」
くらいに抽象化して言えないのかな

よく慣れて精通していないと嵌る落とし穴満載の言語で最たるものはC++が王様だな
いや、たとえ精通していても…

特に何も抽象化していないいのに抽象化という言葉を使うのはやめましょうよ
ものすごい違和感というかもはや不快感を覚える

オブジェクト指向（設計）とは抽象化ですよ。
オブジェクト指向言語は抽象化言語。
オブジェクトやメッセージに抽象化することで状態や実装を隠ぺいする手法なのです。

javaは単純化したのが命取りのようではあるが、
手続き型中心のオールドプログラマを攪乱し、リバースエンジニアリングさせない効果はある。

parseIntが面倒糞かった

どちらかというと、手続型（命令型）と関数型（宣言型）が対立的な概念で、オブジェクト指向は手続型の範疇というイメージかな。もっとも、関数型（宣言型）の良いところを部分的にではあれ取り入れようという動きは顕著よね。
手続型（命令型）の書き方をベースに書くときに、どの程度オブジェクト指向的な書き方をするかと、どの程度関数型的な考え方を取り入れるかはそれぞれ独立のことだと思う。

>>49
その二つも差はなくね？
関数を入れ子にして手続き書いていくとか
メソッド関数を数珠繋ぎにして手続き書いていくとか
見かけは宣言型でも手続き型と何が違うの？

オブジェクト＝タスクマシン
他のプログラムに干渉されずに独立してプログラムを実行できる仕組み、ならいいんだが

delay()使っても止まってるのはそこだけで、他を止めない

>>51
それは非同期並行タスクとしてそれを持つ各言語で実現されてる

>>52
で、1000以上のキャラの弾幕ゲームを作れるかね？
全部のキャラを独立したオブジェクトでさ

>>50
関数型の考え方を取り入れるというので想定していたのは、純粋でない関数はできるだけ減らすとか、高階関数を活用するとかの素朴な考え方だけど、これらはオブジェクト指向の直接的な関心事ではないでしょう。オブジェクト指向でも取り入れることはできるけど。
いわゆるメソッドチェーンは、それ自体としては宣言的になる場合もあれば、命令的になる場合もあるんじゃないかな。

宣言的な度合いに相対的な高低差があるというだけ

何か抽象的なような煙に巻くような言い方だなｗ

>>46-47 こういう人が未だに居るんだな…
残り少ない生き残りというか残党みたいな信奉者(やや狂信的傾向)
最後まで城を守る！あるいは船と沈む！みたいな

他の言語やパラダイムも勉強して視野広げたほうが良いと思うの
それから、客観的にものを見られるようになったり、合理的に考えたりする力の訓練もね

まあ、どうのこうのといっても、手続き型言語も抽象化されたものだし、
CPUやGPUなども抽象化されたものだし、
その意味では、最初からオブジェクト指向で設計されているともいえる。
数学的な理論づけとしては圏論も欠かせない。
が、これから重要なのは情報理論。それはエネルギー論でもあり、場の量子論でもある、ということ。

場のおじさんだったかｗ

CPUやGPUは尤も生々しい具現だチューにｗ
あんた、場だの論だの抽象だの既存の権威付けられた言葉の印象に憧れてるか酔ってるだけでは？

>>9 java
https://ideone.com/DCrHR4
・Woofの303がFizzFizzFizz版
・countは正規表現つかって実装
・clone, list(b, e)メソッド追加

>>9 ruby
https://ideone.com/1G57lm
・Woofの303がFizzFizzFizz版
・countは正規表現つかって実装

勉強不足ですなー。CPU/GPUは抽象計算機を物理的に実装したものですよ。
計算モデルに従います。

CPU/GPUもやっぱり場の理論によって動作しているのですか？

場の理論といえばやっぱりランダウのバコテン(場の古典論)、QEDはFeynmanが懐かしい

論的量子力学・QFDはBjorken Drell、QCDはFeynman

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

んなこたーない

>>64
ま、量子世界にいるわけですから、いまのところ場の量子論で動作しているということでも
いいわけですが、量子レベルの現象を直接扱っているわけではないと。
現在の計算モデルは、何世代目かの宇宙における構造（カラビヤウ多様体）に起因していると考えております。

オブジェクトンとオブジェクティーノの対称性

>>32
その通りRustだよ

>>36
Rustは3つのインターフェースに分かれてるよ
trait Debug デバック表示用の文字列化
trait Display 通常の文字列化
trait ToString 通常の文字列化＋文字列型Stringに格納するためのメモリ確保

文字列型へのToStringはこのように非常に重い処理なので分離されてる
表示や既存文字列への追記は中間生成Stringを作ると無駄だからね
プログラマはDisplayを実装すればToStringは自動実装されるよ

Debugはそれらと独立のもので自分でも実装していいけど
各型の宣言に #[derive(Debug)] を修飾すると機械的に自動実装してくれる

FizzBuzzへのtrait Displayの実装例が >>20
コストの高いメモリ確保処理は分離されて純粋な文字列化処理のみになってるよ
Rustはこれが標準で数値などのプリミティブ型も全てtrait Displayを実装

こうすることで何がメリットかというと
例えば >>21 のこの処理

　「1から15までのBizzFizzの結果をスペースで繋げて1つの文字列にするコード」
　(1..=15).map(|t| FizzBuzz(t, CLASSIC)).join(" ")

よくある15個のStringを生成してそれらを繋げて1つのStringを作るのと比べて
join()はtrait Display実装型を受け付けるため一気に1つのStringのみ作ります
15個の中間生成Stringのメモリ確保と生成を省くことができてます
これはjoin()に限らずprint!系なども同様です

自然数の文字化だけだとユニークで一対一なのでフェルミだ。
これを３の倍数とか５の倍数とかで文字化すると、そこは複数の値が同じ文字になるのでボゾンだ。
量子統計が異なる。
で、フェルミが積で、ボゾンが和だ。場の量子論から、そうなる。（かなりすっ飛ばした結論笑）
区別がつくものは積であらわされ、区別がつかないものは和であらわされる。
積と和がハイブリッドしたもの...それはアレだ！（ホントかどうか調査中）

>>71
実に醜いし
CPUがやってる作業も壮大な無駄と遠回りだろう

普通にシンプルな手続き型でやりゃいいことを、無駄にオブジェクト指向で作る意味はない

>>73
オブジェクト指向だから実現できてるんじゃね？
使わないと無理っぽい

手続き型で普通のシンプルな条件処理で済むじゃん

>>75
見たい
コード書いてみて

BizzFizzの話題になった初期に出てるじゃん

>>73
オブジェクト指向によってその無駄なCPUの作業を減らしている好例だよ
「文字列型への変換」という格納メモリ確保を伴う重い作業から
「純粋に文字列への変換のみ」を別のインターフェースとして切り出している
そうすることで無駄な一時的な文字列型の生成を防ぐことができているよ

>>74
「何が」オブジェクト指向だから実現できてるの？

オブジェクト指向によって
全ての型に対して「(メモリ確保を伴わない)純粋な文字列化変換」という共通インターフェース(trait Display)を設けて各型がそれを実装しています
それを用いて「(メモリ確保を伴う)文字列型への変換」という共通インターフェース(trait ToString)が全ての型に自動実装されます
この両者の分離により無駄なCPU処理と無駄な一時メモリ確保を防いでいます

>>80は>>74と同一人物なのかな？

一般的にオブジェクト指向を使わないとインターフェイス抽象型による共通の扱いができないから各々の型でバラバラにやることになって破綻だよな

複数の異なる型を同じメソッドで呼び出しできる
これがオブジェクト指向の最大の利点だ

多相性は型システムの問題のような気もするけど。

単なる多相性だと型を横断しての共通呼び出しが保証されない

>>49
無駄なこだわり主張して現場を困らせるやつの典型例だな

手続き型が小汚いので、各オブジェクト指向系言語は工夫しているが、
ダメなものはダメで、さらに小汚いものが書かれて、それをオブジェクト指向のせいにしている。
Why extends is evil が、その典型的な例で、最後にはなにも解決せず、さらに悪化させたまま
終わっている。そこには絶望しか残っていない。
手続き型でも、キレイにかけるやつはかけるのだが...残念なプログラマが多い。
プログラムは文学的/文芸的であるが、叙述ミステリーであっては困る。

>>9 java
https://ideone.com/C9Cmel
・Woofの303がFizzFizzFizz版
・OOPらしく（？）継承でなんとかするやつ
・委譲でなんとかするやつは>>62

>>9 octave
https://ideone.com/MXBicD
・Woofの303がFizzFizzFizz版
・Java版のRuby移植のOCaml移植のOctave移植
・ほかの言語のクセが混入しちゃってOctaveらしくないかも

実行結果

~ $ perl FizzBuzz_variations-26830.pl
1 2 Fizz 4 Buzz Fizz 7 8 Fizz Buzz 11 Fizz 13 14 FizzBuzz
1 2 Fizz 4 Buzz 6 7 8 9 10 11 12 Fizz 14 Buzz FizzBuzz
1 2 Fizz 4 Buzz Fizz Boom 8 Fizz Buzz 11 Fizz Fizz Boom FizzBuzz FizzBuzzBoom
1 2 FizzFizz 4 BuzzBuzz Fizz WoofWoof 8 Fizz Buzz 11 Fizz 13 Woof FizzBuzzBuzz BuzzBuzzWoof FizzFizzFizz
1 2 Fizz 4 Buzz Fizz Pop 8 Fizz Buzz Whack Fizz 13 Pop FizzBuzz FizzBuzzPopWhack
1 2 Fizz 4 Buzz Fizz Pop 8 Fizz Buzz Whack Fizz Chop Pop FizzBuzz FizzBuzzPopWhackChop

おー、octaveって初めて見た。

>>90
むむ、4番目と6番目の結果が違う

4番目
1 2 FizzFizz 4 BuzzBuzz Fizz WoofWoof 8 Fizz Buzz 11 Fizz Fizz Woof FizzBuzzBuzz

6番目
1 2 Fizz 4 Buzz Fizz Pop Zing Fizz Buzz Whack Fizz Chop Pop FizzBuzz

>>87
俺のオブジェクト指向を見てくれ、こいつをどう思う？
https://paiza.io/projects/74r7Bk2gDxB1PllUsjS1vQ

>>93
失格
皆が検証しているwoofの303やchopの120120を求めることすらできないプログラムになっている

>>92
90 の 4,6行目と 93の 4,6行目は合っているように見える

ｵﾚの目が疲れている？

>>94
余裕でした、なぜならオブジェクト指向だから
https://paiza.io/projects/JoOYtyQ9TMC-CV0n_HWDuA

>>95

4行目
1 2 FizzFizz 4 BuzzBuzz Fizz WoofWoof 8 Fizz Buzz 11 Fizz 13 Woof FizzBuzzBuzz
1 2 FizzFizz 4 BuzzBuzz Fizz WoofWoof 8 Fizz Buzz 11 Fizz Fizz Woof FizzBuzzBuzz

6行目
1 2 Fizz 4 Buzz Fizz Pop 8 Fizz Buzz Whack Fizz Chop Pop FizzBuzz
1 2 Fizz 4 Buzz Fizz Pop Zing Fizz Buzz Whack Fizz Chop Pop FizzBuzz

FizzBuzzのプログラムを書いてみるとデータと操作は分けた方がいんじゃないかという思いが強まるよな
なんでもかんでもオブジェクトにするのが旧オブジェクト指向だとすると
データ構造や言語機能の補間のためにオブジェクトを作るのが新オブジェクト指向なのかもしれない

>>91
octaveに三項演算子があるか
ifが式で値を返せるようになってたらなあ

x = {b m}(1 + isempty(b));　←こんなこと書きたくはなくて
x = isempty(b) ? m : b;　←こう書けたり
x = if isempty(b) then m else b;　←こう書けたらなあ！
x = ifelse(isempty(b), m, b);　←こうは書けるみたいだけど欲しいものとはまた違うし

それ以外は良い言語だお（　＾ω＾）
いっしょに行列グリグリしようず

>>98
行きつくところはFizzBuzz拡張DSL

Haskell等でeDSLか
他言語でインタープリタかJIT

>>68
ウィック回転することでFizzBuzzの時間の流れから時間を消し去ることが可能

>>103
アンカー間違えた orz
>>89 のソースの修正ね

>>103
それ13などの二桁以上の数字に対応できる？

「各桁に含まれる数字か」というルールについては、元のルール（>>9）自体が、2桁以上の数字を想定してないと思うよ。11とか13を基準の数字とするpopwhackとzingchopは「割り切れるか」の方のみを判定条件にしているし。
仮に2桁以上の数字についても「含まれるか」ルールでの判定をするのであれば、たとえば111に11が含まれる回数を1回と考えるのか、2回と考えるのか決めておく必要があると思う。

よくある常識的なルール
消費した分を再び使うことはできないものとする
によって曖昧性を排除できるかと

>>106
決めればいいじゃないｗ
その場合は2回だな

重複していても異なるなら数えることならば3030303030に303は4つ？

正規表現で数えましょ

決めなくて良くないか？オブジェクト指向と関係あるとは思えない

2桁以上の数字の「含まれる」基準の解釈を、オーバーラップ許容型（部分文字列として含めばすべてカウントする）かオーバーラップ非許容型（消費した部分文字列は再利用不可とする）かのどちらかに決めてそのとおりに実装するというのは別に難しいことではないだろうけど、拡張FizzBuzzルールとしてはどちらでもいい枝葉末節の話だからね。前スレの942（Woofルールは303をFizzFizzFizzに変換するのではないか）のような本質的な指摘とは異なる。
2桁以上の数字の「含まれる」基準の判定にも対応するべきだ、その際の基準はオーバーラップ許容型（あるいはオーバーラップ非許容型）であるべきだという主張をすること自体は別に否定しないけど、元の要求仕様（>>9）に含まれている内容ではないから、個人的にはどうでもいい話だと思う。やりたい人がやればいいのでは。

口達者やなー

元々の話は想定される仕様拡張にオブジェクト指向プログラミングなら対応できるのか？で始まったのがFizzBuzz拡張
だから今回の仕様拡張『2桁以上の数字が含まれる場合』が『その含まれるがオーバーラップを許す場合と許さない場合それぞれを実装』にも対応できるか試されるところ
対応できなければ失格だろう

エクセルの表でスマートに作れる

>>114
ほお、ではお前が対応できるか見てやろう、やってみろ

>>113
お前もだ、お前もやれ

俺がオブジェクト指向審査委員長をやる

逃げるなよ

>>115
もしそんなことができるならエクセルはオブジェクト指向

>>113
>>114
期限は3時間な、今日の14時までに出来なかったらお前らにこのスレ一番の無能の烙印を押したうえでオブジェクト指向審査失格の判定をくだすからせいぜい頑張れよ

俺はどっちも逃げるに1票入れとくわｗ

たとえば、Pythonならstr.countを使えばオーバーラップ非許容版になるし、オーバーラップ許容版は先読みアサーションでできる。他の言語でも実装は同様に簡単だろうし、どうでもいい話だと思うよ。

print('111'.count('11')) #->1
print('3030303030'.count('303')) #->2

import re
print(len(matches := re.findall(r'(?=11)', '111'))) #->2
print(len(matches := re.findall(r'(?=303)', '3030303030'))) #->4

せやな
あとは >>114 の問題だな
>>114 が言い出したオブジェクト指向を自分でやり遂げられるのか
それを最後まで見届けよう

the digits contained by a given number
repeated as many times as the condition is true
という原文を考慮するとWoofに
{11: "Whack”, 13: “Chop”}}を追加すれば
111は"FizzWhackWhack”
313は"FizzFizzChop”と解釈するのが普通かな

replaceに重きを置いてdigitは消費ルールにするんなら
111は"FizzWhack”
313は"FizzFizz”

どっちもありだけど
replaceするワードごとに消費リセットするのは
実装から逆算したご都合主義的なルールなので無しだな

>>125
よしわかったお前もエントリーな
14時までに書けよ

>>126
いや、仕事しろよ

>>123
FizzBuzzで正規表現を持ち出すのは大袈裟すぎ
正規表現は禁止で

X.comはクリーンアーキテクチャゴミ過ぎるって話題で盛り上がってるな、クリーンアーキテクチャこそオブジェクト指向の負の遺産だよな

>>128
縛りプレイか
お前はそれでやれ
14時までだぞ

113, 114, 125, 128
こいつらが14時までにできるのかご注目

>>125
123のオーバーラップ非許容版（一度消費すると再利用不可版）はたしかに基準となる数字ごとに消費をリセットしているけど、別にそれが実装上のご都合主義とは思わないけどね。仮にこれを良しとしないなら、基準となる数字同士の間に包含関係がある場合にどう変換するかも仕様として定めておく必要がある。たとえば、2 -> hoge, 22 -> puge みたいな変換ルールが与えられたときに222をどう変換すべきかみたいな話ね。>>123のオーバーラップ非許容版ならhogehogehogepugeとなるのに対し、消費をリセットしない仕様ならhogehogehogeかpugehogeみたいな感じになるんだろうけど、いずれにせよどちらの仕様にしたいかというだけの話だと思うけど。

仕様を決めればそのとおりに実装することはどうとでもなるだろうけど、こういう枝葉末節の仕様を細かく決めていくこと自体にはそんなに意味がないんじゃないかなとは思う。

>>127
仕事とオブジェクト指向どっちが大事なんだ！

>>20 を対応

これらは非オーバーラップ版としてそのまま動作

>> const IN: Count = |t, n| t.to_string().contains(&n.to_string()) as usize;
>> const DIV_OR_IN: Count = |t, n| (t % n == 0 || t.to_string().contains(&n.to_string())) as usize;
>> const DIV_AND_MULTI_IN: Count = |t, n| (t % n == 0) as usize + t.to_string().split(&n.to_string()).count() - 1;

オーバーラップ版は新設

const DIV_AND_MULTI_IN_OVERLAP: Count = |t, n| (t % n == 0) as usize + overlap_count(t, n);

fn overlap_count(haystack: usize, needle: usize) -> usize {
let haystack = haystack.to_string().into_bytes();
let needle = needle.to_string().into_bytes();
haystack.windows(needle.len()).filter(|&target| target == needle).count()
}

>>129
抽出化を入れまくったりしてクリーンアーキテクチャの実装様式をゴミにする開発担当が悪いのであって
依存方向を制限するという原則自体には依然として価値があるぞ

>>117
ｵﾚ89の作者なんだけれども…

>>135
ドメインロジック部分から周辺入出力まで各階層を分けるのはどのモデルでもだいたい同じで
あとは依存性逆転の原則を守ればいいだけだよね
つまり双方がインターフェースのみに依存せよが正しいオブジェクト指向プログラミング

>>89の6行目のまま複数桁に対応すんじゃねーかな
パターンじゃなくて特定の文字へのgマッチだから
確認・検証、略

こう見えてもｵｼﾞｻﾝ忙しいんだよ

>>136
なんかすみません…

>>134
Rustはええよなー標準ライブラリがつおい

>>137
だったらその正しいオブジェクト指向プログラミングとやらでFizzBuzz書いてみろよタワケが

>>120
エクセルの表はセル内の数式で勝手に演算するからなぁ
誰もどこからもプログラムで指令なんかしない

つまりオブジェクト指向ってのはツールで実現できるから、言語で実装しようとするから汚くなる

>>143
せやかて工藤、プログラム言語でFizzBuzzを計算できる人たたくさんいるけどExcelでFizzBuzzを計算できた人はいまのところお前も含めて一人もおらんぞ、ちゅうことはやExcelの方が不便なんじゃねえのかな

は？
エクセルの列に3の倍数、5の倍数とか作れば終わるじゃん

で、列を統合すりゃ完成よ

>>145
FizzBuzz各バリエーションはどうするの？

>>9 java
https://ideone.com/YO6IJy
・class FizzBuzz廃止

>>9 ruby
https://ideone.com/oNWERQ
・class FizzBuzz廃止

>>9 octave
https://ideone.com/aqe5by
・関数の呼び出し関係を↑のJavaやRubyと同じに変更
・fizzbuzz関数が結果を返していたのが>>88
・fizzbuzz関数がクロージャを返すのがこれ

エクセルニキ完全沈黙

>>137
>インターフェースのみに依存せよ
別にオブジェクト指向じゃなくても普通のプログラミングの原則やろ

>>148
エクセルニキじゃないけど出来ないと思うのが逆に不思議
Excel苦手？

エクセル苦手っていうか表計算の仕組みを全く理解していないんだろうな

>>150
俺には無理、イキリ散らしているお前でさえ出来てない、いまのところExcelで出来た人は0人
いまの状況でExcelでできるというのが逆に不思議、何の根拠もない

> 115 デフォルトの名無しさん 垢版 | 2026/08/31(月) 10:37:57.07ID:Jy5vPfka
> エクセルの表でスマートに作れる

はよ作ってみせろや、スマートになｗ

本当に馬鹿なんだねぇ

>>154
まだ出来ないのか？ｗ

おいおいまだ出来てないんだってよこいつｗ
いつまでかかってんだよ、さっさとやれよ

できるんだよね〜Excelならスマートにできるんだよね〜お〜ん？ｗｗｗ

またお前か

A列に1からnまでの連番を作って、B列に変換関数を書いて、C列に結果を出力するみたいな感じ？　それでできたことになるのかは、自分にはちょっとよく判断がつかないが。今のExcelってLetとかが入ったから、理論的には他のプログラミング言語と同等の記述能力があるんでしょ。だから変換関数自体はいちおう書けるんじゃないかと思うけど（見やすいかどうかはともかく）。

A列に
1
2
3
…
=一個上-1

と入力しておいて、B列に式

=IF(AND(MOD(A1,3)=0,MOD(A1,5)=0),"FizzBuzz",IF(MOD(A1,3)=0,"Fizz",IF(MOD(A1,5)=0,"Buzz","")))

を縦ににずっと設定していけばできるだろJK

これはCLassicで、多少ややっこしくなるけれど他のvariationも頑張れば同様に
VBA等を使うまでもなく式でもできるさ

variationは多少煩わしのでｵﾚはいいや気が乗らん

>>160
=一個上-1
↓
=一個上+1

な。

B列は3の倍数
C列は5の倍数・・・でいいんだよ

あとはVBAで必要な数与えりゃ、必要分の行をコピーで増やせば出来上がり

行がオブジェクトでもあり、列がオブジェクトでもあり、セルがオブジェクトでもある
ループも使わず結果が出る

>>9のFizzBuzzバリエーションwoofも書ける？

>>163 またせた、っ >>162

各列にルールごとの変換結果を持っておいて、それを適宜組み合わせるという発想は、「最初からテーブルで全部持っておく」おじさんの理想にかなり近いのでは。

=LET(Ary,A1#,Res,
IF(MOD(Ary,3)=0,"Fizz","")
&IF(NOT(ISERROR(FIND(Ary,"3"))),"Fizz","")
&IF(MOD(Ary,5)=0,"Buzz","")
&IF(NOT(ISERROR(FIND(Ary,"5"))),"Buzz","")
&IF(MOD(Ary,7)=0,"Woof","")
&IF(NOT(ISERROR(FIND(Ary,"7"))),"Woof",""),
IF(Res="",Ary,Res)

A1にスピル配列で
なんでExcelでFizzBuzzができるかという話になってるのかは分からないけど、条件増えてもこれで配列渡しでもイケると思う

FINDの引数を入れ替えるミス
お恥ずかしい

>>163は相当頭悪そう

何のための列だよ
自由自在

>>165
エクセルのいいところは、最初っから何個使うかわからんテーブル形式ではなく
必要な分を行追加コピーで済むことだ
全部数式込みで増やせて、増やした瞬間に計算終わっちゃうから必要最小限のテーブルしか作らない

>>9 の全バリエーションに対応してから言えよ
何が自由自在だよ、自縄自縛の間違いだろｗ

頭悪いのって不幸だねぇ

>>170
そんなんＥｘｃｅｌでガムばらなくてもいいんじゃない？

>>169
それはまた同時にＥｘｃｅｌの欠点でもある二面性じゃない？

>>171
>>9 の全バリエーションにはいつ対応できるんだ？ お〜ん？ お〜ん？ お〜〜〜ん？？？

>>172
それが正しい、Excelでやるよりプログラム言語で計算した方が100倍マシ

Excelのセルを縦横無尽に参照した式瀬ッての多様やVBAマクロは難読があっという間に��くなりきわめてたちが悪いからな。
賢い人ならなぜ問題か知っていること
だからそこで頑張ってもしょうがない

> 115 デフォルトの名無しさん 垢版 | 2026/08/31(月) 10:37:57.07ID:Jy5vPfka
> エクセルの表でスマートに作れる

あれあれ〜〜〜？？？　まだですか〜〜〜？？？
まだできないんですか〜〜〜？？？　お〜〜〜ん？？？

頭悪そう
エクセルの難読なのがあったとして
それと同じ機能をプログラム言語で記述したらさらに難読でしかないって理解できないのだねぇ

>>162
問題を矮小化して解決した気になってるんじゃねえよｗｗｗｗｗ
>>9 を解け >>9 が問題なんだよ、問題が何なのかも理解してないのかエクセル大先生はよｗｗｗｗｗ

>>178
ほうほう、お前はよほど頭が良いようだな
>>9 をプログラム言語で計算するよりもエクセルで簡単にできるんだな
よしわかった、じゃあやってみろ、お前が言うことが本当だとするならできるはずだよな
できなかったらお前は大嘘つきだ

>>178
おまえ、苦しんだことないな、
いや野良ＥｘｃｅｌやＶＢＡ作り散らかして周りに迷惑かけているタイプだろ

セルはすべてグローバル変数と同じ。それば無数にある

それを他のセルに設定されている「露わには目に見えない」式の中であちこちから参照する
そしてその式の値が反映されているセルがまたどこかの式が参照する…このくりかえし

プログラミング言語の発展はそういった複雑さの爆発や難読性をどう抑制し
なんとか大規模ソフトウエアを作れるようするかの戦いでもあったんだぞ

お前はグローバル変数ばかりでプログラム書くのか？
人のことバカにしたような口きいてるが
何ひとつ知らないのはお前の方だ恥ずかしいやつめ

で、オブジェクト指向教はその抑制の役には
あまりたたなかったんだよな

Excelの話はもういいよ。

Excelの話題になると、ちょっと式設定やVBAを使えるようになっただけで天狗になっている井の中の蛙が
変な時論や蘊蓄で周りも攻撃しちらかしたりして雰囲気悪くするから相手にしない方が良いよ。

変てこなオレオレ オブジェクト指向信者もにたようなもんだが

変てこなオレオレオブジェクト指向といえば場のオブジェクト指向おじさんだけど
場のオブジェクト指向おじさんも >>9 をできなかったんだよな
>>9 は良い課題なのかも知れないね

オブジェクト指向をマンセーしている原理主義者は
大概ヘンテコこだよ

>>184
へ、作るつもりがないだけだよ、作ってもおもしろくない。仕様もあいまいだし。
FizzBuzzはABC予想と考えて、場としてのABC予想を考えているところ。
積と和の関係。

ttps://i.gyazo.com/8510f28a95ef5cff135c8240f8562e70.png

>>183
Excelはどうでもいいと思うけど、雰囲気悪くするはちょっと面白いね
ここって和気藹々とお話するスレなのか？

吉野家のコピペのようなどこか奥底で人間愛を感じられるものは好きだな
自分が無知で愚かなだけなのに人を心底バカにしたり嫌がらせするのはｺﾞﾒﾝこうむりたいわ

いやー
エクセルごとき使えないって馬鹿にされて当たり前でしょ

せめてモデルとビューは分けないとな

>>190
じゃあその使いこなしたのを披露して

>>9 octave
https://ideone.com/a2Z8kW
・他言語の実装に引っ張られすぎてたので野生を取り戻した
・結局のところスカラで計算してたのが>>147
・可能な限り行列をグリグリしてるのがこれ
・結果として結合部分がちょっとナーバスになっちゃった
　行列全体をケアできるような処理しか対応できなくなった
・あと男らしくfor丸出しで計算したいのでfold_lefは廃止
・なんかトータルで遅くなってるような気がしないでもない

>>149
依存性逆転の原則（dependency inversion principle）とは、オブジェクト指向設計の用語であり、ソフトウェアモジュールの疎結合を確立する特別な形態を表現したコンセプトである。
オブジェクト指向設計の5つの原則SOLIDの一つとして知られている。
上位モジュールと下位モジュールの双方が抽象（インターフェース等）に依存すべき原則である。

インターフェース分離の原則 (Interface segregation principle) もあるしな
各オブジェクトは様々に機能分化された用途ごとの無数のインターフェースから複数を組み合わせて実装することになる

>>194
>依存性逆転の原則（dependency inversion principle）とは、オブジェクト指向設計の用語であり

全然関係ない
インターフェース定義したらオブジェクト指向みたいなバカな考えやめろや

オブジェクト指向設計界隈から生まれた用語ではあるけど
パラダイムに関係のないモジュール設計の一般原則

異なる型のオブジェクトに共通の性質を与えてポリモーフィズムにより区別することなくメソッド呼び出しできるようにする枠組みがインターフェース

インターフェースにすればモジュールが実装を知らなくても済むようになる
なんて素晴らしい

C言語のexternによる外部関数プロトタイプ宣言との違いを
400字づめ原稿用紙1枚程度で述べよ (配点20点)

>>200
C言語の extern も「中身を知らずに呼び出す」点は似ていますよね！でも、目的と柔軟性が大違いです。C言語の extern（場所案内）実体（中身）は世界に1つだけ。別のファイルにある「その関数」をピンポイントで指すため、後から中身をサクッと差し替えるのは苦手です。インターフェース（交換用の型枠）ルールを満たせば、中身は何種類でも作れて自由に入れ替え可能です。例えば「印刷」という枠に対して「紙に印刷」「PDF化」などを状況でガシャッと切り替えられます。extern は「離れたファイルを繋ぐための仕組み」、インターフェースは「後からいくらでも部品を交換できるようにする設計図」というイメージです！もしよろしければ、この違いについてさらに深掘りしてみませんか？C言語でこれを再現する「関数ポインタ」の仕組み実際のコードでの見え方の違い次にどちらの話題を知りたいか教えてくださいね！

「教えてくださいね！」じゃねーよAIめが。

概ね合っているが、別ソースファイルだとそれを編集したらそれだけリビルドしリンクすればOKなのでそこ違う。

複数のものを同じインタフェースで構造ごとに呼び分けるのはCでは
意図的にそういうコードをユーザーが書かなきゃならん点は合ってる。

したがって、AI君10/20点
j便で書けずAIに代返してもらった椰子0/20点で落第な

だがな、
》同じインタフェースで構造ごとに呼び分ける
本当にそんな書き方をする機会って多いか？

callerが参照するオブジェクトの種類やmethodが
同じインタフェースで違うものにまちまちにすり替わっても
動作し可読性を高めるように書く

そういう書き方って頻繁にあるかな、
またそれって継承とはまた少し違った沼の入り口ではないかな
結局依存が込み入る

>>203
作るものによるとしか言いようがない。
Linusも昔、そういったことはいってて、OSについていうならドライバー周りくらいだって話をしてる。

【歴史】オブジェクト指向は失敗だったのか。35年のすれ違いの歴史。
www.youtube.com/watch?v=XqpQ549I7AM

少数だが初期から気が付いていた人はいた
周りからは変人扱い

>>203
Rustの標準ライブラリは全てその形でインターフェース抽象型に相当する形でジェネリックにコード共有で作られてる

例えばtrait Readは
抽象メソッドfn read(&mut self, buf: &mut [u8]) -> Result<usize>;を実装するとその型は
提供メソッドのread_to_end read_to_string read_bufなど14個のメソッドが自動的に使える

例えばtrait Iteratorは
抽象メソッドfn next(&mut self) -> Option<Self::Item>;を実装するとその型は
提供メソッドcount nth find filter map flat_map fold collectなど74個のメソッドが自動的に使える

>>205
観るわ

Rustのtraitは、JavaのインターフェイスやC++の抽象クラスと違って、継承ツリーを作らなくてもいいんだっけ？

>>207
Rustは新しい言語のぶん、色々改良・進化してるのかもしれないな
個人的にはやるつもりはなかったんだけれど、
とある事情で使うことになるかもだわ
まあでもオブジェクト指向の問題課題はまだまだ引きずっていそうだな

あと、メモリの安全性は結構だけど、
コンパイル通すのにひとてま間かかりそうな点が気が乗らない
だってｵﾚメモリ関係のバグ10年に一回くらいしか出さないのに
そのために毎回手間暇罹る気がして

まあ使う前の思い込みかも知れないのでファンは気にしないでおくれ

>>211
Rustはメモリ自動解放だから従来の言語と比べて手間がかからなくなったよ
様々な点で書きやすくなってる

>>9 octave
https://ideone.com/5UcfxX
・もっと行列グリグリ
・forループ1個、arrayfun2個残ってたのが>>193
・forループ1個、arrayfun2個無くしたのがこれ

>>205
「データの形と処理の流れを先に、階層は最後の手段に」まあそりゃそうだわな、結局そう言うことだと思うわ。

>>205
プログラミング言語の歴史で大切なものを失った流れが興味深い
Rustのenumとmatchでおなじみの判別共用体とその安全な分岐、と何度も出て来た

それがなぜこれほど長い期間信じ切られて常識のように支持されて来たのか、
そしていまだに熱心な信者がいるのみならず、
新たにこの分野に参加してくるnew commerにまで誤った教育を通して浸透し続けているのか
ホント新興宗教の流行のような不思議な現象だと思う。

個人的にはオブジェクト指向、特にクラスベースオブジェクト指向が指示され流行してきたココ数十年は
コンピューターサイエンスやソフトウエア工学の暗黒時代だったのではないかという気さえする

先生！関連する動画にこんなのがありあした
ttps://www.youtube.com/watch?v=FSnSZ_h7OQ0

オブジェクト指向とは何か、を誰も明確に説明できないまま、その機能的副産物をありがたがって過剰に使用して、それに対する反発が出て改善が行われて、その改善をオブジェクト指向そのものの否定と勘違いしている。
ソフトウェア技術者は哲学が得意そうなイメージがあるが、ソフトウェア開発における抽象化は実用主義的な割り切り・選別であって哲学の本質主義的な抽象化ではなく、本質の抽象はあまり得意ではないのかもしれない。

>>218
オブジェクト指向＝世界のモデル化
ということか

>>219
オブジェクト指向を哲学するのは落合陽一先生だけで良い

オブジェクト指向は世界に対する自分の認識をそのままコードに落とすことだとするとやってる本人的には納得感が得られやすいから過大評価されがちなのかなって思った

>>202
>もしよろしければ、この違いについてさらに深掘りしてみませんか？C言語でこれを再現する「関数ポインタ」の仕組み実際のコードでの見え方の違い次にどちらの話題を知りたいか教えてくださいね！
これは定型文だな
中身を変えて必ず文末に現れる

Rust の Path はあまり上手じゃないと思う

MicrosoftのWindowsが足を引っ張ってるよな

VB6を切ったのが悪い

>>226
VBで >>9 やってみ
なぜVB6が切られたのかわかるから

>>220
そうではないがそう解釈しちゃう人が多いって話だろ。
まあ動画でも言ってるけど、階層で綺麗に分類したくなるってのは思考として自然と言えば自然だからな。

素人講師でも、車だのPersonだのを例に示せば、もっとど素人の受講者を煙に巻いて分かったような気にさせる説明しゃ易いしな
でもそんなデータモデリング実践ではまれなのに、向いてないところにまで適用してカプセル化と多階層と継承で何と実演しちゃおうと
ぐちゃぐちゃ悪戦苦闘してゴミコード量産が連綿と続けられてきた
それを実世界のモデリングだの抽象化だの、言葉の意味も正しく理解してないのに
言いはって悦に入ってたという集団狂気みたいなものか

クラス継承は不要。
最近のプログラミング言語はクラス継承機能を外している。

人間と鳥を継承して鳥人間を作るより
人間に羽を付けて鳥人間もどきにする方がいいってこと？

プログラミングで実際に使う共通の機能で考える
もし共通に呼び出せる機能があるならその機能のインターフェース抽象型としてまとめる

沼の入り口には変わりないようなｗ

言うほどお前のコードは一般化されないって理解するところからやな

インターフェイスを使えば解決するね
インターフェイスの抽象メソッドは各型が個別に実装するものだから

新たな宗派の台頭か?

多階層にしなければそれでも継承でもなんとかなる「場合もある」かもな

インターフェースは具象型ではなく抽象型だ
その抽象メソッドを実装することで初めて仲間入りする

何か来るかは来てのお楽しみ、目をつむって呼んで頂戴って、
それはそれで厄介ごとのタネになるような…

>>231
鳥人間を一から作れば済むこと

>>230
クラス継承は害悪だの悪魔のクラス継承だの言ってたのにめっちゃトーンダウンしてるやんｗ

※効果には個人差があります。

鳥人間は、鳥と人間を継承しているのではなく、
鳥と鳥人間の基本クラスがあり、人間と鳥人間の基本クラスがある。
鳥と人間の基本クラスもある。
基本クラスは共通の性質を抽出したもの。
先に基本クラスを（間違った性質で）定義してしまうから、問題が発生する。

多重継承が複雑化する原因であって継承自体は問題ないでしょ
人間と鳥がセックスしても子供なんて生まれないのと同じで違う役割のクラス混ぜてもまともなもの生まれない
どうしても人間に鳥の機能付けたいなら羽とか砂ずり付いたクラスを人間に外付けすりゃ良い

それらは全てインターフェース

鳥人間は鳥の性質を持った人間だけど人間の性質を持った鳥ではない
つまり人間を継承することは許されるが鳥を継承することは許されない

ただし、本当に継承するのがいいかどうかはユースケース次第です、はい。

鳥人間の何の機能が必要なのか？箸でご飯を掴んでくちばしで食べる衛生機能か？羽毛の上にダウンジャケットを羽織る防寒機能か？話はそれからだ人間も鳥も鳥人間も作るな、必要なのは防寒関数だけの可能性がある

防寒関数は防寒対象が必要だから
「必要なのは防寒関数だけの可能性」は無い

現実をそのままモデリングするってのは無理だけど現実を全く参考にしないでコード組むってのも不可能だからな。
ドメインモデリングの有用性ってのはそのくらい中間的なものだよ。

わしが現役の頃は仮想関数テーブルでキャッシュを汚すなと親方に怒られたもんだ

Rustみたいな単相化が速くていいよな
必要なら仮想関数テーブルも選択できる

今時そんなところでランタイム速度は変わらんよ。

仮想関数テーブルは明確に遅いから避けられるなら避けるべし

クラス継承階層の多段の仮想関数テーブルをたどって行くパターンは特に遅すぎ

スピード以前に問題大ありだろ

vtableが遅い言われてたの2000年代前半くらいの頃だけどなｗ

ここにいる人たちの時間が25年前で止まってるのはどうしてなの？

普通の関数呼び出しと比べてvtable経由は現在も変わらず遅い
魔法は発明されていない

最適化する前に計測しろって格言を知らない人たちなんでしょうなあ

コンパイラとCPUが魔法の様に最適化してくれる

コーディングの最適化とはあまり関係ない話だよな
メソッド呼び出しでvtable相当を使いがちな言語と言語側の最適化の話だな

>>252
vtableが使われると遅い

>>259
最適化するとvtableを避けられるプログラミング言語を使ってるの？具体的にどれ？

WindowsのCOMはvtableだけど遅くはないな
影響が出るのは多重継承のvtableで検索コストが増大した時だ

>>257
主に以下3つの理由からです
1. 間違ったオブジェクト指向を教育される環境にいた
2. 間違ったオブジェクト指向を正してくれる人間が周りにいない環境にいる
3. 原典や良書と呼ばれるものを読まずにネットのまとめ記事で分かった気になっている

>>263
vtableすなわち動的ディスパッチは必ず遅くなる
そのため動的ディスパッチを回避する手段が昔からあったり回避できる言語も増えてる

>>264
・そもそもスレが板違い
・オブジェクト指向(OOP)という言葉を使いだした当事者が厳密な定義をしてない
・言葉に振り回されて肝心のものが作れないアホの吹き溜まりになってる

Rust はトレイトの継承しかなく、dyn Trait の vtable のレイアウトは静的に決定される。
dyn Trait のメソッドを呼び出す時に vtable を経由して呼び出すだけなのでほとんど遅くはならない。
インライン展開やゼロコスト参照の妨げにはなるから、そこは遅くなる可能性があるが。

AIに聞いたところ、C++ も vtable を静的に決定しているが、Rust とは異なり全コンパイルしないのでライブラリの中のクラスを継承していて、そのクラスの継承関係が変更されていた場合は壊れる（未定義動作）。 （「Fragile Base Class」問題と言うらしい。）
Java は vtable をクラスロード時に構築してるがそのままだと遅くて、インラインキャッシュやJITの投機的最適化によって遅くならないようにしている。

>>267
C++はインターフェースとして純粋仮想関数の抽象クラスを使うけど
複数のインターフェースを使うと各々vtableを複数使い分けるコストもある
Rustは複数のトレイトを使っても静的に1つのvtableにまとまる

Rustのゴリ押しが酷いスレだな

オブジェクト指向といえばメソッド呼び出し分けで動的ディスパッチ/静的ディスパッチの話は不可避だけど
今まで話が出て来なかったのも不思議ね

どうせRustの話だろ、オブジェクト指向の話じゃねえよ

>>268
Rustはダイナミックディスパッチが別扱いで型合わせでごたごたする

Rust以外にも静的ディスパッチの単相化にできる言語は多い
C++はテンプレートでGoやSwiftはジェネリクスで単相化にできる

どうでもええわ

オブジェクト指向とはステージが違うんだよステージがな
Rustはオブジェクト指向出禁にしようぜくっそうぜえわ

ここはオブジェクト指向を嗜む人間がしっぽりと豊かな時間を満喫する大人のBARなんだよ

>>272
どの言語でも単相化は具体的な型に確定するから可能になるんだよ
ダイナミックディスパッチはどの言語でも抽象的な型のまま扱う

>>272
Rustはコードをimpl Trait⇔dyn Traitに替えるだけで静的ディスパッチ⇔動的ディスパッチを切り替えられるから一番簡単だぞ
impl Trait→dyn Traitの変換も参照ならそのままキャストできて値ならBox化すれば可能

このスレもまた複おじスレになりつつある

GoとRustはこの分野でも従来と一線を画していて、
従来の言語はvtableへのポインタをオブジェクトの中に隠しフィールドのように内臓してしまっていたのに対して、
GoとRustはvtableへのポインタをオブジェクトの外に外付けした。
オブジェクトは太らず自然そのまま扱える。
外付けすれば動的ディスパッチに対応できる。

>>261
やっぱり何も分かってない。。

だよな
単相化できないクソ言語は捨てるのが正しい
メソッド呼び出しが動的ディスパッチになって遅いから多相を使うのを辞めるなんて本末転倒

ポリモーフィズムはオブジェクト指向の核だよ花だよ
使うと遅くなる言語は筋が悪いかもね

複おじ連投し過ぎｗｗ

型付けが動的な言語に慣れた身からすると
要らぬ苦労、ご苦労様なこった

>>285
PythonもRubyもJavaScriptも型を後付けしようと必死こいてるけどそれについてはどう思ってるの？
ダックタイピングで十分なの？

Rubyが遅いのとC++のvtableが遅いのはほぼ同じ理由

>>280
>オブジェクトは太らず自然そのまま扱える
これ結構大事だよね
隠しフィールドなんて邪魔物でしかない

>>286
必要な場合だけでいいと思う。どうしても副作用を避けたい場合や
多人数で働き、チームメイトが玉石混合でも品質をなるべく確保したい場合など。

型も動的、データ構造も動的、プロパティーも動的、従属するメソッドも動的、オブジェクトの所属する型(クラスやパッケージ)も動的
自分がきちんとコントロールできる力があればこれっらの自由度は非常に強い武器になる

ということであちきはオブジェクト指向、とくにクラスベースオブジェクトは
ごくまれにしか使わなくなってしまいました
プロトタイプベースやプロパティーはたまに使う

動的型付けの副作用により実践でトラブルに遭遇したのは10年に一回くらいかな
ファイルから読みこむあるフィールドが仕様では数値なので数値としてパースするコードに対し
ファイルが誤って非数値文字列が入っていて、数値文字列でないというエラーを吐いたとか

あと、JITやcompileの最適化は型付けの方が有効だろうな
何がくるか絞れる分

振り返ってみると、C++を使うということは何の苦行だったのかという気がする
何かの罰ゲーム？みたいな苦痛

>>286
今さら型付けを導入しようとしている背景のひとつは
Javaのような静的型付けのクラスベースオブジェクト指向言語から入って
プログラミング言語はそういうものだと思うようになった初心者などに
すそ野が広がって戸惑いを与えていることも一因だと思う
門戸開放政策みたいなものか

型があればコンパイル時にわかる単純なバグを動的型付き言語ではわざわざテストを書いて一生懸命確認しないといけないもんな、そういう無駄な作業を頑張ることが初心者には受け入れられなかったのかもな

型を明示したら自動的に型がテストされるしくみが有れば良いだろうけどな
言語レベルでそれをサポートしたプログラミング言語を静的型付き言語と呼ぶことにしよう

>>291
それ静的型付けでも同じように実行時エラーになるだけだよ

>>295
>型があればコンパイル時にわかる単純なバグを動的型付き言語ではわざわざテストを書いて一生懸命確認しないといけない

これがよくある誤解
特にテストを書かない人は自己正当化のためにそう思いたいらしい

>>298
何が誤解なの？

２０年経っても同じようなくだらない話ばっかだな

静的型付き言語では型の間違いはコンパイルエラーになるから型のテストは書かないわな
自己正当化とかそういうのではなく書く必要がないからね

>>300
お前、サリーとアン課題解けなさそう

ほらな、この手の言語バカって昔からなんも変わってない。
まあ言語がc++からrustには変わってるってのはあるか。
そういえば江添とか生きてんのかね

>>303
サリーとアン課題は解けたのか？ あ？

>>297
手短で伝わらなったんだと思う。
読み込んだ際に直ちにエラーになるのではなく、読み込んだ物を先の方で
いざ演算などで使う暖になって、数値じゃないとエラーになる。
読み込から離れた場所でオブジェクトの型が不適合だと露わになる
この距離感が静的の場合と違う

>>300
お前なんか下る話どころかくだらない話すら できないでやんの

>>305
それは実行時に読み込んだ値をパースするタイミングの話で実装の問題だ
静的型付き言語だったら起こらない類の問題ではないように思う

静的の場合scanfの返り値チェックなど省くとそれに近いことになるが
その場合ゴミが帰る。
動的な場合、数値だと思ったら文字列が渡っていく
そいう違いがある

値を読み込んで文字列型で保持しておいてパースを先延ばしにするのは静的言語でもやるよ、読み込んですぐにパースするのが型チェックの意味では良いのかもしらんけど、パースした結果の構造を引き回すことでコードがわかりづらくなることもあるからパースするタイミングはここがベストというものがないように思う

使う前までパースを先延ばしにしたら静も動と同様
使う段直前でエラーだな

あとやっぱ、型が静的な方がcompile時の静的解析レベルで
怪しい書き方の検出がしやすいだろうな

おまえらアホやろ
入力エラーは最終的にエラーとして返せればよいだけだ

>>309
パース前とパース後で型は異なり構造体だとしても一つのオブジェクトに過ぎないからコードが分かりづらくなることは一切ない
型が区別できるようにすることは重要

何かずれた回答だな、
最終的にエラーとして返せればよい「だけ」で問題解決するなら
なぜデバッグで苦労するのよ

委譲のリターンイモずる管理地獄の罠にでもはまりやがれってんだ

エラーを返す関数を書く気がないからだろ

型はこの変数はこのサイズで収納してこの演算命令を使うという意思表示だと思ってるけど
最近の言語は曖昧にしても同じような成果物になるもんなの？
そうならなくてもよいと思うけど

お前みたいな奴は、バグなんて単にデバッグすればいいだけとかいって
対処朗報で糞コード書いていざそのせいで炎上しても
逃げ足だけは早いんだよな

>>317は>>315宛てね

>>316
文脈・使われ方で型推測される
で実用上それで概ね決定できる
という考え方

>>316
正しい
そのために同じ整数値であっても意味が異なり混じってはいけないならラップして別の型にする
使えるメソッドも異なるしな

混じって全然問題ない場合はどうすんのよ

構造体のアラインメントとかシェーダパラメーターとか型なくて平気なんか？、あった方が作る方も分かりやすくないか？というのは型ありになれてるせいか？、もはやAIにコード書いてもらってるから一切気にしてないが

バイナリーレベルの構造を扱う場合は型もしくはビットフィールド的なものを使うに決まってんじゃん
それ以外の一般的な値の集合が対象にきまてるだろ

>>321
インデックスの整数とIDの整数と料金の整数と個数の整数が混じったら困るだろ

全部整数ならその集合を収められる任意の型で問題ないだろ
何に困るんだよ？

適用できるメソッドが異なる
だから別の型のオブジェクトにする

使う側が間違えないようにという親切心なんだろう、俺は成果物が同じなら何でも良いと思ってるけど

メソッドが一個ですむので、複数作って呼び方を統一する苦労がない
ってのが>>285 迄の話で起点になってるんだが
もしかして日本語おｋ？

そうね1個でよいね
同じ意味で使ってるなら間違えようがない

うん。違う処理のメソッドを同じインターフェースで同じ場所から呼ぶなんて
○地外沙汰だわ。そんなことしちゃだめさ

インターフェースとしては何でも受け入れるけど実体は厳密な型で実装されているってことね

>>328
メソッドが1個だけ？
メソッド名と仕様を教えてくれ

う〜ん、何て言ったらいいやら
文だけのコミュニケーションの難点かな

>>332
もっとも単純な例だとたとえば、Absでもいいじゃん

数値 ＝abs（数値）

型ごとにmethod設ける必要もなし、キャストで統一する必要もなし

つかまた子ども電話相談室状態だよちょっとげんなり

ID:bQCh0Y2i　(24回)
頭おかしい

>>335
色々質問されたり分かってない人から反論されるとﾚｽが増えちゃうんよ
だから子ども電話相談室みたいに初歩的なことくどくど訊かれてレスの応酬するの嫌いなの

perlの人？

動的extentの人では？

Why Guy Steele Jr. use the term "extent instead of "lifetime" ? - Google 検索

Guy Steele used the term "extent" instead of "lifetime" to establish a precise formal counterpart to "scope," cleanly separating the temporal dimension (when a binding can be referenced during execution) from the spatial dimension (where a name is textually visible in code). [1]
## Scope vs. Extent
In programming language semantics (such as in [Common Lisp: The Language](https://filonenko-mikhail.github.io/cltl2-doc/enpdf/cltl2.pdf) and Scheme), Steele defined variable usage across two independent axes: [1, 2]

* Scope: The spatial or textual region of the program where a name can refer to a specific binding.
* Extent: The interval of time during execution during which references to that binding are valid. [1]

## Why "Extent" Instead of "Lifetime"?

* Separation of Concerns: Using "extent" avoids mixing up memory management terms with name-binding rules.
* Binding vs. Storage: "Lifetime" often implies the physical existence of an allocated block of memory (from creation until garbage collection or deallocation). "Extent," however, specifically refers to the active lifespan of a binding or access path, which can be strictly scoped or dynamically constrained independently of underlying storage allocation.
* Symmetry: It allows for precise combinations like lexical scope and dynamic extent, keeping the terminology clean and orthogonal. [1, 3, 4, 5]

[1] [https://prl.khoury.northeastern.edu](https://prl.khoury.northeastern.edu/blog/2019/09/05/lexical-and-dynamic-scope/)
[2] [https://dl.acm.org](https://dl.acm.org/doi/fullHtml/10.1145/3544885.3544889)
[3] [https://en.wikipedia.org](https://en.wikipedia.org/wiki/Common_Lisp)
[4] [https://ieeexplore.ieee.org](http://ieeexplore.ieee.org/iel1/2279/4109/00159138.pdf)
[5] [https://common-lisp.net](https://common-lisp.net/project/cmucl/downloads/release/19f/cmu-user.pdf)

日本語で

ガイ・スティール・ジュニア（Guy Steele Jr.）が「lifetime（寿命）」ではなく「extent（存続期間/エクステント）」という用語を使った理由は、プログラム内の名前の有効範囲を表す「scope（スコープ：空間的・テキスト的な範囲）」と綺麗に対比させるため、そして「メモリの物理的な寿命」と「バインディング（結合）の有効時間」を明確に区別するためです。
## 1. 「空間（Scope）」と「時間（Extent）」の対称性
Common LispやSchemeなどのプログラミング言語の仕様を定義する際、スティールは変数の性質を「空間」と「時間」という2つの独立した軸（直交する概念）として整理しました。

* Scope（スコープ）：プログラムのソースコード上で、その名前（変数名など）が参照可能な「空間的（テキスト上）の範囲」。
* Extent（エクステント）：プログラムの実行中において、そのバインディング（名前と値の結びつき）が有効に存在する「時間的な区間」。

「Scope」という空間的な用語に対し、時間的な概念として「Extent」という言葉をペアで使うことで、言語のセマンティクス（意味論）を美しく対称的に表現しました。
## 2. 「Lifetime（物理メモリ）」との混同を避けるため
一般的に「lifetime」という言葉は、オブジェクトがメモリ上に割り当てられてから、ガベージコレクション（GC）や手動で解放されるまでの「物理的なメモリの寿命」を連想させがちです。
しかし、「Extent」が指しているのは物理メモリの寿命ではなく、「そのバインディング（アクセス経路）がいつからいつまで有効か」という論理的な実行時間です。
例えば、ある変数の「Extent（存続期間）」が終了してプログラムからアクセスできなくなった後でも、ガベージコレクションが実際にそのメモリを回収する（＝Lifetimeの終了）までにはタイムラグがあります。この2つを混同しないために、あえて別の学術的な用語が必要でした。
------------------------------
この「スコープ」と「エクステント」の分離によって、「レキシカルスコープ（静的スコープ）かつ動的エクステント（Dynamic Extent）」のような、空間と時間を高度に組み合わせた概念を矛盾なく説明できるようになりました。

C++において、配列などの「空間的な広がり（次元の要素数・サイズ）」を表す用語として extent が標準ライブラリ（仕様）に正式に導入されたのは、2011年（C++11）からです。
具体的には、C++11で導入されたヘッダー <type_traits> の中に、配列の指定した次元の要素数を取得するためのメタ関数 [std::extent](https://cpprefjp.github.io/reference/type_traits/extent.html) が定義されたことで、公式な用語として定着しました。 [1, 2]
その後、C++の進化とともにこの「空間の大きさ」としての extent の概念はさらに強化されています。
## C++における extent の歴史と発展

| 規格 | 導入された機能・概念 | 用語としての役割 |
|---|---|---|
| C++11 | std::extent | 型（配列）の指定した次元の「要素数（サイズ）」をコンパイル時に取得するメタ関数として公式採用。 |
| C++20 | std::span[](https://www.modernescpp.com/index.php/stdspan-in-c20-more-details/) | 連続したメモリ領域（配列やvectorなど）を指す軽量なビュー。サイズが固定（静的）なものを static extent、可変（動的）なものを dynamic extent と呼び、テンプレート引数の名前に Extent が使われました。 |
| C++23 | std::mdspan[](https://cpprefjp.github.io/reference/mdspan/extents.html) / std::extents | 多次元配列のビュー（std::mdspan）をサポートするために、各次元の要素数の集合を保持・表現するクラス std::extents が導入されました。 |

## なぜC++は「size」や「length」ではなく「extent」を選んだのか？
C++にはすでに size() や length() という用語がありますが、多次元配列を扱うにあたって extent という英語の本来の意味（「空間的な広がり、範囲、長さ、次元の境界」）が非常に都合が良かったためです。

* 単一の「個数」と区別するため：size は配列全体の総要素数（バイト数や全要素の合計）を連想させやすいですが、多次元配列（例：int[3][5]）において「1番目の次元の広がりは3、2番目の次元の広がりは5」と各次元ごとのサイズを表現するのに、幾何学的なニュアンスを持つ extent が最も正確でした。
* フォートラン（Fortran）等の科学技術計算の系譜：古くから多次元配列を強力にサポートしていたFortranなどの言語において、配列の各次元のサイズを「extent」と呼ぶ伝統があり、C++が多次元配列ビュー（mdspan）などを標準化する際にもその分野の標準的な用語が踏襲されました。

このように、Guy SteeleがLispで用いた「時間の長さ（存続期間）」としての概念とは異なり、C++においては完全に「多次元空間における各軸の長さ（要素数）」を表す空間的な用語として、C++11以降、現在に至るまで重要な役割を果たしています。

効きすぎやろｗｗｗ

>>338
もうやめたれ

まとめると
従来から使われていたlifetimeはLispの状況ではちょっと違うから新たなLisp用語extentを使った
C/C++では従来からのlifetimeが意味的にも正しくて規格書でもlifetimeのみ登場するためextentは不適切

多次元配列の幅にextentを使うようになったのはC++の0x11から

物理メモリの内容の有効期間と変数(Symbol)がそれにbinｄしている有効期間が異なる言語
ex) Lisp, Scheme, Python, Perl, Ruby, Go や Ｃ#も？など
における物理メモリ内容のlifetimeとSymbolのbindの有効期間を明確化するため
extentという用語を用いてlifetimeと区別した

なお、ＣやＣ＋＋ではSymbolのBindに相当するものはない

>>347
物理メモリの内容の有効期間の意味で揉めそう

>>348
まぁfreeしたら無効とか、関数からreturnしてstackが戻ったら無効とか

>>347
それはおかしい
GC言語において有効か無効かは
「その瞬間に仮にGCが発動したら回収されるなら無効で残るなら有効」
トンデモ主張「GCがまだ来ないから有効」は馬鹿げている

変数のextent(Lisp用語)と
オブジェクトのlifetime(一般用語)は
似て非なるもの

現代の一般的な言語では変数のextentを意識する必要はないので
Lisp的な意味でのextentは使われず死語といって差し支えない状態

>>347
＞物理メモリの内容の有効期間と変数(Symbol)がそれにbinｄしている有効期間が異なる言語

Rustもそれに該当しますがlifetimeと呼ばれていますよ
だからそのあなたの定義に違和感があります

>>350
こういったらどうよ。
あるSymbolがBindしているGC領域内のあるメモリの内容は、1≦＝reference countでllifetime valid。
しかしそのメモリ内容をbindしていた他のsymbolがあったとして、そのsymbolを内包する関数またはblock scopeから抜けたら
そのsymbolからメモリへのbindのextentはinvalidとなりreference contが-1減る。
reference contが0になったら、メモリの内容にＧＣが来るまで値の残骸がたとえ残っていてもlifetimeは尽きていてgarbage。

ここでSymbolという用語になじみが無かったら変数名と読み替えて。

変数の有効期限と言ったらextentを使うよう学んできてる
今後もSymbol bindや変数の有効期限にはextentを使っていくつもり

>>353
その言語でそういうのなら従えばいい。
現にC++ではetentは多次元配列の幅ということになった。

しかしSymbolや変数のlifetimeってなによ？
翌々考えると逆に違和感がある

で、話を数百スレ戻すと、言いたかったのはオブジェクト指向で乱用される動的extentのインスタンスは害があるってこと
もー、簡単なことなのに話が進まんよ

>>353
Rustのlifetimeは
物理メモリの内容の有効期間と
変数(Symbol)がそれにbinｄしている有効期間の
二択で選ぶなら前者だよ

>>354
言ってることが矛盾してるぞ
変数(のスコープ等)が尽きても他の参照が残ってればGC回収されないだろ
つまり変数へのバインディングとは無関係だ

>>356
「動的extentのインスタンス」って言った場合のextentは
変数のextentじゃなくオブジェクトのlifetimeを指してるんでしょ？

>>357
Rustでも同じ物理メモリを他の変数が再利用していいよ
だから物理メモリなんてどうでもよくて変数が重要

>>357 だよね。
>>353 読んで、え？と思った。

>>358 よくべんきょしなとしか言いようがない

>>359 なかなかいいところに気が付いたね。

しかしに俺にレス多いよ
自分で調べて分かることはなるべく自力で頼みたい

>>360
Rustにおけるlifetimeという用語はborrowの有効期間のこと
それはもとを辿ればborrow元の変数が指してるオブジェクトのlifetimeのこと
だから二択なら前者

CLについてサイト見つけた 参考になるかどうか
ttps://qiita.com/seijikoide/items/13e2130fc141e1d8595d

>>362
Rustでは借用元の変数の寿命と物理的メモリの寿命は一致しません
>>347の「物理メモリの内容の有効期間と変数(Symbol)がそれにbinｄしている有効期間が異なる言語」に該当します

>>363
変数xがクロージャにキャプチャされただけだよね
Lispに限らずキャプチャできるならどの言語でも同じ

Rustはクロージャにキャプチャした場合
かつ 元の寿命を超える場合
コンパイラがoutliveだから「move」と明記しなさいと明確化してくれる
下記の例だと「変数」は関数内一時変数からクロージャ随伴変数へ物理移動して延命している

fn foo() -> impl FnMut(&str, i32) -> i32 {
let mut 変数 = 123;
move |cmd, arg| {
match cmd {
"get" => 変数,
"set" => { 変数 = arg; arg },
_ => 0,
}
}
}

fn main() {
let mut x = foo();
println!("get {}", x("get", 0));
println!("set {}", x("set", 456));
println!("get {}", x("get", 0));
}

// 実行結果
// get 123
// set 456
// get 456

>>364
>Rustでは借用元の変数の寿命と物理的メモリの寿命は一致しません
その2つが一致するとは誰も言ってない

>物理メモリの内容の有効期間と変数(Symbol)がそれにbinｄしている有効期間が異なる言語
Rustがこれに該当しないとも言ってない

分かってるよね？

>>362
違いますよ
Rustは変数にライフタイムがあります
借用した参照にも二次的に同じライフタイムが付きます

https://doc.rust-lang.org/rust-by-example/scope/lifetime.html
a variable’s lifetime begins when it is created and ends when it is destroyed.
変数のライフタイムは作成時に始まり破棄時に終わります。

>>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}");
}