C++相談室 part156

**デフォルトの名無しさん** · 2021/05/19(水) 10:55:13.24

前スレ
C++相談室 part155
https://mevius.5ch.net/test/read.cgi/tech/1616555235/

**デフォルトの名無しさん** · 2021/05/19(水) 11:23:50.45

乙

**デフォルトの名無しさん** · 2021/05/19(水) 11:31:17.57

乙でございます

**デフォルトの名無しさん** · 2021/05/19(水) 11:33:27.40

乙python

**デフォルトの名無しさん** · 2021/05/19(水) 11:36:23.16

前スレの>>989
> 可変個の参照の組 (vectorでいい) を関数 hoge に渡したいときって、hoge が vector< reference_wrapper<T> > を取るようにして
> hoge({ref(A), ref(B), ref(C)})
> みたいに呼ぶか、可変引数テンプレートを使って hoge の中でパースするかっていうのが普通のやり方かな？

なんですが、もしかして reference_wrapper って構築時に左辺値を渡したらそれの参照を保持してくれる？
だとしたら
hoge({A, B, C})
と呼べるしかなりスッキリしますね
hoge 内でいちいち get() しないといけないのはダルいですが……

**デフォルトの名無しさん** · 2021/05/19(水) 12:17:48.45

継承や委譲との付き合い方がよく分からなくなった

あるクラスの機能を全部持っていてほしいが is-a 関係がないとかで継承関係にはないように思える場合ってどうすんの
例えば一辺の長さを表す変数やはみ出し判定メソッドを持つ「グリッド座標クラス」があったとして、今「オセロを解くクラス」を作りたいとき

オセロを解くこと is a グリッド座標では全くないし継承するのは頓珍漢に思える
一方で「オセロを解くクラス」がグリッド座標のインスタンスを委譲として持っていたとして、盤の大きさとかはみ出し判定メソッドにわざわざ「グリッド座標クラス」のインスタンスを通してアクセスするのも果たして正しいだろうか
例えば盤面 a と盤面 b を同時に持ったりもするだろうが、a.size() とか b.size() は同じものを表すのでこのようにアクセスするのは可読性を損なう
だから「オセロを解くクラス」は盤面の大きさとかはみ出し判定メソッドを自分のメンバとして持っていてほしいが、継承するべきようにも思えない

**デフォルトの名無しさん** · 2021/05/19(水) 12:37:51.61

複数の盤面持つんならメンバで持つ一択だと思うけど
「解くクラス」に外部からはみ出し判定アクセスするのもおかしな話だけど
描画の都合とかで外部からアクセスするのが欠かせないなら、インデックス受け取って盤面の参照返すメンバ関数でも用意すればいい

**デフォルトの名無しさん** · 2021/05/19(水) 12:44:45.80

あ、あるいは解くクラスが単に外部の盤面を参照する形でもいいかもね

**デフォルトの名無しさん** · 2021/05/19(水) 12:46:25.42

>>7
> 複数の盤面持つんならメンバで持つ一択だと思うけど
「オセロを解く」といった時点で盤の大きさ等決まるんだから、自分のメンバとして基本的な機能持っててほしいと思うんですが、偏った考え方ですかね

> 「解くクラス」に外部からはみ出し判定アクセスするのもおかしな話だけど
そう思います

**デフォルトの名無しさん** · 2021/05/19(水) 12:47:08.07

>>8
それはインスタンスとして盤面を持つという意味ではなくですか？

**デフォルトの名無しさん** · 2021/05/19(水) 12:51:42.12

フロント部分とオセロを解くソルバー部分で持ち方変えるってのが普通

**デフォルトの名無しさん** · 2021/05/19(水) 12:52:13.78

そう、内包しようとしない方が自然かもしれない
(読んだ範囲で勝手に考えてるだけだけど)
例えばその解くクラスってのがAI的に自動で解くクラスなら、じゃあその対戦相手に同じ(だがインスタンスは別)AIや
プレイヤーが参戦したらどうなるんだ？と考えると
盤面は独立してるほうが自然な気はする(個人の見解です

**デフォルトの名無しさん** · 2021/05/19(水) 12:54:28.27

>>6
オセロを解くアルゴリズムとオセロをプレイするモデル次第なのでなんとも。

まあ、オセロを解くんだったら多数のオセロ盤を持つだろうから、グリッドクラスを派生させてオセロ盤クラスを作るだろうな。
人間がオセロをプレイするのを素直にモデル化してもいいけど、ゲーム機のオセロゲームをプレイするようにモデル化したほうが、オセロを解く側のミスや負担が減る。

**デフォルトの名無しさん** · 2021/05/19(水) 13:23:50.34

>>11
フロント部分って今の場合だと「オセロクラス」ってことですか？
つまり「オセロクラス」と「オセロを解くクラス」が、どちらがどちらを含むではなく、やり取りしあって動くべきだということですか？

**デフォルトの名無しさん** · 2021/05/19(水) 13:26:27.55

>>13
派生って継承ってことですか？
つまり必ずしも is-a を満たさなくても機能を全部引き継ぐなら継承は是 (あるいはそうモデル化するのが良い) ということでしょうか

**デフォルトの名無しさん** · 2021/05/19(水) 14:13:31.63

かんたんだろ
色々判定してくれるオセロ妖精すなわち神を作ればいい

**デフォルトの名無しさん** · 2021/05/19(水) 14:28:08.35

＞is-a を満たさなくても機能を全部引き継ぐなら
どちらも自分で書いてるしグリッドクラスも継承を想定して作れるんだからそれでいいとおも
他人の書いた継承を想定してなさそうなのはやめといた方がいいけどね

てかis-a,has-aはあくまで迷ったときの指針に過ぎんし自分で継承が良さそうと感じたならそれで正解だよ

**デフォルトの名無しさん** · 2021/05/19(水) 14:43:02.57

>>15
この場合、is-aは「グリッドとして同一視できる」を意味するから、オセロ盤をグリッドとして扱うことができるのなら継承もあり。

ただc++の継承は、継承元を総称として扱うという強い意味（継承元と派生クラス全体の強い結びつき）もあるのに注意。
オセロ盤とかその他のゲーム盤とかのクラスを（グリッドとして）使うということでもなければ、継承しないほうが設計の自由度を保てる。