|
I don't know about the rest of you, but I personally prefer FAST code to SHORT code. The function you posted is considerably slower, do some benchmarks, I have.
This code....
int main(int argc, char **argv) {
int x;
for (x=0; x<9999999; x++) {
wildcmp("*t?st?n*this*t*", "testin this sh*t");
}
}
using your function...
real 0m13.170s
user 0m13.120s
sys 0m0.020s
using my function...
real 0m6.804s
user 0m6.790s
sys 0m0.000s
Furthermore I don't see why you criticize me for using loops when you are using a recursive function.
Thanks for your reply anyhow,
Jack
|
|
|
|
|
i didn't criticize you.
i just said that wildcard matching is not a very heavy problem to solve and that i don't understand why people spend hours looking around to find code while it takes a cigarette's lifetime to do it yourself.
first of all i feel happy that my function works at all! secondly, i know that recursion produces noticeable overhead, and as i said it was not my primary objective to write a fast function. i just tried to write it in 5 minutes time.
|
|
|
|
|
|
I'm a speed freak so this is exactly the answer I was looking for after I noticed c++ guru's comments on code complexity. TBH I thought both implementations were straight forward, but speed is more critical.
Cheers
"Two wrongs don't make a right, but three lefts do!" - Alex Barylski
|
|
|
|
|
Gotta go with c++ guru on this one.
unless you are writing code for slow embedded processors with 1K of RAM, you are better off with the much clearer code from c++ guru. I can see at a glance how his code works. However, if there happened to be a bug in Handy code, or i needed to upgrade the functionality, i wouldn't have a clue where to start.
Readability is extremely important when sharing code around.
|
|
|
|
|
What is unclear about my code? Do you not understand pointer arithmetic?
-Jack
|
|
|
|
|
It is just clearer to use C++ gurus style. I take a lot of code from code project and am very grateful for it. With most of the classes i have to make some modification or other as I am writing a commercial application which often requires tweaks. I need wildcard matching in a number of places but maybe a little more than * and ?. Therefore, the first thing i considered was how i could add extra tokens. It appears at a glance that c++ gurus code is easier to grasp.
I understand pointer arithmethic just fine, and i believe the claim that your code is twice as fast. It is more important for me to have bug free code as wildcard comparison functionality is carried out on a very small scale in my application. Any bugs are headaches. I am firmly a c/c++ devotee and hate all the luggage that comes with .NET, VB, etc. But we can have a small tradeoff for readability in the general case. Why give those guys ammunition for their 'C/C++ code is unreadable and only hacks use it' argument?
No offense but i will use the gurus code because i have my reasons. It is not fair to blindly knock it though.
anyway, it is better you submitted this article than no article.
cheers
|
|
|
|
|
This code looks like it would perform slow as hell. A recursive function like this would have an incredible amount of overhead. I think in this case, re-inventing the wheel will bite you in the ass. I imagine that on a longer string, this function will get slower and slower.
|
|
|
|
|
Because often when you reinvent the wheel, you forget to put some spokes in!
It's not just coding time, but also testing time.
|
|
|
|
|
Well... all the other answers speak for themselves, so
I will try not to add anything to it.
May be your code is shorter, and may be it works.
Nevertheless you could have written it a bit more gentle.
Like this, it seems quite a bit arrogant.
In fact, the choice of speed or space always depends on what you need.
Usually speed is more usefull, sometimes you need space (like on a small
linux firewall that should fit on a floppy, or so)
Hope you don't mind that we will use Jack Handy's code
Targys
|
|
|
|
|
a bit more gentle?
if you think jack handy's code is more gentle, fine. but i think you're one of the use-and-dont-ask kind of guys then.
even if it is the faster solution (which end-user application ever requires a million wildcard matches?) the readability of jack's procedure approaches zero. if you do not recognize this, you're either in the wrong business or talking about things you don't know about.
additionally, your 'fit on a floppy' argument is also in the wrong place: my code is shorter, and so is the compiler output.
of course i don't mind if you use jack's code. but if i were to maintain the code, i'd prefer my solution.
regards
|
|
|
|
|
The C++ Guru wrote:
a bit more gentle?
if you think jack handy's code is more gentle, fine. but i think you're one of the use-and-dont-ask kind of guys then.
I think he was talking about your arrogant attitude in your post, not your code.
-Jack
|
|
|
|
|
While recursiveness is great, it is a higher overhead. If Jack can solve the problem with no recursion, I vote Jack's code is better.
However, since we are nick picking, both of your codes suck! None check for NULL pointers! So maybe you are in the wrong business or learn to shut up.
Hector Santos, CTO
Santronics Software, Inc.
http://www.santronics.com
|
|
|
|
|
I think some of you guys like complicated code that other people wouldn't want to read or learn from. In a large programmer team this is useless. Jack's code would not stand a minute of our code reviews.
"The C++ Guru"s code is not the solution I would prefer, but it is by far more readable, and a fairly good starting point ...at least for non-time-critical end user apps.
Besides, i can't see any checks for NULL pointers in Jack's code. can you?
Kent C. Dorner
IBM Billing Solutions
|
|
|
|
|
Personally, I agree. I believe Jack's code is more readible. I tend to look for look for logic that looks for recursion.
Correct, both codes do not check for nulls.
[SIDE NOTE] I've been involved in hundreds of corporate development projects. I lead many of them before eventually leaving to start my own company. IMO, it depends on the "large team" make up. If you include non-trained (no where else to put them) programmers in the loop, sure, its harder for them to read code. But then again, they shouldn't be part of the "tools development" group. They are usually not expected to have input in the matter. However, I would suggest that they would be the first to find the bug by accidently introducing NULLs.
In general, tools are usually designed by trained computer scientist. Applications development uses them. Nonetheless, in the new world of IDEs and Component Engineering, many of these disciplines are merged (good or bad) even to the extend that you don't need an "official education" (whatever that means) in computer coding techniques.
Hector Santos, CTO
Santronics Software, Inc.
http://www.santronics.com
|
|
|
|
|
Kent C. Dorner wrote:
Jack's code would not stand a minute of our code reviews.
I suggest that your "large programmer team" stick to Java. I would be happy to see your team come up with something better. Keep in mind that no matter what your wife might say, performance does matter.
-Jack
There are 10 types of people in this world, those that understand binary and those who don't.
|
|
|
|
|
ok, for all you f***ing managed c++ bozo's out there, listen up. I challenge ANY of you to jump into stl and say its readable. No wonder IBM Billing is such a POS if they would rather have "easier" readability in code then performance.
Oh yeah, c++ guru, some f***ing guru, ever hear of inline you f***ing putz ?
I googled this wildcmp function, and bar none its the best damn wild compare I have seen yet. I can't believe some of the nonsense that is being posted here as an attempt to discredit the author for some reason unbeknownst to me.
and finally, for you babies who can't stand to manage their own pointers (et al managed c++ bozos)
if ( ( !string ) || ( !wild ) )
return( 0 );
|
|
|
|
|
YEAh this code is the sh*t. And his code does make more sense if you are able to think outsdie the box rather than whien about no recursion. The fact of the matter is that if his solution is better than you should use it, thats the whole point of a polymorphic language. And if you dont understand pointers enough to pass null pointers into functions, well... maybe you should... rewrite the code so it checks for pointers?
I am but a lowly highschool student, but i've been coding since i was 7. And anyways, if you want to know what kind of program would require intense wildcard comparing, well, I wrote a program that auto-comments a source code file using a wildcard scheme, basically checks each line based on wildcard queries it loads up from a file and if the test is successful it inserts that comment at the end of that line. Pretty mindless commenting, but its just cause i'm sick of commenting my CS homework. So yeah, Jack Handy is the man.
http://www.coxar.pwp.blueyonder.co.uk/
|
|
|
|
|
Both of you wrote good code that is simple and readable,
In any case for many of us is no problem to write something like this but I would use their code just to reduce time for development, I think we have to say a lot of thanks. So guys just be a litle bit polite to each other.
|
|
|
|
|
Thanks for the code! I was searching the web for a simple wildcard matching routine ... I don't want full blown regular expressions, I just want to do simple wildcards against a list of filenames. This is perfect!
|
|
|
|
|
You might want to look into the PathMatchSpec() function in shlwapi.dll.
--Mike--
"Everyone has figured out what 'service pack' really means, so they had to go and change the language. Perhaps this is what Bill was talking about in the 'security is top priority' letter."
-- Daniel Ferguson, 1/31/2002
My really out-of-date homepage
Sonork - 100.10414 AcidHelm
Big fan of Alyson Hannigan.
|
|
|
|
|
Now _that's_ what I was looking for.
Thanks!
Steve
|
|
|
|
|
I found this very useful. thx!
Todd Smith
|
|
|
|
|
I ran the following test cases through wildcmp, all successful. (The test() function compares the pattern to the input string, and compares against the expected result).
test( "", "", true );
test( "*", "", true );
test( "*", "A", true );
test( "", "A", false );
test( "A*", "", false );
test( "A*", "AAB", true );
test( "A*", "BAA", false );
test( "A*", "A", true );
test( "A*B", "", false );
test( "A*B", "AAB", true );
test( "A*B", "AB", true );
test( "A*B", "AABA", false );
test( "A*B", "ABAB", true );
test( "A*B", "ABBBB", true );
test( "A*B*C", "", false );
test( "A*B*C", "ABC", true );
test( "A*B*C", "ABCC", true );
test( "A*B*C", "ABBBC", true );
test( "A*B*C", "ABBBBCCCC", true );
test( "A*B*C", "ABCBBBCBCCCBCBCCCC", true );
test( "A*B*", "AB", true );
test( "A*B*", "AABA", true );
test( "A*B*", "ABAB", true );
test( "A*B*", "ABBBB", true );
test( "A*B*C*", "", false );
test( "A*B*C*", "ABC", true );
test( "A*B*C*", "ABCC", true );
test( "A*B*C*", "ABBBC", true );
test( "A*B*C*", "ABBBBCCCC", true );
test( "A*B*C*", "ABCBBBCBCCCBCBCCCC", true );
test( "A?", "AAB", false );
test( "A?B", "AAB", true );
test( "A?*", "A", false );
test( "A?*", "ABBCC", true );
test( "A?*", "BAA", false );
Paul McGuire
KLA-Tencor/Process Analysis & Control Division
Austin, TX
|
|
|
|
|
Your test #7 prove the bug i found in this code:
pattern: start*end
will not match text: start___end___end
it will not since the second look will go and perform match to the first part of the string: start___end
and then will return false since we did eached the end of the pattern but not the end of the string
|
|
|
|
|