Bart <bc@freeuk.com> writes:I'd say that just the (known) flaw makes them (slightly) complicated;[...][...]
C's operator precedence rules are complicated and arguably flawed.
so you need to remember that "flaw" (or "inconsistency") to be safe.
The rest is completely sensible. And even if one doesn't have a table
to look up the precedences they mostly can be derived (presuming one
has a feeling for the underlying logic of these things or experiences
from other related areas).
They could have been defined differently. A simpler set of rules,There are. (What I called above as "derived underlying logic".) Some
with fewer levels, *might* have been better. I don't have any
concrete suggestions -- nor do I have any strong preferences.
I accept C's rules as they are. I would accept them if they had
been defined differently.
Nothing about the current rules particularly bothers me. There are
no objective criteria for deciding what the rules *should* be.
aspects have already been formulated in this and other threads here.
But maybe not obvious to recognize without background in mathematics,
logic, or CS.
Even having multiplication bind more tightly than addition is(Now opinions are getting really strange; in the above stated sense.)
fundamentally an arbitrary choice
(though one that's almostThe more complex the expressions are the more structure they need.
universally recognized, even outside the context of programming
languages).
[...]
If not, people can choose to ignore those them when writing C code,Yes, they can, and I personally tend to agree that they should.
for example like this where all () are technically superfluous:
>
crcu32 = (crcu32 >> 4) ^ s_crc32[(crcu32 & 0xF) ^ (b & 0xF)];
IMO, the parenthesis above make precedence clear (if unknown!), but
are not contributing to readability. It would have made more sense
to separate the sub-expression within the [...] in an own object to
enhance readability and to more easily understand what's going on.
To emphasize; not the precedences are the problem above, but the
complexity of the expression in connexion with lack of structuring.
Huh? - How that? - Are you saying here that practically only C-like[...]When designing a new language, there are real advantages in strictly
imitating C's rules, just because so many programmers are familiar
with them.
languages are in common use? - But even if so; there's quite some
languages with differing precedence rules, not C-based, and without
such a flaw like the one being discussed. - When designing a *new*
language I'd certainly choose one of the sensible precedence rules,
and just without those obvious flaws. (And not use "C" as base, of
course.)
(I would have been silly for C++ or Objective-C toOr - with reference to that flaw - just more consistent.
change the precedence rules, even to improve them.) But there
are also real advantages in using precedence rules that are better
(e.g., simpler) than C's.
Consistent systems are inherently simpler, in the sense of easier to
understand and thus more straightforward to use. A precondition for
that is, as said, at least a basic understanding of such things.
It depends on the nature of the language.Janis
It could be an interesting discussion for comp.lang.misc.
Les messages affichés proviennent d'usenet.