[過去ﾛｸﾞ] C++相談室 part155 (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
1: 2021/03/24(水)12:07 ID:R+oM8cup(1) AAS
※前スレ
C++相談室 part154
2chｽﾚ:tech
テンプレここまで
903: 2021/05/17(月)08:17 ID:/XJ4GxVV(1) AAS
>>901
まだ権威とか言ってる・・・
数学的に無理というのは権威関係なしに「無理」なんですよ
904(1): 2021/05/17(月)08:27 ID:xbubPeOw(1/5) AAS
なんかごちゃごちゃしているけど……
・複素数の体における比較は未定義
・複素数体に距離の位相を入れて比較を定義することは可能（複素平面など）
と言うことだろ。
まあ、直接比較するのは使い勝手が悪いので、距離の位相には適当な写像を使うのが普通だけど（絶対値とか）。
905(1): 2021/05/17(月)08:31 ID:rt013aFx(1/6) AAS
複素数は自然な全順序にはならない
特定の条件を満たす順序は存在しない
ってだけで
順序を定義することは可能だし実際定義して使うこともある
906(1): 2021/05/17(月)08:31 ID:pyZ7P5gV(1/6) AAS
証明にだって厳密さが欠けていることが後からわかった（適用条件が誤っていた）り超ごくまれにだが結論自体誤っていたりしたことが……
ケンペ鎖とか、
あとABC予想の証明ぐらい高度なやつになったら職業数学者であっても査読者の質で
是非を判断せざるおえないﾊｽﾞ
もちろん直接関連論文を書く人は自分が納得するところまできちんと追うだろうがPGがなんでそこまでせねばならんのやヽ(#`Д´)ﾉ
907: 2021/05/17(月)08:32 ID:pyZ7P5gV(2/6) AAS
>>905
|z|とかarg(z)とかな
908(1): 2021/05/17(月)08:34 ID:pyZ7P5gV(3/6) AAS
やっぱ自然演繹は良くない
あらゆる証明は最初から形式証明にかけるべきや
909(1): 2021/05/17(月)08:38 ID:3ODjt5IZ(1/5) AAS
>>904
それやっても大小関係を使ったアルゴリズムは実数では正しく動くけど
複素数ではことごとく破綻するけどな
数値計算でなければ独自の大小関係を定義したら動くかも知れないが
それはオナニーと同じだ
>>900
そういうことだよな
910(1): 2021/05/17(月)08:38 ID:xbubPeOw(2/5) AAS
>>908
そんなにプリンキピア・マテマティカを書きたいか。せめて読破してから言え。
911(1): 2021/05/17(月)08:40 ID:xbubPeOw(3/5) AAS
>>909
破綻とは矛盾のことかな？
複素平面が矛盾するとは世紀の発見だ。ぜひとも論文を。
912(1): 2021/05/17(月)08:41 ID:3ODjt5IZ(2/5) AAS
>>911
何言ってんの
実数では正しく動く大小関係を使ったアルゴリズムを
どうやって複素数で正しく動かすんだよ
頭大丈夫か？
913: 2021/05/17(月)08:45 ID:3ODjt5IZ(3/5) AAS
絶対値の大きさ云々の話ならピボット選択は正しく動くだろうな
まあこれは浮動小数点演算の特性からそうなるのであって数学的には関係ない
914(2): 2021/05/17(月)08:46 ID:xbubPeOw(4/5) AAS
>>912
距離に写像すればいい。
数値計算でも普通に複素数の絶対値取って比較しているだろ。
915(1): 2021/05/17(月)08:52 ID:3ODjt5IZ(4/5) AAS
>>914
おいおい・・・
上にも出てきてるけどQR分解を複素数で書いてみろよ
916(1): 2021/05/17(月)09:48 ID:p0CmvUql(2/3) AAS
>>915
実装したことないから詳しくないけど、検索したらこんなのあった。
外部ﾘﾝｸ[html]:ameblo.jp
なんか問題あるのかしらん？
917(1): 2021/05/17(月)10:03 ID:3ODjt5IZ(5/5) AAS
>>916
それはもちろん俺もやってみた
外部ﾘﾝｸ[html]:ameblo.jp
これがコードだよな
でも結果がおかしいんだよ
918: 2021/05/17(月)11:39 ID:p0CmvUql(3/3) AAS
>>917
「結果が間違っている」て言われたってなぁ。>>917の指導教官でも上司でも無いから助言する気無いし。
まあ、複素平面の距離は半順序だから（狭義の弱順序よりさらに弱い）、全順序を必須とするアルゴリズムには使えんわな。>>914は一部撤回するよ。
919: 2021/05/17(月)11:39 ID:ZeUb3kXE(1) AAS
2つの複素数 z1, z2 に対して z1 < z2 を |z1| < |z2| と定義してしまうと、
z1, z2 がたまたま(複素数の一部であるところの)実数である場合は、
x1 < x2 が |x1| < |x2| と定義されることになってしまうが、
そうすると、負数の時に通常の実数の比較と結果が違ってきてしまう。
920(1): 2021/05/17(月)12:08 ID:CucgVtNi(1) AAS
だから複素数体を順序体にできないことなんて代数の教科書にいくらでも証明載ってるんだから読めよ
いつまでやってんだ
921(1): 2021/05/17(月)12:09 ID:giSQx4b2(1) AAS
std::locale::global(std::locale("japanese"));
必要ですか？
無くても動いてるときに敢えて描くと可笑しくなりますか？
922: 2021/05/17(月)12:12 ID:cCPUzk2p(1/2) AAS
complexには<=>がないね
923: 2021/05/17(月)12:14 ID:+IMuyr7J(1) AAS
>>921
何のために？
挙動が変わることはあるけどそれがおかしいかどうかは目的次第
924: 2021/05/17(月)12:29 ID:0hooCSOD(1) AAS
>>920
QZがあまりの悔しさにID変えて荒らしてるんだよ
925: 2021/05/17(月)13:05 ID:DzXjbqQO(1) AAS
>>906
>判断せざるおえない
単刀直入に言ってバカっぽい
926: 2021/05/17(月)13:40 ID:AtV47BCw(1) AAS
ハンダンセ猿はすばしっこいからな
927: 2021/05/17(月)13:54 ID:+0j9FXFm(2/2) AAS
QA分解はそもそも数値誤差を減らすのがめちゃくちゃ難しいからあんま使われんのよ。
特別な事情がない限りは軽はずみに手を出すのはやめた方がいい。
928: 2021/05/17(月)16:56 ID:Hl6gcnGv(1) AAS
g++で Member 'x' was not initialized in this constructor
って警告が出るんだが、これをpragmaで抑止したい。
このwarningを抑止するためのキーワードを教えてもらえないだろうか
929: 2021/05/17(月)17:16 ID:cCPUzk2p(2/2) AAS
C++20のコード晒せるところ、どっかある？
ideoneやcodepadはダメだった
930(1): 2021/05/17(月)17:58 ID:v7SqzMPT(1) AAS
wandbox
931(1): 2021/05/17(月)18:24 ID:rt013aFx(2/6) AAS
>>863
複素数より実数の方が演算が広いから複素数を継承して実数を作る
継承してメンバ関数を増やす
作り方として適切かどうかはともかくとして、
例としては何も間違ってないと思うのだが
932: 2021/05/17(月)18:34 ID:rt013aFx(3/6) AAS
C++的に複素数に順序を取り入れるなら
辞書的順序が一番使われ方として多いかと
コンテナに入れるのに順序が必須な場合とか
std::pair < double, double >
これだって勝手に定義される
C/C++に数学的な汎用性が必須ではないのは
C/C++をやっていればわかると思う
1./-0. < 1./0. とか pow(0,0) = 1 とか数学的には明らかにおかしいでしょ
933: 2021/05/17(月)18:51 ID:pyZ7P5gV(4/6) AAS
まあ辞書順は可能だぬ
934(2): 2021/05/17(月)19:28 ID:xbubPeOw(5/5) AAS
>>931
c++のpublic継承は継承先クラスを継承元クラスと同じものとして扱うので、特性の包含性が重要。
なので、失われる特性があるなら継承はしないほうが良い。
上でも挙がっているけど、複素数は実数の全順序性という特性が失われるので継承はしないほうが良い。やるなら無限体を継承元クラスにすべきだわな。
935: 2021/05/17(月)19:49 ID:pZGof8k7(2/2) AAS
>>910
ブルバギじゃなくて？
936: 2021/05/17(月)20:09 ID:FZJkNpOI(1) AAS
正多面体と素数
動画ﾘﾝｸ[YouTube]
937: 2021/05/17(月)20:11 ID:PX9GndkV(1) AAS
何のスレやねん
938(3): 2021/05/17(月)20:51 ID:pyZ7P5gV(5/6) AAS
>>934
継承したからといって継承元クラスで定義される演算を継承したクラスにも引き継がねばならない理由は無い
演算子のオーバーロードと型変換関連のコンストラクタまたはキャスト演算子を定義したら
同じ演算子に対してパラメータの型毎に許す演算と許さない演算を任意に設定できる
特にComplexクラスからRealクラスを派生させた場合は
（この場合は|z|やarg(z)といった複素数の演算子がReal以外の実数を返すComplexのメソッドとすることになりそうだがそれはおくとして
ある意味話は簡単で、Complex同士のoperator<()の一族を定義せずにおもむろにReal同士でだけ定義するだけにしたらええんじゃ
つか個人的にｶﾅーﾘ疑問なのですだが、AがBの真部分集合であることと、
Aを表すのクラスとBを表すクラスの継承関係は一体追求すべき何の関係があるん？？
939(3): 2021/05/17(月)21:58 ID:SfcIGFpx(1) AAS
継承元として振る舞えるのはポリモーフィズムの必須要件じゃない？
親クラスとして振る舞えなくなる子クラスとか存在価値ないでしょ
940(1): 2021/05/17(月)22:27 ID:rt013aFx(4/6) AAS
>>934
は？
複素数を継承して実数を作る
という話だけど
941(1): 2021/05/17(月)22:36 ID:pyZ7P5gV(6/6) AAS
>>939
実数を複素数としてふるまわせたいならRealをComplexに型変換したら済むので継承やポリモーフィズムは必須ではない
>>938の問いに戻るがなんで集合としての包含関係をそう執拗に継承関係に反映させようとするんじゃ……
だいたい実数から複素数を作る演算（|z|とarg(z)で複素数zを作る）もあるし
複素数から実数を作る演算（|z|やarg(z)）があるから変換は双方向的なので、
この場合派生クラスから基底クラスへの一方的変換だけでは片手落ちなのは明白
無理矢理やったら>>938に書いたみたく|z|やarg(z)といった複素数の演算子がReal以外の実数を返すみたいなgdgdな話に……
942(1): 2021/05/17(月)22:39 ID:rt013aFx(5/6) AAS
>>941
おまえ文系だろ
>>939に「ポリモーフィズムは必須」なんて書いてない
943: 2021/05/17(月)23:00 ID:hwY+PVbw(1/2) AAS
>>938
＞継承したからといって継承元クラスで定義される演算を継承したクラスにも引き継がねばならない理由は無い
さすがに演算が別物レベルで違うのはc++のpublic継承を使うべきじゃない。
public継承は継承元クラスのポインタ変数・参照として使えるという意思表示でもある。使えると言っているのに使えないのはクラスのユーザーを混乱させるし、コンパイラとかからの支援も期待できなくなる。
継承元か継承先かを意識してプログラムしなきゃいけないのは典型的な「継承の危険な使い方」だよ。
944(1): 2021/05/17(月)23:17 ID:hwY+PVbw(2/2) AAS
>>940
えっ、そうなの？
それなら継承の問題は無いと思うけど、継承を使うメリットある？ c++だと性能的に不利な気が。
浮動小数から整数を継承するのと似たような臭いがする。
945: 2021/05/17(月)23:39 ID:GYmzER1r(1) AAS
浮動小数と整数は継承関係にない代わりに個別に暗黙変換のルールが作り込まれているわけだから
同列には語れんような。
946(2): 2021/05/17(月)23:53 ID:rt013aFx(6/6) AAS
>>944
元は>>846
>>863が逆だと勘違いしたんだろうねえ
そこから中身のないプライドを保つ為だけの書き込み多数
947: 2021/05/18(火)00:42 ID:pJ71QEbf(1) AAS
>>946
お前頭悪いって良く言われるっしょ
948: 2021/05/18(火)01:40 ID:FUhBCUlD(1) AAS
ここまでのアホみたいな流れは全部>>793のクソコードのせいにして終わり終わり
949: 2021/05/18(火)02:05 ID:0A1+AcfP(1/2) AAS
>>942
>939 は >938 に反論する形で
継承元（Complex）として振る舞えるのは（Realが満足すべき）ポリモーフィズムの必須要件、
と言っているのだから
>ポリモーフィズムは必須」なんて書いてない
なんて大嘘
950: 2021/05/18(火)02:07 ID:0A1+AcfP(2/2) AAS
全く>>946はこの問題でいっぱいレスしている割にｶﾞﾁで頭悪いのではないか
951: 2021/05/18(火)06:07 ID:M8tLf7N/(1/7) AAS
外部ﾘﾝｸ:wandbox.org
これの実行結果なんだけど
何で == になるのか誰かわかる？
952: 2021/05/18(火)07:35 ID:iJzvlnxx(1/5) AAS
<=>使ったことないけど==は自分で定義しとかないといかんらしいぞ
あとこれ仮想関数にする必要あるのか疑問(無駄にサイズ増えるし。あと継承もいらん気がする
953: 2021/05/18(火)07:37 ID:M8tLf7N/(2/7) AAS
<=>から==を導出させるには=default;しなきゃいけないんだけど
=default;した関数の内容を独自なものにするには
virtualで上書きするくらいしか思いつかない
954: 2021/05/18(火)07:40 ID:iJzvlnxx(2/5) AAS
わからんけど、そのpointの大きさ(内積してsqrt)で比較するようなコードをコンパイラが勝手に作ってくれるのけ
955: 2021/05/18(火)07:43 ID:RvkfiLpS(1) AAS
メンバの辞書式順序で比較するコードを勝手に作ってくれる
956: 2021/05/18(火)07:44 ID:M8tLf7N/(3/7) AAS
そんなわけないと思うからこそ=default;した関数の内容を独自の内容に変更したい
957: 2021/05/18(火)07:45 ID:M8tLf7N/(4/7) AAS
メンバの辞書式順序と違う定義にはできんの？
958: 2021/05/18(火)07:47 ID:iJzvlnxx(3/5) AAS
だから==も書かないといけないんじゃね
多分だけど、そのpointの==は中身point_baseの比較しかしてないんでしょ
959: 2021/05/18(火)07:48 ID:M8tLf7N/(5/7) AAS
独自の定義にするには == 必須で
<=> から導出させようという考えがそもそも間違い？
960(1): 2021/05/18(火)07:51 ID:iJzvlnxx(4/5) AAS
pointの方で=defaultはうまくいくかもしれんね(今試せないのですまん
961: 2021/05/18(火)07:59 ID:M8tLf7N/(6/7) AAS
>>960
そのようで
外部ﾘﾝｸ:wandbox.org
しかし、これをやりたくないから<=>を=default;しようと試してたんだ
962: 2021/05/18(火)08:24 ID:M8tLf7N/(7/7) AAS
>>930
言うの遅くなったけど
?X
963: 2021/05/18(火)11:01 ID:K5WN/Dsi(1/2) AAS
こんなしょうもない例でもこれだけもめるんだから
抽象的な定義をするときは思った以上に概念を共有できないということだな。
964: 2021/05/18(火)11:06 ID:Tj0Ma2DE(1/2) AAS
ンなこと言うんなら最初っからお前が揉めないような定義をバンと出せばいいんじゃないの？
出来ないなら黙ってて
965(1): 2021/05/18(火)11:57 ID:K5WN/Dsi(2/2) AAS
だから揉めないような定義なんかないって主張なんだが。
966: 2021/05/18(火)12:05 ID:3kx5cfZQ(1) AAS
>>965
なら黙ってろカス
無能ほど自己主張は強い
967(2): 2021/05/18(火)12:43 ID:eJEusld6(1/3) AAS
UQを含めてC++流のクラスや継承に価値を見出せない人が結構いるようだが
当時、アメリカではCだけでは複数のプログラマによる共同開発に問題が
来たしていて大問題になっていたのがC++の登場で解決したとされているぞ。
どうしてかというと、protected属性などでメンバ変数を「隠蔽」できることで
他の人の作ったパーツを破壊することなく使えることになったことが大きいと
聞いた。もちろん継承もその一つ。
968(1): 2021/05/18(火)13:02 ID:eJEusld6(2/3) AAS
>>967
継承は、他の人が作ったプログラムに機能を「追加」するときに何が追加された
のかが明確になるので便利。
継承の機能が無ければどの部分が追加されたのか分からないし、
追加した際に元々動作していた基本部分までバグが入る可能性があるが、
継承した場合にはそれが無い。
UQみたいに「委譲」でなんとかするのは、言語機能のサポートが得られないので
記述量が増えてメンドクサイ。
969: 2021/05/18(火)13:33 ID:iJzvlnxx(5/5) AAS
UQってなんやと思ったけどQZのことか
てかまともにソフト書いたことない奴には言ってもわからんと思う
970(1): 2021/05/18(火)16:26 ID:EATlfCml(1/2) AAS
自衛隊の大規模接種センター(東京センター)は生年月日の入力欄初期値が1970年1月1日なんだが、Unixタイムを意識したのかな？
外部ﾘﾝｸ:www.vaccine.mrso.jp
971(1): 2021/05/18(火)16:53 ID:LV/0HQIM(1/2) AAS
>>967
一番良かったのは namespace
972: 2021/05/18(火)16:55 ID:LV/0HQIM(2/2) AAS
>>970
適当な番号でも受付完了するらしいな
受付出来るけど接種に来ても打ってもらえないから
そういう適当なことなしないでくれってアナウンスしてるけど
テロリストにDoSに準じる攻撃方法教えてるようなもんだろ
973: 2021/05/18(火)16:58 ID:nXH1x7Lj(1) AAS
何関係ないこと語り出してんの
974: 2021/05/18(火)16:59 ID:EATlfCml(2/2) AAS
中国のハッカーはHoneypotなのではと警戒してるらしいよ
975: 2021/05/18(火)18:41 ID:eJEusld6(3/3) AAS
>>971
それは全く違う。
1990年くらいにCからC++に移行が進もうとしていたとき、C++にはまだ
namespaceキーワードで指定するnamespaceの概念は無かったから。
976(1): 2021/05/18(火)19:04 ID:HX5VOoCQ(1) AAS
>>968
それって差分プログラミングじゃないの
977(1): 2021/05/18(火)19:12 ID:lxDAggBF(1) AAS
>>976
外部ﾘﾝｸ[php]:www.ced.is.utsunomiya-u.ac.jp
「継承の機能を使うことにより、すでに定義済みのオブジェクトに
・機能を追加
・変数を追加
・機能の一部を変更
などをエレガントに記述することができるようになり、オブジェクト（コード）の再利用性が向上します。すでに実装済みの機能に、自分が実装したい機能として足りない部分だけを追加してプログラムを作成できるようになりますので、これを差分プログラミングと呼んだりします。」
978(2): ◆QZaw55cn4c 2021/05/18(火)21:00 ID:TyliVLtj(1) AAS
>>977
それは委譲でも十分で、差分プログラミングだけしたいのなら継承は不要だと私は考えています
>>859
＞クラスAをクラスBに所有させたとき、Bの公開したいいいメソッドを逐一クラスAにも書かねばならないのがﾒﾄﾞｲ
鋭い意見です、唯一共感できるレスポンスだと思いました
確かにおっしゃるとおりですが、しかし、このメンドクサイ手順を踏めば vtable が不要になる、という意味ではメリットの方が大きいと私は思います
あとは基底クラスへのポインタを一括して握っておいて、派生クラスへのポインタごとに仮想メソッドで処理を分け分けする、というのが出来なくなりますが、私はそういう場面で出会ったことがありません……
外部ﾘﾝｸ:ideone.com
979: 2021/05/18(火)22:28 ID:rG13Y8DO(1) AAS
差分プログラミングかー 昔はそんなこと言われてたね
ユーティリティクラスに持つべき共通関数をベースクラスに実装しておけばサブクラスでも簡単に呼べる！とか間違ったクラス設計が横行してた時代
980: 2021/05/18(火)22:41 ID:Tj0Ma2DE(2/2) AAS
その時はまだ失敗してなかったんだから「間違ったクラス設計」じゃないんじゃないの
間違ってるのが後からわかったんでしょ
なら間違いの原因は別にある
981: 2021/05/19(水)01:12 ID:fToUWXI/(1) AAS
>>978
>私はそういう場面で出会ったことがありません……
それはあんたが仕事をしてないからですよ
982(1): 2021/05/19(水)01:58 ID:yT7tFlzp(1) AAS
>>978
一行目、普通は、C++においては委譲より継承の方が楽に書けるのだから、
C++での差分プログラミングは継承を用いるのが基本で楽なので「継承で十分」と
考えるべきで、C++はそういう設計。
あなたは逆さまで、C++の初期のころからの基本設計に逆らおうとしている。
983: 2021/05/19(水)02:30 ID:kKkrLvTk(1) AAS
継承使わずに委譲って言ってる人はvirtualはどうしてんの？
984(1): 2021/05/19(水)02:32 ID:/jpsBven(1) AAS
つーka仕事で使ってないやつによくある感違いだけど
C++にしろ他の言語にしろ、道具であって目的は「トータルとして楽する」ためにすべてはあるので
別にアート作品や哲学やってんじゃねーんだから、「本質的に美しい」とか「こうあるのが正しい」
とかはどうでもいいからな
トータルとして楽にするためには時に面倒な実装や仕組みをつかうこともあるが、結局最終的に
楽できなきゃそんなものに意味はない
985: はちみつ餃子 ◆8X2XSCHEME 2021/05/19(水)02:35 ID:ONEwpJm5(1) AAS
>>982
それは間違った考え方。
継承は機能を追加するためのものではない。
機能を追加したいなら機能を追加すればよい。
986: 2021/05/19(水)02:45 ID:zjDnGFHC(1) AAS
継承したくないとか言ってる奴らってインターフェースの概念ないバカだけでしょ
987: 2021/05/19(水)02:56 ID:iywlut5a(1) AAS
virtual は必ず描く
private は使わず protected を使う
988: 2021/05/19(水)05:27 ID:mqAmVEur(1/3) AAS
必ずってのもどうかと思うけどな
上にあったpointクラスもそうだけど、メモリ上のサイズがメンバ変数のサイズと一致して欲しい&組み込み型のように配列をmemcpyできるべきクラスなら
無意味にvtblなんか付けるべきじゃない
>>984の言うように楽かどうかもそうだけど、何をユーザーに提供するか、どういう要件が必要なのかと突き詰めていったら最終的に取れる選択肢なんかほとんどない
QZもやはちみつもそうだが、お遊びの長くても数百行のコードしか書いたことないやつは多分それらの部品を何か作るためにまともに年単位で使い倒したことが無いんだろ
それら思いつきで書いた程度のコードは全くブラッシュアップされてないから全く使い物にならんのだが、使ってないからそれに気づかない
実際気付き始めたらあちこち直しまくって膨大な時間使って最後にはゼロから書き直して全く違った設計になると思うが、そうして初めてOOPや継承の利点もわかるんだけどね
989(1): 2021/05/19(水)05:56 ID:Gyc2jKZQ(1) AAS
可変個の参照の組 (vectorでいい) を関数 hoge
に渡したいときって、hoge が vector< reference_wrapper<T> > を取るようにして
hoge({ref(A), ref(B), ref(C)})
みたいに呼ぶか、可変引数テンプレートを使って hoge の中でパースするかっていうのが普通のやり方かな？
ちょっと冗長な感じがしてしまう
参照の組じゃなくてポインタの組にするとかも手かもしれんが
990(1): 2021/05/19(水)05:58 ID:LZZifCH2(1/4) AAS
いきなり継承いらんｷﾘｯとかすげえ極論を言い切るやつ
自分の発言に将来にわたってずっと責任を持つ気なさそう
その時のその場だけ俺カッケーできりゃいいってやつ
991: 2021/05/19(水)06:12 ID:mqAmVEur(2/3) AAS
>>989
どれがいいかはさておき可変長テンプレート引数はめんどいよ、やってみたらわかる
同じ型のものを可変個受け取るためのものじゃない(トリック的に回避はできるが)し、hoge内だけでパースは無理
992: 2021/05/19(水)06:57 ID:LZZifCH2(2/4) AAS
conceptでできそうだな
まだ試してないけど
993(1): 2021/05/19(水)07:09 ID:CHs6khMr(1) AAS
>>990
継承イランといってる奴なんていなくね？ QZは怪しいが...
継承が適切な箇所なら継承を使う、機能追加で差分のコードが少なくてすむからという理由だけでは必ずしも使わない(その場合に継承が適切な関係ならば使う、そうでないなら委譲なりなんなり他の設計にする)ということを言ってるだけでないの？
994: 2021/05/19(水)07:14 ID:LZZifCH2(3/4) AAS
>>993
>>801
995(1): 2021/05/19(水)08:07 ID:iIq+id16(1/2) AAS
継承いらないっていうのはこういうことだろ？
インターフェースは継承するが、クラスは継承しない
クラスを継承するようなことをしたい場合には、メンバー変数としてクラスのオブジェクト持って、それへ処理を移譲する
今時のオブジェクト指向プログラミングでは、わりと常識的な概念だと思うが
996: 2021/05/19(水)08:42 ID:mqAmVEur(3/3) AAS
＞インターフェースは継承する
いるやん
＞クラスを継承するようなことをしたい場合
その場合C++的には素直に継承した方が上手くいくと思うけどな(D&Eで禿が言ってたが、継承を全部委譲に置き換えるというのをやってみたらしいが「結果はひどいものだった」と
普通に継承してうまく行かんか破綻するなら、そもそも継承的なことを考えてはならない関係だと思うけどね
997: 2021/05/19(水)08:55 ID:IMMR+vsB(1) AAS
継承いる！に飛びついた連中も
その後の流れで
継承要らない！に飛びついた連中も
本質的には同じなんよ
周回遅れで誰かの後追いするマシーンなんよ
998: 2021/05/19(水)09:06 ID:RuJgA5Em(1) AAS
インターフェースは実装するって言うでしょ
C++的にはどっちも継承だけど
999: 2021/05/19(水)09:53 ID:LZZifCH2(4/4) AAS
>>995
メソッドがそこそこ少なきゃいいけど
世の中そんなに甘くない
1000: 2021/05/19(水)10:07 ID:iIq+id16(2/2) AAS
Kotlinちゃんは甘いです
インターフェースを継承し、コンストラクタで渡されたオブジェクトへそのインターフェースの実装を委譲するのを、1行で書ける
外部ﾘﾝｸ[html]:dogwood008.github.io
1001(1): 1001 ID:Thread(1/2) AAS
このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 55日 22時間 0分 41秒
1002(1): 1002 ID:Thread(2/2) AAS
5ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
省4
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.281s*