Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

My favorite regex of all time

catonmat.net

Post reply on HN
Print view View original

111–117 of 117 posts

Re: My favorite regex of all time

#111

Post by jarek »

csense wrote: post #57
lambada wrote: post #2

Are people seriously still deliberately using ASCII-reliant code?

Every time I've had to deal with Unicode and internationalization, it's been a problem. For example, a few years ago I grabbed a source tarball from somewhere, I forget what or where. It had the author's name in a comment, which included an O with dots over it. That was the only non-ASCII character in the source code. No matter what I did, both Eclipse and command-line javac refused to compile the source. Finally I w…

I, for one, applaud this attitude. It gives programmers and companies that know what they're doing a leg up over people who couldn't even bother to figure out UTF-8. Natural segmentation of a target market is a good thing.

Re: My favorite regex of all time

#112

Post by laumars »

jbooth wrote: post #107
laumars wrote: post #87

Earlier quoted context omitted.

If a regex is going to be reusable, then yeah, I'd agree. But dumping single lines of code into their own functions just for readability isn't practical for real time systems. In those cases you really should be using comments as they get stripped out by the compiler.

REGEXES aren't practical for real time systems. If you're using a regex, and certainly if you're using a language other than C, you probably have space for the function call overhead.

I don't really agree with that.

Sometimes C is inappropriate (eg you'd be nuts to build a website in C yet some sites do offer real time services)

Often the data set and/or logic required makes C an inappropriate language (eg you wouldn't use C for AI nor for some types of database operations).

And even in the cases where you're just building a standard procedural system, sometimes the interface lends itself better to other languages (eg C would be possibly the worst language for real time websites.)

But even in the cases where you're building a solution that's suited for C, there are still other performance languages which could be used.

"Real time" is quite a general term and as such, sometimes it makes more sense to use scripting languages which are performance tuned. Which is where writing 'good' PCRE is critical as RegEx can be optimised and compiled - if you understand the quirks of the language well enough to avoid easy pitfalls, eg s/^\s//; s/\s$//; outperforms s/(^\s|\s$)//; despite it being two separate queries as opposed to one.

Re: My favorite regex of all time

#113

Post by jbooth »

laumars wrote: post #112
jbooth wrote: post #107

Earlier quoted context omitted.

REGEXES aren't practical for real time systems. If you're using a regex, and certainly if you're using a language other than C, you probably have space for the function call overhead.

I don't really agree with that. Sometimes C is inappropriate (eg you'd be nuts to build a website in C yet some sites do offer real time services) Often the data set and/or logic required makes C an inappropriate language (eg you wouldn't use C for AI nor for some types of database operations). And even in the cases where you're just building a standard procedural system, sometimes the interface lends itself better t…

"Real time" is commonly assumed to mean that you can't use a garbage collected language or need to be extremely careful doing so because random pauses of 100ms break your constraints.

If you're in a situation where the overhead of a couple of function calls is unacceptable, regexes are totally unacceptable and you need to write custom character manipulation.

This situation is really rare and in almost all business cases, using C is inappropriate.

Re: My favorite regex of all time

#114

Post by tripzilch »

dredmorbius wrote: post #35
rmc wrote: post #24

Earlier quoted context omitted.

It's not an ASCII v EBCDIC thing, its an ASCII vs Unicode thing.

More generally, it's a characterset / collate sequence thing. Specifying a range with a start and end point requires understanding what that range specifies. Which can change depending on context, locale, characterset, etc.

Also in the 32-127 ASCII range? I thought they just differ in 128-255 with the code pages and such?

Re: My favorite regex of all time

#115

Post by tripzilch »

Wouldn't it be smarter, in that case, match something like [\x20-\x7F] (unsure if that's valid regex, but you get the point), it's more explicit that way, being very obvious about what characters are included, as well as immediately being clear (to me) about the intention of the character class. "0x20 to 0x7F" triggers the idea of "Printable ASCII" a lot sooner than to .

Re: My favorite regex of all time

#116

Post by nobleach »

natrius wrote: post #84
CountHackulus wrote: post #68

Earlier quoted context omitted.

It's not just Unicode either. I just mentioned EBCDIC because that particular regex has bit me before when I was translating perl scripts from Linux to zOS USS. Take a look at the code page for EBCDIC, you'll see quickly why it's a massive pain to sort through regexes like that.

I honestly thought you were being sarcastic. I've never heard of someone who has actually used EBCDIC.

I'm sure you've heard of the IBM AS/400 which is still firmly entrenched in MANY Fortune 500 companies. Not to mention tons of state and county government installations handling payroll, inventory, taxrolls, etc. I had to deal with a Perl script which dealt with ASCII to EBCDIC to port data to an Oracle database. If you're a Windows only shop, that's fine, but don't assume that anyone whom isn't is ancient.

Re: My favorite regex of all time

#117

Post by dredmorbius »

tripzilch wrote: post #114
dredmorbius wrote: post #35

Earlier quoted context omitted.

More generally, it's a characterset / collate sequence thing. Specifying a range with a start and end point requires understanding what that range specifies. Which can change depending on context, locale, characterset, etc.

Also in the 32-127 ASCII range? I thought they just differ in 128-255 with the code pages and such?

In the case of EBCDIC, there are several places in the alphabetic collation sequence in which non-alpha characters are interspersed among the letter codes. Most notably between R & S, though it appears that I-J also includes a standout. The fact that there are multiple incompatible forms of EBCDIC doesn't help matters much.

Makes sorts really tweaky.

http://en.wikipedia.org/wiki/Ebcdic

Post reply on HN