■

・前日。
散歩３０分。出発の時間が遅れたので１時間はいけなかった。
晩飯は肉豆腐＋SUNAOクッキー＋ミニハーゲンダッツ。
風呂は５０分早く入浴。
帰宅後・夜にステロイド点鼻薬。夕方に忘れてしまったので帰宅後になった。

・睡眠時間６～８時間くらい。
終盤が二度寝できなさそうだったので１時間弱ほど早く起床。断続的な覚醒はあるもののやはり二度寝はスムーズ。寝るのに多少は慣れてきた感があるが、抱き枕を仰向け時にもそのまま使ってたりしたので寝相的には安定してない感じ？

・仕事。
午前はデータまわりの設定を一通り完了させた。以前の飛んだ作業＋正式な作業をしたのでそこそこ時間はかかったが、これでデータまわりは問題ないはず。あとはコード側を午後に進めていこう。

・仕事。
午後になったのでコード作業。の前に、なんかよくわからんが勝手にパーツが非表示になったりしてるのでそこの調査を先にしたい。いちいち手動で表示オンにするのは面倒だ。データ側で意図的にオフにしてるのも一部はあるが、そうでないのにオフになってるし。

・仕事。
というわけでデバッグして怪しい部分を特定できて、そこを修正したら正常に表示されたのでたぶんここの問題。そしてここはライブラリ側の問題なので、一旦確認依頼を投げて休憩。疲れた。
ライブラリ側もおそらく今回作り上げ始めたやつだからな。バグがあるのは仕方ないが、それはそれとして調査は疲れる。今日はここまででも良いかもしれない。
ただ、もう少しだけ作業したいんだよなー。「コルーチンっぽく書きたいんだけどC++なので難しい」的なサムシング。とうとうラムダ式が解禁されたのでそれを使えばある程度は上手くいくんだけど、ラムダ式自体のスコープが切れてしまうと結局参照できないし、メンバで保持するんだったらそれはもうメンバ関数化してしまった方が良いんじゃね？的な感じ。
どうすっかなー。この手の処理はこれからそれなりに作る事になると思うので、今のうちに方法論を固めておきたいのだが。まぁ時間がかかるので今日中はムリかぁ。方針を考えるくらいは今日中にやるかな？

・ふむ。向こうのブランチではすでに修正されてるっぽいか。とはいえこちらの手元でも修正できてるっぽいので急いでマージして欲しいわけでもないか。というわけでマージ待ちにしとくかな。

・というわけで休憩した後にコルーチンの方針まわり。
まず、そもそも以下のような感じで書きたいわけだ。

void ChangeAnimCoroutine(){
  //Outアニメ開始
  startAnime("out");
  
  //アニメ終了待ち
  while(! IsAnimEnd()){
    yield return null;
  }
  
  //はけてる間にあれこれ
  DoSomething();
  
  //Inアニメ開始
  startAnime("in");
  
  //アニメ終了待ち
  while(! IsAnimEnd()){
    yield return null;
  }
  
  //入力の再受付とか
  DoSomething();
}

これだとフローが視覚的にわかりやすくてとても良い。が、C++なのでこういった書き方はできない。また、アニメーション終了待ちはコールバック方式になっている。
で、ラムダ式が使えるようになったので以下のようには書けるのは確認済み。

mylib::Function<bool()>& startOutAnimeFunc = m_FuncTempArr[0];
mylib::Function<bool()>& doSomethingFunc = m_FuncTempArr[1];
mylib::Function<bool()>& startInAnimeFunc = m_FuncTempArr[2];
mylib::Function<bool()>& doSomething2Func = m_FuncTempArr[3];
{
  // Outアニメ開始
  startOutAnimeFunc.RegisterFunction([this, &doSomethingFunc]() -> bool {
    // Outアニメ開始
    {
      startAnime("out", doSomethingFunc);
    }
  return true; });

  // はけてる間にあれこれ
  doSomethingFunc.RegisterFunction([this, &startInAnimeFunc]() -> bool {
    // ここでなんかやる
    {
    }

    //次の処理に繋げる
    {
      startInAnimeFunc();
    }
   return true; });

  // Inアニメ開始
  startInAnimeFunc.RegisterFunction([this, &doSomething2Func]() -> bool {
    // Inアニメ開始
    {
      GetLayoutAPI().StartAnime("in", doSomething2Func);
    }
  return true; });

  // 入力の再受付とか
  doSomething2Func.RegisterFunction([this]() -> bool {
    // 入力再開とかそんなん
    {
    }
  return true; });
}

//上の一連の処理を開始
startOutAnimeFunc();

コルーチンよりはやや煩雑な作りだが、しかしまぁまだわかりやすい方だろう。
ただ、問題は一番最初にある「～Func = XXX」みたいなところで、「メンバ変数の参照として保持しないとスコープで消えてしまう」「メンバ変数にする都合で全ての関数の型がボタン用のコールバックと同じになってしまう」という２つの問題がある。まず単純に設計として美しくないってのもあるし、それ以前にボタン以外のコールバックが必要になった場合に詰んでしまう。まぁ後者は関数をさらにSharedPointerみたいな感じにしてしまえばいけなくはないが、そこまでやるならやはり他の方法が良い。
無難にやるなら以下のような感じだろうか？

// Outアニメ開始
void Hoge::startOutAnimeFunc(){
  // Outアニメ開始
  {
    startAnime("out", Hoge::doSomethingFunc);
  }
}

