最終更新: 2014-01-02T18:04+0900
なんてことをこの日記の冒頭に掲げたもんだから自分でやってみた(どういうこと？)。
既存アプリに影響があるので良くないけど、bregonigへの暫定的な変更はこう。
} else {
/* ERROR */
onig_err_to_bregexp_msg(err_code, NULL, msg);
- return -1;
+ return err_code == ONIG_MISMATCH_INPUTSHORTAGE ? 0 : -1;
}
入力が足りなくてマッチしなかったときは、エラーメッセージをセットするけど戻り値は負数(エラー)ではなく 0(マッチなし)。
鬼車(5.9.2)に「K.Takata's software : bregonig.dll」で手に入る onig-5.9.2-mod.diffを適用したものをさらに変更。マッチに失敗したときのエラーの種類で hitendしたかどうかを伝える。ちゃんと動くのか非常にあやしい代物。TODOもいっぱいある。
やっぱり鬼車は手に負えないかも。
なんのことはない、影響を受ける既存アプリにはサクラエディタが含まれている。正規表現のコンパイルエラーと入力不足によるマッチなしを区別するためにちょっと変更した。
一行検索(従来動作)してみて、マッチが行末まで続いていたり次の行の内容次第でマッチが成功に変わりそうなときはとりあえず二行ぶん検索してみる。それでも状況が同じなら 50MiBのバッファを埋めてから三度目の検索を行う。50MiBって大きすぎるだろうか。大きさの問題だろうか。かかか。
実装は CSearchAgent::SearchWord()に。これって単語検索専用のメソッドではなかったのですよ。CGrepAgentもこれを利用したらよかった。
バッファの実体は std::wstringで。文字列を比較するにも wmemcmpなりを使おうとして結局 std::wstring("hoge") == L"hoge" を使ったへたれなので、str系のライブラリ関数は恐ろしくて毎回すぐに投げ出します。(あれを使いこなせる人は VBや PHPも使いこなせると思うんですよ)
[\s\S]*$ というパターン。最後の行の末尾までマッチして欲しいのに一行目の改行直前で止まってしまう。マッチに成功したときの hitEndフラグの扱い。hitEnd()の実装の参考になるか？と思ったけどそうもいかなそう。
Revision 74 hitEnd()の実装（但し仕様は満たしていない）。 Revision 85 useAnchoringBounds()及びuseTransparentBounds()に対応。→hitEnd()の実装を修正。 Revision 103 hitEnd()に@Deprecatedを追加。
/**
* This method is experimentation phase, and implementation has not been completed yet.
* @return
* @deprecated
*/
@Deprecated
public boolean hitEnd() {
return (hasAnchoringBounds ? (range == region.end(0)) : (input.length() == end()));
}
hasAnchoringBoundsが設定されてる場合は無視するとして、そうでないときは入力の長さとマッチの末尾(end())が一致してることをテストしてるだけに見える。それって hitEnd()とは違うよね。5月31日の日記で文字列 aa に対してパターン aa を適用したときに hitEnd()が falseになった事例を引用した。
そうそう。これこそが hitEnd()の使い道 >Check if string is a prefix of a Javascript RegExp - Stack Overflow コメントの最後に見たことのある名前が☺
PCRE(現在 ver. 8.10)は戻り読みも再帰も(パターンのコンパイル時の)改行指定オプションもスキャナー的に使うための hitEnd()のような機能(read pcrepartial)も、およそ欲しいものをすべて備えている。悪名高いスタックオーバーフローにも、1.スタック使用量を減らす。2.代替メモリ確保関数を使う(汎用ゆえに遅いmalloc/freeか自作)。3.pcre_exec()の代わりに pcre_dfa_exec()を使う。みたいな各種対策があるらしい。
最終更新: 2010-08-08T15:03+0900
基本料金の安いシンプルコース用プランにのりかえたいができない。
「シンプルコース」開始 (2007年11月12日) 前より現在の携帯電話機をご利用いただいている方は、「シンプルコース」で携帯電話機のご購入 (機種変更) が必要です。
シンプルコース用のプランを選択するには、シンプルコースを契約して補助なしで端末を一括か分割払いで買うか、フルサポートコースを二年以上続ける必要がある。
フルサポートコースってのは、端末購入補助があるかわりに端末を二年以上使用しなければいけない縛りがある(補助を毎月の高めの基本料金で返してる実態があるから、即解約(端末は手もとに残る)で補助金丸儲けはできない道理)。二年たつとシンプルコースに移れる。
さて、2007年11月12日より前からだから最低でも二年半以上、今の端末をフルサポートコースなみの基本料金で使用してきた俺がシンプルコースを選択できない理由はなんだろう。
この差別の不当な実態がこれ。
格安端末にシンプルコースで機種変更して、SIMを新端末から旧端末に差し替えるんだと。「また一度他社にMNPで移動し、再度auに戻ってきても新規料金が適用されるので安くなります。」なんて返答も。バカなの？(auが)で済まされることではない。馬鹿にしてる。2007年に総務省の要請を承けて？、今より優遇されてたフルサポートコースと、今とは正反対にやる気のないシンプルコースとをもちだしてきたときも感じたが(⇒20071004p01)、端末の――SIMロックされてたり SIMなんかなかったんだからそれは「回線の」と同じ意味だ――長期利用者を蔑ろにしすぎ。過去には長期利用者にメリットのないフルサポートコースと誰にもメリットのないシンプルコースの二択を迫り、今は料金プラン変更のために新端末を買えとか。いらんものはタダでもいらんから格安端末のために 1円だって出さない。でも高い基本料金を払い続けるのもしゃくだ。auが悪いんじゃなくて(腹は立つし捨てたいが)、代わりの選択肢がドコモとソフトバンクなのが悪い。
最初にキャリアに本体代金として高額を上納して、代わりに月々の利用料を多少安くしてもらう仕組みができただけ。
携帯本体という名の「上納金」を、月々ちょっとずつ払うか(auのフルサポートコース)、最初に一括で払うか(auのシンプルコース)、上納金の払い方が 2種類になっただけです。
でも、最後にもう一度だけ申し上げますが、07年11月以前よりauを継続利用中の方はくれぐれもご注意ください。あなた様が支払い続けている高い月額使用料、それは上納金としては一切カウントされておりません。上納金にすらならない無駄金を今日も明日も明後日も、あなたがそれに気づくまで延々と支払い続けているこの事実を、auは決して教えてはくれません。
うまくすれば上納金はなくせるみたいだし、今はシンプル=一括、フルサポ=分割という対応もなりたたないが、シンプルコースに移れない理由を説明しようとするとこれが答えなんでしょうね。自分の実感を自分より上手に代弁してくれてる。auに(自分の口から発せられた)建て前*をのませることはできないのかな。過去にさかのぼって、不当な制限により支払いを余儀なくされた基本料金の差額も取り返したい。
* 「携帯電話ご購入代金をお客様に全額ご負担いただくかわりに、月々の基本料金を安く設定した料金プランがご利用いただけます。」