CF2.5 Extension として公開されていた REGEX 2022 の Beta 3.00 を公開します。
The Beta Extension version.3 will excuse for as the complete freeware.
Excuse me, except you if Mr. putin.
Beta 2 との互換性は？
試してないので動作互換性は保証しません。サンプルファイルが Beta 2 と Beta 3 で基本的な部分は更新が無くそのまま引き継がれているので、たぶん動きます。
インストールは Beta 3 で上書きコピーするだけです。
Download >> 配布終了
Beta 3 について
Beta 1|2 はドラフト版という位置づけで機能実装を急いだ結果、いろいろ便利になったが内部処理的には「いかんでしょ」「いかんのか？」が多数含まれており、それらを Beta 3 でまとめて修正しました。内部処理的には全くの別物になっていますが、処理速度について向上する余地はあまり無く Beta 3 ではメモリ管理部分を中心に Beta 2 との比較でよりセキュアなプログラムになっています。
パフォーマンス的には CF25 エクステンション開発独自の問題点として文字列を必ず TCHAR で確保しなければという厳しいレガシー仕様があります。C++11 以降の Modern C++ では文字列に String 使えとだいたい言われる、ですが String を保持してもエクステ内部ではそれを TCHAR に変換し、最後に TCHAR を long に変換しプログラム本体へ送信するということをやっています。
String から TCHAR へ変換する部分が不可避であり最大のボトルネック、これが今後解決できればと思っています。
追加機能
Beta 3 では文字列検索機能として Regex Search に「Exact Match (Full Match)／完全一致」が追加されました。
「完全一致」に関連した機能で「Smart Delimiter (スマートデリミタ)」も実装されています。
完全一致検索とは？
二つの文字列を比較する「文字列マッチ」では、文字列全体が完全に同一である場合「完全一致」と判定されます。
例えば「ABCD」という文字列の文字単位での完全一致は「ABCD」、しかしどちらかが「ABC」だった場合二つの文字列は文字単位での完全一致判定を得られない（”D” が不足している）。この条件だと Regex の Partial Match を使うと部分的一致判定が出せます。
Beta 2 で先に実装された Regex の Partial Match (部分一致) は文字列の一部が一致すれば True を返すという文字列比較で、判定幅が広いです。
Beta 3 で実装された正規表現（Regex）を使った「完全一致 (Exact Match)」は正規表現でグループ化（キャプチャ）された文字列と比較対象の文字列で全体が一致したら True を返す、これを使ってフォーマットに従ってデータが記述されているかを判定でき、同時にデータの抽出も出来ます。
文字列マッチと正規表現の完全一致 (Exact Match) は別物
検索ロジックが全く異なるため通常の文字列比較(文字列マッチ)と正規表現の完全一致を混同して使うのは、完全な無駄です。文字列マッチよりも正規表現の完全一致は処理速度的にも重い。正規表現でやる必要が無い処理は正規表現でやらない方が高速に処理されます。
文字単位の比較ではなく正規表現の Capturing Groups を駆使した文字列のグループ化機能を使って全体が一致するか判定を求めるという機能なので、サブマッチ要素を２つ以上含む正規表現を使って完全一致判定を得て、そのサブマッチ要素を抽出するという目的で作られています。
当エクステンションに実装された正規表現の Exact Match は通常の文字列マッチに利用されることを想定していません。
正規表現無しの文字列マッチとして利用した場合の異常動作やクラッシュについてはとりあえず「仕様」とします。まだ対策を施していません。
正規表現の完全一致についてはブログに専用の記事を用意しましたので、詳細についてそちらもご参照ください。
http://prester.org/cf2.5/?p=13352
その他 1：文字列扱う以外のエクステも作りたい衝動
Beta 3 の非公式機能として他オブジェクトの固定値を取得しエクステから位置を操作する機能を実装してあります。文字列扱うのに疲れた時の癒しになったので、この機能は今後発展形を模索していきます。
その他 2：曖昧だった文字列長の仕様などを確定
Beta 2 までは FileSystem で扱う文字列長の知識が曖昧だったから無駄多めバッファ指定のメモリ確保をしてました。Beta 3 以降は FileSystem で扱うパス名など文字列長について Windows OS で公式にサポートされている NTFS との互換性を維持するための上限 260 文字となっています。
Mac OS や UNIX 系では文字列長に制限無いようですが、ファイル|ディレクトリ数が数千に達する場合に必要なメモリバッファを計算すると Windows OS の対応が正しい気がするので、もともと Windows PC 用のエクステですからディレクトリ|ファイル名の最大文字列長は 260 文字で固定することにしました。ただしこれでも数万のレコードを扱う場合、パフォーマンスが著しく落ちる可能性はあります。
Windows OS は 1 フォルダ内に格納できるファイル数上限を「4,294,967,295」と定めており、筆者はこの条件でエクステンションが動作するか挑戦する気は、一切無いのです。
Beta3 では FileSystem で取得できるネームリストのメモリバッファは 104’000 Bytes に一時的に固定されています。これは文字列長 260 文字のファイル｜ディレクトリ数が 200 個程度なら取得できる容量で、これを超えた場合の処理をまだ書いてません。この制限は Beta 4 で解決される予定。
FileSystem でファイル|ディレクトリのリスト取得のリスト順について
参考(cpprefjp – C++日本語リファレンス)：std::filesystem::
cpprefjp – directory_iterator
リファレンスでは「ファイル走査順序は未規定、ファイル名の辞書順に走査される保証はない」と記述があります。
実際にファイル数 100 程度で試したところ完全なファイル名順のリストは得られませんでした。少ないファイル数の場合はだいたい名前順で返ってきますがリファレンスによると「保証はない」のです。
Beta 2|3 ではまだソートを実装していないのでファイル名取得で得られた結果は後からソートが必要になるかもしれません。CF25 のリスト側で受け取った値をソート可能ですが、これだと名前順でしかソートできません。
Beta 4 以降でファイル（ディレクトリ）名|作成日時|ファイルサイズを使った「ソート指定機能」を付ける予定です。エクステンション内部でソートを行い結果を返し CF25 側では値を受け取り表示するだけという状態にしたい。
ただし実装の優先順位は現在あまり高くありません。正規表現のエクステンションとして完成させることが優先されているためオマケ機能である FileSystem 関連機能は後回しになります。
FileSystem に関連した機能として「Path History」
Beta 2 にも実装はありましたが Beta 3 では少し実用性が上がっています。
「Path History」はフォルダアクセス履歴をエクステンション内部に保持して履歴をたどり「戻る／進む」動作を簡単に作ることができます。現在は「戻る」だけができます。
保持できる履歴は上限があり、上限を超えた際の動作確認をまだ行っていないため現時点での利用を推奨しません。Beta 4 で完成させます。
Beta 4 で実装予定の機能
現在は「大文字と小文字を区別する」モードが初期設定で有効になっていて、これが変更できません。Case-Sensitivity の有効／無効切り替えは Beta 4 で実装されます。Beta 3 ではすでにプロパティにチェックボックスだけ作ってありますが、機能していません、中身はこれから作ります。
おまけ機能に日付と時刻を取得する機能を Beta 4 で実装します。CF25 本体は持ってない機能ですが公式エクステンションに「Date & Time」という拡張はあります。しかし希望するのはもっとシンプルに ISO 8601-2:2019 フォーマットで年月日時分秒を一括して取得する機能なので、これを実装します。
ISO 8601-2:2019 フォーマットは正規表現の完全一致を使えばサブマッチとして各要素を取得し、スマートデリミタ機能と合わせれば日本語を使った日時表記へ簡単に変換できます。
Beta 4 は１０月頃公開を予定。バグや要望・質問がありましたらブログコメント欄をご利用ください。作者が２週間に一回くらい見回りに来ます。