Live data from Hacker News

\d less efficient than [0-9]

stackoverflow.com

31–40 of 80 posts

Re: \d less efficient than [0-9]

#31
post #5

Earlier quoted context omitted.

Anyone know if this happens in other languages?

Happens in PHP only if you enable Unicode regex handling via the /u modifier and are running libpcre 8.10 or later (which corresponds to PHP 5.3.4 and later, assuming you're using the bundled libpcre): http://3v4l.org/QD3k0

If you're using pcre directly from C code, this is controlled by specifying the PCRE_UCP flag to pcre_compile(). By default, \d and friends only match ASCII characters even if the PCRE_UTF8 flag is set.

Re: \d less efficient than [0-9]

#32
post #9

I was a bit surprised that Perl does not seem to be matching Unicode digits. Anyone know why? $ echo '0' | perl -pe 'print "yes: " if m/\d/' yes: 0 $ echo '੧' | perl -pe 'print "yes: " if m/\d/' ੧

Ditto PHP:

  php > var_export(preg_match("/\d/", "1"));
  1
  php > var_export(preg_match("/\d/", "۳"));
  0

Re: \d less efficient than [0-9]

#33
post #18

Earlier quoted context omitted.

Not true for Go http://play.golang.org/p/ls96RxJxpz

I would be reluctant to rely on this until the Go documentation is clearer on the intended behavior. Right now it's very poorly specified. The regex doc[1] talks about "same general syntax" as Perl, but points to [2], which doesn't seem to understand what it's saying, describing '\d' in terms of its "Perl" meaning, but then saying that it's [0-9]. [1] http://golang.org/pkg/regexp/ [2] https://code.google.com/p/re2/wi…

As a Perl developer that's been making the switch to Go, I've been caught out a few times with Go's no-so-Perl-like regular expression syntax. In fact I wish I knew about your 2nd link before now, because that could have saved me a few hours over recent months.

Re: \d less efficient than [0-9]

#34
Regex is a really powerful tool, but sometimes I wonder just how well people actually understand it as the vast majority of people (myself included) seem to be self taught in the syntax - only learning the bits they need as and when they need it.

The problem is, regular expressions is packed full of counter intuitive idiosyncrasies which make perfect sense once they're explained, but are far from obvious. Take this for example:

    s/(^\s+|\s+$)//g
is slower than running two separate regex, like so:

    s/^\s+//;
    s/\s+$//;
So it does make me wonder the number of bugs that have been introduced to software by bad regex.

Re: \d less efficient than [0-9]

#37
post #4

Earlier quoted context omitted.

Is that actually a good thing? If I'm using \d to validate numbers (for example to check before string to int conversion, or IP address, phone number, or any other use), other unicode digits are not helpful to me. It's great to support unicode, but I don't think the \d should have been extended this way. Add a \ud or something.

Given that the category is specifically "decimal digit", I think it's good, so long as the number parsing code accepts them all too.

Yes. Assuming that, it's good. I think that assumption is likely to be invalid in many cases, though.

Re: \d less efficient than [0-9]

#39
post #9

I was a bit surprised that Perl does not seem to be matching Unicode digits. Anyone know why? $ echo '0' | perl -pe 'print "yes: " if m/\d/' yes: 0 $ echo '੧' | perl -pe 'print "yes: " if m/\d/' ੧

Ditto PHP: php > var_export(preg_match("/\d/", "1")); 1 php > var_export(preg_match("/\d/", "۳")); 0

Add /u

    php > var_export(preg_match("/\d/u", "۳"));

Re: \d less efficient than [0-9]

#40
post #18
post #5

Earlier quoted context omitted.

Anyone know if this happens in other languages?

Not true for Go http://play.golang.org/p/ls96RxJxpz

Considering go's vocal support for UTF8 I'm surprised at this behavior and curious to the reason for excluding it.
Post reply on HN