On 2024-02-18, Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:
> On 18/02/2024 01:22, Keith Thompson wrote:
>> What audience are you writing for that knows that "*" means
>> multiplication but won't understand "a = b + c * d;"?
>>
>> [...]
>>
> Anyone who either thinks that the rule to to apply the operations in
> sequence from left to right, or thinks that the writer may be using this
> rule, or who thinks that if you enter the expression into a calculator,
> the calculator is always right.

Or someone who was last employed in 1985, working in Smalltalk.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On 18/02/2024 02:42, Lawrence D'Oliveiro wrote:
> On Fri, 16 Feb 2024 23:44:10 +0000, bart wrote:
>
>> On 16/02/2024 23:10, Lawrence D'Oliveiro wrote:
>>> On Fri, 16 Feb 2024 10:01:37 +0000, bart wrote:
>>>
>>>> hsum = hist[0].count+hist[1].count+hist[2].count+hist[3].count;
>>>> if(nrhist<=4 || nrpixels / (nrpixels - hsum) >= count_factor ) {
>>>> // ...
>>>> }
>>>
>>> I see you had to shorten the variable names as well. Descriptive layout
>>> *and* names too much for you?
>>
>> Keep local variable names short and snappy is part of knowing how to
>> write readable code.
>
> That’s about making the code easier to write, not easier to read. Don’t
> confuse the two. And don’t assume that the first has more importance than
> the second.

It is easier to type "i" than "histogram_counter". But it also makes a
long expression with more than one index operation in it easier to read.
--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

On 18/02/2024 05:46, Janis Papanagnou wrote:
> On 18.02.2024 03:30, Lawrence D'Oliveiro wrote:
>> On Sun, 18 Feb 2024 02:35:37 +0100, Janis Papanagnou wrote:
>>
>>> I recall that we had used the _specific literal constant_ 0 as a
>>> "universal" constant to all integral types, floats, and pointers without
>>> cast.[*] That was in the 1990's.
>>
>> That is still true in the C spec today. Note that “0” as a pointer does
>> not mean that the address value has to be zero: the implementation is
>> expected to convert the integer literal 0 to whatever address value is
>> meant to be interpreted as “no such address”.
>
> This is exactly what I was remembering. Thanks for the confirmation.
>
> Janis
>
Yes, The practical implication of that is that memset(ptr, 0,
sizeof(MYSTRUCT)) may fail unexectedly if MYSTRUCT contains pointers.

--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

On 18/02/2024 02:28, Lawrence D'Oliveiro wrote:
> On Sat, 17 Feb 2024 16:45:49 -0800, Keith Thompson wrote:
>
>> Yes, casts certainly can be dangerous ...
>
> This is why C++ defined four different kinds of casting. The dangerous one
> is called “reinterpret_cast”, while the others are much safer to use.

And my experience is the opposite. Reinterpeting a bit pattern as
something else is a safe and proper use of a cast, whilst calling
user-defined code without necessarily realising it is dangerous, and
manipulating inheritance hierachies in strange ways is also confusing
and dangerous.

--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

On 18/02/2024 07:48, Malcolm McLean wrote:
> On 18/02/2024 01:22, Keith Thompson wrote:
>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>> [...]
>>> In computer programs it is normally acceptable to write a = b + c * d
>>> and because programs contain so many similar expressions, and because
>>> the reader is another programmer and knows that the meaning is
>>> constrained by the language as well as by convention, it will not
>>> cause any confusion. But in a non-computer, non-professional
>>> mathematical context, it is too likely to cause confusion, and you
>>> must write a = b +   (c * d).
>>
>> What audience are you writing for that knows that "*" means
>> multiplication but won't understand "a = b + c * d;"?
>>
>> [...]
>>
> Anyone who either thinks that the rule to to apply the operations in
> sequence from left to right, or thinks that the writer may be using this
> rule, or who thinks that if you enter the expression into a calculator,
> the calculator is always right.

1970s calculators might have been too crude to use precedence. But Casio
calculator now will give you 14 if you enter '2 + 3 x 4'. Any calculator
app will do so. Even Google will give you 14 if you enter that.

Very few expect it to be 20.

