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参照か右辺値をとる関数としてオーバーロードするしかないですよね？

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

>MoveConstructibleかつMoveAssignable
こうなってるからヨシ！

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

>>22
move後の変数は、読み取った場合の値はどうなってるか保証できないが、
値を書き込むことは正常に出来る事が保証されていると聞いた。
破棄することや、初期化することも問題ない。

◆QZaw55cn4c · 2021/05/19(水) 19:54:41.64

>>1
お疲れ様です

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

>>25
moveコンストラクタは呼ばれないの？
呼ばれるのなら保証するのは自分自身なのでは？

**デフォルトの名無しさん** · 2021/05/20(木) 02:43:42.49

>>27
moveコンストラクタは、変数定義を
TYPE x = y;
の形式で書いた場合に y が右辺値の場合に呼び出されるだけ。
move代入は、
x = y;
の形式で書いた場合に y が右辺値の場合に呼び出されるだけ。
後者の場合、xがmove後であるかどうかは関係ない。

変数xの中身をmove後のxへの書き込み、xの破棄、x.init()などとしての
再初期化が「保証される」というのは、保証されるようにSTLライブラリなどが
作られているという意味で、コンパイラが保証するというわけではない。

**デフォルトの名無しさん** · 2021/05/21(金) 05:29:55.67

T が値なら終了して、vector<T> なら再帰的に自分を呼ぶ関数を作りたいのですが、T が vector (あるいはコンテナ) かどうかで分岐する処理ってどうやって書くのが良いですか

あと近い話題で、+ 演算子をオーバーロードして vector + vector が結合された vector を返すようにするのってナシですかね？(string のように)
要素同士の和をとるのと紛らわしいですか？
cat(vector, vector) とかの方が良いかな

**デフォルトの名無しさん** · 2021/05/21(金) 06:16:08.57

固定長文字列クラスってないんですかね

template<int N> void hoge(string s){
　……
　assert(N == s.size());
　array<int, N> a;
　……
}
なる関数を呼び出すときにテンプレートパラメータを省略したいんです
s が固定長なら s から N を推論してくれますよね

**デフォルトの名無しさん** · 2021/05/21(金) 06:29:04.74

あるいは hoge の引数を costexpr に限る方法なんかがあれば、N は必ずコンパイル時に推論できるようになるの思うので、もしそういうものがあればそれでも大丈夫です

**デフォルトの名無しさん** · 2021/05/21(金) 11:15:57.88

もしかして、C++11に対応したSTLで、BSD/MIT 系ライセンスのものは存在してませんか？
・apache-stlは、2008年くらいで開発が終了しているようです。
・msvc用のstlはapacheライセンスですが、vcruntime.hが存在しないと
　エラーになるようです。

**デフォルトの名無しさん** · 2021/05/21(金) 12:27:55.17

apacheで良ければllvm

**デフォルトの名無しさん** · 2021/05/21(金) 15:55:15.71

>>30-31
これマジキボンヌなので何卒よろしくお願いします