ここは微小なスレですね

湍

つい最近のことですがC#にyieldなるステートメントが追加されていることを知りました。
どうやらこいつを使うとマイクロスレッド(ファイバやコルーチンともいうらしい)のようなことが出来るようです。


で、こいつがあれば敵の挙動やステージの敵配置を外部スクリプト化する意味なくね？と思ったわけですよ。
確かにスクリプトならプログラムを起動したまま書き換え可能であるという利点もあるのですが、一番大きな意義は(自分の場合は)途中で実行を停止して呼び出し元に戻った後で改めてそこから実行を再開させるコードが書けるというところにありました。例は上に挙げた「[サンプル] イテレータとマイクロスレッド - C# によるプログラミング入門 | ++C++; // 未確認飛行 C」にあります。
一般にはビルドの時間が必要ないとかプログラマとスクリプタを分離できるといった話があると思いますが、VC#のビルドは一瞬ですしプログラマもスクリプタもやるとすれば自分一人ですし。
なのでC#で直接書けちゃうならそっちのほうがいいに決まっているのです。


しかし一つ心配なのはC#という言語に依存することになるかもしれないこと。
Win32APIでもファイバを扱うことは出来るそうなのですが、COMコンポーネントをさわるなら慎重にって話があります。

正直内容は半分理解できたかどうかも怪しいところとはいえ、危ないよと言われると尻込み。
やねうらおさんがアセンブラを併用したマイクロスレッドを実装されているものの、まだちゃんと調べていないので詳細はよく分からず。


　


Managed DirectXは開発が停止しているのでどうしようもなくなったらC++へ移行する可能性も捨て切れない中C#への依存を深めるか現状維持か。


　


書きながらも考えて一応結論。
もうLua用のインターフェイスは出来上がっていますし当面はLuaを使い続けることにします。
でもLuaStateを1つにまとめる作業くらいはやっておこうか。動作速度とかメモリ消費とかの関係で。


  • 8/6 追記

NyaRuRuさんのところをコメントまで読んでみたら、APIのFiberが面倒を起こすのはマルチスレッド環境であるとのことです。
内容をちゃんと理解できないまま信じるのもどうかとは思うのですが、湍がシングルスレッドであることを考えるともしかしてFiber使っとけばおｋなのでしょうか。