On 18/02/2024 11:30, bart wrote:
> On 18/02/2024 07:48, Malcolm McLean wrote:
>> On 18/02/2024 01:22, Keith Thompson wrote:
>>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>> [...]
>>>> In computer programs it is normally acceptable to write a = b + c * d
>>>> and because programs contain so many similar expressions, and because
>>>> the reader is another programmer and knows that the meaning is
>>>> constrained by the language as well as by convention, it will not
>>>> cause any confusion. But in a non-computer, non-professional
>>>> mathematical context, it is too likely to cause confusion, and you
>>>> must write a = b +   (c * d).
>>>
>>> What audience are you writing for that knows that "*" means
>>> multiplication but won't understand "a = b + c * d;"?
>>>
>>> [...]
>>>
>> Anyone who either thinks that the rule to to apply the operations in
>> sequence from left to right, or thinks that the writer may be using
>> this rule, or who thinks that if you enter the expression into a
>> calculator, the calculator is always right.
>
> 1970s calculators might have been too crude to use precedence. But Casio
> calculator now will give you 14 if you enter '2 + 3 x 4'. Any calculator
> app will do so. Even Google will give you 14 if you enter that.
>
> Very few expect it to be 20.
>
>
Oh you are right. I pushed it into the calculator that ships with my
Mac, and it is 14. It did use to be 20 for that type of calculator.

The one I had at school would have answered 20. But I seldom used
calculators after leaving school. They can't do the sums you have to do
at university.

--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

