Difference between strcmpi() and stricmp() ?
Bruno Baguette
What is the difference between strcmpi() and stricmp() ???
Theses functions are in the string.h include...
Thanks in advance ! ;-)
----------------------------------------------------------------------------
--
Bruno Baguette (bruno.b...@francemel.com)
Richard Heathfield
<7mt74k$skj$1...@xenon.inbe.net>...
> Hello,
>
> What is the difference between strcmpi() and stricmp() ???
One is not mentioned in the ANSI standard, whereas the other is not
mentioned in the ANSI standard.
>
> Theses functions are in the string.h include...
No they aren't. Not according to the standard anyway.
>
> Thanks in advance ! ;-)
How can I be grumpy after that winkie? Okay, I'll tell you. There is NO
DIFFERENCE AT ALL between them. In some implementations (notably Microsoft)
strcmpi and stricmp are both functions to compare two strings without
sensitivity to case. Other implementations don't use, supply or support
them at all. I think one's a bit older than the other but I forget which
one is the more recent, preferred form. They both have the same syntax and
purpose and they are both non-standard. Avoid their use in source code
posted to comp.lang.c, or some of the regulars will invoke nasal demons on
your behalf - which isn't pretty, trust me on this. :-)
--
Richard Heathfield
The bug stops here.
Jarmo Tiittanen
Bruno Baguette wrote:
> Hello,
>
> What is the difference between strcmpi() and stricmp() ???
>
> Theses functions are in the string.h include...
>
> Thanks in advance ! ;-)
>
> ----------------------------------------------------------------------------
> --
> Bruno Baguette (bruno.b...@francemel.com)
The routine strcmpi is the same as stricmp. strcmpi is implemented through a
macro in string.h and translates calls from strcmpi to stricmp.
And of course there is a few differences between strcmpi() and stricmp()
1. strcmpi macro is provided for compatibility with other C compilers.
2. portability
strcmpi dos, unix, win32 and ansi c++
stricmp dos, unix, win16, win32, ansi c, ansi c++ and os/2
Regards
--
Jarmo Tiittanen
Svanströminkuja 5-7 B22
00870 HELSINKI
http://www.dlc.fi/~jacxs
a980...@myy.helia.fi
j.o.ti...@dlc.fi
Joel Bisqwit Yliluoma
> 2. portability
> strcmpi dos, unix, win32 and ansi c++
> stricmp dos, unix, win16, win32, ansi c, ansi c++ and os/2
stricmp() is ansi c?
Well, the GNU libc (Linux) lacks ansi
--
main(C,f,s){for(/** gcc sig.c;a.out>/dev/audio ## http://iki.fi/bisqwit/ **/
write(C=0,"(C)Bisqwit\n",11);f=99;++C){for(s="+%7%+%7%5%4%2%457%0%0%754%2%+"
"%%%5%542%457%0%0%042%2#+%!#0%+%$%%%"[C&63];s--;f=f*89/84);for(s=999+99*(C&2
);--s;putchar(((s*(f-776?f:0)&32767)*s/199999+39-(C&2?rand()%s/24:0))/16));}}
Richard Heathfield
<rcrk3.216$p15...@read2.inet.fi>...
> On Sun, 18 Jul 1999 22:44:36 +0300, Jarmo Tiittanen wrote:
> > 2. portability
> > strcmpi dos, unix, win32 and ansi c++
> > stricmp dos, unix, win16, win32, ansi c, ansi c++ and os/2
>
> stricmp() is ansi c?
No, it isn't.
Ben Pfaff
Joel Bisqwit Yliluoma wrote:
> On Sun, 18 Jul 1999 22:44:36 +0300, Jarmo Tiittanen wrote:
> stricmp() is ansi c?
So i have told that it's ansi c portable, but these string compare functions are
a little odd things. For example string compare functions, which not recognize
upper and lower case letters are same format as strcmp function.
And this is quite compiler issue, because most compilers are they own similar
functions.
For examples Symantec strcmpl(), Microsoft _stricmp(), Borland strcmpi() and
stricmp() and so on. And these function are not jibe with ANSI-standard, and
that's why all compilers not support them. And this phase I'm out, so I'm just
waiting someone how could explain these things to me.
In fact there is no ANSI function for comparing strings
case-insensitively. You can use the function below if you like:
int
blp_strcasecmp (const char *s1, const char *s2)
{
for (;;)
{
if (!*s1 || !*s2
|| tolower ((unsigned char) *s1) != tolower ((unsigned char) *s2))
return (unsigned char) *s1 - (unsigned char) *s2;
s1++;
s2++;
}
}
--
"Large amounts of money tend to quench any scruples I might be having."
-- Stephan Wilms
Ben Pfaff
Ben Pfaff wrote:
> Jarmo Tiittanen <j.o.ti...@dlc.fi> writes:
>
> And these function are not jibe with ANSI-standard, and
> that's why all compilers not support them.
>
> In fact there is no ANSI function for comparing strings
> case-insensitively.
I know, that comparing one string to another are case insensitivity and these functions
are not jibe with ansi c as above.
But how they can be portability with ANSI C or is this some kind of fake?
Oh you mean the quotation that said that stricmp(), etc. are ANSI C?
That's just wrong.
Joe Wright
>
> On Sun, 18 Jul 1999 22:44:36 +0300, Jarmo Tiittanen wrote:
> > strcmpi dos, unix, win32 and ansi c++
> > stricmp dos, unix, win16, win32, ansi c, ansi c++ and os/2
>
> stricmp() is ansi c?
>
>
--
Joe Wright mailto:cons...@infi.net
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---
Jack Klein
<j.o.ti...@dlc.fi> wrote in comp.lang.c:
> Hi,
>
> Richard Heathfield wrote:
>
> > Joel "Bisqwit" Yliluoma <bis...@iki.fi> wrote in article
> > <rcrk3.216$p15...@read2.inet.fi>...
> > > On Sun, 18 Jul 1999 22:44:36 +0300, Jarmo Tiittanen wrote:
> > > > 2. portability
> > > > strcmpi dos, unix, win32 and ansi c++
> > > > stricmp dos, unix, win16, win32, ansi c, ansi c++ and os/2
> > >
> > > stricmp() is ansi c?
> >
> > No, it isn't.
>
> How about portability with ANSI C as above or is this just some Borlands
> fake?
> I'm just curious to know this, because they said so.
>
> Well, I have one other question too.
>
> Are these all headers ANSI C standards?
> <assert.h> <ctype.h> <errno.h>
> <float.h> <limits.h> <locale.h>
> <math.h> <setjmp.h> <signal.h>
> <stdarg.h> <stddef.h> <stdio.h>
> <stdlib.h> <string.h> <time.h>
>
> Or are some of these just some Unix standardizations and they should be
> somewhere else?
>
> Regards
These are exactly the fifteen standard headers defined in the original
ANSI and ISO standards. Since then an additional three have been
added, bring the current list to eighteen:
<assert.h> <ctype.h> <errno.h> <float.h> <iso646.h> <limits.h>
<locale.h> <math.h> <setjmp.h> <signal.h> <stdarg.h> <stddef.h>
<stdio.h> <stdlib.h> <string.h> <time.h> <wchar.h> <wctype.h>
The coming update to the ANSI/ISO C standard, code named "C9X", will
be adding more.
Jack Klein
--
Home: http://home.att.net/~jackklein
New Stuff: http://home.att.net/~jackklein/newstuff.html
Updated 11-Jul-1999
Jack Klein
<j.o.ti...@dlc.fi> wrote in comp.lang.c:
> Hi,
>
> Ben Pfaff wrote:
>
> > Jarmo Tiittanen <j.o.ti...@dlc.fi> writes:
> >
> > And these function are not jibe with ANSI-standard, and
> > that's why all compilers not support them.
> >
> > In fact there is no ANSI function for comparing strings
> > case-insensitively.
>
> I know, that comparing one string to another are case insensitivity and these functions
> are not jibe with ansi c as above.
>
> But how they can be portability with ANSI C or is this some kind of fake?
They are not. It is just that Borland's help files on compatibility
contain some mistakes. Some of the functions which they claim are
ANSI/ISO standard are not, and they do not show ANSI compatibility for
some functions which are indeed standard. They seem to have made an
effort, but nobody is perfect.
Ben Pfaff
> return (unsigned char) *s1 - (unsigned char) *s2;
Shouldn't it be:
return tolower((unsigned char) *s1) - tolower((unsigned char) *s2);
?
if you try blp_strcasecmp("ab", "aC") with the original version it will
return 'b' - 'C', so > 0, when it should be < 0;
It depends on what you're planning to use it for. For my purposes it
doesn't matter. FWIW the GNU version of strcasecmp() does follow your
spec.
--
"In My Egotistical Opinion, most people's C programs should be indented six
feet downward and covered with dirt." -- Blair P. Houghton
Lawrence Kirby
j.o.ti...@dlc.fi "Jarmo Tiittanen" writes:
>Hi,
>
>Bruno Baguette wrote:
>
>> Hello,
>>
>> What is the difference between strcmpi() and stricmp() ???
>>
>> Theses functions are in the string.h include...
>>
>> Thanks in advance ! ;-)
>>
>> ----------------------------------------------------------------------------
>> --
>> Bruno Baguette (bruno.b...@francemel.com)
>
>The routine strcmpi is the same as stricmp. strcmpi is implemented through a
>macro in string.h and translates calls from strcmpi to stricmp.
Since neither of them is defined by the C language there is nothing in C
that would support this assertion.
>And of course there is a few differences between strcmpi() and stricmp()
>1. strcmpi macro is provided for compatibility with other C compilers.
Other than what? You seem to be confusing the C language with
whatever functions your particular compiler (whatever that may be)
supports.
>2. portability
> strcmpi dos, unix, win32 and ansi c++
> stricmp dos, unix, win16, win32, ansi c, ansi c++ and os/2
A couple of Unix systems I checked didn't support either function. I'd
also be very surprised if ANSI C++ did. stricmp is certainly not
an ANSI C standard library function.
--
-----------------------------------------
Lawrence Kirby | fr...@genesis.demon.co.uk
Wilts, England | 7073...@compuserve.com
-----------------------------------------
Martin Ambuhl
>
> Hello,
>
> What is the difference between strcmpi() and stricmp() ???
>
> Theses functions are in the string.h include...
Neither function is a standard C function, so you will need to read your
implementation's documentation to find out anything. It is likely that one is
just an alias for the other, catering to different implementation's different
names for non-standard functions.
Chris Torek
>>... You can use the function below if you like:
>>
>>int
>>blp_strcasecmp (const char *s1, const char *s2)
>>{
>> for (;;)
>> {
>> if (!*s1 || !*s2
>> || tolower ((unsigned char) *s1) != tolower ((unsigned char) *s2))
>> s2++;
>> }
In article <3792...@news.arrakis.es> Josep Monés i Teixidor
<jmo...@arrakis.es> writes:
>Shouldn't it be:
> return tolower((unsigned char) *s1) - tolower((unsigned char) *s2);
>?
Ah, now, see, here is where having a standard would help. :-)
Since there is no standard (as far as I can tell), you have to
write your own. Thus you can choose whichever way suits you better.
I think I would prefer Josep's myself, and would probably write:
int mystrcasecmp(const char *s1, const char *s2) {
unsigned char c1, c2;
do {
c1 = tolower(*(const unsigned char *)s1++);
c2 = tolower(*(const unsigned char *)s2++);
} while (c1 == c2 && c1 != '\0');
return c1 - c2;
}
Note that it is not necessary to test both characters for "!= '\0'",
because the three possibilities for any given pair of "unsigned char"s
taken from the two strings are:
neither is '\0' (neither string ends yet)
only one is '\0' (in which case, c1 != c2, so the loop stops)
both are '\0'
Only the last possibility requires an extra test for '\0', and since
both c1 and c2 will be '\0' in this case, you can test either.
Using tolower(), rather than toupper(), makes the function work
(for some definition of "work") the German eszet character (ß, in
ISO Latin 1), which has no uppercase equivalent, so that I have
no idea what toupper(0xdf) returns in that environment. Whether
"mystrcasecmp" should be able to compare a double (uppercase) S with
a single lowercase ß, and consider them equal, I am not sure.
(I do wonder whether other languages have upper- and/or lower-case-only
characters.)
--
In-Real-Life: Chris Torek, Berkeley Software Design Inc
El Cerrito, CA Domain: to...@bsdi.com +1 510 234 3167
http://claw.bsdi.com/torek/ (not always up) I report spam to abuse@.
Ben Pfaff
Using tolower(), rather than toupper(), makes the function work
(for some definition of "work") the German eszet character (ß, in
ISO Latin 1), which has no uppercase equivalent, so that I have
no idea what toupper(0xdf) returns in that environment. Whether
"mystrcasecmp" should be able to compare a double (uppercase) S with
a single lowercase ß, and consider them equal, I am not sure.
Isn't this sort of thing tailor-made for strxfrm() and strcoll()? It
can't occur in the C locale, after all, so only internationalized
programs need to worry about it.
Jarmo Tiittanen
Joel Bisqwit Yliluoma wrote:
> On Sun, 18 Jul 1999 22:44:36 +0300, Jarmo Tiittanen wrote:
> > 2. portability
> > strcmpi dos, unix, win32 and ansi c++
> > stricmp dos, unix, win16, win32, ansi c, ansi c++ and os/2
>
> stricmp() is ansi c?
So i have told that it's ansi c portable, but these string compare functions are
a little odd things. For example string compare functions, which not recognize
upper and lower case letters are same format as strcmp function.
And this is quite compiler issue, because most compilers are they own similar
functions.
For examples Symantec strcmpl(), Microsoft _stricmp(), Borland strcmpi() and
stricmp() and so on. And these function are not jibe with ANSI-standard, and
that's why all compilers not support them. And this phase I'm out, so I'm just
waiting someone how could explain these things to me.
> Well, the GNU libc (Linux) lacks ansi
Maybe it needs its own string comparing function?
Of course I have to say I'm not 100% sure about these thing.
Jarmo Tiittanen
Ben Pfaff wrote:
> Jarmo Tiittanen <j.o.ti...@dlc.fi> writes:
>
> And these function are not jibe with ANSI-standard, and
> that's why all compilers not support them.
>
> In fact there is no ANSI function for comparing strings
> case-insensitively.
I know, that comparing one string to another are case insensitivity and these functions
are not jibe with ansi c as above.
But how they can be portability with ANSI C or is this some kind of fake?
> You can use the function below if you like:
>
> int
> blp_strcasecmp (const char *s1, const char *s2)
> {
> for (;;)
> {
> if (!*s1 || !*s2
> || tolower ((unsigned char) *s1) != tolower ((unsigned char) *s2))
> return (unsigned char) *s1 - (unsigned char) *s2;
> s1++;
> s2++;
> }
> }
I have did lots of my own string comparing function, but this is a little different
than my, so maybe I will use this soma day.
Jarmo Tiittanen
Richard Heathfield wrote:
> Joel "Bisqwit" Yliluoma <bis...@iki.fi> wrote in article
> <rcrk3.216$p15...@read2.inet.fi>...
> > On Sun, 18 Jul 1999 22:44:36 +0300, Jarmo Tiittanen wrote:
> > > 2. portability
> > > strcmpi dos, unix, win32 and ansi c++
> > > stricmp dos, unix, win16, win32, ansi c, ansi c++ and os/2
> >
> > stricmp() is ansi c?
>
> No, it isn't.
How about portability with ANSI C as above or is this just some Borlands
fake?
I'm just curious to know this, because they said so.
Well, I have one other question too.
Are these all headers ANSI C standards?
<assert.h> <ctype.h> <errno.h>
<float.h> <limits.h> <locale.h>
<math.h> <setjmp.h> <signal.h>
<stdarg.h> <stddef.h> <stdio.h>
<stdlib.h> <string.h> <time.h>
Or are some of these just some Unix standardizations and they should be
somewhere else?
Regards
Jarmo Tiittanen
Ben Pfaff wrote:
> Oh you mean the quotation that said that stricmp(), etc. are ANSI C?
> That's just wrong.
Hmm, I think I have some idea about that now, so it's not ANSI C, but it's something else,
right.
So, I shouldn't believe everything what I read
Thank's your respond
Jarmo Tiittanen
Jack Klein wrote:
> These are exactly the fifteen standard headers defined in the original
> ANSI and ISO standards. Since then an additional three have been
> added, bring the current list to eighteen:
>
> <assert.h> <ctype.h> <errno.h> <float.h> <iso646.h> <limits.h>
> <locale.h> <math.h> <setjmp.h> <signal.h> <stdarg.h> <stddef.h>
> <stdio.h> <stdlib.h> <string.h> <time.h> <wchar.h> <wctype.h>
>
> The coming update to the ANSI/ISO C standard, code named "C9X", will
> be adding more.
Thank's your respond.
I wasn't sure about <float.h> <locale.h> <setjmp.h> <signal.h>, but now I'm
glad because there is no reason to worry about these.
Jarmo Tiittanen
Jack Klein wrote:
> On Mon, 19 Jul 1999 01:54:30 +0300, Jarmo Tiittanen
> <j.o.ti...@dlc.fi> wrote in comp.lang.c:
>
> > Hi,
> >
> > Ben Pfaff wrote:
> >
> > > Jarmo Tiittanen <j.o.ti...@dlc.fi> writes:
> > >
> > > And these function are not jibe with ANSI-standard, and
> > > that's why all compilers not support them.
> > >
> > > In fact there is no ANSI function for comparing strings
> > > case-insensitively.
> >
> > I know, that comparing one string to another are case insensitivity and these functions
> > are not jibe with ansi c as above.
> >
> > But how they can be portability with ANSI C or is this some kind of fake?
>
> They are not. It is just that Borland's help files on compatibility
> contain some mistakes. Some of the functions which they claim are
> ANSI/ISO standard are not, and they do not show ANSI compatibility for
> some functions which are indeed standard. They seem to have made an
> effort, but nobody is perfect.
I see, now this is clear as water and Borland's help files are dangerous, because it contains
lots of mistakes. Could you recommend some really good ANSI/ISO standard book, that I could
get rid of these help file messes?
That's true nobody is perfect.
By the way, you have nice homepages I visited there today ;^)
Thank you very much your good replie.
Josep Monés i Teixidor
I'm not sure, but I think that your function is not correct (see below):
Ben Pfaff escribió en mensaje <87emi5z...@pfaffben.user.msu.edu>...
[...]
>In fact there is no ANSI function for comparing strings
>case-insensitively. You can use the function below if you like:
>
>int
>blp_strcasecmp (const char *s1, const char *s2)
>{
> for (;;)
> {
> if (!*s1 || !*s2
> || tolower ((unsigned char) *s1) != tolower ((unsigned char) *s2))
> return (unsigned char) *s1 - (unsigned char) *s2;
Shouldn't it be:
return tolower((unsigned char) *s1) - tolower((unsigned char) *s2);
?
if you try blp_strcasecmp("ab", "aC") with the original version it will
return 'b' - 'C', so > 0, when it should be < 0;
> s1++;
> s2++;
> }
>}
>--
>"Large amounts of money tend to quench any scruples I might be having."
> -- Stephan Wilms
Regards,
Josep
Jack Klein
<j.o.ti...@dlc.fi> wrote in comp.lang.c:
> Hi,
>
> Jack Klein wrote:
>
> > On Mon, 19 Jul 1999 01:54:30 +0300, Jarmo Tiittanen
> > <j.o.ti...@dlc.fi> wrote in comp.lang.c:
> >
> > > Hi,
> > >
> > > Ben Pfaff wrote:
> > >
> > > > Jarmo Tiittanen <j.o.ti...@dlc.fi> writes:
> > > >
> > > > And these function are not jibe with ANSI-standard, and
> > > > that's why all compilers not support them.
> > > >
> > > > In fact there is no ANSI function for comparing strings
> > > > case-insensitively.
> > >
> > > I know, that comparing one string to another are case insensitivity and these functions
> > > are not jibe with ansi c as above.
> > >
> > > But how they can be portability with ANSI C or is this some kind of fake?
> >
> > They are not. It is just that Borland's help files on compatibility
> > contain some mistakes. Some of the functions which they claim are
> > ANSI/ISO standard are not, and they do not show ANSI compatibility for
> > some functions which are indeed standard. They seem to have made an
> > effort, but nobody is perfect.
>
> I see, now this is clear as water and Borland's help files are dangerous, because it contains
> lots of mistakes. Could you recommend some really good ANSI/ISO standard book, that I could
> get rid of these help file messes?
>
> That's true nobody is perfect.
>
> By the way, you have nice homepages I visited there today ;^)
>
> Thank you very much your good replie.
>
> Regards
See http://home.att.net/~jackklein/c/c_books.html#c_books for books I
recommend. Plaugher & Brodie is good because it comes with basically
the complete contents of the book on a set of cross-indexed HTML files
so you can use your web browser as a compiler independent online help.
If you want a good tutorial as well, King's book is the best I have
seen and has an alphabetical index of all the standard library
functions.
Kaz Kylheku
<bruno.b...@francemel.com> wrote:
>Hello,
>
>What is the difference between strcmpi() and stricmp() ???
The i has moved three characters to the right.
Richard Heathfield
<slrn7p5ea...@ashi.FootPrints.net>...
Or perhaps the difference is:
ptrdiff_t diff;
diff = stricmp - strcmpi;
:-)
[But I'll bet that subtracting one function address from another is as
illegal as a very illegal thing that breaks the law a lot and doesn't even
say sorry.]
Lawrence Kirby
...
>Using tolower(), rather than toupper(), makes the function work
>(for some definition of "work") the German eszet character (ß, in
>ISO Latin 1), which has no uppercase equivalent, so that I have
>no idea what toupper(0xdf) returns in that environment.
The standard says that if there is no uppercase equivalent it must
leave the character unchanged. The problem I suppose i how the
implementor specifies "equvalent".
> Whether
>"mystrcasecmp" should be able to compare a double (uppercase) S with
>a single lowercase ß, and consider them equal, I am not sure.
>
>(I do wonder whether other languages have upper- and/or lower-case-only
>characters.)
I believe there are. C certaintly supports such langauges.
Jarmo Tiittanen
Jack Klein wrote:
> See http://home.att.net/~jackklein/c/c_books.html#c_books for books I
> recommend. Plaugher & Brodie is good because it comes with basically
> the complete contents of the book on a set of cross-indexed HTML files
> so you can use your web browser as a compiler independent online help.
>
> If you want a good tutorial as well, King's book is the best I have
> seen and has an alphabetical index of all the standard library
> functions.
I will check your recommendations on the homepage.
I forwarded this message to me, so I'm ready to go to book shop.
This King's book sound good.
Thank' you :-)
Greg Martin
Jarmo Tiittanen wrote in message <3792671C...@dlc.fi>...
http://www.cpsc.ucalgary.ca/~dsb/C-MANUAL/index.html#Table%20of%20Contents
Very handy.
Greg Martin.
Greg Martin
Kaz Kylheku wrote in message ...
>On Sun, 18 Jul 1999 20:42:01 +0200, Bruno Baguette
><bruno.b...@francemel.com> wrote:
>>Hello,
>>
>>What is the difference between strcmpi() and stricmp() ???
>
>The i has moved three characters to the right.
Ah hah ... a wandering i!
Greg.
Jarmo Tiittanen
Greg Martin wrote:
> Hi Jarmo ... here is a URL for Plauger and Brodie's reference
> http://www.cpsc.ucalgary.ca/~dsb/C-MANUAL/index.html#Table%20of%20Contents
Thank's Greg
I bookmarked this address and I will print out these pages at school some day.
Thank's again your replie.
Richard Heathfield
I just looked up strcmpi and stricmp in Turbo C++ 2.0 where it says they
are both unique to DOS. I then looked them both up in the help files for
Borland C++ 5.02, which make it quite clear that neither function is ANSI
C. How exactly is this ***correct*** information dangerous?
It's possible that some version of Borland C++ in between these two had an
incorrect help file, but I strongly doubt it. Occam's Razor tells me
/someone/ screwed up here, but not Borland.
>
> That's true nobody is perfect.
>
I suspect that in this particular case it's not Borland who need to be
worrying about perfection.
Ben Pfaff
[...]
Here's the instruction from Borland C++ version 4.52
[...]
Portability
DOS UNIX Win 16 Win 32 ANSI C ANSI C++ OS/2
stricmp + + + + +
+ +
_fstricmp + +
[...]
You managed to show us a corrupted version of the very information
that we'd actually be interested in. Perhaps you could fix the
formatting above, so that we can tell which boxes are meant to be
checked, and then repost that part.
--
"You call this a *C* question? What the hell are you smoking?" --Kaz
Jarmo Tiittanen
Richard Heathfield wrote:
> I just looked up strcmpi and stricmp in Turbo C++ 2.0 where it says they
> are both unique to DOS. I then looked them both up in the help files for
> Borland C++ 5.02, which make it quite clear that neither function is ANSI
> C. How exactly is this ***correct*** information dangerous?
>
> It's possible that some version of Borland C++ in between these two had an
> incorrect help file, but I strongly doubt it. Occam's Razor tells me
> /someone/ screwed up here, but not Borland.
>
Here's the instruction from Borland C++ version 4.52
1.
Syntax
#include <string.h>
int stricmp(const char *s1, const char *s2);
int far _fstricmp(const char far *s1, const char far *s2)
Description
Compares one string to another, without case sensitivity.
stricmp performs an unsigned comparison of s1 to s2, starting with the first
character in each string and continuing with subsequent characters until the
corresponding characters differ or until the end of the strings is reached. The
comparison is not case sensitive.
It returns a value (< 0, 0, or > 0) based on the result of comparing s1 (or
part of it) to s2 (or part of it).
The routines stricmp and strcmpi are the same; strcmpi is implemented through a
macro in string.h that translates calls from strcmpi to stricmp. Therefore, in
order to use stricmp, you must include the header file string.h for the macro
to be available.
Return Value
If s1 is... stricmp returns a value that is...
less than s2 < 0
the same as s2 == 0
greater than s2 > 0
Portability
DOS UNIX Win 16 Win 32 ANSI C ANSI C++ OS/2
stricmp + + + + +
+ +
_fstricmp + +
2.
Syntax
#include <string.h>
int strcmpi(const char *s1, const char *s2);
Description
Compares one string to another, without case sensitivity.
strcmpi performs an unsigned comparison of s1 to s2, without case sensitivity
(same as stricmp
--implemented as a macro).
It returns a value (< 0, 0, or > 0) based on the result of comparing s1 (or
part of it) to s2 (or part of it).
The routine strcmpi is the same as stricmp. strcmpi is implemented through a
macro in string.h and translates calls from strcmpi to stricmp. Therefore, in
order to use strcmpi, you must include the header file string.h for the macro
to be available. This macro is provided for compatibility with other C
compilers.
Return Value
If s1 is... strcmpi returns a value that is...
less than s2 < 0
the same as s2 == 0
greater than s2 > 0
Portability
DOS UNIX Win 16 Win 32 ANSI C ANSI C++ OS/2
+ + + +
After this I can't say nothing why ***correct information*** is dangerous, but
I hope someone else could.
> > That's true nobody is perfect.
> >
>
> I suspect that in this particular case it's not Borland who need to be
> worrying about perfection.
I think so too.
By the way is strcmp ANSI C?
I got one webpage where they say so.
Thank's your respond
Jarmo Tiittanen
And Turbo C++ version 3.00 says same as 4.52, this is so arrgghgh.
Regards
Jarmo Tiittanen
Jarmo Tiittanen wrote:
> Hi,
>
>
>
> Portability
>
> DOS UNIX Win 16 Win 32 ANSI C ANSI C++ OS/2
> stricmp +dos +unix +16 + 32 +C +C++ +OS/2
> _fstricmp +dos +16
>
> Portability
>
> DOS UNIX Win 16 Win 32 ANSI C ANSI C++ OS/2
>
> +dos +unix +32 +C++
Now it's a little more clear.
Tom Torfs
JT> And Turbo C++ version 3.00 says same as 4.52, this is so arrgghgh.
Borland C++ 3.0 says:
+ DOS + UNIX + Windows + ANSI C + C++ Only +
strcmp | Yes | Yes | Yes | Yes | |
strcmpi | Yes | | Yes | | |
strnicmp | Yes | | Yes | | |
_fstrcmp | Yes | | Yes | | |
_fstrnicmp | Yes | | Yes | | |
+=====+======+=========+========+==========+
So I believe you are mistaking.
greetings,
Tom
tomt...@village.uunet.be
Noone Really
> >(I do wonder whether other languages have upper- and/or lower-case-only
> >characters.)
>
> I believe there are. C certaintly supports such langauges.
In fact there are languages with more `cases' than that. Usually, one
thinks of three cases as the general case: lower case, upper case and
title case (th, TH and Th are the closest in English if th were treated
as one character). Of course, there are also languages where the glyph
for a letter changes in some positions (e.g. sigma in Greek at the end),
but these are not considered `cases' conventionally.
---
Jarmo Tiittanen
Tom Torfs wrote:
Yes you right
File Edit Search Run Compile Debug Project Options Window
Help
+-[_]-------------------------------- Help
------------------------------1-[ ]-+
¦ Return
Value:
¦ These routines return an int value that
is _
¦ _ < 0 if s1 <
s2 _
¦ _ == 0 if s1 ==
s2 _
¦ _ > 0 if s1 >
s2 _
¦
_
¦
Portability:
_
¦ + DOS Ð UNIX Ð ANSI C Ð C++ Only
+ _
¦ strcmp ¦ Yes ¦ Yes ¦ Yes ¦
¦ _
¦ strcmpi ¦ Yes ¦ ¦ ¦
¦ _
¦ strnicmp ¦ Yes ¦ ¦ ¦
¦ _
¦ _fstrcmp ¦ Yes ¦ ¦ ¦
¦ _
¦ _fstrnicmp ¦ Yes ¦ ¦ ¦
¦ _
¦
+-----¤------¤--------¤----------+ _
¦
_
¦ See
Also: _
¦ _fstrncmp and _fstrnicmp strncmp, strncmpi, and
strnicmp _
¦
_
¦
Examples:
_
¦ strcmp example strcmpi example stricmp
example _
¦
+- __________________________________________________________________________ -+
F1 Help on help Alt-F1 Previous topic Shift-F1 Help index Esc Close
help
rajeev...@my-deja.com
strcmp() - Does not ignore the case of the 2 strings
to be compared.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
Jarmo Tiittanen
Ben Pfaff wrote:
> Jarmo Tiittanen <j.o.ti...@dlc.fi> writes:
>
> [...]
> Here's the instruction from Borland C++ version 4.52
> [...]
> Portability
>
> DOS UNIX Win 16 Win 32 ANSI C ANSI C++ OS/2
> stricmp + + + + +
> + +
> _fstricmp + +
> [...]
>
> You managed to show us a corrupted version of the very information
> that we'd actually be interested in. Perhaps you could fix the
> formatting above, so that we can tell which boxes are meant to be
> checked, and then repost that part.
Okey, here they are
stricmp dos, unix, win16, win32, ansi c, ansi c++ and os/2
_fstricmp dos and win16
strcmpi dos, unix, win32 and ansi c++
Actually I'm totally sick this issue now, because it came one stupid
play.
But I'm glad that learnt some new things.
Thank's to you and everybody else and Thank's your respond.
Sunil Rao
> 2. portability
stricmp() is not a standard function - neither in C nor in (off-topic
already) C++. It's not as simple as you might think at first when you
consider international character sets. Not so sure about your unix
portability - my system here has a strcasecmp() (from BSD 4.3) but no
stricmp() or strcmpi().
--
{ Sunil Rao }
"In my opinion, I think that an author when he is writing should
definitely not get into the habit of making use of too many
unnecessary words that he does not really need in order to put his
message across." - George L Trigg, Phys. Rev. Lett. 42748 (1979).
Sunil Rao
> > Hi Jarmo ... here is a URL for Plauger and Brodie's reference
> > http://www.cpsc.ucalgary.ca/~dsb/C-MANUAL/index.html#Table%20of%20Contents
>
> Thank's Greg
>
> I bookmarked this address and I will print out these pages at school some day.
http://www.cpsc.ucalgary.ca/~dsb/C-MANUAL/crit_pb.html suggests that Don
S Bidulock is breaking the law by putting it up on the web for everybody
to use. Making your own copies is explicitly illegal.
There's a legal version you can access online from
http://www.dinkum.com/refxc.html - but you cannot legally make
electronic or paper copies.
Richard Heathfield
> strcmpi() - Ignores case while comparing
> strcmp() - Does not ignore the case of the 2 strings
> to be compared.
...except in Zog C v3.141, where strcmpi Searches Trees Recursively
Checking Major Pointer Incompatibilities, and in Futon C v1.04, where
strcmpi simply calculates the standard deviation of its arguments.
Since strcmpi is not an ANSI C function, these implementations (and any
others similarly unconnected with string comparison) are quite legal.
Lew Pitcher
except for the fact that strcmpi() intrudes on the str* namespace reserved
for other standard string functions. In other words, strcmpi() may not be
a supported function *now*, but the _name_ is reserved for future use.
>
>--
>Richard Heathfield
>
>The bug stops here.
>
Lew Pitcher
System Consultant, Integration Solutions Architecture
Toronto Dominion Bank
(Opinions expressed are my own, not my employer's.)
Richard Heathfield
<3794b7f6....@news.bellglobal.com>...
> On 20 Jul 1999 19:11:31 +0100, "Richard Heathfield"
<comp...@eton.powernet.co.uk> wrote:
>
> >rajeev...@my-deja.com wrote in article
<7n1qhe$qf2$1...@nnrp1.deja.com>...
> >> strcmpi() - Ignores case while comparing
> >> strcmp() - Does not ignore the case of the 2 strings
> >> to be compared.
> >
> >...except in Zog C v3.141, where strcmpi Searches Trees Recursively
> >Checking Major Pointer Incompatibilities, and in Futon C v1.04, where
> >strcmpi simply calculates the standard deviation of its arguments.
> >
> >Since strcmpi is not an ANSI C function, these implementations (and any
> >others similarly unconnected with string comparison) are quite legal.
> except for the fact that strcmpi() intrudes on the str* namespace
reserved
> for other standard string functions. In other words, strcmpi() may not be
> a supported function *now*, but the _name_ is reserved for future use.
>
Quite right. That point keeps coming back, doesn't it? But of course, if
it's reserved so that Zog C can't use it, it's also reserved so that no
other compiler can use it. Therefore to advise on its use is ***even
more*** wrong than I had claimed.
Richard Heathfield
<snip>
>
> Actually I'm totally sick this issue now, because it came one stupid
> play.
Well, I'm afraid you're about to get (a little bit) sicker. I just went to
the trouble of installing my old copy of Borland C++ 4.5, so that I could
check on its compatibility settings for strcmpi. And, as I suspected, it
does NOT list ANSI C amongst its portability options for strcmpi.
BUT it /does/ list ANSI C portability for stricmp! So you were partly
right; the help file does indeed include an error. Furthermore, Borland C++
5.02 (on closer inspection) has exactly the same problem - it lists stricmp
as ANSI C (but not strcmpi).
> But I'm glad that learnt some new things.
And so did I. Well, one new thing anyway. And I probably owe you an apology
for not checking more closely first time around.
Time for me to fire off a snotty posting to
news:borland.public.cpp.language, I think. ;-)
Jarmo Tiittanen
Richard Heathfield wrote:
> Jarmo Tiittanen <j.o.ti...@dlc.fi> wrote in article
> <37948D14...@dlc.fi>...
>
> <snip>
> >
> > Actually I'm totally sick this issue now, because it came one stupid
> > play.
>
> Well, I'm afraid you're about to get (a little bit) sicker. I just went to
> the trouble of installing my old copy of Borland C++ 4.5, so that I could
> check on its compatibility settings for strcmpi. And, as I suspected, it
> does NOT list ANSI C amongst its portability options for strcmpi.
If I recall right I haven't ever said that strcmpi is mentioned anywhere as
portability with ANSI C.
> BUT it /does/ list ANSI C portability for stricmp! So you were partly
> right; the help file does indeed include an error. Furthermore, Borland C++
> 5.02 (on closer inspection) has exactly the same problem - it lists stricmp
> as ANSI C (but not strcmpi).
This was my problem, but now I knew, I shouldn' believe all what I have read.
Oh, I just read all my messages again which concern this issue and I sure now
that I haven't ever said strcmpi is portable with ANSI C or what ever.
> > But I'm glad that learnt some new things.
>
> And so did I. Well, one new thing anyway. And I probably owe you an apology
> for not checking more closely first time around.
No you don't, because this help file mistake was very educational and somehow
funny too.
> Time for me to fire off a snotty posting to
> news:borland.public.cpp.language, I think. ;-)
;-)
Thank's your respond
Jarmo Tiittanen
As Richard said " I'm afraid you're about to get (a little bit) sicker", and now
I have to say I got much more sicker after read these two message.
;-)
Jarmo Tiittanen
Sunil Rao wrote:
> Jarmo Tiittanen wrote:
> > 2. portability
> > strcmpi dos, unix, win32 and ansi c++
> > stricmp dos, unix, win16, win32, ansi c, ansi c++ and os/2
>
> stricmp() is not a standard function - neither in C nor in (off-topic
> already) C++.
Why it's off-topic already, I can't understand?
> It's not as simple as you might think at first when you
> consider international character sets. Not so sure about your unix
> portability - my system here has a strcasecmp() (from BSD 4.3) but no
> stricmp() or strcmpi().
As the original message was " Difference between strcmpi() and stricmp()
?",
before this question I didn't know that Borlands help file is a some
stupid error.
Niklas Matthies
> On 20 Jul 1999 19:11:31 +0100, "Richard Heathfield" <comp...@eton.powernet.co.uk> wrote:
>>Since strcmpi is not an ANSI C function, these implementations (and any
>>others similarly unconnected with string comparison) are quite legal.
> except for the fact that strcmpi() intrudes on the str* namespace reserved
> for other standard string functions. In other words, strcmpi() may not be
> a supported function *now*, but the _name_ is reserved for future use.
One thing just occurred to me: Since case sensitivity is not guaranteed
for external linkage, does this mean that STR*, Str* etc. are also
reserved? At least in the sense that writing a function named StrFoo()
with external linkage could collide with a future ANSI C library function
strfoo()? Oh my.
-- Niklas
Kaz Kylheku
>One thing just occurred to me: Since case sensitivity is not guaranteed
>for external linkage, does this mean that STR*, Str* etc. are also
>reserved? At least in the sense that writing a function named StrFoo()
>with external linkage could collide with a future ANSI C library function
>strfoo()? Oh my.
You deduced correctly. Writing a function called StrFoo() is not strictly
conforming.
Also, since linkage may be restricted to considering only the first six letters
of each external name, writing a function or object called printfoo is also not
strictly conforming. This is the same as printf in the first six characters.
Michael Rubenstein
wrote:
>On 20 Jul 1999 19:11:31 +0100, "Richard Heathfield" <comp...@eton.powernet.co.uk> wrote:
>
>>rajeev...@my-deja.com wrote in article <7n1qhe$qf2$1...@nnrp1.deja.com>...
>>> strcmpi() - Ignores case while comparing
>>> strcmp() - Does not ignore the case of the 2 strings
>>> to be compared.
>>
>>...except in Zog C v3.141, where strcmpi Searches Trees Recursively
>>Checking Major Pointer Incompatibilities, and in Futon C v1.04, where
>>strcmpi simply calculates the standard deviation of its arguments.
>>
>>Since strcmpi is not an ANSI C function, these implementations (and any
>>others similarly unconnected with string comparison) are quite legal.
>except for the fact that strcmpi() intrudes on the str* namespace reserved
>for other standard string functions. In other words, strcmpi() may not be
>a supported function *now*, but the _name_ is reserved for future use.
That's clearly the intent, but the standard doesn't actually
prohibit an implementation from defining such identifiers at
file scope or with extern linkage in any way it wishes as long as
it is not declared in any standard header except those that the
for which the standard reserves it. I consider it imprudent for
an implementation to use such identifiers, but the list of
prudent implmeentors is very small.
--
Michael M Rubenstein
Michael Rubenstein
Fortunately, we shouldn't have to live with these anachronism's
too much longer -- they are removed from C9X.
--
Michael M Rubenstein
Richard Stamp
>stricmp() is not a standard function - neither in C nor in (off-topic
>consider international character sets.
I've always found that argument rather weak, given that toupper() and
tolower() exist. There's a natural definition of stricmp()/strcmpi()/
strcasecmp() in terms of toupper() and strcmp().
One argument against stricmp() is that it's unclear why strcmp() deserves
this special treatment -- why don't we have strichr(), stristr(), stripbrk()
etc. etc. All the same it seems a marginally surprising omission to me.
Cheers,
Richard
Tom Torfs
RS> I've always found that argument rather weak, given that toupper()
RS> and tolower() exist. There's a natural definition of
RS> stricmp()/strcmpi()/ strcasecmp() in terms of toupper() and
RS> strcmp().
But as recent disagreement has pointed out, different people have different
opinions about what this "natural" str...cmp() should return. There are
basically 3 possibilities: (casts omitted for simplicity)
1) c2 - c1
2) toupper(c2) - toupper(c1)
3) tolower(c2) - tolower(c1)
And these may behave differently in several locales (of course using
strcoll() would solve these problems, but one can hardly define a regular
str...cmp() function in terms of strcoll(), IMO).
(number 1 can easily be dismissed but the 2 other ones may behave
differently as well)
greetings,
Tom
tomt...@village.uunet.be
Richard Stamp
>Richard Stamp wrote in a message to Sunil Rao:
> RS> stricmp()/strcmpi()/ strcasecmp() in terms of toupper() and
> RS> strcmp().
>
>But as recent disagreement has pointed out, different people have different
>opinions about what this "natural" str...cmp() should return.
That's true -- I'd missed this part of the discussion.
Cheers,
Richard
Sunil Rao
It's also concceivable (though admittedly improbable) that the
"uppercase" version of a string might not simply be the same as ther
string formed by "uppercasing" all of its characters. I don't know much
about foreign-language scripts, though.
--
{ Sunil Rao }
"...certainly no beast has essayed the boundless, infinitely
inventive art of human hatred. No beast can match its range and
power." - Arundhati Roy, "The God of Small Things", 1997.
Tom Torfs
> > RS> There's a natural definition of stricmp()/strcmpi()/
> > RS> strcasecmp() in terms of toupper() and strcmp().
> >But as recent disagreement has pointed out, different people have
> >different opinions about what this "natural" str...cmp() should
> >return.
> That's true -- I'd missed this part of the discussion.
SR> It's also concceivable (though admittedly improbable) that the
SR> "uppercase" version of a string might not simply be the same as
SR> ther string formed by "uppercasing" all of its characters. I don't
SR> know much about foreign-language scripts, though.
However, I would consider that an argument in favor of adding a
case-ignoring strcmp() as well as functions for uppercasing and lowercasing
strings (but then of course not defined in terms of toupper(), as Richard
suggested).
greetings,
Tom
tomt...@village.uunet.be
Dik T. Winter
> Sunil Rao wrote in a message to Richard Stamp:
> SR> "uppercase" version of a string might not simply be the same as
> SR> ther string formed by "uppercasing" all of its characters. I don't
> SR> know much about foreign-language scripts, though.
>
> However, I would consider that an argument in favor of adding a
> case-ignoring strcmp() as well as functions for uppercasing and lowercasing
> strings (but then of course not defined in terms of toupper(), as Richard
> suggested).
I think not. The function 'strcmp' is defined in terms of the type 'char',
a case independent compare can not be performed in those terms in some
locales (think about the German es-zet, which has no single character
upper-case equivalent).
For a true case independent compare 'strcoll' in the appropriate locale
is better.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/
mmb
hi,
http://www.rzuser.uni-heidelberg.de/~jr4/cgi-bin/precse.cgi
I have a feedback-script coming from the URL above.
http://www.rzuser.uni-heidelberg.de/~jr4/cgi-bin/precogefb.c
Somehow, for a reason I don't understand, it is calculating the wrong
number for the number of the picture.
It is always the same constant number 5368730, that is too much, but when
I am subtracting it, it is still the same.
That means, I always get the same wrong result, whether I am writing:
if(cchoice==vpchoice-5368730) or just
if(cchoice==vpchoice)
Does someone wants to take a look at?
sincerely,
--- mmb
Mark McIntyre
2) Anyway your URL points to your programme not your code. Doh!
3) Your question had better be ANSI C related, after all that!
On Fri, 1 Oct 1999 19:31:13 +0200, mmb <j...@ix.urz.uni-heidelberg.de>
wrote:
Ryan Malcolm Adams
Hello there,
I was wondering if anybody could tell whether using a switch statement
would lead to faster code than a - if ... else if ... else if - type
affair?
Thanks!
Ryan
Charles
Ryan Malcolm Adams <shs9...@reading.ac.uk> wrote in message
news:Pine.SOL.3.95q.99100...@sumb1.reading.ac.uk...
Dann Corbit
news:37f5...@news.toast.net...
On the other hand...
The C language does not define the speed of these things, nor how they are
implemented.
Consider the following:
if (foo)
foofoo();
else if (bar) barbar();
else foobar();
Now, suppose that (foo) happens 99.9% of the time? A simple test might be
faster than a switch.
In general, a switch will probably do better when there are a pile of
labels. But don't count on it.
In any case, you are an *IDIOT* if you write one construct or the other
because you think it will be faster.
*******************************************************************
WRITE THE CODE THAT IS CLEAR AND EXPRESSES THE MEANING UNAMBIGUOUSLY OF THE
ALGORITHMS IMPLEMENTED FOR CRYING OUT LOUD.
*******************************************************************
Then, when you are all done, if it is too slow for specifications, look at
ways to speed it up. AND THE LAST THING YOU SHOULD BE LOOKING FOR IS
"SHOULD I USE A SWITCH OR A BUNCH OF IFS.
There. I've had my little scream and I feel a lot better.
--
C-FAQ: http://www.eskimo.com/~scs/C-faq/top.html
"The C-FAQ Book" ISBN 0-201-84519-9
C.A.P. Newsgroup http://www.dejanews.com/~c_a_p
C.A.P. FAQ: ftp://38.168.214.175/pub/Chess%20Analysis%20Project%20FAQ.htm
Pachiano, Vince
"It Depends"
I have seen some compilers build a giant, and sparse jump table.
This is fast, but may have many null entries
On others, I have seen case statements simply coded as a series of
if - else if statements.
Marcin Gryszkalis [dagoon/cryogen]
> > > I was wondering if anybody could tell whether using a switch statement
> > > would lead to faster code than a - if ... else if ... else if - type
> > > affair?
> No wait! An if()...
> On the other hand...
> The C language does not define the speed of these things, nor how they are
> implemented.
Another question but similar - what is faster:
1:
for (long loop)
{
if ()
call proc1()
else
call proc2()
}
2:
if ()
proc=proc1
else
proc=proc2
for (long loop)
{
call proc
}
Was a surprise to ma that [1] is over 20% faster (i386, Watcom C)
- do you have any idea why?
thanks
Marcin
.d$$$$b, $d$$$$b. .d$$$$b, Marcin Gryszkalis
$$' `"" $$' `"' $$' `$$ Dagoon of Cryogen
$$. .ss $$ $$ $$ dag...@abyss.lodz.pdi.net
`"8$$8"' 88 88 88 dag...@rs.math.uni.lodz.pl
Steven Huang
[...]
> Another question but similar - what is faster:
> 1:
> for (long loop)
> {
> if ()
> call proc1()
> else
> call proc2()
> }
> 2:
> if ()
> proc=proc1
> else
> proc=proc2
> for (long loop)
> {
> call proc
> }
> Was a surprise to ma that [1] is over 20% faster (i386, Watcom C)
> - do you have any idea why?
Absolutely not, without knowing what's in proc1(), proc2(), and the
condition of the for loop. All you're saying is that some if
conditions are faster than calling a function through a pointer. No
generalization is possible.
Ray Dunn
>Another question but similar - what is faster:
>
>1:
>
>for (long loop)
> {
> if ()
> call proc1()
> else
> call proc2()
> }
>
>2:
>
>if ()
> proc=proc1
>else
> proc=proc2
>for (long loop)
> {
> call proc
> }
>
>Was a surprise to ma that [1] is over 20% faster (i386, Watcom C)
> - do you have any idea why?
I can guess, but you can find out, by looking at the assembler output
using your debugger - you probably don't need to understand the
exact meaning of each instruction to be able to roughly estimate
relative speed of the two versions.
My guess is that the difference in speed of the code to call a function
variable over a "normal" call, is more than that of the code of the
conditional.
To answer the original question about switch and if-else's. It depends.
However a general rule is that the more alternatives there are, the more
likely that the switch will be faster, but usually only if the cases
specify a contiguous range of values. If the case values are disjoint,
there will probably be no significant difference.
Remember also, that if the most frequent path through the logic is that
the first condition is TRUE, then the if-else version will probably
average to be faster. Hint: order your condtions so the the most likely
come first.
[Note the "probably", "usually" - there are too many variables to be
categorical]
--
Ray Dunn
Montreal
ray...@canada.com
Harlan Brown
C also. I have written some real time data aquistion programs where speed
was important. Unfortunatly the company that I worked for required that I
use VB for most of the applications. Ironic huh. It is my experience that
the Switch statement is faster than the if, else if. I have done some
experiments where I have timed functions using these structs with a ms
timer. How the code that these statements are used in is written is a factor
though.
Harlan Brown
har...@gte.net
Marcin Gryszkalis [dagoon/cryogen] <dag...@rs.math.uni.lodz.pl> wrote in
message news:Pine.A41.3.96.991006...@rs.math.uni.lodz.pl...
> > > > Hello there,
> > > > I was wondering if anybody could tell whether using a switch
statement
> > > > would lead to faster code than a - if ... else if ... else if -
type
> > > > affair?
> > > A switch statement.
> > No wait! An if()...
> > On the other hand...
> > The C language does not define the speed of these things, nor how they
are
> > implemented.
>
> Another question but similar - what is faster:
>
> 1:
>
> for (long loop)
> {
> if ()
> call proc1()
> else
> call proc2()
> }
>
> 2:
>
> if ()
> proc=proc1
> else
> proc=proc2
> for (long loop)
> {
> call proc
> }
>
> Was a surprise to ma that [1] is over 20% faster (i386, Watcom C)
> - do you have any idea why?
>
Scott McMahan
> I was wondering if anybody could tell whether using a switch statement
> would lead to faster code than a - if ... else if ... else if - type
> affair?
It depends on the compiler. For the equivalent either should
generate the same code, but there are things you can
do in if/else you can't do in switch statements.
Scott
Joe Maun
"Marcin Gryszkalis [dagoon/cryogen]" wrote:
>
[..]
>
> Another question but similar - what is faster:
>
> 1:
>
> for (long loop)
> {
> if ()
> call proc1()
> else
> call proc2()
> }
>
> 2:
>
> if ()
> proc=proc1
> else
> proc=proc2
> for (long loop)
> {
> call proc
> }
>
> Was a surprise to ma that [1] is over 20% faster (i386, Watcom C)
> - do you have any idea why?
Perhaps. Consider it is quite possible the compiler moved the if / else
in [1] out of the loop all by itself (depending on what the condition
was), thus turning [1] into:
for(long loop)
proc1();
--
Joe
Chris Torek
Marcin Gryszkalis [dagoon/cryogen] <dag...@rs.math.uni.lodz.pl> writes
[vertically compressed by me]:
>Another question but similar - what is faster:
>
>1:
> for (long loop)
> if () call proc1()
> else call proc2()
>
>2:
> if () proc=proc1
> else proc=proc2
> for (long loop)
> call proc
>
Would it also surprise you to find that:
for (long loop)
a();
is 20% faster (or slower) than:
for (long loop)
a();
? (Yes, those are utterly identical source fragments.) If this
*is* surprising, you have not had enough experience with funny
things like cache effects. :-) (Perhaps the code got recompiled
with the current library, which put the data at a slightly different
address, etc. Some compilers have optimization options in which
you feed the compiler a data file produced by running your program
as compiled with another compiler option, so that the compiler can
observe the program's actual runtime access patterns and move the
data to "cache-friendly" locations.)
In general, you should write your code in whatever way is *clearest*
(to the people who will maintain it), and then tune it for speed
only if/when it turns out to be too slow. One of the interesting
things about this is that "clearest" is often quite fast as well,
because omitting needless fluff makes code clearer, and the fastest
code is the code that is not there at all. (Something you never do
always takes no time to do.)
(Of course, there are times when "simple" and/or "clear" turn out
to be slow and you have to come up with some awful mess. But those
are ... not as frequent as people come up with awful messes, anyway.)
--
In-Real-Life: Chris Torek, Berkeley Software Design Inc
El Cerrito, CA Domain: to...@bsdi.com +1 510 234 3167
http://claw.bsdi.com/torek/ (not always up) I report spam to abuse@.
Fabien LE LEZ
>(Of course, there are times when "simple" and/or "clear" turn out
>to be slow and you have to come up with some awful mess. But those
>are ... not as frequent as people come up with awful messes, anyway.)
... and if a piece of code seems to be too slow, put it between /* and
*/ before typing the new version : if the reader can't understand the
fast-but-obscure version, he'll have the slow-but-readable version to
help him.