optimizing an expression

[Ben Pfaff]

That, OTOH, seems overkill to me; all you should need (as well as what
you need at the very least) is

printf(ngettext("I see %u ships.\n", nship), nship);

What you need is the properly internationalised text for "I see N
ship(s)." The _internationalisation_ library should not need to know
that the _English_ singular for ships is ship. (Unless, of course, your
local language is English; but in that case, _it_ should give you that
English singular, and not rely on the user-programmer to specify it for
that language alone.)

Your approach makes it impossible to produce grammatical output
in any language at all on a system that lacks functioning i18n
libraries and message catalogs (and being able to locate and read
the message catalogs at runtime), whereas with the approach
actually used this is as simple as invoking a stub of the form
"return n == 1 ? singular : plural;".

 

[bartc]

Your approach makes it impossible to produce grammatical output
in any language at all on a system that lacks functioning i18n
libraries and message catalogs (and being able to locate and read
the message catalogs at runtime), whereas with the approach
actually used this is as simple as invoking a stub of the form
"return n == 1 ? singular : plural;".

Or you can just use:

printf("I see %u ship(s).\n",nships);

This is the approach of Vista, so it must be OK.

 

[Tim Rentsch]

Can you lay off "the isn't worthy of being called a programmer"
schtick. It's incredibly patronising.

My comments were no more patronizing or condescending than the
comments of yours (snipped out of your reply) that I was
responding to.

I've never argued about programmers who "can" or "can't".
Comprehension is not a binary "can comprehend" and "can't comprehend".
I can comprehend the writing of JK Rowling and James Joyce, but one
of them is lot less work. But, I'd like to think that good
programmers would strive to be more like the former than the latter.
Good authors, maybe not.

This analogy misses the point, IMO, in several different ways.
C has a precise semantics; English does not. All programmers
write code as well as read it, whereas readers of English typically
don't also write, at least not on the scale of whole books.
Moreover the difference in scale makes the offered comparison
rather pointless -- in code the writing under consideration
is one "clause" of one "sentence", but the books are many
chapters of many paragraphs of (usually) multiple sentences
each. A better analogy would be to ask if someone understands
the difference between a restrictive clause and a non-restrictive
clause, which any competent writer will.

I can read comprehend ?:, and in simple expressions it can be much
more eloquent. There are places where the brevity of ?: gives a
program extra clarity for the reader. But when the expressions are
complex that clarity is lost, comprehension becomes much harder work
and the only gain is a little less typing. That's a poor tradeoff, if
your code is ever to be maintained by people less eloquent in C than
yourself.

If you'll recall the comments in your earlier posting were
written in response to the text

(upthread)>> [... on expressions like 'a = b ? c : d' ...]

So the comments above need to be made a bit more explicit
if you want them to convey any significant amount of useful
information.

My point is merely this. If I use ?: in complex expressions, what is
the benefit and what do I gain?

That isn't a point, it's a question. If the posting had asked a
question (and meant it as a question) the response/answer to it
would have been quite different. Of course it's often true that
people ask rhetorical questions as a way of making a point
rather than meaning it as a question. In my experience this
usually means either that they don't really know just what
their point is or they're afraid to say it straight out
because if said directly the ridiculousness of the comment
would be obvious. So if there's something you want to
say (or a question you want to ask), my advice is to
say it (or ask it) clearly and directly.

 

[Tim Rentsch]

"user923005" <[email protected]> ha scritto nel messaggio
[snip performance questions]

typedef int e_type;

e_type median3(e_type a, e_type b, e_type c)
{
return (a < b) ? ((b < c) ? b : ((a < c) ? c : a)) : ((a < c) ?
a : ((b < c) ? c : b));
}

what about
e_type medianr(e_type a, e_type b, e_type c)
{e_type r;
if(a>c) {r=a, a=c, c=r;}
if(a>b) {r=a, a=b, b=r;}
if(c<b) {r=c, c=b, b=r;}
return b;
}

In all these different variations of median, it's suprising that
no one has emphasized obviousness of correctness. For example,

...
#define CHECK(a,b,c) do if ((a)<=(b) && (b)<=(c)) return (b); while(0)
CHECK(a,b,c);
CHECK(a,c,b);
CHECK(b,a,c);
CHECK(b,c,a);
CHECK(c,a,b);
CHECK(c,b,a);
assert(0);
return 0;
#undef CHECK

or instead using the return form

#define CHECK(a,b,c) ((a)<=(b) && (b)<=(c)) ? (b)
return CHECK(a,b,c)
: CHECK(a,c,b)
: CHECK(b,a,c)
: CHECK(b,c,a)
: CHECK(c,a,b)
: CHECK(c,b,a)
: (assert(0), 0);
#undef CHECK

In either of these it's easy to tell at a glance that all
cases are tested and that the appropriate value is returned
in all cases.

There is a test for correctness in my test driver.

Having a unit test is orthogonal to the point I was making.
Not that I think having a unit test is pointless, far from
it, but that doesn't affect the clarity/obviousness of
the original code. (And there is always the question of
whether the unit test is testing the right thing.) Ideally
there would be both: code whose correctness is obvious,
_and_ some sort of test scaffolding to increase our
confidence that it computes good results rather than bad.

 

[Tim Rentsch]

It also has unneeded whitespace. Variables (if you want to call them
that), like whitespace, can improve readability.

Whether deliberately or not, you're misinterpreting or
misunderstanding me. Of course using variables _can_
improve readability, but "can" doesn't always mean "does".
Same is true for whitespace. The whitespace in the
above example is "needed" in that leaving it out
would (IMO) lessen readability. The variable is
unneeded because (again IMO) putting it in does
little or nothing to improve readability.

 

[Tim Rentsch]

It adds a little readability for me. Or at least it did.
On further inspection, it seems that the long version
wasn't actually bad. Your milage may vary. Mine does.

I took your statement as a one-off rather than intending
to express a general principle, which I think is how
you meant it. A different context might yield a different
result.

It's not god-awful, but it's far from an improvement.
My money stays on the first horse.

On a personal level I had a similar reaction to the
earlier form. But there's another way to approach
the problem, namely, devise a test and try to measure
some objective differences. After that there may be
something useful to talk about.