On 18/02/2024 09:09, Michael S wrote:
> On Sun, 18 Feb 2024 02:42:40 -0000 (UTC)
> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>
>> On Fri, 16 Feb 2024 23:44:10 +0000, bart wrote:
>>
>>> On 16/02/2024 23:10, Lawrence D'Oliveiro wrote:
>>>> On Fri, 16 Feb 2024 10:01:37 +0000, bart wrote:
>>>>
>>>>> hsum =
>>>>> hist[0].count+hist[1].count+hist[2].count+hist[3].count;
>>>>> if(nrhist<=4 || nrpixels / (nrpixels - hsum) >= count_factor ) {
>>>>> // ... }
>>>>
>>>> I see you had to shorten the variable names as well. Descriptive
>>>> layout *and* names too much for you?
>>>
>>> Keep local variable names short and snappy is part of knowing how to
>>> write readable code.
>>
>> That’s about making the code easier to write, not easier to read.
>> Don’t confuse the two. And don’t assume that the first has more
>> importance than the second.
>
> Short-named local vars are easier to read, too.
> That is, as long as they are truly local, rather than declared at the
> top in the style advocated by Malcolm (and by bart too?).
>
>
>
"i" is effectively a keyword, and "i=0" was picked up as one of the most
common sequences in C by some sort of analysis. I think it was for
compression. Just out "int i;" at the top and you have it in scope and
handy. And don't decare it in the loop because you can't then do

for (i = 0; i < N; i++)
if(!x[i])
break;
if (i == N)

and you don't want a mix of counter variables declared in the loop and
variables not. It's not a huge deal. But it is that bit harder to
understand and to read.
--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

Richard Harnden <richard.harnden@gmail.invalid> writes:

> On 17/02/2024 01:43, Kaz Kylheku wrote:

[.. ideas for how to deal with parentheses and precedence ..]

>> It seems it might be mildly useful to have (? ...) parentheses
>> which override precedence and associativily like the regular ones,
>> but emit a diagnostic.
>>
>> If the parentheses are necessary, the diagnostic indicates that.
>>
>> If the parentheses do nothing, it also indicates that.
>>
>> So based on the diagnostic, you remove just the ? or the entire
>> (? ...).
>
> Okay, but they help with semantics, so just leave them in. Is it
> better to remove them and add a commnent ... ? // didn't expect
> that!
>
> Do extra parens in the source - when they turn out to be
> unnecessary - result in bloated executable size?

Almost certainly not.

> Or will the compiler optimise them away?

Probably the code will be transformed, prior to code generation,
to an internal form where parentheses don't even exist, so no
further effort is needed to remove superfluous parentheses.

> Do extra parens in the source help the human reader?

Let's consider an example. Suppose we see this line of code:

if( (a == b) & (c == d) ) ...

(I have put in extra spaces inside the if() parentheses so the
condition being tested stands out more.)

The parentheses in the test condition are unnecessary. Why are
they there? Was the author

confused about what the rules are?

unsure of what the rules are, and put them in to be safe?

aware that the parentheses are unnecessary, but put them
in because a co-worker is known to be confused or unsure?

confident that everyone on the team knows the rules, but
added the unnecessary parentheses because of some internal
coding standard or belief about good practices, etc?

Without more information it's difficult to guess which of those
possibilities explains the situation.

By contrast, suppose we see this line:

if( a==b & c==d ) ...

First, it is reasonable to infer that the author believes the
equality comparisons will be done before the bitwise and (and
that belief is correct as far as C is concerned).

Second, the extra spaces allow that assumption to be verified,
either by the compiler or by a stand-alone tool, and a warning
given if the assumption was wrong (for example, if the '&' had
instead been a '+').

Third, the extra spaces help a reader understand both how the
expression is parsed and that the author knows the rules and the
code accurately reflects how the program will in fact behave.

Fourth, the visual appearance of the second line makes it easier
to assimilate than the first line (not rigorously tested, but
there is anecdotal evidence that it's true).

Even if extra parentheses in the source do help a human reader
(and certainly they can in some cases), in my view it seems clear
that there is more benefit to choosing the extra spaces style
than the extra parentheses style.

Just some things to think about...

On 18/02/2024 12:00, Malcolm McLean wrote:
> On 18/02/2024 11:30, bart wrote:
>> On 18/02/2024 07:48, Malcolm McLean wrote:
>>> On 18/02/2024 01:22, Keith Thompson wrote:
>>>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>>> [...]
>>>>> In computer programs it is normally acceptable to write a = b + c * d
>>>>> and because programs contain so many similar expressions, and because
>>>>> the reader is another programmer and knows that the meaning is
>>>>> constrained by the language as well as by convention, it will not
>>>>> cause any confusion. But in a non-computer, non-professional
>>>>> mathematical context, it is too likely to cause confusion, and you
>>>>> must write a = b +   (c * d).
>>>>
>>>> What audience are you writing for that knows that "*" means
>>>> multiplication but won't understand "a = b + c * d;"?
>>>>
>>>> [...]
>>>>
>>> Anyone who either thinks that the rule to to apply the operations in
>>> sequence from left to right, or thinks that the writer may be using
>>> this rule, or who thinks that if you enter the expression into a
>>> calculator, the calculator is always right.
>>
>> 1970s calculators might have been too crude to use precedence. But
>> Casio calculator now will give you 14 if you enter '2 + 3 x 4'. Any
>> calculator app will do so. Even Google will give you 14 if you enter
>> that.
>>
>> Very few expect it to be 20.
>>
> >
> Oh you are right. I pushed it into the calculator that ships with my
> Mac, and it is 14. It did use to be 20 for that type of calculator.

Even the shell does it properly:

$ echo $(( 2 + 3 * 4 ))
14

>
> The one I had at school would have answered 20. But I seldom used
> calculators after leaving school. They can't do the sums you have to do
> at university.
>

Desktop calcualtors meant for accountants, where 'plus-equals' is a
single key ... now they are impossible to use.

On 18.02.2024 12:01, Malcolm McLean wrote:
> On 18/02/2024 02:28, Lawrence D'Oliveiro wrote:
>> On Sat, 17 Feb 2024 16:45:49 -0800, Keith Thompson wrote:
>>
>>> Yes, casts certainly can be dangerous ...
>>
>> This is why C++ defined four different kinds of casting.

It was certainly good to separate the different types of casts.

Though I generally tried to avoid casts (in C and in C++), and
that worked generally pretty well...

>> The dangerous one
>> is called “reinterpret_cast”, while the others are much safer to use.

....and I think I (almost?) never needed to use this type of cast.

The same with const_cast; I tried to write 'const'-coherent code
and did not need it. And also the remaining ones I rarely used.

>
> And my experience is the opposite. Reinterpeting a bit pattern as
> something else is a safe and proper use of a cast, whilst calling
> user-defined code without necessarily realising it is dangerous, and
> manipulating inheritance hierachies in strange ways is also confusing
> and dangerous.

But you don't "manipulate" hierarchies with a dynamic_cast; it's
(from the four) the most (sort of) "complex" cast, in the sense
that it's evaluated on run-time, but you get definite results
from it to reliably act on the objects (or 0) that you can test
with that cast. (Disclaimer: as far as long-term memory serves.)

I also think that re-interpreting types on bit level is not only
the most C-like but by far also the most "dangerous" one, no
less as it is in C.

The separation of casts in C++ helps locating critical places.
(In C with the two parenthesis syntaxes that was a nightmare.)

Janis

On 18.02.2024 10:02, Michael S wrote:
> On Sun, 18 Feb 2024 02:28:33 -0000 (UTC)
> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>> On Sat, 17 Feb 2024 16:45:49 -0800, Keith Thompson wrote:
>>
>>> Yes, casts certainly can be dangerous ...
>>
>> This is why C++ defined four different kinds of casting. The
>> dangerous one is called “reinterpret_cast”, while the others are much
>> safer to use.
>
> Potential usefulness of the distinction almost fully nullified both
> by retention of C-style cast and by presence of similarly omnipotent
> function-style cast that C++ added on its own.

You don't have to use the old C syntax or C++ function-style for
old casting. It's on you to make use of the new distinct forms.
And in projects you can define coding standards to make sure that
the old less secure forms are not used. We certainly defined such
standards in out projects.

Janis

On 18.02.2024 07:12, Lawrence D'Oliveiro wrote:
> On Sun, 18 Feb 2024 06:46:36 +0100, Janis Papanagnou wrote:
>
>> This is exactly what I was remembering.
>
> This is why it helps to keep a copy of the docs handy.

???

Janis

On 18/02/2024 03:40, Lawrence D'Oliveiro wrote:
> On Sun, 18 Feb 2024 02:16:39 +0100, Janis Papanagnou wrote:
>
>> (I don't know the terms Bodmas/Bidmas, though. ...
>
> We learned BODMAS, too. Although I remember the “O” stood for “Of”, as in
> implied multiplication. So that binds more tightly than division (“D”),
> which in turn binds more tightly than explicit multiplication (“M”). So
> for example
>
> a ÷ b(c + d)
>
> should be interpreted as
>
> a ÷ (b(c + d))
>
> while
>
> a ÷ b × (c + d)
>
> should be interpreted as
>
> (a ÷ b) × (c + d)

Having been educated in Britain, I have never heard of "Bodmas" or
"Bidmas". I don't recall any mnemonic for the rules of precedence in
normal arithmetic.

In written maths, you can use spacing and free arrangement of symbols to
indicate precedence. But you should be very careful of mixing division
and multiplication operators unless it is clear from the layout - the
way people interpret these things differ. Different countries have
different rules, and the rules change over time.

On 17/02/2024 21:08, Michael S wrote:
> On Sat, 17 Feb 2024 12:04:28 +0100
> David Brown <david.brown@hesbynett.no> wrote:
>
>> On 17/02/2024 02:13, Keith Thompson wrote:
>>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>>> On Fri, 16 Feb 2024 08:54:21 +0100, David Brown wrote:
>>>>> And use good tools, such as an IDE that gives you suggestions and
>>>>> auto-completion.
>>>>
>>>> auto-completion doesn’t really take you far, though. My favourite
>>>> example is how many times people write “sqrt(x * x + y * y)” to
>>>> compute a hypotenuse, not realizing that there is a “hypot(x, y)”
>>>> function available in any reasonable maths library.
>>>
>>> More relevantly, it's in the C standard library (since C99, I
>>> think).
>>
>> Also relevant, IMHO, is that "sqrt(x * x + y * y)" is faster on
>> virtually any real system.
>>
>> "hypot" is generally not implemented as a dedicated hardware
>> instruction, and is thus handled in software - it will involve a
>> library call to a "hypot" function that finds the maximum absolute
>> values of x and y, divides both x and y by this, then squares them
>> and adds them, then finds the square root, and then multiplies up
>> again - all so that it will give the correct result without a risk of
>> overflow.
>>
>
> It is not how it is done and *not* because division is slow, but
> because your method could produce the result that is off by one LS bit.
> Most likely, a library implementation looks like that, at least
> algorithmically:
>

OK. I don't claim to have more than an approximate idea about how these
are implemented, and freely accept that you and others know the details
much better. (I know I can always look these things up if I need them,
but have never had cause to do so.) My point was just that the "hypot"
function will be a lot slower than the plain sqrt() version, but it will
also be more accurate and have greater ranges.

On 18.02.2024 13:09, Malcolm McLean wrote:
>>
> "i" is effectively a keyword, and "i=0" was picked up as one of the most
> common sequences in C by some sort of analysis. I think it was for
> compression. Just out "int i;" at the top and you have it in scope and
> handy.

Sure.

> And don't decare it in the loop because you can't then do
>
> for (i = 0; i < N; i++)
> if(!x[i])
> break;
> if (i == N)
>
> and you don't want a mix of counter variables declared in the loop and
> variables not. It's not a huge deal. But it is that bit harder to
> understand and to read.

You could of course use a semantical name and keep variables localized

bool null_found = false;
for (int i = 0; i < N; i++)
if(!x[i]) {
null_found = true; break;
}
if (! null_found)

(Of course you should find a better, more sensible name for the !x[i]
condition, which I cannot guess from the few lines above.)

But that's of course a style issue, where opinions certainly differ,
and that people who prefer terse names and terse code will probably
dislike this. (Myself I like local declarations and semantical names.)

Janis

On 18/02/2024 03:34, Lawrence D'Oliveiro wrote:
> On Sat, 17 Feb 2024 12:04:28 +0100, David Brown wrote:
>
>> And that's great, if your x and y are nearing half the maximum range of
>> your floating point type. But how often is that realistic?
>
> There is an old saying: “correctness comes before efficiency”.
>

Sure - but what is "correct" here? Very often, "correct" in floating
point code means "end results within a certain margin of error, for
realistic input values". What these error margins and ranges are will
depend on the code and its use.

IEEE correctness is a different matter - it aims to be as accurate as
possible within the limits of the representations used. That is not a
suitable specification for "correctness" in user code - but it is a way
to help write your user code to specification.

> A key principle of IEEE754 is that users, particularly users nonexpert in
> the field of numerics, should be exposed to a minimum of surprise.
>

It could well be a surprise to non-experts that there is a function
"hypot" in the C library, rather than just writing "sqrt(x*x + y*y)".
And it would certainly be a surprise to non-experts that the dedicated
"hypot" function is far slower than the hand-written version.

In general, however, I agree with you in regard to IEEE754's intentions.

On 18.02.2024 08:48, Malcolm McLean wrote:
> On 18/02/2024 01:22, Keith Thompson wrote:
>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>> [...]
>>> In computer programs it is normally acceptable to write a = b + c * d
>>> and because programs contain so many similar expressions, and because
>>> the reader is another programmer and knows that the meaning is
>>> constrained by the language as well as by convention, it will not
>>> cause any confusion. But in a non-computer, non-professional
>>> mathematical context, it is too likely to cause confusion, and you
>>> must write a = b + (c * d).
>>
>> What audience are you writing for that knows that "*" means
>> multiplication but won't understand "a = b + c * d;"?
>>
> Anyone who either thinks that the rule to to apply the operations in
> sequence from left to right, or thinks that the writer may be using this
> rule, or who thinks that if you enter the expression into a calculator,
> the calculator is always right.

We probably should fall back to calculators (and interfaces) with
RPN input; this solves not only the precedence "problem" but also
the parenthesis "problem". :-)

Janis

On 17/02/2024 20:37, Kenny McCormack wrote:
> In article <uqqrd3$h6ku$1@dont-email.me>,
> David Brown <david.brown@hesbynett.no> wrote:
> ...
>> OK, let's everyone who takes a computer with them planning on doing
>> programming is likely to have the ability to look things up online. We
>> are no longer in the 1990's.
>
> From which language was the above paragraph Google-translated?
>

Spotting the missing word "say" was left as an exercise for the reader.

On 18.02.2024 15:46, David Brown wrote:
> [...] Different countries have
> different rules, and the rules change over time.

In my country luckily not the (long established) math rules.

Janis

On 18/02/2024 03:43, Lawrence D'Oliveiro wrote:
> On Sat, 17 Feb 2024 12:11:36 +0100, David Brown wrote:
>
>> On 17/02/2024 00:11, Lawrence D'Oliveiro wrote:
>>
>>> On Fri, 16 Feb 2024 08:59:35 +0100, David Brown wrote:
>>>
>>>> Here's a clue. It's one thing to mark your #endif's with a comment on
>>>> which #ifdef it matches, but if you need to do that with your "if"
>>>> statements, your style is an incomprehensible mess.
>>>
>>> I wonder why ...
>>
>> /You/ wrote it, and I've not seen anyone but you post code with " }
>> /*if*/ " comments. So only you can explain why your feel your own style
>> is such an incomprehensible mess.
>
> You are the one who has never seen it before, and so you react with
> ignorance and fear. Almost as though the code has become like magic to
> you.

"Ignorance and fear" ? Really? /That/ is what you inferred from my post?

>
> You are the one calling it an “incomprehensible mess”, it is up to you to
> back up your claim.

My claim is that no one would feel the need to add "/*if*/" comments to
closing brackets unless they felt the code was not clearly
comprehensible without such comments. I am saying that /you/ write
/your/ code as though /you/ think your own code is hard to comprehend.

On Sun, 18 Feb 2024 15:54:05 +0100
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:

> On 18.02.2024 13:09, Malcolm McLean wrote:
> >>
> > "i" is effectively a keyword, and "i=0" was picked up as one of the
> > most common sequences in C by some sort of analysis. I think it was
> > for compression. Just out "int i;" at the top and you have it in
> > scope and handy.
>
> Sure.
>
> > And don't decare it in the loop because you can't then do
> >
> > for (i = 0; i < N; i++)
> > if(!x[i])
> > break;
> > if (i == N)
> >
> > and you don't want a mix of counter variables declared in the loop
> > and variables not. It's not a huge deal. But it is that bit harder
> > to understand and to read.
>
> You could of course use a semantical name and keep variables localized
>
> bool null_found = false;
> for (int i = 0; i < N; i++)
> if(!x[i]) {
> null_found = true; break;
> }
> if (! null_found)
>
> (Of course you should find a better, more sensible name for the !x[i]
> condition, which I cannot guess from the few lines above.)
>

Your variant is unlikely to achieve the result that an idiom shown by
Malcolm normally wants to achieve, which is not just the knowledge that
a certain condition happened, but also an index at which it happened for
a first time. This modification will do both:
int nul_idx = N;
for (int i = 0; i < N; i++) {
if(!x[i]) {
nul_idx = i;
break;
}
}
if (nul_idx == N) {
} else {
}

It is true that it is longer to type than Malcolm's variant, but IMHO
it is a little easier to understand. More importantly, it's more
resilient to future changes in the code. E.g. somebody wants to add
another loop in which the natural name for the index is again i and
this new loop happens to be placed between the first and the last use
of nul_idx.

> But that's of course a style issue, where opinions certainly differ,
> and that people who prefer terse names and terse code will probably
> dislike this. (Myself I like local declarations and semantical names.)
>
> Janis
>

On 2/18/24 00:45, Janis Papanagnou wrote:
> On 18.02.2024 03:07, Keith Thompson wrote:
....
>> 0 is of type int. In most contexts, it will be implicitly converted to
>> any scalar type -- which is why { 0 } is a valid initializer for any
>> type (C23 will allow {}).
>
> What I had in mind was not the implicit cast from any integer literal
> to other scalar types. But back these days the folks who handled that
> told us that the 0 was a specific value, especially in the context of
> pointers (where, IIRC, the NULL pointer could have a non-0 decimal
> value, but using 0 would not act as decimal 0 but as NULL-pointer).
> In other words; however NULL was defined you could use p=NULL or p=0
> with the same result.
> (But since this had been just second hand information that I hadn't
> checked myself I'm asking.)

What you're thinking about is called a null pointer constant(NPC). 0 is
the simplest NPC, but any integer constant expression with a value of 0,
or such an expression cast to (void*), also qualifies as a null pointer
constant. In many contexts, a null pointer constant gets implicitly
converted to a null pointer of the the appropriate type. In C2023,
nullptr also counts as an NPC.

Note that an integer expression with a value of 0 that does NOT qualify
as an integer constant expression therefore also does not qualify as an
NPC. (void*)n when n happens to be 0 might or might not be a null pointer.

All null pointers must compare equal to each other, and are prohibited
from comparing equal to a pointer to any object or function. In
particular, this means that any null pointer must compare equal to 0.
However, null pointers need not be represented by all bits zero, and
there can be multiple different representations of a null pointer in any
given type.

On 18/02/2024 14:31, Janis Papanagnou wrote:
> On 18.02.2024 12:01, Malcolm McLean wrote:
>> On 18/02/2024 02:28, Lawrence D'Oliveiro wrote:
>>> On Sat, 17 Feb 2024 16:45:49 -0800, Keith Thompson wrote:
>>>
>>>> Yes, casts certainly can be dangerous ...
>>>
>>> This is why C++ defined four different kinds of casting.
>
> It was certainly good to separate the different types of casts.
>
> Though I generally tried to avoid casts (in C and in C++), and
> that worked generally pretty well...
>
>>> The dangerous one
>>> is called “reinterpret_cast”, while the others are much safer to use.
>
> ...and I think I (almost?) never needed to use this type of cast.
>
> The same with const_cast; I tried to write 'const'-coherent code
> and did not need it. And also the remaining ones I rarely used.
>
>>
>> And my experience is the opposite. Reinterpeting a bit pattern as
>> something else is a safe and proper use of a cast, whilst calling
>> user-defined code without necessarily realising it is dangerous, and
>> manipulating inheritance hierachies in strange ways is also confusing
>> and dangerous.
>
> But you don't "manipulate" hierarchies with a dynamic_cast;
>
So "manipulate" is the wrong word. You can't create or modify a
hierarchy with a cast. But you can obtain access to members in strange ways.

Reintepreting bits is safe. Obviously you can do it in a way that gets
it wrong. But that is true of all computer code. It's clear what you are
doing, and if the reinteretation isn't valid it will probably
immediately crash and is highly unlikely to appear to work when it does
not, and so it's not dangerous.
--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

On 18/02/2024 14:54, Janis Papanagnou wrote:
> On 18.02.2024 13:09, Malcolm McLean wrote:
>>>
>> "i" is effectively a keyword, and "i=0" was picked up as one of the most
>> common sequences in C by some sort of analysis. I think it was for
>> compression. Just out "int i;" at the top and you have it in scope and
>> handy.
>
> Sure.
>
>> And don't decare it in the loop because you can't then do
>>
>> for (i = 0; i < N; i++)
>> if(!x[i])
>> break;
>> if (i == N)
>>
>> and you don't want a mix of counter variables declared in the loop and
>> variables not. It's not a huge deal. But it is that bit harder to
>> understand and to read.
>
> You could of course use a semantical name and keep variables localized
>
> bool null_found = false;
> for (int i = 0; i < N; i++)
> if(!x[i]) {
> null_found = true; break;
> }
> if (! null_found)
>
> (Of course you should find a better, more sensible name for the !x[i]
> condition, which I cannot guess from the few lines above.)
>
x is an array of given data which contains scalars, that is conventional
and you ought to be able to work that out. On loop exit i will be set to
the index of the first zero value, or N if no zero is found, and we then
test for the latter. It should be perfectly obvious to anyone with any
experience what is going on, and it's a perfectly normal thing to need
to so. Your way is maybe a bit easier to follow, but having a flag
called "null_found" hanging around probably isn't necessary, whilst we
could well need i for the index of the first zero value later on.

> But that's of course a style issue, where opinions certainly differ,
> and that people who prefer terse names and terse code will probably
> dislike this. (Myself I like local declarations and semantical names.)
>
x, i, N. You do need to know the conventions to make it easy to read.

--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

On 18/02/2024 14:46, David Brown wrote:
> On 18/02/2024 03:40, Lawrence D'Oliveiro wrote:
>> On Sun, 18 Feb 2024 02:16:39 +0100, Janis Papanagnou wrote:
>>
>>> (I don't know the terms Bodmas/Bidmas, though. ...
>>
>> We learned BODMAS, too. Although I remember the “O” stood for “Of”, as in
>> implied multiplication. So that binds more tightly than division (“D”),
>> which in turn binds more tightly than explicit multiplication (“M”). So
>> for example
>>
>>      a ÷ b(c + d)
>>
>> should be interpreted as
>>
>>      a ÷ (b(c + d))
>>
>> while
>>
>>      a ÷ b × (c + d)
>>
>> should be interpreted as
>>
>>      (a ÷ b) × (c + d)
>
> Having been educated in Britain, I have never heard of "Bodmas" or
> "Bidmas".  I don't recall any mnemonic for the rules of precedence in
> normal arithmetic.
>
My sister used to be maths teacher and she taught Bodmas. I remember
because she pointed out that there was some inconsistency in it which
had confused a child, but I can't remember what that was, I think it was
ti do with unary minus.
Brackets, of, division, multiplication, addition, subtraction. "of"
doesn't really appear in school mathematical expressions and was mainly
to make it pronouceable, and it is now "Bidmas" where "i" is "index",
meaning exponent.

> In written maths, you can use spacing and free arrangement of symbols to
> indicate precedence.  But you should be very careful of mixing division
> and multiplication operators unless it is clear from the layout - the
> way people interpret these things differ.  Different countries have
> different rules, and the rules change over time.
>
I read a lot of mathematical papers that I haven't been formally trained
how to read or understand, and it is often challenging. But precedence
is seldom a difficulty.

--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm