Re^3: Regex - one and only one / at beginning and end of file path

What concern does that snippet address? I don't see how it has anything to do with anything posted anywhere on this thread?

As for performance, despite appearances, you're actually going to have a hard time beating the regex engine. With substr, you usually have to do a (relative) lot of explicit work in Perl code, which means many more ops to interpret; with regexen, most of the infrastructure is implicit in the guts of Perl, which execute much faster.

Makeshifts last the longest.

Comment on Re^3: Regex - one and only one / at beginning and end of file path

Replies are listed 'Best First'.
Re: Re^3: Regex - one and only one / at beginning and end of file path by CombatSquirrel (Hermit) on Dec 15, 2003 at 18:52 UTC
It concerns checking whether or not a string starts and ends with "/", which was, as far as I can see the OPs question. I do realize that (s)he asked for a RegEx solution, but the "Is the one line solution faster than the two line solution?" part made me think that it was not really relevant in which way checking should occur. I would have assumed that `substr` was faster than RegExes, because it would just be a simple comparision of an array element (in C -- as I said, I didn't benchmark it, so I am making analogous assumptions) vs. something that hardly could be easier in case of the RegEx. If you say that the RegEx would probably be faster I'll have to believe you, but I don't think that my original reply could really have hurt anyone reading it. Just my own opinion, though. CombatSquirrel. Entropy is the tendency of everything going to hell.	[reply] [d/l]
Re^5: Regex - one and only one / at beginning and end of file path by Aristotle (Chancellor) on Dec 15, 2003 at 20:19 UTC
But the OP was trying to make sure that the string has exactly one slash at both ends. Your snippet does not check for multiple slashes nor does it do anything about missing ones. The "blanks" that have to be filled in your approach basically consistute the entire solution. As for the performance, this is Perl, not C; a string is not just a pointer to a chunk of bytes in memory, but wrapped in a complex data structure, and so is substr's return value. Then there's the need to have a lot of explicit ops in the optree, and on the other hand, there's the many (though specific) optimizations the regex engine has enjoyed. Optimizing a highlevel language like Perl, if you even want to, is a very different science from optimizing a lowlevel language like C. Makeshifts last the longest.	[reply]