On 04/06/2026 13:35, David Brown wrote:Of course they are different things - albeit related things, rather than /completely/ different. One is a question of fact, the other a question of opinion, and they do not always coincide.On 04/06/2026 13:40, Bart wrote:So, you're arguing 'more than needed' is a completely different thing from 'too many'.On 04/06/2026 10:34, Tim Rentsch wrote:>Bart <bc@freeuk.com> writes:>>My point was that it could be objective, at least for too many. So>
(a*a) + (b*b) would be commonly agreed to have too many, [...]
Apparently you misunderstand what is meant by the word objective.
An objective statement is one that is independent of personal
assessment, even collective personal assessment.
I don't know of any infix PL syntax where 'a*a + b*b', as a standalone expression, doesn't mean '(a*a) + (b*b)'.
>
Google agrees with me (in that 2*2+3*3 shows 13), and so does my Casio calculator.
>
It's not my personal opinion!
You are - again - moving the goalposts.
>
It is an objective fact that "a * a + b * b" means "(a * a) + (b * b)" in normal mathematics (at least in the countries I am familiar with), and also in most mainstream programming languages.
>
It is an objective fact, therefore, that "(a*a) + (b*b)" has more parentheses than needed in the context of most programming languages.
>
"(a*a) + (b*b) has too many parentheses", on the other hand, is a purely subjective opinion.
It is a fact that "a << (b + c)" has more parentheses than needed. But I think we are both of the opinion that it does not have "too many" parentheses - it has an appropriate number of parentheses.
Sigh...There is no "technically" about it. It is unambiguous in C.
>It is technically unambiguous in C.
If you wrote, for example, that "a << b + c" is ambiguous in C, then you
It can be ambiguous in the mind of somebody who would have to double-check the precedence levels, or where the C context is missing.I would not use the word "ambiguous" there - "unclear" would be more appropriate in the situation when someone does not know the C precedence levels.
If you are given the expression and don't know it is in C, it's a very different matter - there are all kinds of things it could mean. In C++, it could mean concatenating two strings and passing the result to a output stream. In Forth, it could mean anything you like. With no context, the expression is not "ambiguous" because that implies that there is a number of reasonable interpretations - and without context, there is no limit to the interpretations.
So while I entirely agree that "a << b + c" may not be clear, and may easily be misinterpreted, "ambiguous" is the wrong word to use.
The discssion seems to about what exactly is 'too many'.No, it's an attempt to get you to understand the difference between "objective" and "subjective" - fact and opinion. I don't understand why you are having such a problem here.
Apparently you can constuct a valid C source file where 99.9% of the text consists of () characters, but if someone - or even a million people - say that it is too many, then that is just their subjective opinion.64 levels of nested parentheses is /factually/ and /objectively/ too many to be guaranteed supported by a conforming C compiler. It takes a far smaller number to be viewed as too many in the subjective opinion of a large proportion of people.
I don't have the patience for such nonsense any more:Yes. They are unnecessary in C (that is a fact), and most people would not find them helpful in understanding the expression (that is a claimed fact, given without evidence, about people's opinions. It is my opinion that this claimed fact is true).
* The () in '(a * b) + c' are generally unnecessary
* The () in 'a << (b + c)' are advisableThat is a subjective opinion. /I/ would generally advise including the parentheses here. Other people might have a different opinion. And people can have different opinions depending on the target audience.
* The () in '(a << b) + c)' are necessary if the intent is to haveThe parentheses in "(a << b) + c" are necessary if the intent is to shift "a" by "b", and then add "c" to the result. That is fact, not opinion. Any discussion of "intuitive" is necessarily subjective.
what might be the more intuitive meaning.
If this not 100% C-specific, than () are needed for both the last two examples, but not the first.Do /you/ know what is fact and what is opinion here? Do you understand the difference, after spoon-feeding you these examples?
You all know this.
And do you understand why it is important in a discussion to be able to make these distinctions? It matters, even if you and I would likely both want the parentheses mostly in the same places.
It is neither a "gotcha", not a consequence of poor design. It does not "fall down". It is simply a minor consequence of the choice of operator syntax. Such an expression would occur rarely in code, and to be a "gotcha" it would need to be realistic for someone to write it, without spaces, and for their code to compile and be used without the mistake being noticed. Do you think that is in any way realistic? I do not.This is where it falls down. It's very clearly a 'gotcha', and consequence of poorly thought-out design.(Note that C has its own problems in this area:>
>
a = b/*p; // divide b by dereferenced pointer p
>
Here, /* also happens to start a block comment.)
>
Here you are objectively wrong. C does not have a "problem" with this. The parsing rules of the language are clear - often called "maximum munch". The character sequence "/*" is the start of a comment, it is not two separate operators.
And to be "poor design", it needs to be something that is likely to cause problems (which it is not), or which requires significant effort to work around. Writing "a = b / *p;" is not challenging, and a lot of people prefer spaces around binary operators anyway.
I'd say you were making a mountain out of a molehill, but I don't think it's as big as a molehill.
That the behaviour is deterministic doesn't change that.Of course it does. If some compilers treated it differently, then there might be a chance that someone wrote such code and got the expected results from the tool they were using, even though it was treated differently by other tools.
My mind-reading skills are not that well developed.What was the 'something' in "It's silly to worry about something that ..."?>It's silly to>
worry about something that 999 people out of a 1000 (and the actual
numbers are undoubtedly much higher) are able to navigate without
difficulty. Yet the examples you give insist on focusing on the few
hopeless individuals.
Are you saying that whoever wrote code like this:
>
crcu32 = (crcu32 >> 4) ^ s_crc32[(crcu32 & 0xF) ^ (b & 0xF)];
>
is needlessly worrying about the 99.9+% of the readership who you claim will know C syntax rules precisely? That is, they would find this version just as clear without any extra cognitive effort:
>
crcu32 = crcu32 >> 4 ^ s_crc32[crcu32 & 0xF ^ b & 0xF];
>
?
Tim did not write that.
I assume it's people being unable to understand that second example.He did not say he was talking about those examples. Given that the "crc" examples are more distant in the Usenet thread, it seems a stretch to assume he was referring to them, rather than to the code examples you had just given. (It would, perhaps, have been helpful if Tim had not snipped those examples.)
Yet I seee parenthese being used in such cases a LOT more than 0.1% of the time. 50% or more would be my guess.
That example was not on the list of examples you gave recently.It was posted several times.
(https://github.com/richgel999/miniz/blob/master/miniz.c line 81, second hit for '>>')
Les messages affichés proviennent d'usenet.