[ruby-dev:22161] Re: Dir.glob と Shjift_JIS について

山本です。


>fnmatchでも**を扱えるようにするというのはいいかもしれませんが、
>FNM_PATHNAMEって意味は逆じゃありませんでしたっけ。

Dir.glob("a*.dat")

と書いた場合、これは
「a ではじまり .dat で終わるファイル」と
「a ではじまるフォルダ以下にある .dat で終わるファイル」の
２つの意味を含みますよね。

* が / にマッチしない場合は

Dir.glob("a*/**/*.dat")
Dir.glob("**/a*.dat")

とそれぞれかけますが、この両方にマッチさせたいケースはあまりない気がします。
仮に両方にマッチさせたいとしても、'\0'で区切ればよいのだから、
File::FNM_PATHNAME の動作に統一してしまっても、困らないと思います。


>全然オーバーヘッドを気にしているわけではなくて、ターミネータを
>越えてアクセスしようとするところが、バッファオーバーランを誘発
>しそうでなんとなく気になってます。

でも、(p) + 1 を使うシングルバイト環境では、p == '\0' でも１増えますよね。
Next() の動作が環境によって異なるのは避けたいです。
mblen()はターミネータを越える数を返さないだろうし・・・

>
>> aa/aa/aa/aa/* みたいに、最後が magic なパターンで glob_helper を呼んだ場合に、 / の度に
>> 
>>     p = sub ? sub : path;
>>     if (!has_magic(p, 0, flags)) {
>> #if defined DOSISH
>> 	remove_backslashes(path);
>> #else
>> 	if (!(flags & FNM_NOESCAPE)) remove_backslashes(p);
>> #endif
>> 
>> が呼ばれる部分の方がマルチバイト環境では気になります。
>
>これはまぁ、以前から若干思わないでもなかったのですが、トータル
>としてはそう大きくはならないだろうと思ってます。

ベンチマーク上は Next()の呼び出し回数はパスの長さ n に対して O(n*n) のオーダで増えるので、
パスが長くなるにつれ遅くなるのがわかるんですが、トータルでは確かに微々たる物かも。

でも、最適化してみたい気はするなあ。


!# ruby -Ks

require "benchmark"

n = 100000

Benchmark.bm { |x|
    x.report {
        for i in 1..n
            File.fnmatch("b??/*/b??", "bee/banana/bee")
        end
    }
    x.report {
        for i in 1..n
            File.fnmatch("b??/*/b??", "bee/banana_n_banana_n_banana/bee")
        end
    }
}


/////////////////////
// Result

S:>e:\ruby-1.8.0\bin\ruby a.rb
      user     system      total        real
  0.580000   0.000000   0.580000 (  0.580000)
  0.621000   0.000000   0.621000 (  0.621000)

S:>ruby a.rb
      user     system      total        real
  0.951000   0.000000   0.951000 (  0.952000)
  1.442000   0.000000   1.442000 (  1.442000)