Live data from Hacker News

A Regular Expression Matcher (2007)

cs.princeton.edu

31–36 of 36 posts

Re: A Regular Expression Matcher (2007)

#31
post #12

Earlier quoted context omitted.

I keep one-line blocks unbraced when possible and my reasoning is definitely not to feel like a tough macho man. It's more like a mild form of OCD where any syntax that's not necessary just bothers me if I don't omit it.

Reductio ad absurdum: I assume your variable names are single-letter, your Python is indented only one space per block level and every C program is a one-liner? You should check out the Code Golf stackexchange; you'd do well. Kidding aside, I can appreciate your feeling of OCD (I fight that urge too) but remember that most syntax is for humans, not machines. Using braces communicates intent to the reader; omitting th…

Nah, humans go by indentation anyway. Just use whatever brace style you like, but make sure you have a linter / formatter that makes sure your indentation agrees with your braces.

Re: A Regular Expression Matcher (2007)

#32
post #6

Earlier quoted context omitted.

> (It's also a good example of how pointer-arithmetic and nul-terminated strings should be used, but the less said about that, the better). Why the less said the better? I'm always disappointed when people say C is bad at string manipulation. The "character at a time, no allocations needed, stop when you hit the end" style demonstrated here and elsewhere have always resonated deeply with me.

> I'm always disappointed when people say C is bad at string manipulation. The "character at a time, no allocations needed, stop when you hit the end" style demonstrated here and elsewhere have always resonated deeply with me. The main reason is that C doesn't really offer many primitives for string manipulation beyond pointer manipulation. All you really get is the stuff in `string.h`, which isn't much, and most of…

The problems you describe are all well understood to C programmers and hence not really a huge issue. You are severely overstating their difficulty.

Re: A Regular Expression Matcher (2007)

#33
post #22

Earlier quoted context omitted.

"Is this: while (foo != '\0') { bar++ = foo++; } really that much nicer than this: while (i != len) { bar[i++] = foo[i++]; }" Not visually, but the latter increments i twice in every loop :-). It also typically uses an extra register and requires an explicit 'compare with zero'. Both mattered more 40+ years ago.

> the latter increments i twice in every loop :-). D'oh! Good catch. That's what I get for coding without testing at 3am... Just realized `foo != '\0'` should be `* foo != '\0'`, too. Derp. > It also typically uses an extra register and requires an explicit 'compare with zero'. Okay, I see the extra register, but I'm lost on any extra comparisons versus the pointer-arithmetic version. The pointer version still has to…

"The pointer version still has to test for the nul character anyway, right?"

Some architectures set the zero flag on memory loads. I think the PDP is one of them. Google gives me https://groups.google.com/forum/m/#!topic/net.lang.c/LKAYbzX..., which claims that

    while (*ra++ = *rb++);
    
compiles to

    L16:
        movb        (r10)+,(r11)+
        jeql        L17
        jbr         L16
    L17:
If you do i != len, you need an extra comparison instruction.

Re: A Regular Expression Matcher (2007)

#35
post #33

Earlier quoted context omitted.

> the latter increments i twice in every loop :-). D'oh! Good catch. That's what I get for coding without testing at 3am... Just realized `foo != '\0'` should be `* foo != '\0'`, too. Derp. > It also typically uses an extra register and requires an explicit 'compare with zero'. Okay, I see the extra register, but I'm lost on any extra comparisons versus the pointer-arithmetic version. The pointer version still has to…

"The pointer version still has to test for the nul character anyway, right?" Some architectures set the zero flag on memory loads. I think the PDP is one of them. Google gives me https://groups.google.com/forum/m/#!topic/net.lang.c/LKAYbzX... , which claims that while (*ra++ = *rb++); compiles to L16: movb (r10)+,(r11)+ jeql L17 jbr L16 L17: If you do i != len , you need an extra comparison instruction.

Ah! Interesting. Thank you :)

Re: A Regular Expression Matcher (2007)

#36

Earlier quoted context omitted.

> I'm always disappointed when people say C is bad at string manipulation. The "character at a time, no allocations needed, stop when you hit the end" style demonstrated here and elsewhere have always resonated deeply with me. The main reason is that C doesn't really offer many primitives for string manipulation beyond pointer manipulation. All you really get is the stuff in `string.h`, which isn't much, and most of…

The problems you describe are all well understood to C programmers and hence not really a huge issue. You are severely overstating their difficulty.

I don't mean to imply that they're difficult to overcome. I'm just trying to explain why people often say that C has poor string handling. Many modern languages provide more comprehensive string libraries, and the ones that are provided tend not to suffer from such problems. It's not that C is incapable of doing string handling (it's capable, yes), but when you constantly find yourself tossing out C's string library altogether and rolling your own instead, it becomes obvious that C's provided string handling functionality is inadequate for many use cases.
Post reply on HN