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…
A Regular Expression Matcher (2007)
31–36 of 36 posts
Re: A Regular Expression Matcher (2007)
#32Earlier 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…
Re: A Regular Expression Matcher (2007)
#33Earlier 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…
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)
#34Re: A Regular Expression Matcher (2007)
#35Earlier 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.
Re: A Regular Expression Matcher (2007)
#36Earlier 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.