{進捗記録}{進捗}{希哲16年1月28日}{rgx_T}{s_T の補助函数}{幸いした}{書き換え作業}{置換作業}{必要な時期}{置換した}(69)

{希哲16年1月28日16歩 K#F85E/E74C-C804}

進捗時限記録中略

Cμ 文字列処理改良rgx_T の置換道手の引数順序変更

作業方針再検討終了

あとは rgx_T::rpl()引数順序変更rgx_T の置換道手の引数順序変更完了だが,これまでの道手呼び出し箇所Dexごく一部限られていたのに対し,.rpl()Cμ 初期からあちこち使っている置換道手なので,少し複雑な作業になる。

まず,いったん .rpl()適当な名前変えて無効化し,呼び出し箇所引数順序変更済みの .rpl_glb() あるいは客体表現置換するか,正規表現客体表現使うまでもない処理なら s_T の補助函数置換する現時点.rpl_glb().rpl()冗長版に過ぎないため,置換したままにしておいて問題ない交度整理をしていけば自然に戻るはずなので,あえて再置換はしないことにした。

置換作業に入る前に,作業必要s_T の補助函数整備必要だが,既存の「類型化正規表現rgx_x_T置換道手旧式引数順序にならっているため,まず最初に客体表現ojx_x_Tへの書き換え作業済ませることにした。rgx_T直接使った交度から類型化正規表現への書き換え作業想定より遅滞していたことが幸いして,現時点類型化正規表現多くない

いずれにせよ正規表現総点検客体表現への書き換え必要な時期であり,保守性効率性大きな向上見込める良い機会だ。

{進捗記録}{}{進捗}{希哲15年8月13日の開発}{見つけた}{求めていた}{知っていた}{交度量}{初回使用時構築}{xt C}(39)

{希哲15年8月13日13歩 K#F85E/E74C-2061}

類型化正規表現に関して,xt C だけではまだ不安が残るため,当面は安全性重視初回使用時構築利用することにして終了依存関係単純なうちはまだいいが,将来的複雑性予見出来ない。交度量にもさほどはなく,書き換え容易だろう。

この手法自体は知っていたが,いまいち説明納得出来ず,この場合に適用していいものか迷いがあった。『ストラウストラップのプログラミング入門』求めていた単純説明見つけたので採用することにした。

事実上定数であれば,函数であっても the_ 接頭子を使っていいことにした。

{進捗記録}{進捗}{デライト}{出振るい}{GDB}{希哲15年7月8日の開発}{認識が甘かった}{大域変数の初期化順序}{コメントアウト記法}{大域変数}(43)

{希哲15年7月8日12歩 K#F85E/E74C-584F}

進捗時限記録中略)

デラング整備不具合修正

ようやく原因判明修正途中だったコメントアウト記法出振るいして終了。

C++ における大域変数の初期化順序問題で,環境依存だった理由も分かった。初歩的なことだが,そもそも大域変数多用するような実装をしてこなかったのでこれまで直面せず,認識が甘かった

ふだんほぼ使わない GDB まで持ち出してあれこれ試行錯誤したが,その過程文字列正規表現周りに最適化余地も多く見つかり,結果的には良かった類型化正規表現のためにもどうしても解決しておきたかった。

本番環境とほぼ同じ環境で,空いている捌き手利用してデバッグ環境を整えたので,稼働中デライト影響は無かった。この経験は今後に活かせそうだ。

{類型化正規表現}

{}