堕天使の煉獄

うーんうーん。

そろそろしんどくなってきた。

相も変わらずＰＧやってるのですが。

ＧＵＩ機能的な文字列描画まわりテスト。


文字のアライメント付き表示（８方向+中央の９位置）とか
文字数が指定の範囲を超えたらスクロール表示とか。

そんでさらに、その文字列表示オブジェクトを
行の単位で扱えるリストビュー的なのとか。
行間のマージンの指定とかもあったり、背景の指定も出来たりみたいなの。

……。

クラスの実装はさておき、上の例を表示するのには
利用側からは、こんなかんじで記述して使うのですが……


なんかもう、多重継承にテンプレートに、さらにはクラステンプレートの継承とか
ｃ++の用法的にはまともな使い方してるつもりなんですけどね。

ただの文字を表示するだけに、なんだか大げさになりすぎたかなぁ。
とかちょっと我に返り気味……。

んまあ、ここから新しい機能とか追加したりするのは
仕組み的に楽なんでしょうけども、
一年後とかにコレ見て、利用法の方がすぐにぱっと出てくるかと言えば……。

そういうところは、テンプレートとか使うと
かえって訳がわからなくなっちゃうような。


あと、ｃ＋＋の駄目なところを回避するのが
結構な足かせになっちゃってるのを、最近頓に。

まず、上のソース見てもらうとわかるのですが
オブジェクトの生成にはだいたいmakeという生成ヘルパーを使用してます。

コレの中身は単純に自分をnewしてshared_ptrにいれて返してるだけの物です。

そうしている理由というのが、単にstd::make_shared<Hoge>(...)とか
毎回書くのが面倒……というわけではなく、（それも無いわけじゃないけどｗ）

C#なんかの最近の言語と違って、
ｃ++はインスタンスとポインタの両方の生成方法が任意に使えるのですが、
インスタンスで生成した物はポリモーフィズムが使えなくなっちゃうんですよね。

継承されたオブジェクトを親クラスに入れる事が出来る……というのは
ポインタ限定なんですよね。
（出来ない訳じゃないけど、する意味はない）

class HogeBase{...};
class Moge : public HogeBase{...};

で、

HogeBase* hoge1 = new Moge();

は、いいけど

HogeBase hoge2 = Moge();

だと、hoge2の中身はHogeBaseになってしまう
正確には、HogeBaseのコピーコンストラクタが呼ばれて
（上の例だとムーブコンストラクタかな？）実質
HogeBase hoge2 = HogeBase();

と同じ事になってしまう。
当然Mogeクラス独自のメソッドやメンバ変数は一切使えない。

スライシングと言う奴ですね。

なので、多態性を持たせようとおもうと、ポインタで生成させないといけない。
が、newしたらdeleteしないと、当然メモリリークしてしまう。

そうなると、必然的にshared_ptrに常に包む運用が現実的なわけです。
（スマポはポインタなので、多態性は普通につかえる）

で、そうなると、そもそもコンストラクタをprivateにしちゃって
makeメソッドからしか生成出来ない、つまりshared_ptrの形でしか
生成出来ないようにした方が都合がよいわけです。

が、しかし、ここでふぁっきんなのが、
そういう用途で使おうとおもうと

std::make_sharedが使えなくなっちゃうんですよね。

いや、回避方法はあるっちゃあるのですが。

通常の

std::shared_ptr<Hoge>(new Hoge);

にくらべて

std::make_shared<Hoge>();

で生成する事により、例外安全と、生成コストの軽減という恩恵がある。

が、std::make_sharedはprivateなコンストラクタが呼べないんですよね……。

回避するには、インナークラスを使った生成クラスを内部に持って、
そこで生成するとか、いくつか回避方法はあるものの。
実際のところ、make_sharedと通常の生成と、
そのコスト速度差はだいたい1.5倍～２倍程度らしいです。

毎フレーム大量に生成、消去する様な物の場合は
そもそもshared_ptrは向いてない、もしくはあろけーたを自作するなど
チューンが必要になったりするのだけども

今回のような一度生成したら、しばらく使い続ける様な物に関しては
最初の一回の生成のコストが多少増えたところで問題ない。

しかし、ｃ++なんて言語をやってる輩からすれば
実行速度が速い！　というのが矜持じゃないですか。

なので素直にmake_sharedが使えないというのは

「ふんぐぐぐぐぐっっっ……！！！（血涙）」

ってかんじなのですよ（ぉ

そんでさらに、スマポに包んで、もうあとは問題なしかと言えば問題はまだあって。

全部が全部shared_ptrにしてしまうと
浅いコピーと深いコピーを使い分ける必要も出てきたりで。

