ほんの少し吉野家に行っていなかったら、生姜焼定食が変わっているじゃないですか。メニュー写真の見た目では、無造作に炒めた肉とタマネギが乗っていて今ひとつ不味そうに見えたのですが、いざ食べてみると……とんでもない改悪でした。
何これ、豚丼の具材を生姜ダレで焼いただけじゃん。肉薄いし少ないし(タマネギで多く見せかけているだけ)。このご時世、値上げは仕方ないと思うよ。でもさ、これはちょっと無いんじゃないの？ 俺の豚生姜焼定食を返せ。いや、その前に俺の牛鉄鍋膳(当然とじ卵)を返せ。
所詮吉野家は牛丼の味しか維持する気が無いんだろうな。
これで吉野家で定食を食べるという選択肢は消えた。
aoinh;gw;oihasgr;oihnsardgrlojknh;
困った。pt_parseを使おうが、ast_parseを使おうが、マッチ文字長が0のノードが消えてしまう。
文法: nums = *int_p alps = *alpha_p nums_alps = nums >> alps 入力: "ABC" 出力(pt_parseの戻り値のtrees。idはルール名に置き換え): nums_alps alps alps A alps B alps C 入力: "0ABC" 出力: nums_alps nums nums 0 alps alps A alps B alps C 入力: "" 出力: (ID=0な空のノード一つ)
構文木のnumsに対応する部分を処理するとき、numsが消えているかどうか、もっと言えばnums_alps自体が消えているかどうかをいちいちチェックしないといけないわけですか? 構文解析後なのに? 意味が分かりません。
トレースしてみたら、boost_1_35_0/boost/spirit/tree/common.hppのconcat_match()内でlength()==0故にマッチ情報が捨てられてしまうみたい。えー、ちゃんと連結してくれよー。何か意図があるのかな。
独自のポリシークラスで処理すれば何とかなるんだろうけど、メンテナンスのことを考えるとそこまではしたくないので、この方向はあきらめることにする。
なので、次はクロージャでなんとかする方向で考えてみる。構文定義部分が汚くなっちゃうけどしかたない。