On Wed, 14 Feb 2024 11:30:14 +0000, bart wrote:

> All such choices have a flaw: you need to bundle a binary program to act
> as scripting language ...

There are quite a few scripting languages that are in such common use, it
becomes reasonable that the target system will have these either already
installed, or easily installable. Assuming it is a reasonable type of
target system, with integrated package management.

On Wed, 14 Feb 2024 14:17:07 +0000, bart wrote:

> ... many weren't at all impressed with having
> to type 'gcc prog.c -o prog.exe -O3' when they were used to typing:
>
> make
>
> I began to suspect that some people (not in this group) didn't actually
> know how to build hello.c from a command line.
>
> An analogy would be where I'd reduced the job of installing a kitchen to
> hammering in one nail, but somebody didn't know how to use a hammer.

How about another analogy, where people who are accustomed to cars with
automatic transmissions where you just move the lever to “D” to move off,
and you tell them they have to press the clutch before they can select a
gear.

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>
>> scott@slp53.sl.home (Scott Lurndal) writes:
>>> Michael S <already5chosen@yahoo.com> writes:
>>>>On Tue, 13 Feb 2024 16:59:38 -0800
>>>>Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>>>>> Though personally, I'd probably make the assignment the operand of a
>>>>> larger expression. I understand that
>>>>> if (foo)
>>>>> is a common idiom where foo is of any scalar type, but I personally
>>>>> prefer to write one of
>>>>> if (foo != 0)
>>>>> if (foo != '\0')
>>>>> if (foo != 0.0)
>>>>> if (foo != NULL)
>>>>> because I find it clearer (unless foo is of type bool or is otherwise
>>>>> appropriate to use directly as a condition).
>>>>>
>>>>> Thus if x and y are ints, I'd probably write:
>>>>> if ((x = y) != 0)
>>>>> (Assuming I'm not required to follow MISRA rules.)
>>>>>
>>>>> YMMV.
>>>>>
>>>>
>>>>Agreed with two small exception:
>>>>(1) I never write '\0' myself always preferring plain 0.
>>>
>>> I'm in Keith's camp here when working with a char type, I'll
>>> use '\0' rather than plain zero.
>>>
>>> I tend to suffix constants as well if they're not being
>>> used as 'int', perhaps a bit too picky?
>>>
>>> uint64_t v;
>>> ...
>>> if (v == 0ul) ...
>>
>> There's no suffix for uint64_t. 0ul is of type unsigned long, which may
>> or may not be the same type as uint64_t.
>>
>> In this particular case, I'd just use 0. If for some reason I needed to
>> make it explicitly of type uint64_t (say, for an argument to a variadic
>> function), I'd write `(uint64_t)0`.
>
>stdint.h also provides an UINT64_C(...) macro that could be used,
>though, as you say, 0 is really all that's needed in this case.

OTOH, all the systems the code in question run typedef uint64_t to unsigned
long, so the 'ul' suffix works correctly in all forseeable usages in this
application. And it's less to type than casting. Granted it's not
particularly meaningful in the 0ul case, but it's a habit that does
come in handy in expressions like

uint64_t address;
address = (0xcul << 44) | ((uint64_t)node << 44) | (device << 32) | register_offset;

Yes, a cast on the constant would work as well. And yes, a good compiler
will warn if the suffix is missing from the first constant value.

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>On Tue, 13 Feb 2024 14:19:20 -0800, Keith Thompson wrote:
>
>> But C has a *lot* of precedence levels, and they're not all obvious.
>>
>> If I see `a | b ^ c`, I'm not likely to remember off the top of my head
>> ...
>
>So don’t remember “off the top of your head”: keep the docs handy. That’s
>what I do.

Why? The code is easier to read and maintain if the precedence is
made explicit.

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> On Mon, 12 Feb 2024 12:23:35 +0100, David Brown wrote:
>> Do you know what "incompatible types" are, and what they mean? Do you
>> realise that they cannot be swapped around as you suggest?
>
> And yet, all the examples posted so far have involved, not the actual
> types, but pointers to them.

Because pointers to incompatible types are a good way to demonstrate
incompatibility.

Two types can be incompatible even if there are implicit conversions
between them. For example:

int i = 0;
long l = 0;
i = l;
l = i;

This is valid code that does not demonstrate the fact that int and long
are incompatible. But if two types foo and bar are incompatible, then
foo* and bar* are also incompatible *and there are no implicit
conversions between foo* and bar*. That's why the examples use
pointers.

int i = 0;
int *pi = &i;
long l = 0;
long *pl = &l;
i = l; // valid even though int and long are incompatible
pi = pl; // constraint violation because int and long are incompatible

Do you understand that int and long are incompatible even though they're
implicitly convertible, even if they happen to have the same size and
representation? Do you understand what "incompatible types" are? If
not, please consult the standard. If you're using C11 or N1570, start
with section 6.2.7, "Compatible type and composite type" (or the
equivalent subsection in another edition).

Finally, upthread in reponse to Ben's statement:
```
The type of c == d is int, but the value will be either 0 or 1.
```

you wrote:
```
That is the only kind of “boolean” C has.
```

Can you explain exactly what you meant by that? It could easily mean
that you think that int values of 0 and 1 are the only kind of boolean C
has, which is clearly incorrect.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

scott@slp53.sl.home (Scott Lurndal) writes:
> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
[...]
>>> There's no suffix for uint64_t. 0ul is of type unsigned long, which may
>>> or may not be the same type as uint64_t.
>>>
>>> In this particular case, I'd just use 0. If for some reason I needed to
>>> make it explicitly of type uint64_t (say, for an argument to a variadic
>>> function), I'd write `(uint64_t)0`.
>>
>>stdint.h also provides an UINT64_C(...) macro that could be used,
>>though, as you say, 0 is really all that's needed in this case.
>
> OTOH, all the systems the code in question run typedef uint64_t to unsigned
> long, so the 'ul' suffix works correctly in all forseeable usages in this
> application. And it's less to type than casting. Granted it's not
> particularly meaningful in the 0ul case, but it's a habit that does
> come in handy in expressions like
>
> uint64_t address;
> address = (0xcul << 44) | ((uint64_t)node << 44) | (device << 32) | register_offset;
>
> Yes, a cast on the constant would work as well. And yes, a good compiler
> will warn if the suffix is missing from the first constant value.

There are certainly systems (including Windows and 32-bit Linux) where
unsigned long is 32 bits. On such systems uint64_t is likely to be
defined as unsigned long long. Even where unsigned long is 64 bits, an
implementation could define uint64_t as unsigned long long.

I think it's a bad idea to make assumptions about which underlying types
are used for the fixed-width types. I might write the above as:

uint64_t address;
address = ((uint64_t)0xc << 44) | ((uint64_t)node << 44) | (device << 32) | register_offset;

(I presume device and register_offset are of type uint64_t.)

I don't think I've ever used the UINT64_C() macro, but that's another
possibility. It's less ugly than the format macros in <inttypes.h>.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

On 14/02/2024 21:47, Scott Lurndal wrote:
> bart <bc@freeuk.com> writes:
>> On 14/02/2024 20:07, Richard Harnden wrote:
>
>>> Do you really expect a non-trivial program to consist on only one source
>>> file?  How would that work with many people all working on the some
>>> file?  Merges would be a nightmare.
>>>
>>
>> I don't understand your comment or how it fits in with what I'm saying.
>>
>> NETPPM apparently consists of 100s of small, individual programs. Even
>> SL agreed they were trivial. Many seem to be implemented as a single C
>> file to perform the task.
>>
>> So why can't I compile even one such file?
>
> That is entirely _your_ problem.

Bollocks it is.

Somebody could add even extra layers of pointless complexity to the
build process, but who would notice?

There appears to be nobody in Unix who questions such things; everyone
takes takes at face value. So long as it eventually produces a result,
no matter how long it takes or how torturous the process, nobody cares.

Well, have you considered that that may have alread happened?

> The source is freely available. Why don't you look at it instead
> of complaining about it?

I've spent an hour looking at the 270,000 lines of source code. I was
going to extract bits of to put together one mini app, but I eventually
lost the will to live.

Here, why write one line when half a dozen will do? Why not chain a
dozen function calls needlessly just to make it harder to hunt down the
underlying function? Urghh...

It's not how I'd write it.

> I've never read so many complaints from one person.

Here's a challenge: give me a reason not to complain.

>> What /would/ impress me more is a portable, non-partisan C library that
>> is able to stand by itself with zero dependencies.
>
> Feel free to develop one yourself if you think it is so easy. Make sure
> it builds and functions correctly on all the mainstream operating systems,
> including android, IOS, Linux, Windows and the legacy Unix distributions.

What exactly is it about reading one file and writing another that you
think makes that so challenging? Are you not aware that dealing with
different platforms is the compiler's job?

In any case, I've written so much image-handling stuff that I could do
it in my sleep.

With my current library, inverting an image looks like this when
accessed from scripting code:

a := bmload("test.pgm")
bmsave("itest.pgm", bmneg(a))

I do need help with complex compressed formats like JPG and PNG which
need external support. But those are in hand using C solutions that ARE
more amenable to use. I can pass those through my C compiler to create s
suitable DLL.

On 2024-02-15, bart <bc@freeuk.com> wrote:
> There appears to be nobody in Unix who questions such things; everyone
> takes takes at face value. So long as it eventually produces a result,
> no matter how long it takes or how torturous the process, nobody cares.

This is false. There are many critics "in Unix", of Makefiles, GNU
Autotools, the C language including its preprocessing, the shell
language, various utilities, POSIX API's, and almost imaginable element
of the whole cornucopia. Many are well-informed, experienced and have
well-reasoned opinions.

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

Michael S <already5chosen@yahoo.com> writes:

[.. should 'a += b += c;' be disallowed for style reasons? ..]

> It's actually highly confusing for me as well.
> For reasons I am not fully understand, it is interpreted as
> a += (b += c)
> which is obviously legal.
> I don't understand why it isn't interpreted as
> (a += b) += c
> which is [a little less obviously] illegal.

Here is another way to think about it.

C (and many or most other languages) are fairly strict about what
is allowed on the left-hand side of an assignment. For example,

a + b += c;

is not allowed. Neither is

(a + b) += c;

although the reasoning is a little different in the two cases,
neither is allowed, because neither one makes sense.

By analogy with the second example, the statement

(a += b) += c;

isn't allowed, because the left-hand side is wrong. So if we
see

a += b += c;

it would be silly to parse it as

(a += b) += c;

because that's illegal. The only other way to parse it, viz.,

a += (b += c);

passes the semantic prerequisites. Since it's the only way that
makes sense, it seems natural that (without any parentheses) the
syntax should reflect that.

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>
>> scott@slp53.sl.home (Scott Lurndal) writes:
>>
>>> Michael S <already5chosen@yahoo.com> writes:
>>>
>>>> On Tue, 13 Feb 2024 16:59:38 -0800
>>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>>>>
>>>>> Though personally, I'd probably make the assignment the operand of a
>>>>> larger expression. I understand that
>>>>> if (foo)
>>>>> is a common idiom where foo is of any scalar type, but I personally
>>>>> prefer to write one of
>>>>> if (foo != 0)
>>>>> if (foo != '\0')
>>>>> if (foo != 0.0)
>>>>> if (foo != NULL)
>>>>> because I find it clearer (unless foo is of type bool or is otherwise
>>>>> appropriate to use directly as a condition).
>>>>>
>>>>> Thus if x and y are ints, I'd probably write:
>>>>> if ((x = y) != 0)
>>>>> (Assuming I'm not required to follow MISRA rules.)
>>>>>
>>>>> YMMV.
>>>>
>>>> Agreed with two small exception:
>>>> (1) I never write '\0' myself always preferring plain 0.
>>>
>>> I'm in Keith's camp here when working with a char type, I'll
>>> use '\0' rather than plain zero.
>>>
>>> I tend to suffix constants as well if they're not being
>>> used as 'int', perhaps a bit too picky?
>>>
>>> uint64_t v;
>>> ...
>>> if (v == 0ul) ...
>>
>> There's no suffix for uint64_t. 0ul is of type unsigned long,
>> which may or may not be the same type as uint64_t.
>>
>> In this particular case, I'd just use 0. If for some reason I
>> needed to make it explicitly of type uint64_t (say, for an argument
>> to a variadic function), I'd write `(uint64_t)0`.
>
> stdint.h also provides an UINT64_C(...) macro that could be used,
> though, as you say, 0 is really all that's needed in this case.

Using UINT64_C(...) to make a constant of type uint64_t is a bit
too sneaky for my taste. Despite what may appear to the be case,
UINT64_C(...) produces a constant of type uint_least64_t, not
uint64_t. Of course if the implementation does have a uint64_t
type, then UINT64_C(...) will have the same width (but not
necessarily the same type) as uint64_t, but the roundabout logic
still bothers me.

scott@slp53.sl.home (Scott Lurndal) writes:

> Michael S <already5chosen@yahoo.com> writes:
>
>> On Tue, 13 Feb 2024 16:59:38 -0800
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>>
>
>>>
>>> Though personally, I'd probably make the assignment the operand of a
>>> larger expression. I understand that
>>> if (foo)
>>> is a common idiom where foo is of any scalar type, but I personally
>>> prefer to write one of
>>> if (foo != 0)
>>> if (foo != '\0')
>>> if (foo != 0.0)
>>> if (foo != NULL)
>>> because I find it clearer (unless foo is of type bool or is otherwise
>>> appropriate to use directly as a condition).
>>>
>>> Thus if x and y are ints, I'd probably write:
>>> if ((x = y) != 0)
>>> (Assuming I'm not required to follow MISRA rules.)
>>>
>>> YMMV.
>>
>> Agreed with two small exception:
>> (1) I never write '\0' myself always preferring plain 0.
>
> I'm in Keith's camp here when working with a char type, I'll
> use '\0' rather than plain zero.
>
> I tend to suffix constants as well if they're not being
> used as 'int', perhaps a bit too picky?
>
> uint64_t v;
> ...
> if (v == 0ul) ...

You say what you do but don't say why. Can you explain your
rationale or motivation?

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

> scott@slp53.sl.home (Scott Lurndal) writes:
>
>> Michael S <already5chosen@yahoo.com> writes:
>>
>>> On Tue, 13 Feb 2024 16:59:38 -0800
>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>>>
>>>> Though personally, I'd probably make the assignment the operand
>>>> of a larger expression. I understand that
>>>> if (foo)
>>>> is a common idiom where foo is of any scalar type, but I
>>>> personally prefer to write one of
>>>> if (foo != 0)
>>>> if (foo != '\0')
>>>> if (foo != 0.0)
>>>> if (foo != NULL)
>>>> because I find it clearer (unless foo is of type bool or is
>>>> otherwise appropriate to use directly as a condition).
>>>>
>>>> Thus if x and y are ints, I'd probably write:
>>>> if ((x = y) != 0)
>>>> (Assuming I'm not required to follow MISRA rules.)
>>>>
>>>> YMMV.
>>>
>>> Agreed with two small exception:
>>> (1) I never write '\0' myself always preferring plain 0.
>>
>> I'm in Keith's camp here when working with a char type, I'll
>> use '\0' rather than plain zero.
>>
>> I tend to suffix constants as well if they're not being
>> used as 'int', perhaps a bit too picky?
>>
>> uint64_t v;
>> ...
>> if (v == 0ul) ...
>
> There's no suffix for uint64_t. 0ul is of type unsigned long,
> which may or may not be the same type as uint64_t.
>
> In this particular case, I'd just use 0. If for some reason I
> needed to make it explicitly of type uint64_t (say, for an
> argument to a variadic function), I'd write `(uint64_t)0`.

Ick. At least write '(uint64_t){ 0 }' rather than casting.

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Michael S <already5chosen@yahoo.com> writes:
[...]
> Here is another way to think about it.
>
> C (and many or most other languages) are fairly strict about what
> is allowed on the left-hand side of an assignment. For example,
>
> a + b += c;
>
> is not allowed. Neither is
>
> (a + b) += c;
>
> although the reasoning is a little different in the two cases,
> neither is allowed, because neither one makes sense.
>
> By analogy with the second example, the statement
>
> (a += b) += c;
>
> isn't allowed, because the left-hand side is wrong. So if we
> see
>
> a += b += c;
>
> it would be silly to parse it as
>
> (a += b) += c;
>
> because that's illegal. The only other way to parse it, viz.,
>
> a += (b += c);
>
> passes the semantic prerequisites. Since it's the only way that
> makes sense, it seems natural that (without any parentheses) the
> syntax should reflect that.

I don't think that reasoning is entirely solid.

The same reasoning might imply that because x+++++y is legal only if
it's parsed as x++ + ++y, then it makes sense for the syntax to reflect
that. But in fact the syntax isn't defined that way, and x+++++y is a
syntax error (parsed as x ++ ++ + y).

a += b += c parses the way it does because of the way the syntax is
defined, with assignment associating right-to-left. It needn't have
been defined that way, and if assignment associated left-to-right it
would require parentheses to make it valid. In such a hypothetical
not-quite-C language, parsing a += b += c as (a += b) += c would not be
at all silly.

It's true (I think) that assignment associates right-to-left because
that's more convenient.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
[...]
>> In this particular case, I'd just use 0. If for some reason I
>> needed to make it explicitly of type uint64_t (say, for an
>> argument to a variadic function), I'd write `(uint64_t)0`.
>
> Ick. At least write '(uint64_t){ 0 }' rather than casting.

Why?

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

scott@slp53.sl.home (Scott Lurndal) writes:

> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>
>> On Tue, 13 Feb 2024 14:19:20 -0800, Keith Thompson wrote:
>>
>>> But C has a *lot* of precedence levels, and they're not all
>>> obvious.
>>>
>>> If I see `a | b ^ c`, I'm not likely to remember off the top of my
>>> head ...
>>
>> So don't remember off the top of your head, [just] keep the docs
>> handy. That's what I do.
>
> Why? The code is easier to read and maintain if the precedence is
> made explicit.

Every serious C developer should know all the operator precedence
relationships without having to look them up.

In cases where it is still felt necessary to indicate how different
operators parse with respect to one another, it's better to do that
using spacing than with parentheses, as for example

a | b^c

or

alpha | beta ^ gamma

On 14.02.2024 15:29, David Brown wrote:
> On 14/02/2024 13:26, Janis Papanagnou wrote:
>> On 14.02.2024 09:46, David Brown wrote:
>>>
>>> I hadn't done much with C++ before then. At that time, most of my
>>> professional programming was in assembly (on small microcontrollers) and
>>> Pascal, with only some C.
>>
>> I'm surprised that Pascal was in professional use back then.[*]
>> Pascal had always been derided as "academic" or "toy" language.
>
> In the DOS/Windows world, Pascal was a major language for a long time -
> starting with Turbo Pascal, then Borland Pascal for DOS then Windows,
> then Delphi. Delphi's descendants are still in heavy use for Windows
> development. (And dotnet came from Delphi and related projects.)

Yes, I'm aware of the "popularity" (as Michael called it) of especially
the Turbo and Borland Pascal dialects [on DOS]. Being platform specific
(for a "personal computer" platform) and being dialects they have never
really been an option for our usage; popularity in general - and surely
in DOS contexts! - was never a criterion for us. (Using standards was,
though!) Yet, beyond popularity on DOS, I haven't heared much about it.
Other languages of the Pascal languages branch, like Ada, certainly had
their professional application areas (in aeronautics, for example)! But
Pascal?

Janis

On 14.02.2024 21:52, Lawrence D'Oliveiro wrote:
> On Wed, 14 Feb 2024 00:18:50 +0100, Janis Papanagnou wrote:
>
>> Though most precedence rules in C make parenthesis usually unnecessary
>> and expressions rarely need parenthesis to provide that certainty.
>
> And yet you were the one who added unnecessary ones in your example, I
> didn’t.

Yes, and I explained that with the given rules you have no "clutter"
(as you called it), so that you can use them even if [by precedence]
unnecessary, to make (a few) specific contexts _clearer_ (i.e. the
opposite of clutter).

Janis

On 14.02.2024 13:32, David Brown wrote:
> On 14/02/2024 11:43, Malcolm McLean wrote:
>
>> The whole point of using C s to get away from the ad hoc scripting
>> language that you don't use frequently enough to remember exactly how
>> it works, and to use something familiar. So we do want a C
>> interpreter, not a "C-like interpreter" to add yet another language
>> with its own quirks to the mess which Bart has so correctly identiifed.
>
> Please stop using the "royal we" to mean you, personally. If there were
> many people wanting C interpreters for writing scripts, there would be
> lots of C interpreters and lots of scripts written in C. The reality is
> that there is one dead project, and there's tcc's script mode - but I
> have never heard of it being used in practice. Meanwhile, there are
> vast numbers of C programmers, and vast amounts of scripts written in
> Bash, Perl, Python, TCL, and other languages suitable for scripting.
> That should be a good indication that few people feel the need for
> writing scripts in C, even if they are familiar with C.

It's worth to add Awk to your list of script languages, since it's
standard on Unix, and its syntax largely resembles the syntax of C.

Janis

On Tue, 13 Feb 2024 13:20:06 -0800, Keith Thompson wrote:

> Early Unix did have some methods for accomodating
> upper-case-only keyboards, some of which survive to the present.

As I recall, if you typed your username all in uppercase when logging in,
the login (getty?) program set a terminal mode that converted all
uppercase to lowercase on input, and all lowercase to uppercase on output.

Sort of a “passive-aggressive” case-conversion mode, if you like ...

On Wed, 14 Feb 2024 21:53:37 GMT, Scott Lurndal wrote:

> address = (0xcul << 44) | ((uint64_t)node << 44) | (device << 32) | register_offset;

I did say parenthesis clutter seemed to be a common affliction among C
programmers, didn’t I?

address = 0xcul << 44 | (uint64_t)node << 44 | device << 32 | register_offset;

On Wed, 14 Feb 2024 14:38:01 -0800, Keith Thompson wrote:

> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>
>> And yet, all the examples posted so far have involved, not the actual
>> types, but pointers to them.
>
> Because pointers to incompatible types are a good way to demonstrate
> incompatibility.

But it was those types I was talking about, not pointers to them.

On Wed, 14 Feb 2024 15:29:00 +0100, David Brown wrote:

> In the DOS/Windows world, Pascal was a major language for a long time -
> starting with Turbo Pascal, then Borland Pascal for DOS then Windows,
> then Delphi. Delphi's descendants are still in heavy use for Windows
> development. (And dotnet came from Delphi and related projects.)

In the PC world generally, UCSD Pascal and its offshoots (of which Turbo
Pascal was one) were very popular.

The UCSD p-system pioneered the concept of “write once, run anywhere”, by
defining a standardized p-code interpreter that could be implemented
across a whole range of different processor architectures. Once you had
done that, plus some basic OS routines, the main part of the software,
written in Pascal, should port straight across.

Yes, there was a performance hit. But many people considered it worth
avoiding the pain of having to rewrite your code.

On Tue, 13 Feb 2024 16:55:32 +0100, Janis Papanagnou wrote:

> You are mistaken; C++ had no 'bool' type initially. It had been added
> later.

The first version of the C++ standard was C++98, and that had bool in it.

On Thu, 15 Feb 2024 08:23:09 +0100, Janis Papanagnou wrote:

> It's worth to add Awk to your list of script languages, since it's
> standard on Unix, and its syntax largely resembles the syntax of C.

Perl does everything Awk can do, and do it just as concisely, and it can
do more besides.

On Thu, 15 Feb 2024 01:07:33 +0000, bart wrote:

> Bollocks it is.

You keep insisting so. It would be simple enough to prove your point, by
stripping out this “needless” complexity and proving you can build the
code much more simply.

Otherwise, you just fall into the “methinks he doth protest too much”
school of Windows sufferers.