時代が早くしろと言うのです

開発にスピード感がない。
最適化のためにリリースが遅れるのは悪みたいな風潮が辛い。最適化のスピードがハードウェアの進歩よりも遅いなら無駄と言われても仕方ないような気もする。でも、ハードウェアの性能が10倍になるのに5年かかって、ソフトウェアの効率を10倍にするのに5年かかるとしたら、どっちもちゃんと仕事すれば5年後には開発開始当時の100倍の体験が出来るよね。18ヶ月で等倍の効率のソフトウェアをリリースしてもその時点では18ヶ月前の2倍(cf.ムーアの法則)の体験しかできない。

まぁ、机上の空論と一蹴されるような話ですね。
企画クラッシャーにならないように頑張ろう。



以下、まったり開発の試行錯誤。


const修飾子つければダウンキャストしていいんですね、知らなかった。
推奨される事はないだろうけど、こういう書き方も出来るんだなーと。
つい多用したくなりそうだ。

こんなのが必要な場合、関数fの引数の型のBaseクラスの設計が悪いとは言えそう。
もう一段階抽象度を上げれば解決しそうだけど、まぁ、優先度は低いので後でやろう。



もう一つ設計の問題（解決済み）
何かのクラスに何かの値をセットしたいとき。

クラスTが充分に小さかったらこれでいい（かもしれない）のだけど、コピーコストが無視できないときがある。
どっかでT作って捨てる処理が１回余分に発生するので。
その時右辺値参照が便利そうなのだけど、そのためにはSet関数の引数のconst外さないといけない、と思う。

めんどくせー。

ゲームのプログラムで値をセットするためのオブジェクト（ただのラッパー）なんてどうせ一時的なものなので、constなんていらなかったということですね。




あと、ハマったことのメモ。
MSVC++ 2010でのコンパイルエラー

error C2248: 'std::unique_ptr<_ty>::operator =' : private メンバー (クラス 'std::unique_ptr<_ty>' で宣言されている) にアクセスできません。

unique_ptrをprivateなメンバー変数に持つクラスをコピーしようとすると発生した。同様に代入もダメ。自動生成されるコピーコンストラクタじゃ対処できないので、自分で書かないといけないってことらしい。
上手いこと自動でやってくれないのね、って思ったけど良く考えるとそれも困るのか。unique_ptrで管理されるインスタンスの所有権が曖昧にならないよう、コピーメンバ関数みたいなので実装したほうがいいかもしれない。

コピーメンバ関数？

メンバが増えると書き直さないとダメだけどとりあえずこれでいいのかもしれない。
・引数にとったクラスのprivateメンバってアクセスしていいのね…（自身からのアクセスってことになるからなのか？当然引数にconst付いてるとこんなこと(swap)は出来ない）
・copy実行すると引数にとったクラスのメンバー変数のポインタ(pimpl)はnullptrになる


【同日追記】
そもそも最初からunique_ptrで管理してればコピー関数なんていらないかもしれない。
新しくインスタンスが作られないので。

これならポインタを付け替えるだけなので、コピーコンストラクタが呼ばれない。
関数に渡すときはunique_ptrごと参照で渡す。
つまるところ、unique_ptrは感染するということになるのだろうか。