which one is better

[DaVinci]

Is #define STREQL(x,y) ((*x == *y)&&(strcmp((x),(y))==0)) is bettern
than STREQL(x,y) (strcmp((x),(y))==0).why?

 

[Michael Mair]

Is #define STREQL(x,y) ((*x == *y)&&(strcmp((x),(y))==0)) is bettern
than STREQL(x,y) (strcmp((x),(y))==0).why?

In which respect?
Tell us what _you_ think.
If this is a homework question, consider just admitting it.

Note that the former may break because you forgot to put x and
y in parentheses and, even if you had not, because x and y are
replaced twice by macro expansion which breaks for x and y that
have side effects.


Cheers
Michael

 

[Richard Bos]

Is #define STREQL(x,y) ((*x == *y)&&(strcmp((x),(y))==0)) is bettern
than STREQL(x,y) (strcmp((x),(y))==0).why?

Yes. No. Because. Depends.

What do you _want_ from this macro? That's the important thing.

Richard

 

[Frederick Gotham]

DaVinci posted:

Is #define STREQL(x,y) ((*x == *y)&&(strcmp((x),(y))==0)) is bettern
than STREQL(x,y) (strcmp((x),(y))==0).why?

The first macro checks whether the first characters are the same. If they
aren't, then it returns. If they are, then it invokes strcmp to check
whether the entire strings are equal. It's taking advantage of "short-
circuit evaluation". To avoid multiple evaluation, it could be rewritten
as:

#include <string.h>

char const *STREQL_str1,*STREQL_str2;

#define STREQL(x,y) \
(STREQL_str1 = (x),STREQL_str2 = (y), \
*STREQL_str1 == *STREQL_str2 \
&& !strcmp(STREQL_str1,STREQL_str1))

The second macro simply calls strcmp.

Which one is more efficient will be dependant upon:

(1) The efficiency of the strcmp algorithm
(2) The amount of strings tested which are actually equal.
(3) The amount of strings tested which have the same initial character.
(4) Other stuff specific to the implementation.

If you want to test it on your own system, then run each of them in a loop
several thousand times and time them.

 

[Ben Pfaff]

To avoid multiple evaluation, it could be rewritten as:

#include <string.h>

char const *STREQL_str1,*STREQL_str2;

#define STREQL(x,y) \
(STREQL_str1 = (x),STREQL_str2 = (y), \
*STREQL_str1 == *STREQL_str2 \
&& !strcmp(STREQL_str1,STREQL_str1))

The second macro simply calls strcmp.

I wouldn't recommend doing that. It's not reentrant and it uses
global variables. It's likely to cause surprises later. Instead
of doing that, I'd suggest just writing out the strcmp() call
explicitly where you need to compare strings. Then, later, if
profiling shows that one of those strcmp() calls is a hot spot,
add the short-circuit test in-line where it is needed.

 

[Fred Kleinschmidt]

Is #define STREQL(x,y) ((*x == *y)&&(strcmp((x),(y))==0)) is bettern
than STREQL(x,y) (strcmp((x),(y))==0).why?

It seems silly to even consider such a macro.

In your code, to use the macro, you would have to write:
if ( STREQL( str1, str2 ) ) {
...
}

when you could dispense with the macro altogether and just write
if ( strcmp( str1, str2 ) == 0 ) {
...
}

or even
if ( !strcmp( str1, str2 ) ) {
...
}

 

[websnarf]

Is #define STREQL(x,y) ((*x == *y)&&(strcmp((x),(y))==0)) is bettern
than STREQL(x,y) (strcmp((x),(y))==0).why?

This will depend largely on the scenario.

In the first macro, there is reference made to x and y twice. This
means that there are cases where the two macros do not behave
equivalently (consider the case when x is ++p, for example).

In the majority of cases they should behave equivalently, so there is
just the question of speed. The first macro may seem to save you a
function call, which is good if the strings are typically not equal in
the first character. However, the compiler may inline and perform this
optimization (or the equivalent) for you when using the second macro
automatically anyways. You might go ahead and time it on a few
scenarios -- I think it may vary a lot depending on both the compiler
and scenario.

 

[goose]

Is #define STREQL(x,y) ((*x == *y)&&(strcmp((x),(y))==0)) is bettern
than STREQL(x,y) (strcmp((x),(y))==0).why?

I should think that there isn't a difference. Just
call strcmp(x,y). I'd expect strcmp to return
immediately if the first characters of the string
differs anyway.

In fact, now that I think about it, the first one
actually should be almost insignificantly slower
in most general cases, defeating the obvious
purpose of short-circuiting (and avoiding a call
to strcmp) because the first character of each
string is going to be tested *and* a call will
be made to strcmp (in the general case, of course

 

[jaysome]

I wouldn't recommend doing that. It's not reentrant and it uses
global variables. It's likely to cause surprises later. Instead
of doing that, I'd suggest just writing out the strcmp() call
explicitly where you need to compare strings. Then, later, if
profiling shows that one of those strcmp() calls is a hot spot,
add the short-circuit test in-line where it is needed.

Ben gives good advice.

In my experience, over-optimization can be the root of all evil.

Although the following link uses Windows-specific WIN32 function calls
to illustrate the author's point, it nevertheless illustrates concepts
that apply in a broad general sense.

http://www.flounder.com/optimization.htm

Best regards

 

[Michael Wojcik]

In fact, now that I think about it, the first one
actually should be almost insignificantly slower
in most general cases, defeating the obvious
purpose of short-circuiting (and avoiding a call
to strcmp) because the first character of each
string is going to be tested *and* a call will
be made to strcmp (in the general case, of course

Plus, the macro misses out on the further delicious pessimization of
testing for pointer equality:

#define WORSE_STREQL(x,y) ((x) == (y) || \
((*(x) == *(y)) && \
(strcmp((x),(y)) == 0)))

which would be a net win if you very frequently compare two strings
that are actually the same object, and function calls are really
expensive in your implementation, and you never use the macro with
parameters that have side effects, and you compare strings in the
inner loop, and your program is very performance sensitive, and...

Oh, from the fan the feces flies,
When we first try to optimize.

(And they say the US has no tradition of light verse.)

--
Michael Wojcik (e-mail address removed)

Pocket #16: A Ventriloquist's "Helper" -- Recordings for Divers Occasions,
especially cries to put in the mouths of enemies -- "God Bless Captain
Vere!" "Les jeux sont faits!" &c. -- Joe Green

 

[Eric Sosman]

Plus, the macro misses out on the further delicious pessimization of
testing for pointer equality:

#define WORSE_STREQL(x,y) ((x) == (y) || \
((*(x) == *(y)) && \
(strcmp((x),(y)) == 0)))

Just as a by-the-way, I once encountered a strcmp() that
performed this optimization internally, returning zero almost
immediately if its two pointer arguments were equal. I suspect
(but did not verify) that this wasn't because of an explicit
test for equality, but something that "fell out" of other tests
to determine whether the strings' alignments permitted comparing
them in four- or eight-byte chunks rather than byte-by-byte.