and if you walk with the unsigned char pointer - your zero will be always less than something else
and if you walk with the unsigned char pointer - your zero will be always less than something else
All problems in computer science can be solved by another level of indirection,
except for the problem of too many layers of indirection.
– David J. Wheeler
You're right that it has higher precedence, but that only means that:
is equal toCode:if (!a || b)instead ofCode:if ((!a) || b)In your case there can be no confusion as to the meaning of the statement with || and !, because there is only one identifier following the !, so the ! can therefore only apply to that identifier.Code:if (!(a || b))
Precedence is only about the meaning of the statement, i.e. what the syntax tree actually looks like. It is not about what the order of evaluation of nodes within the syntax tree is.
My homepage
Advice: Take only as directed - If symptoms persist, please see your debugger
Linus Torvalds: "But it clearly is the only right way. The fact that everybody else does it some other way only means that they are wrong"
Yeah I kind of came to realise that the 'not' check was redundant, but dident say anything cos I'd look dumb :P I guess theres no sneaking my dodgy code past you guys tho
Anyway my first attempt sucked so I had a go at rewriting the function. This should be faster, and I managed to shave a few characters off it:
Code:int StrCmp(char *a, char *b) { while(*a || *b) { if(*a != *b) return(*a > *b) ? 1 : -1; *a++; *b++; } return 0; }
You can get rid of the stars since you're not using the values of *a and *b anyway.Code:*a++; *b++;
Nice one. Now when I remove the whitespace it fits snuggly into one line of code, which fits with the rest of the functionsOriginally Posted by robatino
I see I forgot to make the char pointer unsigned which would cause problems, but apart from that wouldent the null byte equate to less than whatever it is being compared against anyway?Originally Posted by brewbuck
I wrote my own fmod function that only dealt with cases where the number was less than twice that of the number you want to divide by.
It was significantly faster.
I think that's what put me off relying on other people's code.
I wrote several functions in a basic language that were apparently faster than the equivalent functions that were built in. I think the difference was mainly down to function overheads (or something like that) rather than my code actually being faster.