// はけてる間にあれこれ
void Hoge::doSomethingFunc(){
  // ここでなんかやる
  {
  }

  //次の処理に繋げる
  {
    startInAnimeFunc();
  }
}

// Inアニメ開始
void Hoge::startInAnimeFunc(){
  // Inアニメ開始
  {
    GetLayoutAPI().StartAnime("in", Hoge::doSomething2Func);
  }
}

// 入力の再受付とか
void Hoge::doSomething2Func(){
  // 入力再開とかそんなん
  {
  }
}

まぁ無難ではある。ただ、関数化されてしまったので「これらが一連の処理であるという事が伝わりにくい」ってのと「いちいちヘッダにあれこれ書かないといけない」ってのが面倒くさい。
別方向で一般的なのは以下のようなStateでやる方式だろうか？

void Hoge::UpdateState(){
  switch(m_State){
  case STATE_OUT_ANIM:
    // Outアニメ開始
    {
      startAnime("out", [this]() -> bool {
        ++m_State;
	  return true; });
    }
    ++m_State;
    break;
  case STATE_OUT_ANIM_WAIT:
    //上のコールバックで++m_State
    break;
  case STATE_DO_SOMETHING:
    // ここでなんかやる
    {
    }

    //次の処理に繋げる
    {
      startInAnimeFunc();
    }
    ++m_State;
    //no break;
  case STATE_IN_ANIM:
    // Inアニメ開始
    {
      startAnime("in", [this]() -> bool {
        ++m_State;
	  return true; });
    }
    ++m_State;
    break;
  case STATE_IN_ANIM_WAIT:
    //上のコールバックで++m_State
    break;
  case STATE_DO_SOMETHING2:
    // 入力再開とかそんなん
    {
    }
    ++m_State;
    break;
  }
}

これなら一連の処理である事は伝わりやすい。定数を宣言しないにしてもm_Stateの宣言とかは必要だが、まぁそれは今のラムダ式でも最低限の宣言は必要だからなぁ。
うーん。他になんかあるかなぁ。今の感じだとState方式がマシだろうか。後でもうちょっとだけラムダ式まわりとかの機能を確認してから決めるか。改めて休憩。

・今日はまたセブンの牛カルビ＋ポテトサラダ。ていうか日曜のメシもこれだったんだよな。わりと美味くてもっと食いたい感じだった。昨日はそれを我慢してちゃんとチキンサラダとかにしたが。

・そういやスマホを音楽プレイヤー化しているが、想像以上に充電が減らないな。これなら普通に使えるわ。会社で充電が必要かと思ったがそれも必要ないレベル。まぁ会社ではPCで音楽を聴いてるってのもあるが。

・仕事。というかコルーチン的サムシング。
Stateで良さそうかなぁ。boostにコルーチンはあるっぽいが、それは使っちゃダメだろうしな。ラムダ式でコールバックが書けるだけでも良しとしようか。
ていうかSTATE定数はCPP側に入れても良いか？m_StateはInt型とかにしといてキャストすれば良いか。別に外部から見える必要もないし。
実装まで今日中にやってしまおうかな？さすがに時間的に厳しいか。間に合うっちゃ間に合うが、休憩が入れられないのでナシかな。明日にしよう。

・グラブル。
サプチケが来たか。今の感じだと今年もグラブルは続けそうだし、年に１回くらいは買っても良いかなぁとは思うが現時点で特に欲しいものがない。キャラはもう十分な感じだから召喚石の方かな。さすがに武器単品にお金を出すようなフェイズではない。
すでに召喚石を３凸する分の素材は揃ってるから、買ってすぐに３凸はできる。手持ちのシヴァとかは３凸しても自分への旨味がないのでなー。もっと余らない限りは使わないと思う。
買うなら別に年末とかでも良いんだけど、どうせ買うなら早い方が戦力にはなるしなー。一応、候補を考えてみるか。
召喚石で欲しいのはバハムートとかだが、バハムートはたしかサプチケ不可の石だからな。属性石が欲しいならケルベロスとかいけるかもしれないが、そもそもハデスをすでに持ってるので通常攻刃編成の方に移った方が良い気もするし。何よりバハムートが良いのは素のステータスの高さと召喚効果の強さだからな。そしてフレンドでまぁまぁ拾えるから別に要らんっちゃ要らん。
むしろ「フレンドでは別のを拾いたいのでサブに入れたい石」の方が重要かな。よくあるのはフレイとかか。フレイはサプチケいけるんだっけ？あと、フレイは別に３凸する必要はなさげだしなー。
アポロンとかは欲しいっちゃ欲しい。マウントを召喚石でまかなえるのは大きい。サプチケ使ってまで取るものかはよくわからんが。
ていうかレジェンドガチャに出る連中ばかりだから、その期間じゃなきゃムリか？そこらへんを改めて調べてからかな。
あー。前回の４周年記念の時のサプチケだけ特殊で色々選べたのか。であれば、今回も５周年を待ってからそこらへんを期待した方が良いのかもしれない。自分はもう年に１度しか買わないと思うし。

・今日の夕飯は牛カルビ＋ハムレタスサラダにしてみたが微妙だな。食えなくはないが、やはりポテトサラダとの相性が良すぎるのと、レタスがどうしても「草を食ってる」と感じてしまう。どうにも合わない。

・眠くなってきたな。眠気がなければ今夜のナワバリはやりたかったところだが、帰宅後にどうなるか。サーモンランはおそらくやると思うが、今日の武器編成はクソ寄りだしなぁ。