R. Joseph Newton writes: > When used consciously, with at least a general awareness of the processing > load being invoked, regexes can do some really incredible things.
Thanks! I especially appreciate the example you gave showing how to trim both ends of a string: that it is more efficient to trim each end as a seperate case that to trim them both in the same regex. That is the kind of empirical advice I was hoping to get. > The problem with rolling your own in Perl is the overhead of Perl's magic > variables. Although Perl scalars have very useful features, each scalar does > require structures to support them. So when you try to compete with built-in > functionality, operating at full, optimized C-language implementation speed, > you are carrying a lot of baggage into the race. You will probably lose, no > matter how efficient your code. Yes, I have done my fair share of lisp and forth programming. Both of the languages are similar in some respects, but forth is much more bare-bones, while lisp keeps track of variable types dynamically, and does garbage collection. Forth does not have typed variables, but rather typed operators. A variable is just a memory address. The overhead of keeping good tabs on variables is understood and appreciated. Forth targets embedded applications, while lisp targets more interactive applications. They both have theri place. C is more like forth ionm this respect, while perl is more like lisp, no? > Perl actually does call for a different coding approach than C. Would any C > coder try to roll their own stdio? It seems like that would be a pretty rare > occurence. the standard library is part of the language, and C-coders make > use of it. The core and standard modules are likewise a part of the Perl > language as a whole. > I would hate to tell you how many times I have had to implement my own stdio in C for an embedded application on some hitherto as yet unbuilt cpu architecture... :-( > Since it sound like you have > a considerable investment in your C work, you might also consider packaging > some of it for use in Perl. I'm not recommending embedded code here, so much > as looking for Perl interfaces to compiiled C object files that your Perl > programs can call on for specialized and highly optimized jobs. > > Joseph My main use for perl is in doing things that get too akward as a shell script, or things that use a lot of character string manipulation, as C is difficult at this. I especially remember a set of shell scripts I wrote about 10 years ago that took FORTRAN-77 source files as input and massaged them for use with a custom multi-cpu parallel processor I designed. These scripts worked great, but they were really *UGLY* to look at, and I now know it would have been much easier to write, document, and maintain them had I written them in perl. Unfortunately, I had never heard of perl back then. I see from the perlfaq that perl4 was available then. Too bad I never heard of it. Writing better scripts for system administration and security, and CGI stuff for the web server are my main interests in perl right now. I may be looking into a perl2C tool someday, but not yet. I need to learn perl's OO features first,as I have not tapped into that yet, and I am really a very big OO advocate. Web-wise, I have looked at php, and I probably need to look at JSP, but perl CGI is the classic way to do it, so I will learn that first. I have also had great results using perl to write web clients. -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] <http://learn.perl.org/> <http://learn.perl.org/first-response>
