>>953-957
# スレの流れが錯綜しそうなので、強引にマトメてみる。

最も外側のTLV構造のデコード処理は(>>950-952に書いた)イベント駆動方式(PUSH型)で実現できる。
この部分は比較的に単純なステートマシンだから、わざわざyaccみたいなコードジェネレータを
持ち出す必要性は(個人的には)感じられない(>>957)。

検討課題になるのは、メッセージを組立てた後に、階層的なTLV構造の内側をデコードする
(>>938の)プロセス駆動(PULL型)処理だと思う。
TLV方式は拡張性があるから、必要に応じていくらでも要素を追加できる。
しかも、それに対応するコードは(>>938で書いたような)単純なイテレータで実現できるから、
コピペでコーディングできる。>>955の言葉を借りれば、プロジェクト間で使いまわしができる。
とはいっても単調なコーディング作業の連続だから、(>>948の言う)関数ポインタを活用したり、
あるいはテーブル駆動なコーディング様式を検討したくなるのは、自然な発想だと思う。
そして、それを追求するとTLVデコード処理に特化した俺様言語(DSL)が欲しくなるのも自然な成り行き。

で、DSL(Domain Specific Language)を定義して、その言語処理系(コードジェネレータ)を
開発してみては？という提案が、>>933になる。それに対して、新たにメタ言語を定義して
処理系を開発するのは面倒だから、既に存在しているyaccで(メタ言語を)代用できるんじゃね？
ってのが、>>953の提案。ここでのTLVデコード処理はプロセス駆動方式(PULL型)だから
yaccとの相性は良いかもしれない(>>954)。容易に実現可能である、とまで断定はできないけどね。

(続く)