Re: C vs perl

[samtregar]

Well, that is some aggresively ugly C code. If one objective of you presentation is to convince competent C coders to try Perl then I suggest you take another run at it. With that code the first thing they'll think is that you just don't know enough C to know how much it rocks.

Specific comments:

• Do it in one pass. No one likes to see an alogorithm that has to scan through the input text more than once. That might mean realloc()ing memory as you run short, but you should be able to take a good guess based on the input text length.
• Consider making use of the str*() library routines. Perl has much better string support but it's not as though C is totally lacking!
• Think about building your parser around as swicth-driven state-machine. This is how C parsers are commonly built.
• Maybe do it with YACC instead? No one should build parsers in C by hand once they learn YACC! I bet the YACC implementation would compare favorably with Perl.

-sam

[abstracts]

I totally agree with samtregar that this code really convinces nobody that you know enough C to compare the 2 languages.

What I don't agree with is using realloc instead of scanning the string twice, as realloc will have to copy the string over to a new location if it fails to allocate a larger size of contiguous memory at the same location. I might be wrong and it might even be implementations dependant (what malloc library guarantees giving you the same location if you realloc to a larger size?).

Hope this helps...

[samtregar]

Do you have a better idea? It's pretty hard to know how much memory to allocate when you don't know how big your results will grow! Perl realloc()s on SVs all the time for just this reason.

I suppose he could build a linked-list of text blocks and then reassemble them into a single contiguous block at the end. I doubt that would perform better than realloc() though.

-sam

[abstracts]

One way to do it is by allocating string of length:

newlen = (strlen(str) * strlen("</p><p>")) / strlen("\r\n")
       + strlen("</p><p>") + 1;

which is in this case 3.5 times the length of the original string. This is the total number of bytes required in the worst case scenario: $str =~ /(\r\n)*/. Excessive memory can be reclaimed by doing a realloc *after* the substitution.

As for perl's internal implementation, it's a different issue as the regex engine must work with any regex given. But even with that in mind, you can still build a linked list of offsets and lengths of parts in the original strings that need to copied over, as well as another list of substitutions. The required amount of memory should be easy to compute and will require doing a single copy only.

For this example, this is like doing:

my $str = 'line1\r\nline2\r\n";
my $result = join '</p><p>', split(/\r\n/, $str);

[John M. Dlugosz]

What about using strtok in C? That will give you something similar to foreach (split).