浅いコピーは、単純にメモリのアドレスのコピーだけ、みたいなの。

auto sp = std::make_shared<Hoge>(0,0);
//class Hoge() : m_pos(0,0){}とかになってるとおもいねぇ

auto sp2 = sp;

なんてやると、spとsp2のポインタが指すHogeクラスの実体は同じ物な訳です。

が、これだと都合が悪い時がある。

sp2->setPos(100,100);

なんてやった後、別の場所で

sp->pos();

とコピー元のほうをみると、
こっちもposの値は(100,100)になってしまうのです。
なぜなら、どちらも同じ実体を指している訳ですから。
解ってやってるときならともかく、
複製して、別の物を指していると思ったら、
同じ物という思い違いで思わぬバグになることもあるわけで。

そこで、深いコピー（ディープコピー）が必要になるわけで。

auto sp = std::make_shared<Hoge>(0,0);

auto sp2 = sp->clone();

とすると、
上のような事は起こらない。
cloneの中では新たにHogeクラスを新たにnewして中身をコピーするということが
行われている。
cloneした直後は、中身の値（オブジェクト自体がもってるメンバの値）は同じだけども
インスタンス（実体）は別物となる。

コピーするオブジェクトが、
値オブジェクトなのか（オブジェクトの中身が重要）
oop的なオブジェクトなのか（中身の違いよりも、どのオブジェクトなのかが重要？）
ディープコピーする意図というか意味を理解するには
対象のオブジェクトがどのような意図のオブジェクトなのかの理解が必要になる。
と、けっこう単純な話でもなかったりする。

そんでもって、clone関数は標準であるわけでなく、
自前で用意しないといけない。

上のソースコードの中でも
ラベルオブジェクトを一個だけ作って
ラベルリストに登録する際には、それぞれcloneしたものを登録してたりします。

この例の場合だと、
フォント、文字色、背景といった設定は複製して、
文字列だけ別のに変えたラベルを複製している感じです。

なんかいろいろとごてごて機能つけすぎると
生成部分が複数行になったりするぐらい糞長くなっちゃいがちなので

最初に一個ひな形的なのを作って
cloneで適時生成するようなほうのが楽ちんというのもあります。

がしかし、毎度コピーするたびに
コレは浅いコピーであるべきなのか、ディープコピーするべきなのか。

そしてディープコピーは普通に一回分の生成コスト+中身のコピーのコスト
が掛かるので必要なとき以外はするべきではない。

単純にみーんなスマポでハッピーというわけにも行かない、というかんじぽ。



んでまあ、何が言いたいのかといえば

単純なnewもつかえず、インスタンスも生成させない。
テンプレートでごてごて＜＞がついてる。

コピーにはcloneを使う。

なんか奇形なソースコードになってくなぁ……と。

どんどん、標準な機能が表から消えていき
独自の拡張関数ばかりになっていってしまい
ほんとこれ、１年後とか見たときに、すぐに使えるのだろうか？

もしくは、誰か他の人が見たとき
利用法がすぐに解るのだろうか？　と。

仕様書が無いと使えない、学習コストがかかるライブラリ。

なんか微妙だなぁ。


一昔前に一部で話題になった
main.cppだけで200kb超えの
うんこスパゲッティーソースコードのアクションゲーム。

変数名も、一文字とかざら。
ヘッダファイル？　何それ？
意味をなさない記号の変数名の嵐。
みんなグローバル。
リソース（マップ）とかもソースコードに直接記入。

とか、おおよそ、
やっちゃいけないと言われることがすべて詰まった
恐ろしいソースコードなのですが。

だが動く。

普通にオープニングから複数面クリア、エンディングまである。


オブジェクト指向だとか設計だとか……

そんなんよりもただ、

「動けばいいんだよ」

という強烈なアンチテーゼな作品ですよね。


どっかの二丁拳銃の女海賊さんも言ってたっけ。

「こんなもんはな、撃てて、当たりゃいいんだよ」

と。

「汎用性を求める決定をした時、そのプロジェクトの失敗も決定する」

と書くと、マーフィーの法則っぽい？ｗ


そんな感じで
ちまちまとオレオレライブラリ作りも不毛感がましてきて
末期的な感じだなーとか。

そろそろ、どんなでもいいからまともなゲームっぽいのつくらないとね。

以前つくったＡＤＶ用のシステムも
今見れば噴飯もののソースコードだけども
ちゃんと用件みたして動いてるんだものなぁ。

中身がどれほど高度で精練されていても、
未完成ならばそれに価値はないよな。

んでもまあ、その課程でえた経験と知識……その分だけはまあ
無駄ではないのかもだけども。

そこで失った時間的損失に釣り合うのかと言えば。


そんな感じでぐんにょり中な最近。