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

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

>>18
> ただc++の継承は、継承元を総称として扱うという強い意味（継承元と派生クラス全体の強い結びつき）もあるのに注意。

まさに、そういった意味論的なところで悩んでいます
まあ実際にオセロソルバを作ろうとしているわけではないのですが、同じような局面に何度も出くわして、継承も委譲もどうも適切でないように思えて最終的に「グリッドクラス」の中身をコピペして「オセロソルバクラス」を作るようなこともしばしばしてしまいます

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

そんなん言い出したらメタプログラミングで取り入れるメンバを選択するための継承なんか全部アウトだぞ
STL内部でやってるようなのも全部

ていうか
>まあ実際にオセロソルバを作ろうとしているわけではないのですが
>まあ実際にオセロソルバを作ろうとしているわけではないのですが
>まあ実際にオセロソルバを作ろうとしているわけではないのですが

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

継承でできることを別の手段でもできるって言ってるだけでは説得力がない
そんなん言い出したらC++でできることをCで擬似コード書けるしな

特にコード量が増える「別の手段」を推奨するには
格段に強い理由がないと誰も動かせない

**デフォルトの名無しさん** · 2021/05/19(水) 16:02:58.49

cpprefjp によると std::swap の実装って
void swap(T& a, T& b){
　auto tmp = move(a);
　a = move(b);
　b = move(tmp);
}
みたいな感じですよね？
よくされる「move された後のオブジェクトはどうなってる保証もないのでもう触るべきでない」みたいな説明に照らせば、上のコードは move した後のオブジェクトを再利用してるけど大丈夫なのかなって思ってしまいます
大丈夫なんでしょうか？
また、参照をmoveしたら当然参照元のオブジェクトが「どうなってる保証もない」と考えるべきなんでしょうか？

**デフォルトの名無しさん** · 2021/05/19(水) 16:39:28.28

もう一個質問させてください
引数に参照をとる関数に一時オブジェクトを渡したいこともあるんですが、この場合は const参照か右辺値をとる関数としてオーバーロードするしかないですよね？