Eric said:
If we eliminate from C all the things some people find
confusing, what will remain? The traffic in this newsgroup
shows that people are confused by arrays, by pointers, by
floating-point arithmetic, by much of <stdio.h> (printf()
makes lots of trouble, scanf() even more), by all of <ctype.h>,
by structs, by functions with prototypes, by functions without
prototypes, by variable-length argument lists, and by main().
We're talking about two different ways to do the same thing by an
actual developer (read original post), not about the mistakes made by
people learning the language. I guess the DEEP TERNARY NESTING vs.
MULTILEVEL IF is just a difference of opinion, let's leave it at that.
Purging C of all these (and of the many other confusions
I haven't listed; these are off-the-top-of-my head topics)
would leave a language that might be named "C minus" but would
certainly not merit so high a mark ...
Once again, this is not a discussion about "purging" ternary operators
from the language and forcing developers to use IF statemetns. We're
talking about a solution to a problem (presented by the original
poster), that can be solved by NESTED TERNARIES or MULTILEVEL IF
statements. Nobody is talking about removing actual features from the
language. If you read the original post, you will see that the
individual was "at first glance" confused by the use of nested
ternaries. He also mentioned that certain tools his company used
couldn't recognize the nested ternaries, while it recognized the
multilevel IFs. I don't know where you go the idea that I wanted to
"purge" features from the language. Ternaries are awesome, but their
use in deep nesting can cause problems to less experienced developers,
optimizers, debuggers, complexity analyzers, etc (which was the subject
of the original post- have a look).
I am not bashing ternary operators or you're use of them. You probably
use it in a much clearer way than in the code the OP encountered,
which is fine.
Are you arguing that debuggers should not have capabilities
not shared by all other debuggers? That is, that there should
be just one Ur-debugger?
No, but if you read the concerns of the OP, you will notice that his
tools had trouble recognizing the ternary conditionals AND he was
dealing with code developed by someone else. If you have a really
awesome debugger that lets you set machine level breakpoints while
stepping through source level code, then I guess this is a non-issue.
No; I'm assuming that some compiler somewhere might generate
the same code for both forms.
Then what did you mean by this comment:
---
(2) Try to set a breakpoint in the latter form [with IFs], after
an optimizing compiler has transmogrified the code and
generated the same instructions as for the former form.
---
If you meant that a compiler somewhere might generate the same code for
both forms, then how does your comment above (2) support nested
ternaries?
[Not insulting, I am just confused]
Strange; the latter should be easier. For starters,
there's only one assignment target, hence no need to "notice"
that the four targets in the `if' form are in fact the same.
Different of opinion among different people. Let's leave it there.
Perhaps your friend may have been referring to code like
#define max2(a,b) ((a) > (b) ? (a) : (b))
#define max4(a,b,c,d) max2(max2((a),(b)), \
max2((c),(d)))
... which I would most definitely not recommend; the apparent
simplicity conceals a surprisingly voluminous expansion, with
lots of common sub-expressions a compiler might need to struggle
to eliminate.
Nope, wasn't referring to that.
... at which point you are no longer debugging the actual code,
but a sort of proxy for it. I've debugged plenty of problems
that only showed up after optimization, that is, problems that
simply vanished when optimization was turned down or off. "Test
what you fly; fly what you test."
I was responding to your comment (2). A compiler is free to optimize
either form, so I had no clue what your comment (2) was trying to
convey. Of course you should turn optimization on again after you have
found the fault with the debugger (that's if you had to resort to
turning it off in the first place, which is always a last-hope method).
NASA's mantra "test what you fly; fly waht you test" is posted above
the whiteboard beside me. But what is wrong with doing intermediate
tests on proxies to find a fault, then doing thorough tests on the real
thing afterwards?
Different development activities have different goals and
are sometimes in conflict. It is not always possible to "best
satisfy" all of them; compromises are required.
However, I'll still maintain that it's better to be able
to prove things about a section of code than to run a bunch
of test cases through it and say "Well, nothing broke. Yet."
Code inspections don't catch all bugs, neither does debugging. There is
no "better" method. You try to catch bugs as early as possible, and
you make every phase in the development cycle as robust as possible-
you can't make compromises. Everything must be taken seriously, there
are no preferences.
Difference of opinion. But realize that you can't rely solely on code
inspections.
Proof by assertion. (You're in good company; Edsger W.
Dijkstra did a lot of important work, but is probably best
known for just such a proof.)
Proof? It's an opinion that was a response to your opinion.
If you feel like it, you can do the same with ternaries:
hand_type
= is_flush
? is_straight
? STRAIGHT_FLUSH
: FLUSH
: is_straight
? STRAIGHT
: NOTHING;
... and you can even throw in a few levels of parentheses if
you want them.
Difference of opinion.
Observation #1: Didn't you just get through saying
you *liked* all those braces?
I like extended braces (read my comments again).
Observation #2: Did you just describe the ternary
formulation as "very clean?" My point, exactly.
I said "look very clean" in the superficial sense. That says nothing
about how easy it is to understand the code, or how well tools can
deal with it.
Excuse me, but what justifies this insult? Did I not say
that "When you need them you do in fact need them?" Yes, I
did. Did I claim perfection? No, I did not. Back off.
Read (4) again. It was in response to another poster and the OP who
were obviously concerned about debuggers and other tools. In (4) it
"sounded" like you were saying that people who "needed" debuggers were
inferior somehow. Maybe I took it the wrong way, but then again, you
did take my joke as an "insult" too.
Clarity of expression is not achieved through baby talk.
Clarity is not measured in lines of code, and isn't the only important
facet of software development (even though I think the IFs are more
clear). If you are referring to the fact that some programmers make
their code extra "babyish" to allow beginners to understand it, then
what's wrong with that? Like you said, the two methods can be optimized
to the same machine instructions, so why not make the code extra
"clear" to the people who are most likely to trip over it? Tools matter
too, and OP obviously had some issues with the nested ternaries. Let's
leave opinions out of it, and concentrate on the issues the OP had.
Deal?
There is no reason to continue this discussion, since opinions are just
that, opinions (I appologize for trying to assert my opinion).