To C or not to C++

[Alan Beck]

//Hello All,//

I decided I wanted to learn C programming so I can solve problems with
software instead of hardware.

I have an arduino and am learning it.


Shouod I be learing C,C++ or Arduino "sketch" language.

I have books for all three.l

Thand beforo hand



Regards,
Alan Beck

[Paavo Helde]

08.08.2022 09:43 Alan Beck kirjutas:
>
> //Hello All,//
>
> I decided I wanted to learn C programming so I can solve problems with
> software instead of hardware.
>
> I have an arduino and am learning it.
>
>
> Shouod I be learing C,C++ or Arduino "sketch" language.
>

The wikipedia page for Arduino says it can be programmed either in C or
C++, and "sketch" seems to be a specific C or C++ program composed in
Arduino IDE.

So it looks like you will probably need Sketch and either C or C++. When
choosing, note that C is at least 10 times smaller and easier to learn
than C++, but this also means you will need to make everything by
yourself. You can think of C as a hand saw and C++ as a lathe machine.
In principle you can make everything with a hand saw, it just takes more
effort, whereas using machines means more initial investments.

[Juha Nieminen]

Alan Beck <NOSPAM.A...@darkrealms.ca> wrote:
> //Hello All,//
>
> I decided I wanted to learn C programming so I can solve problems with
> software instead of hardware.
>
> I have an arduino and am learning it.
>
> Shouod I be learing C,C++ or Arduino "sketch" language.

I suppose it depends on the kind of programming you would be doing.

The syntax and standard library of C may be the quickest to learn
because it's not very large. And C as a programming language is
quite ok for many types of application. However, because of its
bare-minimum simplicity some things are extraordinarily hard and/or
tedious (and error-prone) to do with it (especially when it comes
to dynamic memory management and generic data containers. The more
complicated the dynamic data container, the more difficult, tedious
and error-prone it will be to do in C. Not all applications need
such containers, though, so it depends.)

C++ is a significantly larger language, with a significantly larger
syntax and standard library. However, in terms of efficiency it has
nothing to lose to C, and many things are much easier and safer to do
with it (the standard library provides many generic dynamic data
containers that are quite easy to use and which handle dynamic memory
allocation and deallocation automatically, without you having to
bother, as long as you follow a few rules). There are many things that
are much easier to do in C++ than in C. (The other way around doesn't
really exist because pretty much anything you can do in C you can
also do in C++ in the exact same way, or extremely similar way.)
On the other hand, the amount of documentation on syntax and standard
library is vastly larger. So there are pros and cons.

I have never even heard of the "sketch" language so I can't comment.
If I had to make a completely wild guess it's probably some kind of
"higher-level" language with its own pros and cons compared to both
C and C++.

[Ralf Fassel]

* Juha Nieminen <nos...@thanks.invalid>

| I have never even heard of the "sketch" language so I can't comment.
| If I had to make a completely wild guess it's probably some kind of
| "higher-level" language with its own pros and cons compared to both
| C and C++.

On the Arduino, you usually only write the loop() (in C/C++) which
handles incoming events, plus interrupt functions etc, whereas main() is
provided by the IDE.

This code piece is called a 'sketch', which you compile and download to
the arduino.

R'

[Bonita Montero]

You can program an Arduino with a limited C++-subset but
I don't see any use in that because Arduino programs are
always very small.

[Mut...@dastardlyhq.com]

On Tue, 9 Aug 2022 12:31:07 +0200
Bonita Montero <Bonita....@gmail.com> wrote:
>Am 08.08.2022 um 09:43 schrieb Alan Beck:
>>
>> //Hello All,//
>>
>> I decided I wanted to learn C programming so I can solve problems with
>> software instead of hardware.
>>
>> I have an arduino and am learning it.
>>
>>
>> Shouod I be learing C,C++ or Arduino "sketch" language.
>>
>> I have books for all three.l
>>
>> Thand beforo hand
>
>You can program an Arduino with a limited C++-subset but

AFAIK the Arduino IDE just uses gcc with main() somehow built in already
(anyone know how it does it, just an .h file include or something more?) and
useful bits of C++ such as the STL left out because the binary wouldn't
have a chance of fitting in the arduinos memory.

[Manfred]

On 8/9/2022 11:07 AM, Ralf Fassel wrote:
> * Juha Nieminen <nos...@thanks.invalid>
> | I have never even heard of the "sketch" language so I can't comment.
> | If I had to make a completely wild guess it's probably some kind of
> | "higher-level" language with its own pros and cons compared to both
> | C and C++.
>
> On the Arduino, you usually only write the loop() (in C/C++)

Note that the expression (C/C++) is considered a Bad Word nowadays.
The fact is that, even if in principle a C code fragment can be compiled
as C++ code, which might suggest the two languages are closely related,
in truth they are now very different languages, so that they can't be
mixed with each other.
If you are writing code that compiles both as C and C++, then you are in
fact writing C code, not C++.

It may or may not be important to you, but if you show up at a job
interview talking about C/C++, you will effectively show up as someone
who does not know what they are talking about, so beware.

[Keith Thompson]

Manfred <non...@add.invalid> writes:
> On 8/9/2022 11:07 AM, Ralf Fassel wrote:
>> * Juha Nieminen <nos...@thanks.invalid>
>> | I have never even heard of the "sketch" language so I can't comment.
>> | If I had to make a completely wild guess it's probably some kind of
>> | "higher-level" language with its own pros and cons compared to both
>> | C and C++.
>> On the Arduino, you usually only write the loop() (in C/C++)
>
> Note that the expression (C/C++) is considered a Bad Word nowadays.
> The fact is that, even if in principle a C code fragment can be
> compiled as C++ code, which might suggest the two languages are
> closely related, in truth they are now very different languages, so
> that they can't be mixed with each other.

Agreed, mostly.

> If you are writing code that compiles both as C and C++, then you are
> in fact writing C code, not C++.

Or you might in fact be writing C++ code. Which it is depends on which
compiler you intended to feed it to. It might be a fragment of a larger
C++ program that doesn't happen to use any C++-specific features.

Or you *might* have a good reason to want to write code that compiles
both as C and as C++, but such reasons are rare in my experience, and
are not what the term "C/C++" refers to.

(And of course you need to beware of the cases where the same code is
valid C and valid C++ but with different meanings.)

> It may or may not be important to you, but if you show up at a job
> interview talking about C/C++, you will effectively show up as someone
> who does not know what they are talking about, so beware.

Maybe. There's a fair chance that the person you're talking to thinks
"C/C++" actually means something.

> which
>> handles incoming events, plus interrupt functions etc, whereas main() is
>> provided by the IDE.
>> This code piece is called a 'sketch', which you compile and download
>> to
>> the arduino.
>> R'

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

[Juha Nieminen]

Manfred <non...@add.invalid> wrote:
> If you are writing code that compiles both as C and C++, then you are in
> fact writing C code, not C++.

Not really. Just because it might compile if interpreted as C doesn't mean
it's actually intended to be compiled as C.

For example if you write a 'const' variable at the global scope you
might not be intending for it to have external linkage.

If you write an 'inline' function, it may so happen to compile as C,
but it doesn't actually make it valid C (because in C 'inline' has more
requirements than it does in C++).

[Malcolm McLean]

On Wednesday, 10 August 2022 at 01:52:58 UTC+1, Keith Thompson wrote:

> Manfred <non...@add.invalid> writes:
>
> > It may or may not be important to you, but if you show up at a job
> > interview talking about C/C++, you will effectively show up as someone
> > who does not know what they are talking about, so beware.
> Maybe. There's a fair chance that the person you're talking to thinks
> "C/C++" actually means something.
>

Generally people who recruit programmers are competent. You don't reject
a good candidate for that reason.
C++ compilers always ship with C compilers, and it is quite common to
see programs which are a mixture of C and C++ files. It's also quite common
to see functions which are C, or effectively C, in C++ source.
There are many reasons, but a common one is that the code is doing something
which is algorithmically difficult. It can only be written by an expert, and is
valuable. If it is written in C, it's likely easier to integrate into new programs.

[Mut...@dastardlyhq.com]

On Wed, 10 Aug 2022 02:25:18 +0200
Manfred <non...@add.invalid> wrote:
>On 8/9/2022 11:07 AM, Ralf Fassel wrote:
>> * Juha Nieminen <nos...@thanks.invalid>
>> | I have never even heard of the "sketch" language so I can't comment.
>> | If I had to make a completely wild guess it's probably some kind of
>> | "higher-level" language with its own pros and cons compared to both
>> | C and C++.
>>
>> On the Arduino, you usually only write the loop() (in C/C++)
>
>Note that the expression (C/C++) is considered a Bad Word nowadays.
>The fact is that, even if in principle a C code fragment can be compiled
>as C++ code, which might suggest the two languages are closely related,
>in truth they are now very different languages, so that they can't be
>mixed with each other.
>If you are writing code that compiles both as C and C++, then you are in
>fact writing C code, not C++.
>
>It may or may not be important to you, but if you show up at a job
>interview talking about C/C++, you will effectively show up as someone
>who does not know what they are talking about, so beware.

Depends on the job requirements. Some places require knowledge of both
languages and someone good with C++ isn't always good at writing efficient C.

[Mut...@dastardlyhq.com]

On most (all?) versions of Unix C++ has to be wrapped in a C API to be called
from shared object files.

[David Brown]

On 10/08/2022 02:25, Manfred wrote:
> On 8/9/2022 11:07 AM, Ralf Fassel wrote:
>> * Juha Nieminen <nos...@thanks.invalid>
>> | I have never even heard of the "sketch" language so I can't comment.
>> | If I had to make a completely wild guess it's probably some kind of
>> | "higher-level" language with its own pros and cons compared to both
>> | C and C++.
>>
>> On the Arduino, you usually only write the loop() (in C/C++)
>
> Note that the expression (C/C++) is considered a Bad Word nowadays.

That wording implies that it was once a more acceptable term - I don't
think anyone knowledgable in the two languages has been happy about
conflating them. (It's fine to say "C /and/ C++", or "C /or/ C++".)

But a lot of people with less knowledge and experience do mix the
language names, and think of them as variants or at least that C++ is
just "C with some extra features". And the Arduino targets relative
beginners, and goes out of its way to try to hide that kind of
"complexity" from users.

> The fact is that, even if in principle a C code fragment can be compiled
> as C++ code, which might suggest the two languages are closely related,
> in truth they are now very different languages, so that they can't be
> mixed with each other.

They /are/ very closely related languages - and most well-written C code
can be turned into working C++ code with only a few changes (such as
casting the result of calls to malloc - the casts are perfectly fine in
C, but not idoimatic) and without a change in functionality. C is the
base language on which C++ builds.

And yes they /can/ be mixed, and they /are/ mixed. C++ is designed to
be easy to mix with C, and incompatibilities are not made without good
reason. Indeed, a good deal of the things people dislike about C++, or
that are not "good modern language design", trace back to compatibility
with C.

One area of programming where C and C++ are regularly mixed, is
resource-constrained embedded systems. You can easily have a project
with an RTOS in C90, some libraries in C99, application code in C++ of
some sort, drivers in modern C - a full mix. Typically the only code
that is compiled as both C and C++ is the C headers, but you sometimes
get more complicated headers that provide different features depending
on the language at the time.

> If you are writing code that compiles both as C and C++, then you are in
> fact writing C code, not C++.

That's just silly. You are, in fact, writing code that is C code /and/
C++ code. It might not be idiomatic code, but it is perfectly valid.

Some people are under the mistaken impression that to be "real" C++, you
need to use lots of C++ features - that code is not "real" C++ unless it
has classes (preferably with lots of inheritance, virtual methods,
etc.), templates, standard library container classes, and the like.
That's nonsense. /Real/ programmers - i.e., people who make a living as
programmers - know there are many ways to design code and many ways to
implement it, with different pros and cons. C++ is a multi-paradigm
language designed to support a huge range of different styles of code.
If the only difference between your C code and your C++ code is that you
use "enum class" instead of "enum" to make your code safer, you are
writing C++ code.

>
> It may or may not be important to you, but if you show up at a job
> interview talking about C/C++, you will effectively show up as someone
> who does not know what they are talking about, so beware.
>

That is perhaps true for technical interviews, but before you get to
that stage you often have to pass through layers of HR folk who really
do think there is a language called "C/C++" (and who also want
candidates with 10 years of Rust experience).

[Ralf Fassel]

* Manfred <non...@add.invalid>

| > On the Arduino, you usually only write the loop() (in C/C++)
>
| Note that the expression (C/C++) is considered a Bad Word nowadays.

--<snip-snip>--

>
| It may or may not be important to you, but if you show up at a job
| interview talking about C/C++, you will effectively show up as someone
| who does not know what they are talking about, so beware.

Thanks for the hint. I indeed meant "C or C++" instead of implying
C and C++ are somehow interchangeable.

R', time to stop trying to save bandwidth, I guess .-)

[Keith Thompson]

Sure, but "C/C++" isn't a good way to say that. You never see "C/Java".

[Scott Lurndal]

Keith Thompson <Keith.S.T...@gmail.com> writes:

>Manfred <non...@add.invalid> writes:

>
>> If you are writing code that compiles both as C and C++, then you are
>> in fact writing C code, not C++.
>
>Or you might in fact be writing C++ code. Which it is depends on which
>compiler you intended to feed it to. It might be a fragment of a larger
>C++ program that doesn't happen to use any C++-specific features.

Or you might be writing code to solve a problem and realize that
calling it C, C++, C/C++ or fred doesn't matter so long as the
program solves the problem.

[Keith Thompson]

It matters because it's not going to solve the problem unless you feed
it to a language-specific compiler. If you don't intend to do that,
you're writing pseudo-code.

[Manfred]

On 8/10/2022 10:13 AM, David Brown wrote:
> On 10/08/2022 02:25, Manfred wrote:
>> On 8/9/2022 11:07 AM, Ralf Fassel wrote:
>>> * Juha Nieminen <nos...@thanks.invalid>
>>> | I have never even heard of the "sketch" language so I can't comment.
>>> | If I had to make a completely wild guess it's probably some kind of
>>> | "higher-level" language with its own pros and cons compared to both
>>> | C and C++.
>>>
>>> On the Arduino, you usually only write the loop() (in C/C++)
>>
>> Note that the expression (C/C++) is considered a Bad Word nowadays.
>
> That wording implies that it was once a more acceptable term - I don't
> think anyone knowledgable in the two languages has been happy about
> conflating them.  (It's fine to say "C /and/ C++", or "C /or/ C++".)

I first heard of C++ in the late '80s, and it was described to me as:
"It's C, wherein structs can contain functions" (which sounded
immediately as a cool feature to me).
At that time C/C++ was not a Bad Word™, and I think this was justified,
for 2 main reasons:
- C++ was still relatively young, and the view of C++ as a mere
evolution of C was still diffuse. It would take some more time for C++
programmers to gain more maturity and fully grasp the different
landscape of the two (see how many are still arguing that C code is C++
code as well, even today)
- C++11 had not happened, yet.

Today, none of the above is true.

>
> But a lot of people with less knowledge and experience do mix the
> language names, and think of them as variants or at least that C++ is
> just "C with some extra features".  And the Arduino targets relative
> beginners, and goes out of its way to try to hide that kind of
> "complexity" from users.
>
>> The fact is that, even if in principle a C code fragment can be
>> compiled as C++ code, which might suggest the two languages are
>> closely related, in truth they are now very different languages, so
>> that they can't be mixed with each other.
>
> They /are/ very closely related languages - and most well-written C code
> can be turned into working C++ code with only a few changes (such as
> casting the result of calls to malloc - the casts are perfectly fine in
> C, but not idoimatic) and without a change in functionality.  C is the
> base language on which C++ builds.

I disagree. If you program in C++, i.e. you model a problem domain in
C++ from scratch, then you end up with a /very/ different result than
you would if you used C.

>
> And yes they /can/ be mixed, and they /are/ mixed.  C++ is designed to
> be easy to mix with C, and incompatibilities are not made without good
> reason.  Indeed, a good deal of the things people dislike about C++, or
> that are not "good modern language design", trace back to compatibility
> with C.

What I mean by "mixed" here is in fact "confused". Nothing to do with
C++ calling C functions, and vice versa (however this might be accomplished)

>
> One area of programming where C and C++ are regularly mixed, is
> resource-constrained embedded systems.  You can easily have a project
> with an RTOS in C90, some libraries in C99, application code in C++ of
> some sort, drivers in modern C - a full mix.  Typically the only code
> that is compiled as both C and C++ is the C headers, but you sometimes
> get more complicated headers that provide different features depending
> on the language at the time.

Well, I think you agree that a C++ application using a C library is not
really about mixing the two languages, don't you?

>
>
>> If you are writing code that compiles both as C and C++, then you are
>> in fact writing C code, not C++.
>
> That's just silly.  You are, in fact, writing code that is C code /and/
> C++ code.  It might not be idiomatic code, but it is perfectly valid.

Again, I disagree. And it is not silly.

Let's take an example that makes some sense: you write some code that
involves a linked list (or any other container, for that matter) -
consider a C implementation and a C++ implementation.

Are you seriously arguing that the C implementation is a C++
implementation just as well?
(Please note that I /know/ that the C implementation would be legal C++
code. I'm just saying that if you write such a C implementation in a C++
program, then you are Doing It Wrong™)

[Manfred]

Or you might use Java, Python, Perl, ADA, Fortran, COBOL, ECMAScript -
and solve the same problem.
Does it mean they are all the same language?

[Juha Nieminen]

Manfred <non...@add.invalid> wrote:
> Note that the expression (C/C++) is considered a Bad Word nowadays.

I think pointing that out is quite nitpicky.

I believe the vast majority of people are using "C/C++" in a similar
manner as they would use eg. "and/or".

In other words, "C/C++" is simply shorthand for "C or C++ (inclusive)".

[Malcolm McLean]

On Thursday, 11 August 2022 at 03:26:05 UTC+1, Manfred wrote:
> On 8/10/2022 10:13 AM, David Brown wrote:
> > On 10/08/2022 02:25, Manfred wrote:
> >
> > They /are/ very closely related languages - and most well-written C code
> > can be turned into working C++ code with only a few changes (such as
> > casting the result of calls to malloc - the casts are perfectly fine in
> > C, but not idoimatic) and without a change in functionality. C is the
> > base language on which C++ builds.
> I disagree. If you program in C++, i.e. you model a problem domain in
> C++ from scratch, then you end up with a /very/ different result than
> you would if you used C.
> >

It depends what sort of programming you are doing. I work with algorithms.
For example the other day I was looking at nesting (the problem of packing
small objects into bins). There are several ways of approaching the problem,
none of which bear any relation to the programming language you happen
to be using.

> >
> >> If you are writing code that compiles both as C and C++, then you are
> >> in fact writing C code, not C++.
> >
> > That's just silly. You are, in fact, writing code that is C code /and/
> > C++ code. It might not be idiomatic code, but it is perfectly valid.
> Again, I disagree. And it is not silly.
>
> Let's take an example that makes some sense: you write some code that
> involves a linked list (or any other container, for that matter) -
> consider a C implementation and a C++ implementation.
>
> Are you seriously arguing that the C implementation is a C++
> implementation just as well?
> (Please note that I /know/ that the C implementation would be legal C++
> code. I'm just saying that if you write such a C implementation in a C++
> program, then you are Doing It Wrong™)
>

I've got several bits of code where you need two linked lists. The objects
are placed round the perimeter of closed shapes, so they have "previous"
and "next" members. However they are also in another ordering. For
instance if the shapes intersect and the goal is to create another shape
by joining intersections.
Often you need to split or delete the objects as part of processing.

The way I implement this is to just use the C method. I have "previncontour",
"nextincontour" and "previnresult", "nextinresult" pointer members.
It's maybe not the best way of doing it, but it is simple and it works.
However the code is C++, the objects are C++ classes rather than C
structs.

[Juha Nieminen]

Manfred <non...@add.invalid> wrote:
>> They /are/ very closely related languages - and most well-written C code
>> can be turned into working C++ code with only a few changes (such as
>> casting the result of calls to malloc - the casts are perfectly fine in
>> C, but not idoimatic) and without a change in functionality.  C is the
>> base language on which C++ builds.
>
> I disagree. If you program in C++, i.e. you model a problem domain in
> C++ from scratch, then you end up with a /very/ different result than
> you would if you used C.

Sometimes that's a good thing, sometimes not so much.

There's a portion of C++ programmers (thankfully a relatively small
portion in my experience) who think that anything that comes from C
should be avoided if there's a C++ equivalent. Combine that with a
lack of "know your tools" experience and it often results in code
that's more inefficient and wasteful than it would need to be.

My answer to that kind of mentality is always along the lines of,
for example, "std::fopen() *is* C++. If it's standard C++, then it's
C++. How can you even say that something supported by the C++ standard
is 'not C++'? Know your tools. If it's the best tool for a particular
task, then use it. It doesn't matter if it 'comes from C'. Who cares?
There are tons of things in C++ that 'come from C'. Would you avoid
using 'for' loops because they 'come from C'?"

[David Brown]

Yes, C++ was originally "C with classes", and it is not unreasonable to
have used the term "C/C++" in those early days. I was thinking from the
time when C++ became more established and standardised as a language of
choice for a lot of types of development. But I take your point.

>
>>
>> But a lot of people with less knowledge and experience do mix the
>> language names, and think of them as variants or at least that C++ is
>> just "C with some extra features".  And the Arduino targets relative
>> beginners, and goes out of its way to try to hide that kind of
>> "complexity" from users.
>>
>>> The fact is that, even if in principle a C code fragment can be
>>> compiled as C++ code, which might suggest the two languages are
>>> closely related, in truth they are now very different languages, so
>>> that they can't be mixed with each other.
>>
>> They /are/ very closely related languages - and most well-written C
>> code can be turned into working C++ code with only a few changes (such
>> as casting the result of calls to malloc - the casts are perfectly
>> fine in C, but not idoimatic) and without a change in functionality.
>> C is the base language on which C++ builds.
>
> I disagree. If you program in C++, i.e. you model a problem domain in
> C++ from scratch, then you end up with a /very/ different result than
> you would if you used C.
>

C++ is multi-paradigm. There is no single "C++ way" to model a task or
program. It can be done in lots of different ways, depending on the
task and the people working on it. The same applies to a fair extent to
C - I have seen plenty of C programs that are object oriented in design,
or event based, or have "actors" passing messages between them, or many
other ways to organise the C code. It may be true that much of C
programming is "plain imperative" - sets of functions that do things.
But it is not restricted to that.

Now, C++ certainly makes many other types of code structure and task
modelling easier - more natural in the language, more efficient to
write, more efficient at run-time, and better static checking. So when
deciding how to attack a programming task, you might pick different
approaches with C++ than with C, because of different balances in what
fits well with the language. But equally you might not do so - if the
problem lends itself to an imperative approach, you can do that in C++
too (and take advantage of better typing and other features that C does
not have).

>>
>> And yes they /can/ be mixed, and they /are/ mixed.  C++ is designed to
>> be easy to mix with C, and incompatibilities are not made without good
>> reason.  Indeed, a good deal of the things people dislike about C++,
>> or that are not "good modern language design", trace back to
>> compatibility with C.
>
> What I mean by "mixed" here is in fact "confused". Nothing to do with
> C++ calling C functions, and vice versa (however this might be
> accomplished)
>

Well, in that sense the languages most certainly /can/ be "mixed" - it
is done regularly. What you mean, I think, is that they should not be
mixed - you feel a programmer should either think, model and design in a
"C way" and program in C, or they should think, model and design in a
"C++ way" and program in C++.

While I think there is something in that argument, I don't see it as
clear-cut or absolute.

>>
>> One area of programming where C and C++ are regularly mixed, is
>> resource-constrained embedded systems.  You can easily have a project
>> with an RTOS in C90, some libraries in C99, application code in C++ of
>> some sort, drivers in modern C - a full mix.  Typically the only code
>> that is compiled as both C and C++ is the C headers, but you sometimes
>> get more complicated headers that provide different features depending
>> on the language at the time.
>
> Well, I think you agree that a C++ application using a C library is not
> really about mixing the two languages, don't you?
>

In embedded systems like this, everything is compiled together. Even if
you don't touch the library source code itself, it's common to have
hooks, user-defined macros, callbacks, and other connections so that the
library code can absolutely be using the programmer's own code. Plenty
of mixing goes on.

>>
>>
>>> If you are writing code that compiles both as C and C++, then you are
>>> in fact writing C code, not C++.
>>
>> That's just silly.  You are, in fact, writing code that is C code
>> /and/ C++ code.  It might not be idiomatic code, but it is perfectly
>> valid.
>
> Again, I disagree. And it is not silly.
>
> Let's take an example that makes some sense: you write some code that
> involves a linked list (or any other container, for that matter) -
> consider a C implementation and a C++ implementation.
>
> Are you seriously arguing that the C implementation is a C++
> implementation just as well?
> (Please note that I /know/ that the C implementation would be legal C++
> code. I'm just saying that if you write such a C implementation in a C++
> program, then you are Doing It Wrong™)
>

I appreciate what you are saying - I just think it is blatantly
incorrect to say the code is "C, not C++". What you mean is that it is
not /idiomatic/ C++ code. It is not code written in a way that /you/
would write it in C++.

C++ is used in a huge range of systems, with a huge range of different
requirements. You think that if someone needed a dynamically resizeable
list of items, in C++ they'd always reach for a std::vector while in C
they'd write it themselves, and therefore the languages are different.
When I program in C++, if I needed such a list I'd write it myself, far
closer to what you think of as "C style". The standard library
std::vector will not do what I need it to do, so I would not use it.
But what I write would still be C++.

[Mut...@dastardlyhq.com]

Last time I looked you couldn't compile C with a java compiler.

[Öö Tiib]

On Thursday, 11 August 2022 at 05:26:05 UTC+3, Manfred wrote:
> On 8/10/2022 10:13 AM, David Brown wrote:
> > On 10/08/2022 02:25, Manfred wrote:

...

> >> If you are writing code that compiles both as C and C++, then you are
> >> in fact writing C code, not C++.
> >
> > That's just silly. You are, in fact, writing code that is C code /and/
> > C++ code. It might not be idiomatic code, but it is perfectly valid.
>
> Again, I disagree. And it is not silly.
>
> Let's take an example that makes some sense: you write some code that
> involves a linked list (or any other container, for that matter) -
> consider a C implementation and a C++ implementation.
>
> Are you seriously arguing that the C implementation is a C++
> implementation just as well?
> (Please note that I /know/ that the C implementation would be legal C++
> code. I'm just saying that if you write such a C implementation in a C++
> program, then you are Doing It Wrong™)

Within single product variant tree it is good idea to use clear absolutes
and limits and compliances everywhere (like always, never, exactly one,
up to 200, C++14). That helps everybody involved to focus and narrow
what is done and how and under what constraints.

There can be rather obvious reasons for such single product team to
choose writing some program for some process of said product in
common subset of for example C11 and C++11. So as result that
program is indeed both C11 program and C++11 program. What is
here even to argue?

The code is unlikely to follow widespread idioms of programming in
either programming language. But saying that whatever was therefore
"done wrong" without being committed nor having clue what the product
does is silly™. How can one even dream to be capable to judge
adequately?

[Juha Nieminen]

Mut...@dastardlyhq.com wrote:
>>Sure, but "C/C++" isn't a good way to say that. You never see "C/Java".
>
> Last time I looked you couldn't compile C with a java compiler.

I'm somewhat certain that if you search enough you'll find a polyglot
program that will compile both as C and Java.

C is not 100% compatible with C++ either, so any "C code" that you might
write that just happens to compile and work the same in C++ is technically
speaking a C/C++ polyglot. (Sure, it's infinitely easier to write a C/C++
polyglot program than eg. a C/Java one, but still. C is not a pure subset
of C++.)

[Paavo Helde]

That's not the point. When someone talks about "C/C++" they imply that
the programming style and language syntax are so similar for both of
them that there is no need to differentiate between these languages, at
least for the discussion at hand.

Alas, the overlap of style and syntax similarities between idiomatic C
and C++ is pretty small and about the same size than between C and Java,
it's just that many people with only superficial familiarity with the
topic do not really understand that.

[Mut...@dastardlyhq.com]

On Fri, 12 Aug 2022 12:12:19 -0000 (UTC)
Juha Nieminen <nos...@thanks.invalid> wrote:
>Mut...@dastardlyhq.com wrote:
>>>Sure, but "C/C++" isn't a good way to say that. You never see "C/Java".
>>
>> Last time I looked you couldn't compile C with a java compiler.
>
>I'm somewhat certain that if you search enough you'll find a polyglot
>program that will compile both as C and Java.

I rather doubt that. You could #define "class", some class name and "public"
to nothing but you're not going to be able to do much about the extra curly
brackets around main() and C compilers don't like that.

>C is not 100% compatible with C++ either, so any "C code" that you might
>write that just happens to compile and work the same in C++ is technically
>speaking a C/C++ polyglot. (Sure, it's infinitely easier to write a C/C++
>polyglot program than eg. a C/Java one, but still. C is not a pure subset
>of C++.)

So what. Its enough of a subset to work 99.9% of the time.

[Mut...@dastardlyhq.com]

On Fri, 12 Aug 2022 15:55:57 +0300
Paavo Helde <ees...@osa.pri.ee> wrote:
>12.08.2022 11:23 Mut...@dastardlyhq.com kirjutas:
>> On Wed, 10 Aug 2022 10:11:00 -0700
>> Keith Thompson <Keith.S.T...@gmail.com> wrote:
>>> Sure, but "C/C++" isn't a good way to say that. You never see "C/Java".
>>
>> Last time I looked you couldn't compile C with a java compiler.
>
>That's not the point. When someone talks about "C/C++" they imply that
>the programming style and language syntax are so similar for both of
>them that there is no need to differentiate between these languages, at
>least for the discussion at hand.
>
>Alas, the overlap of style and syntax similarities between idiomatic C
>and C++ is pretty small and about the same size than between C and Java,

Rubbish. I've got multi thousand line originally C programs which I've happily
compiled with C++ compilers in C++ mode due to a few minor C++ additions.

>it's just that many people with only superficial familiarity with the
>topic do not really understand that.

I think the lack of understanding is with you.

[Paavo Helde]

12.08.2022 17:43 Mut...@dastardlyhq.com kirjutas:
>
> Rubbish. I've got multi thousand line originally C programs which I've happily
> compiled with C++ compilers in C++ mode due to a few minor C++ additions.

This does not make it idiomatic C++ code.

[Mut...@dastardlyhq.com]

I write my C++ code just like my C code except with C++ extensions so I've no
idea what point you're making.

[Scott Lurndal]

Where is it required that C++ code be idiomatic? What muttley describes
would have been idiomatic C++ code in the cfront 2.1 days.

C with classes is still a useful and common idiom.

[Keith Thompson]

Mut...@dastardlyhq.com writes:
> On Wed, 10 Aug 2022 10:11:00 -0700
> Keith Thompson <Keith.S.T...@gmail.com> wrote:
>>Mut...@dastardlyhq.com writes:

[...]

>>> Depends on the job requirements. Some places require knowledge of both
>>> languages and someone good with C++ isn't always good at writing efficient C.
>>
>>
>>Sure, but "C/C++" isn't a good way to say that. You never see "C/Java".
>
> Last time I looked you couldn't compile C with a java compiler.

int class;

[Keith Thompson]

99.9%? I doubt it. And why would you want to?

Do you really write code *and then* decide whether you're going to
compile it with a C compiler or a C++ compiler?

C++ has facilities for interfacing with C code.

There are rare valid reasons to write code that can compile as
both C and C++ with the same semantics (and you have to exercise
some care to avoid a few pitfalls where the same code can have
different meanings).

Much valid C code is valid C++ code. Most valid C code can be
made into valid C++ code without a lot of effort (casting malloc,
for example). Very little *good* C code is good C++ code.

[Keith Thompson]

I think his point is that you write non-idiomatic C++ code.

Which you can certainly do if you like, but most of us don't.

[Keith Thompson]

Öö Tiib <oot...@hot.ee> writes:
[...]

> There can be rather obvious reasons for such single product team to
> choose writing some program for some process of said product in
> common subset of for example C11 and C++11. So as result that
> program is indeed both C11 program and C++11 program. What is
> here even to argue?
>
> The code is unlikely to follow widespread idioms of programming in
> either programming language. But saying that whatever was therefore
> "done wrong" without being committed nor having clue what the product
> does is silly™. How can one even dream to be capable to judge
> adequately?

I don't doubt that there can be valid reasons for writing code in the
common subset of C11 and C++11, but those reasons are not obvious.
Can you elaborate?

[Malcolm McLean]

On Friday, 12 August 2022 at 20:13:11 UTC+1, Keith Thompson wrote:
> Öö Tiib <oot...@hot.ee> writes:
> [...]
> > There can be rather obvious reasons for such single product team to
> > choose writing some program for some process of said product in
> > common subset of for example C11 and C++11. So as result that
> > program is indeed both C11 program and C++11 program. What is
> > here even to argue?
> >
> > The code is unlikely to follow widespread idioms of programming in
> > either programming language. But saying that whatever was therefore
> > "done wrong" without being committed nor having clue what the product
> > does is silly™. How can one even dream to be capable to judge
> > adequately?
> I don't doubt that there can be valid reasons for writing code in the
> common subset of C11 and C++11, but those reasons are not obvious.
> Can you elaborate?
>

You can toggle the files between C and C++ by changing the extension.
That can help if you're dealing with builds on many platforms.
For instance, you can often compile the program with a simple cc *.c
But what if you've got cpp files that are not also C files? Now, quite
frequently, you've got to set up a build script to compile the c files,
compile the cpp files, and then link them. And that build script is something
that is liable to break.
So instead rename the c files to cpp files, and it's CC *.cpp.

[Öö Tiib]

On Friday, 12 August 2022 at 22:13:11 UTC+3, Keith Thompson wrote:
> Öö Tiib <oot...@hot.ee> writes:
> [...]
> > There can be rather obvious reasons for such single product team to
> > choose writing some program for some process of said product in
> > common subset of for example C11 and C++11. So as result that
> > program is indeed both C11 program and C++11 program. What is
> > here even to argue?
> >
> > The code is unlikely to follow widespread idioms of programming in
> > either programming language. But saying that whatever was therefore
> > "done wrong" without being committed nor having clue what the product
> > does is silly™. How can one even dream to be capable to judge
> > adequately?
> I don't doubt that there can be valid reasons for writing code in the
> common subset of C11 and C++11, but those reasons are not obvious.
> Can you elaborate?

Sure. I mean the reasons are for the product team obvious. These are
not general reasons to use that common subset. Generally it is most
likely waste of effort but for concrete project it is logical solution. I
try to bring few examples that can make it obvious for them.

One of target devices where the process runs may have some reason
why C++ can't be used ... for example defective C++ runtime.
C++ is more restrictive about some things (like type safety). Team is
worried about those things. So they want to make it to build with
C++ just as static analysis.
There can be some tool in usage that reads code for some purpose
and generates something but does not work with C features outside
of common subset.
There may be available collaborators (with very important domain
knowledge) who are capable to learn that common subset quickly
enough but whole C++ would take too lot of months.

[Manfred]

That's all fine, but if you are programming in the common subset of C
and C++, then you are effectively programming in C, aren't you?
I mean, practically: with respect to C, you are excluding at most 5% of
the language; with respect to C++ you are excluding at least 60% of the
language.

Maybe I should make one thing clear, that I thought was in fact obvious:
I didn't say, and I don't believe, that C++ programming is good, as
opposed to C programming being bad, not at all.

[Manfred]

On 8/11/2022 1:53 PM, David Brown wrote:
> On 11/08/2022 04:25, Manfred wrote:
>> On 8/10/2022 10:13 AM, David Brown wrote:
>>> On 10/08/2022 02:25, Manfred wrote:

[...]

I think the distinction about object-orientation (whose popularity has
dropped considerably in the last decade or so, btw) or imperative-ness
of the languages is rather marginal. I agree that both languages can do
with both just fine.
But the difference I have i mind goes much farther than that, just
trivial examples:
- in C code you use macros everywhere, in C++ you tend to avoid them in
favor of templates
- in C you use raw pointers everywhere, in C++ you don't.
- anywhere templates are the good choice (not because they are fancy or
because they are C++-ish, but because they behave well for the task at
hand), you'd use totally different constructs in C.
- the list obviously can grow ad libitum, I just won't make it long here.

It's not about idiomatic for the sake of itself, it's about the best
solution you choose given the problem you have and the tools you have.

If you write a C-style linked list in a C++ program, it's probably due
to some specifics of the domain you are operating in, rather than a
solution commonly adopted by C++ programmers. I have no doubt that it
works best in your case, I don't believe that it works best in most cases.
For one, there's a reason raw pointers are seldom used in C++ - not
because it's the "C++ way", or it's any fancy. It just is because code
works better this way.

As I wrote elsethread, I am not saying that C++ is better than C in an
absolute sense. I am convinced that the choice between the two languages
depends entirely on the problem domain: in some cases C is better, in
other it's the other way around.
However, if C++ is chosen because it is a better solution for the
problem at hand, then I see that, unsurprisingly, you end up writing
code that is quite different from C.

(btw, std::list still exists, it's not banned or anything)

[David Brown]

On 12/08/2022 21:09, Keith Thompson wrote:
> Mut...@dastardlyhq.com writes:
>> On Fri, 12 Aug 2022 12:12:19 -0000 (UTC)
>> Juha Nieminen <nos...@thanks.invalid> wrote:
>>> Mut...@dastardlyhq.com wrote:
>>>>> Sure, but "C/C++" isn't a good way to say that. You never see "C/Java".
>>>>
>>>> Last time I looked you couldn't compile C with a java compiler.
>>>
>>> I'm somewhat certain that if you search enough you'll find a polyglot
>>> program that will compile both as C and Java.
>>
>> I rather doubt that. You could #define "class", some class name and "public"
>> to nothing but you're not going to be able to do much about the extra curly
>> brackets around main() and C compilers don't like that.
>>
>>> C is not 100% compatible with C++ either, so any "C code" that you might
>>> write that just happens to compile and work the same in C++ is technically
>>> speaking a C/C++ polyglot. (Sure, it's infinitely easier to write a C/C++
>>> polyglot program than eg. a C/Java one, but still. C is not a pure subset
>>> of C++.)
>>
>> So what. Its enough of a subset to work 99.9% of the time.
>
> 99.9%? I doubt it. And why would you want to?
>

This all depends on how you count your percentages. If you are talking
about percentages of C files, only a small proportion of files could
compile error-free as C++. If you are talking about the number of lines
of the C files that need to be changed to make the C into valid C++, a
very high percentage of C code is valid C++. It only takes one uncasted
malloc() in a 1000 line file to make the file unable to compile as C++.

> Do you really write code *and then* decide whether you're going to
> compile it with a C compiler or a C++ compiler?
>
> C++ has facilities for interfacing with C code.
>
> There are rare valid reasons to write code that can compile as
> both C and C++ with the same semantics (and you have to exercise
> some care to avoid a few pitfalls where the same code can have
> different meanings).

There is the extremely common case of C header files that are used
directly in C++ (usually with a conditional extern "C" wrapping). These
are more declarations than code, but you might have the odd static
inline function there. For headers, it's usually not a problem to stick
to a common subset of the languages (and also keep it common across
different language standards).

While I have, at a customer's request (always a valid reason!), written
code that is directly compilable as C and C++, I agree it's rare. I
disagree with those that think it is hard or particularly limiting
compared to pure C coding, however.

gcc has a warning flag "-Wc++-compat" for C code. Presumably it exists
because at least some people wanted to write code that worked equally as
both languages.

[Mut...@dastardlyhq.com]

On Fri, 12 Aug 2022 12:09:51 -0700

Keith Thompson <Keith.S.T...@gmail.com> wrote:
>Mut...@dastardlyhq.com writes:

>>>C is not 100% compatible with C++ either, so any "C code" that you might
>>>write that just happens to compile and work the same in C++ is technically
>>>speaking a C/C++ polyglot. (Sure, it's infinitely easier to write a C/C++
>>>polyglot program than eg. a C/Java one, but still. C is not a pure subset
>>>of C++.)
>>
>> So what. Its enough of a subset to work 99.9% of the time.
>
>99.9%? I doubt it. And why would you want to?

You wouldn't if starting from scratch. But old codebases have to be
maintained.

>C++ has facilities for interfacing with C code.

Phew, glad you cleared that up, was getting worried.

>for example). Very little *good* C code is good C++ code.

Depends on what you're doing.

[Mut...@dastardlyhq.com]

On Fri, 12 Aug 2022 12:11:08 -0700
Keith Thompson <Keith.S.T...@gmail.com> wrote:
>Mut...@dastardlyhq.com writes:
>> On Fri, 12 Aug 2022 18:07:38 +0300
>> Paavo Helde <ees...@osa.pri.ee> wrote:
>>>12.08.2022 17:43 Mut...@dastardlyhq.com kirjutas:
>>>>
>>>> Rubbish. I've got multi thousand line originally C programs which I've
>>>happily
>>>> compiled with C++ compilers in C++ mode due to a few minor C++ additions.
>>>
>>>This does not make it idiomatic C++ code.
>>
>> I write my C++ code just like my C code except with C++ extensions so I've no
>
>> idea what point you're making.
>
>I think his point is that you write non-idiomatic C++ code.
>
>Which you can certainly do if you like, but most of us don't.

Perhaps its time someone describes what they mean by idiomatic C++ code.

Off you go...

[David Brown]

I'm not convinced it even makes sense to talk about "idiomatic" code out
of context - I think both C and C++ are used for such a wide range of
applications that the idea is close to meaningless. There are idioms
that are used by many, and code can be idiomatic in a particular field,
but not in general for the language. The "idiomatic" way to write C
code for an 8051 microcontroller is very, very different from the
"idiomatic" way to write C code for a POSIX command-line utility, yet
both are C. C++ for a gaming engine kernel will be very different from
C++ for a Windows database application. Comparing languages, C11 code
will be very different from C90 code, as will C++20 code from C++98 code.

I think it is perhaps enough to say that if you know you are writing a
piece of code from scratch in C++, you won't write it in the same way as
if you were writing it in C. Attempting to put figures on the
differences, or give binary "idiomatic" / "non-idomatic" tags, is not
really helpful.

[Öö Tiib]

You are right that it is closer to C than to C++ because C++ is just lot
bigger programming language. It is trivially true.
Why to name it C? It takes more effort than to program in C. There is
little area of possible code that compiles on both but behavior will
differ. Such code may not be used despite compilers are silent. Can
say compatible subset or common subset as that causes less confusion.

>
> Maybe I should make one thing clear, that I thought was in fact obvious:
> I didn't say, and I don't believe, that C++ programming is good, as
> opposed to C programming being bad, not at all.

Good. Usage of engineering tool is not good or bad, it is tool. Result
can be good or bad, right or wrong, benevolent or evil but that does not
depend on tool.

[David Brown]

On 13/08/2022 04:13, Manfred wrote:
> On 8/11/2022 1:53 PM, David Brown wrote:
>> On 11/08/2022 04:25, Manfred wrote:
>>> On 8/10/2022 10:13 AM, David Brown wrote:
>>>> On 10/08/2022 02:25, Manfred wrote:
> [...]
>

> I think the distinction about object-orientation (whose popularity has
> dropped considerably in the last decade or so, btw) or imperative-ness
> of the languages is rather marginal. I agree that both languages can do
> with both just fine.
> But the difference I have i mind goes much farther than that, just
> trivial examples:
> - in C code you use macros everywhere, in C++ you tend to avoid them in
> favor of templates

I don't use macros "everywhere" in C. I know some people do, but it is
certainly not necessary - in fact, my usage of macros in C and C++ is
mostly quite similar.

There is an old-fashioned style of C programming where you use "#define
NO_OF_THINGS 20" and use function-like macros for code size/speed
efficiency. But in modern C you'd use "static const int no_of_things =
20;", or "enum { no_of_things = 20 };" for the purpose, and static
inline functions instead of function-like macros.

Yes, there are things that you can do in C++ with templates that have a
rough equivalent in C that is only possible with macros. (There's also
lots you can do with C++ templates that has no sane equivalent in C.)
But they are not "everywhere". And they are mostly defined once, tucked
away - just like some of the more bizarre C++ definitions. And then
what does it matter? When you use "pow" in your code, it generally
doesn't matter if it is a C++ templated function, a C11 _Generic macro,
or a pre-C11 compiler-specific "magic" macro. (Well, it matters when
you want to make your own quarternion class and provide a power function
for that...)

> - in C you use raw pointers everywhere, in C++ you don't.
> - anywhere templates are the good choice (not because they are fancy or
> because they are C++-ish, but because they behave well for the task at
> hand), you'd use totally different constructs in C.
> - the list obviously can grow ad libitum, I just won't make it long here.
>

C++ has many more features than C. You can do more with the language,
and do things in a way that cannot (sanely) be done in C. I don't think
there are many that would argue differently, and there is little benefit
in listing some of these features.

But if you don't need such features - the code you have can be expressed
simply with functions and simple types - then code written in C++ does
not necessarily look much different from code written in C.

>>
>> I appreciate what you are saying - I just think it is blatantly
>> incorrect to say the code is "C, not C++".  What you mean is that it
>> is not /idiomatic/ C++ code.  It is not code written in a way that
>> /you/ would write it in C++.
>>
>> C++ is used in a huge range of systems, with a huge range of different
>> requirements.  You think that if someone needed a dynamically
>> resizeable list of items, in C++ they'd always reach for a std::vector
>> while in C they'd write it themselves, and therefore the languages are
>> different. When I program in C++, if I needed such a list I'd write it
>> myself, far closer to what you think of as "C style".  The standard
>> library std::vector will not do what I need it to do, so I would not
>> use it. But what I write would still be C++.
>
> It's not about idiomatic for the sake of itself, it's about the best
> solution you choose given the problem you have and the tools you have.
>
> If you write a C-style linked list in a C++ program, it's probably due
> to some specifics of the domain you are operating in, rather than a
> solution commonly adopted by C++ programmers.

Yes, I agree. My point is that if I do that, and write a C-style linked
list in C++, then I am writing C++, not C. It might be C++ code that is
structured almost identically to C code - it might even be possible to
compile it as C. But it is still C++.

> I have no doubt that it
> works best in your case, I don't believe that it works best in most cases.

Sure - again, I agree. I am merely objecting to categorical and
artificial divisions, declaring that a piece of code is "not C++" based
on a purely subjective idea of how C++ "should" be written.

> For one, there's a reason raw pointers are seldom used in C++ - not
> because it's the "C++ way", or it's any fancy. It just is because code
> works better this way.
>

I am not convinced on either point. First, I think raw pointers /are/
often used in C++ - much more often, probably, than they should be.
Secondly, I don't think the point is that smart pointers (or containers,
or other ways of managing indirect references) "work better" than raw
pointers. For the most part, they just make it easier to write correct
code, especially in the face of subtle issues such as exception safety.
And they make it harder to write incorrect code, since you can no
longer forget to delete your allocated objects. They don't work faster,
or give smaller code, or compile faster - nor do they let you do
something you could not do before using raw pointers, which are things I
would say would qualify as "work better". Perhaps this is just a
quibble about the wording, but I feel the important point of many C++
features is to improve code quality, safety and correctness above all else.

> As I wrote elsethread, I am not saying that C++ is better than C in an
> absolute sense. I am convinced that the choice between the two languages
> depends entirely on the problem domain: in some cases C is better, in
> other it's the other way around.

Agreed.

> However, if C++ is chosen because it is a better solution for the
> problem at hand, then I see that, unsurprisingly, you end up writing
> code that is quite different from C.
>

The choice of language is often not made on purely technical "it's a
better solution" grounds. But while I think that your argument is valid
for a lot of code, I don't think it /always/ applies - and I don't think
it is appropriate to categorise all C++ code that is structured like a C
solution as somehow not "real" C++.

[Chris M. Thomasson]

On 8/8/2022 9:43 AM, Alan Beck wrote:
>
> //Hello All,//
>
> I decided I wanted to learn C programming so I can solve problems with
> software instead of hardware.
>
> I have an arduino and am learning it.
>
>
> Shouod I be learing C,C++ or Arduino "sketch" language.
>
> I have books for all three.l
>
> Thand beforo hand

Personally, I would learn C++ first even though I learned C first. Or,
you can stage it. Learn C first, then C++. C gave me a foundation to
understand the advantages of C++...

[Malcolm McLean]

On Saturday, 13 August 2022 at 20:13:33 UTC+1, David Brown wrote:
> On 13/08/2022 04:13, Manfred wrote:
> > On 8/11/2022 1:53 PM, David Brown wrote:
> >> On 11/08/2022 04:25, Manfred wrote:
> >>> On 8/10/2022 10:13 AM, David Brown wrote:
> >>>> On 10/08/2022 02:25, Manfred wrote:
> > [...]
> >
> > I think the distinction about object-orientation (whose popularity has
> > dropped considerably in the last decade or so, btw) or imperative-ness
> > of the languages is rather marginal. I agree that both languages can do
> > with both just fine.
> > But the difference I have i mind goes much farther than that, just
> > trivial examples:
> > - in C code you use macros everywhere, in C++ you tend to avoid them in
> > favor of templates
> I don't use macros "everywhere" in C. I know some people do, but it is
> certainly not necessary - in fact, my usage of macros in C and C++ is
> mostly quite similar.
>
> There is an old-fashioned style of C programming where you use "#define
> NO_OF_THINGS 20" and use function-like macros for code size/speed
> efficiency. But in modern C you'd use "static const int no_of_things =
> 20;", or "enum { no_of_things = 20 };" for the purpose, and static
> inline functions instead of function-like macros.
>

Generally you'd do that to declare an array rather than use dynamic allocation.
But on most systems the speed improvement no longer justifies the
extra complexity and scope for error you introduce by having a hard limit.

[Keith Thompson]

Malcolm McLean <malcolm.ar...@gmail.com> writes:
> On Saturday, 13 August 2022 at 20:13:33 UTC+1, David Brown wrote:

[...]

>> There is an old-fashioned style of C programming where you use "#define
>> NO_OF_THINGS 20" and use function-like macros for code size/speed
>> efficiency. But in modern C you'd use "static const int no_of_things =
>> 20;", or "enum { no_of_things = 20 };" for the purpose, and static
>> inline functions instead of function-like macros.
>>
> Generally you'd do that to declare an array rather than use dynamic allocation.
> But on most systems the speed improvement no longer justifies the
> extra complexity and scope for error you introduce by having a hard limit.

In C, `static const int no_of_things = 20;` doesn't make `no_of_things`
a constant expression. You can use it as an array length at block scope
*if* the implementation supports variable-length arrays (VLAs), which
were made optional in C11. This:

static const int no_of_things = 20;

int arr[no_of_things];

is illegal (a constraint violation) in C at file scope. (It works in
C++, but I'd use constexpr rather than const.)

enum { no_of_things = 20; } does give you a constant expression, but is
limited to type int. (C23 will change that.)

[David Brown]

Do what? The thing I said is old-fashioned, or the two better (in some
ways) alternatives?

As Keith says, you can't use a "static const int" for a static array
size in C. But you can use an enumeration constant for array sizes, so
that is what I do. (Sometimes #define'd macros are unavoidable for this
kind of use in C, if you need the value to be calculated at compile time
- even if the result is clearly known at compile-time, it is still not a
"constant" by the language rules. C++ is much stronger there.)

> But on most systems the speed improvement no longer justifies the
> extra complexity and scope for error you introduce by having a hard limit.
>

I think you are extrapolating from your own code and assuming it always
applies. Speed differences may or may not be relevant, depending on the
platform and what you are doing with the array. But used correctly and
appropriately, a hard limit is much simpler and has far less scope for
error - a statically declared array of fixed size carries much more
information for error checking (by the compiler, and by code) than a
pointer to a dynamically allocated array.

[Juha Nieminen]

Mut...@dastardlyhq.com wrote:
> Rubbish. I've got multi thousand line originally C programs which I've happily
> compiled with C++ compilers in C++ mode due to a few minor C++ additions.

I assume it's C89. Modern C is more unlikely to be compilable as C++ as-is
(for example because of out-of-order designated initializers, 'restrict',
and so on). Even some completely standard-legal C89 won't compile as C++,
such as:

char *str = "hello";

(which is 100% valid standard C, but not valid C++.)

[Mut...@dastardlyhq.com]

Both clang and gcc will compile it but with a warning.

[Bo Persson]

And the warning says that it *is* valid?!

[Tim Rentsch]

Manfred <non...@add.invalid> writes:

> [...] if you are programming in the common subset of C

> and C++, then you are effectively programming in C, aren't you?

In my experience programming in the common subset of C and C++ is
much more like programming in an annoyingly braindamaged subset of C
than it is like programming in C.

> I mean, practically: with respect to C, you are excluding at most 5%

> of the language; [...]

Unfortunately excluding 5% of the language ends up excluding 95+% of
the programs (and probably more for programs of any reasonable size).
I think no C programmer naturally writes C programs that fall into
the common subset of C and C++, except by accident, and that happens
only rarely, and in small programs.

[David Brown]

No, the warning tells you that it is /invalid/ :

warning: ISO C++ forbids converting a string constant to 'char*'
[-Wwrite-strings]

Muttley must have forgotten to mention that.

(You don't need any flags to get this warning.)

In the interests of letting people port C code to C++, compilers like
gcc are a bit more lenient in what they accept than the standards
require. And like most compilers, gcc and clang are not as strict to
the standards as they might be unless you actively choose flags for that
effect. This means if you want to check if something is valid C++
according to the standards, and try it using <https://godbolt.org> or
similar, you want at least something like "-std=c++17 -Wpedantic" in
your flags. There's still no guarantee the standards checking will be
perfect, but it's likely to be pretty good.

[Mut...@dastardlyhq.com]

He said it won't compile. It WILL compile. A warning is just text.

[Mut...@dastardlyhq.com]

I didn't forget anything. The fact is both those compilers will compile it.
A warning is a warning, its not an error.

[Keith Thompson]

As you probably already know, the standard does not require a conforming
compiler to reject anything unless there's a #error directive that
survives preprocessing. (At least that's the rule for C; I haven't
found wording in the C++ standard that requires rejecting a program with
a #error directive.) For any other violation of the language rules, all
the standard requires is a diagnostic, which can be a non-fatal warning.

You're right, it's not correct to say that `char *str = "hello";` "won't
compile as C++". A conforming compiler must diagnose it, but after
doing so it may either accept it or reject it. The warning quoted above
satisifies the standard's requirement for a diagnostic.

A C++ program containing that declaration is *ill-formed*.

The distinction between a warning and an error is less significant than
you imply it is.

I'd say the content of the warning was relevant. You chose to omit it
for some reason.

[Juha Nieminen]

Mut...@dastardlyhq.com wrote:
> I didn't forget anything. The fact is both those compilers will compile it.
> A warning is a warning, its not an error.

Compilers are not the authorities of what's legal C++ and what isn't.
Just because a compiler might accept something and compile it into
something doesn't mean it's officially valid standard C++.

[Mut...@dastardlyhq.com]

On Tue, 16 Aug 2022 12:56:59 -0700
Keith Thompson <Keith.S.T...@gmail.com> wrote:
>You're right, it's not correct to say that `char *str = "hello";` "won't
>compile as C++". A conforming compiler must diagnose it, but after

Thank you. We got there in the end.

>I'd say the content of the warning was relevant. You chose to omit it
>for some reason.

The assertion was it wouldn't compile, not that it would compile with warnings.

For an activity such as programming that requires attention to detail a lot of
you here are rather lacking in that ability.

[Mut...@dastardlyhq.com]

The original assertion was that it wouldn't compile, not whether it was
100% legal or not.

[Keith Thompson]

You could have helped by providing just a little extra information. You
chose not to. Consider trying to be helpful rather than just showing off
your ability to be obscure.

[Mut...@dastardlyhq.com]

On Wed, 17 Aug 2022 14:49:35 -0700

Keith Thompson <Keith.S.T...@gmail.com> wrote:
>Mut...@dastardlyhq.com writes:
>> On Tue, 16 Aug 2022 12:56:59 -0700
>> Keith Thompson <Keith.S.T...@gmail.com> wrote:
>>>You're right, it's not correct to say that `char *str = "hello";` "won't
>>>compile as C++". A conforming compiler must diagnose it, but after
>>
>> Thank you. We got there in the end.
>>
>>>I'd say the content of the warning was relevant. You chose to omit it
>>>for some reason.
>>
>> The assertion was it wouldn't compile, not that it would compile with
>warnings.
>>
>> For an activity such as programming that requires attention to detail a lot
>of
>> you here are rather lacking in that ability.
>
>You could have helped by providing just a little extra information. You
>chose not to. Consider trying to be helpful rather than just showing off
>your ability to be obscure.

A little extra info about what? I was replying to a 1 line assertion another
poster made. Not my fault if that confused you.

[Manfred]

Which is the textbook definition of taking out of context.

Not my fault if that confused you.
>

In fact the post you are referring to is:

"...Even some completely standard-legal C89 won't compile as C++,

such as:

char *str = "hello";

(which is 100% valid standard C, but not valid C++.)"

Wherein the first line says "it won't compile as C++", and the last line
says "not valid C++".

A human being would read both, and understand that the message here is
about legal vs. not-legal C++, rather than questioning if some compiler
actually accepts the code fragment. This, considering that even the
first statement (the "won't compile" part) is counterpoised to the first
part of the same phrase, which clearly says that the matter is about
"standard-legal" C or C++.

This is for as human beings go. Then, there are the nitpickers.

[d thiebaud]

> In fact the post you are referring to is:
>
>   "...Even some completely standard-legal C89 won't compile as C++,
>    such as:
>
>     char *str = "hello";
>
>   (which is 100% valid standard C, but not valid C++.)"
>
> Wherein the first line says "it won't compile as C++", and the last line
> says "not valid C++".
>
> A human being would read both, and understand that the message here is
> about legal vs. not-legal C++, rather than questioning if some compiler
> actually accepts the code fragment. This, considering that even the
> first statement (the "won't compile" part) is counterpoised to the first
> part of the same phrase, which clearly says that the matter is about
> "standard-legal" C or C++.
>
> This is for as human beings go. Then, there are the nitpickers.

A human being would read this as saying that it won't compile and is
invalid. You should learn to express what you mean clearly.

[Keith Thompson]

Please don't snip attribution lines.

I read the original statement as saying *incorrectly* that it won't
compile (in fact it may or may not compile, depending on the compiler
and settings), and *correctly* that it's not valid C++ (more precisely,
it's ill-formed). I didn't bother to comment on the minor error.

[Mut...@dastardlyhq.com]

On Fri, 19 Aug 2022 03:10:08 +0200
Manfred <non...@add.invalid> wrote:
>In fact the post you are referring to is:
>
> "...Even some completely standard-legal C89 won't compile as C++,
> such as:
>
> char *str = "hello";
>
> (which is 100% valid standard C, but not valid C++.)"
>
>Wherein the first line says "it won't compile as C++", and the last line
>says "not valid C++".
>
>A human being would read both, and understand that the message here is
>about legal vs. not-legal C++, rather than questioning if some compiler
>actually accepts the code fragment. This, considering that even the
>first statement (the "won't compile" part) is counterpoised to the first
>part of the same phrase, which clearly says that the matter is about
>"standard-legal" C or C++.
>
>This is for as human beings go. Then, there are the nitpickers.

Ah, the No True Scotsman fallacy, its been a while since I've seen that :)

[Frederick Virchanza Gotham]

On Tuesday, August 9, 2022 at 11:30:07 AM UTC+1, Bonita Montero wrote:

> You can program an Arduino with a limited C++-subset but
> I don't see any use in that because Arduino programs are
> always very small.


In my day job I program microcontrollers in C++. One is Arduino and the other is Texas Instruments.

It's rare that there's something missing from the standard library that I need. I just write normal C++ code for these two microcontrollers.

I have 512 kB for program code and constants, and 92 kB of RAM. So far I've been able to write pretty complicated programs and only use about a quarter of the memory available. Lately in my day job I'm writing C++ code to move galvoes to direct a laser beam to draw patterns on glass.

Also if I did need more than 512 kB or 92 kB, I can connect a separate chip. (I can even use some of the onboard 512 kB as RAM if I want to).

[Paavo Helde]

13.08.2022 12:38 Mut...@dastardlyhq.com kirjutas:
>
> Perhaps its time someone describes what they mean by idiomatic C++ code.
>

Perhaps the most visible difference is in that in proper C most of the
application level code deals with error checking and resource cleanup,
whereas in proper C++ most of the application level code implements
business logic. Example with two resources, one can easily imagine more.
A resource might be just a dynamically allocated array.

C:

int foo(int arg1, const char* arg2, X* presult) {

A* resource1 = NULL;
B* resource2 = NULL;
int retval;

if (PrepareResourceA(arg1, arg2, &resource1)!=0) {
goto FAILURE;
}
resource2 = PrepareResourceB(arg1, arg2, resource1);
if (!resource2) {
goto FAILURE;
}
if (CombineAB(resource1, resource2, presult)!=0) {
goto FAILURE;
}
// we know that ownership of B has moved over into result:
resource2 = NULL;
retval = 0; // success
goto CLEANUP;

FAILURE:
retval = -1;
goto CLEANUP;

CLEANUP:
if (resource1) {
ReleaseResourceA(resource1);
}
if (resource2) {
ReleaseResourceB(resource2);
}

return retval;
}


In C++, where errors are reported via exceptions, and ownership and
resource cleanup are automatic:

X foo(int arg1, std::string_view arg2) {
A resource1 = PrepareResourceA(arg1, arg2);
B resource2 = PrepareResourceB(arg1, arg2, resource1);
return CombineAB(std::move(resource1), std::move(resource2));
}

[Ben Bacarisse]

What you say is true, but you can make the point without writing clumsy
C and without assuming that the support functions have not been written
to handle prepare, combine and release actions for null pointers
correctly. The C code might, in fact, look like this:

A *resource1 = PrepareResourceA(arg1, arg2);
B *resource2 = PrepareResourceB(arg1, arg2, resource1);
bool result = CombineAB(resource1, resource2, presult);
ReleaseResourceA(resource1);
ReleaseResourceB(resource2);
return result;

--
Ben.

[Malcolm McLean]

Superficially, that code looks tidy.
In reality it isn't. It's not clear to a mantaining programmer that the earlier calls
can fail and return null pointers.

[Ben Bacarisse]

It is tidy. In reality. You mean you don't like it because a reader
has to know what the called function really do.

> It's not clear to a mantaining programmer that the earlier calls
> can fail and return null pointers.

The same is true of all well-written code. It's also true of the C++
about which you did not make the same comment.

--
Ben.

[Scott Lurndal]

Your example presumes that error recovery is basically kill the job.

The error recovery for PrepareResourceA may be significantly different
from the error recovery for PrepareResourceB, and lumping both into
some upstream exception handler (potentially in a completely different translation
unit) makes everything more complicated.

Fix the errors as soon as possible, in line.

[Mut...@dastardlyhq.com]

On Wed, 24 Aug 2022 11:33:33 +0100
Ben Bacarisse <ben.u...@bsb.me.uk> wrote:
> bool result = CombineAB(resource1, resource2, presult);

AFAIK even C 2011 doesn't have "bool". Its defined as the (ugly) _Bool in C99.
Obviously you can typedef however.

[Paavo Helde]

With exceptions the exception can be easily handled at the most correct
level, be it 1 or 20 stack frames above the actual error. If the
exception is caught and handled inside a PrepareResource*(), then it's
all fine. The exception only reaches foo() if it was not possible to
handle it at lower level.

[Mut...@dastardlyhq.com]

The trouble with exceptions is people use them as glorified gotos, often the
same people who think goto's are bad due to the not always obvious flow of
control (though I've never noticed that except in BASIC). The irony is
obviously lost on them.

[Ben Bacarisse]

I did not show headers. C has had bool (defined in stdbool.h) ever
since it got _Bool.

None of the posted code is correct without a few declarations...

--
Ben.

[Mut...@dastardlyhq.com]

On Wed, 24 Aug 2022 15:31:32 +0100

Ben Bacarisse <ben.u...@bsb.me.uk> wrote:
>Mut...@dastardlyhq.com writes:
>
>> On Wed, 24 Aug 2022 11:33:33 +0100
>> Ben Bacarisse <ben.u...@bsb.me.uk> wrote:
>>> bool result = CombineAB(resource1, resource2, presult);
>>
>> AFAIK even C 2011 doesn't have "bool". Its defined as the (ugly) _Bool in
>C99.
>> Obviously you can typedef however.
>
>I did not show headers. C has had bool (defined in stdbool.h) ever
>since it got _Bool.

Fair enough, didn't know that. Whats the point of _Bool then? To stop
issues with C++ if a C99 file is included in a C++ project?

[Ben Bacarisse]

Mut...@dastardlyhq.com writes:

> On Wed, 24 Aug 2022 15:31:32 +0100
> Ben Bacarisse <ben.u...@bsb.me.uk> wrote:
>>Mut...@dastardlyhq.com writes:
>>
>>> On Wed, 24 Aug 2022 11:33:33 +0100
>>> Ben Bacarisse <ben.u...@bsb.me.uk> wrote:
>>>> bool result = CombineAB(resource1, resource2, presult);
>>>
>>> AFAIK even C 2011 doesn't have "bool". Its defined as the (ugly) _Bool in
>>C99.
>>> Obviously you can typedef however.
>>
>>I did not show headers. C has had bool (defined in stdbool.h) ever
>>since it got _Bool.
>
> Fair enough, didn't know that. Whats the point of _Bool then? To stop
> issues with C++ if a C99 file is included in a C++ project?

Lots of old code defined bool. Suddenly making it a type keyword would
have broken that code. The identifier _Bool was reserved to the
implementation so it should not break anything.

--
Ben.

[Keith Thompson]

C23 will make bool, false, and true keywords.

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n3047.pdf

[Ben Bacarisse]

Keith Thompson <Keith.S.T...@gmail.com> writes:

> Ben Bacarisse <ben.u...@bsb.me.uk> writes:
>> Mut...@dastardlyhq.com writes:
>>> On Wed, 24 Aug 2022 15:31:32 +0100
>>> Ben Bacarisse <ben.u...@bsb.me.uk> wrote:
>>>>Mut...@dastardlyhq.com writes:
>>>>
>>>>> On Wed, 24 Aug 2022 11:33:33 +0100
>>>>> Ben Bacarisse <ben.u...@bsb.me.uk> wrote:
>>>>>> bool result = CombineAB(resource1, resource2, presult);
>>>>>
>>>>> AFAIK even C 2011 doesn't have "bool". Its defined as the (ugly) _Bool in
>>>>C99.
>>>>> Obviously you can typedef however.
>>>>
>>>>I did not show headers. C has had bool (defined in stdbool.h) ever
>>>>since it got _Bool.
>>>
>>> Fair enough, didn't know that. Whats the point of _Bool then? To stop
>>> issues with C++ if a C99 file is included in a C++ project?
>>
>> Lots of old code defined bool. Suddenly making it a type keyword would
>> have broken that code. The identifier _Bool was reserved to the
>> implementation so it should not break anything.
>
> C23 will make bool, false, and true keywords.
>
> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n3047.pdf

I didn't know that, but I am not surprised because of the new course C
is taking. I hope it does not run aground...

--
Ben.

[Alf P. Steinbach]

It's apparently the same as with C++: not very practical academics in
charge, expressing their academic ideals. Idealism is a kind of advanced
sabotage. Usually.

- Alf

[David Brown]

Some of the C23 changes are obvious and practical, such as "volatile
semantics for lvalues" (embedded developers have been relying on this
for decades, so it's nice to see it standardised), and the
standardisation of "#warning" (again, something that people have used
for decades).

But there has definitely been a change in the principles. C23 makes
"bool" the type and keyword, with "_Bool" as the "alternative spelling".
Similarly we now have "static_assert", "alignas", etc. "void foo();"
now means "void foo(void);". There are many things like this that
arguably make C a slightly better and neater language, and will not harm
anyone who has been writing decent C99 code over the past couple of
decades. But C has a history older than that - and backwards
compatibility is a prime reason the language is still alive and kicking.

I suppose that we can rely on gcc to follow the fine tradition of
supporting old, outdated and dangerous constructs when invoked without
specific standards or warning flags - I expect it to still work with
code that has "typedef int bool;" for a long time to come.

[Ben Bacarisse]

Who, in particular, do you mean?

> expressing their academic ideals.

In what way is making bool a type keyword expressing an academic ideal?
My thoughts were the reverse: the "purist" route -- of only using
already reserved identifiers -- has been ditched.

--
Ben.

[Malcolm McLean]

Low level, practical programmers tend to think of programming in terms
of manipulating bits in memory.
Academic computer science people tend to think of programming in terms
of manipulating symbols.
So a practical programmer will tend to say "set that bit to indicate the light is
on", a computer scientist will say "bind that variable to true/false to indicate
the status of the light".

[Ben Bacarisse]

Malcolm McLean <malcolm.ar...@gmail.com> writes:

> On Thursday, 25 August 2022 at 11:29:26 UTC+1, Ben Bacarisse wrote:
>> "Alf P. Steinbach" <alf.p.s...@gmail.com> writes:
>>
>> > On 24 Aug 2022 22:48, Ben Bacarisse wrote:
>> >> Keith Thompson <Keith.S.T...@gmail.com> writes:
>>
>> >>> C23 will make bool, false, and true keywords.
>> >>>
>> >>> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n3047.pdf
>> >> I didn't know that, but I am not surprised because of the new course C
>> >> is taking. I hope it does not run aground...
>> >
>> > It's apparently the same as with C++: not very practical academics in
>> > charge,
>> Who, in particular, do you mean?
>>
>> > expressing their academic ideals.
>>
>> In what way is making bool a type keyword expressing an academic ideal?
>> My thoughts were the reverse: the "purist" route -- of only using
>> already reserved identifiers -- has been ditched.
>>
> Low level, practical programmers tend to think of programming in terms
> of manipulating bits in memory.

Are you equating the two or just ignoring high-level practical
programmers?

Anyway, as always, I am curious about how you know this.

> Academic computer science people tend to think of programming in terms
> of manipulating symbols.

I suspect this is simply self-defining. Any academic CS person who,
say, designs a RISK architecture or a low-level network protocol, will
be excused and be deemed to be practical, yes?

> So a practical programmer will tend to say "set that bit to indicate
> the light is on", a computer scientist will say "bind that variable to
> true/false to indicate the status of the light".

I think you are making this us. CS people who set bits to indicate
things just like everyone else.

Does any of this have anything to do with the C standards apparent
change of direct to incorporate C++ features at the expense of old code?

--
Ben.

[Malcolm McLean]

On Thursday, 25 August 2022 at 12:37:11 UTC+1, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>
> > On Thursday, 25 August 2022 at 11:29:26 UTC+1, Ben Bacarisse wrote:
> >> "Alf P. Steinbach" <alf.p.s...@gmail.com> writes:
> >>
> >> > On 24 Aug 2022 22:48, Ben Bacarisse wrote:
> >> >> Keith Thompson <Keith.S.T...@gmail.com> writes:
> >>
> >> >>> C23 will make bool, false, and true keywords.
> >> >>>
> >> >>> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n3047.pdf
> >> >> I didn't know that, but I am not surprised because of the new course C
> >> >> is taking. I hope it does not run aground...
> >> >
> >> > It's apparently the same as with C++: not very practical academics in
> >> > charge,
> >> Who, in particular, do you mean?
> >>
> >> > expressing their academic ideals.
> >>
> >> In what way is making bool a type keyword expressing an academic ideal?
> >> My thoughts were the reverse: the "purist" route -- of only using
> >> already reserved identifiers -- has been ditched.
> >>
> > Low level, practical programmers tend to think of programming in terms
> > of manipulating bits in memory.
> Are you equating the two or just ignoring high-level practical
> programmers?
>
> Anyway, as always, I am curious about how you know this.
>

I used to be a games programmer. I gave it up to do a degree which led to a PhD.
Whilst I didn't do computer science, and the PhD was in protein folding, it did
involve quite a bit of interaction with computer scientists. So I'm reasonably
familiar with both worlds.

>
> > Academic computer science people tend to think of programming in terms
> > of manipulating symbols.
> I suspect this is simply self-defining. Any academic CS person who,
> say, designs a RISK architecture or a low-level network protocol, will
> be excused and be deemed to be practical, yes?
>

There's an overlap between computer science, practical programming, and
electronic engineering. But they're not the same.

>
> Does any of this have anything to do with the C standards apparent
> change of direct to incorporate C++ features at the expense of old code?
>

Computer science people would tend to think that it's important to have
a boolean type, because a lot of logic works on values which are inherently
true or false. Practical programmers would tend to say that it's not, because
most hardware won't support it. You will of course find exceptions.

[Scott Lurndal]

gcc 4.9 will be around forever. (an example, but really, the older
C compilers will not go away just because C23 shows up).

[Ben Bacarisse]

OK. So it's your based on your experience. My experience is different.

>> > Academic computer science people tend to think of programming in terms
>> > of manipulating symbols.
>> I suspect this is simply self-defining. Any academic CS person who,
>> say, designs a RISK architecture or a low-level network protocol, will
>> be excused and be deemed to be practical, yes?
>>
> There's an overlap between computer science, practical programming, and
> electronic engineering. But they're not the same.

Sure. In fact, any academic who may /think/ they are a computer
scientist will be excluded from your definition if they lean towards
something you think is practical. You can't really be wrong, can you?

>> Does any of this have anything to do with the C standards apparent
>> change of direct to incorporate C++ features at the expense of old code?
>>
> Computer science people would tend to think that it's important to have
> a boolean type, because a lot of logic works on values which are inherently
> true or false.

C already has a Boolean type. The question was whether renaming it bool
is the result of fanatical academic interference in the standard.
That's what I was asking about.

--
Ben.

[Keith Thompson]

Malcolm McLean <malcolm.ar...@gmail.com> writes:
[...]

> Computer science people would tend to think that it's important to have
> a boolean type, because a lot of logic works on values which are inherently
> true or false. Practical programmers would tend to say that it's not, because
> most hardware won't support it. You will of course find exceptions.

Many practical programmers would tend to say it's important to have a
boolean type because it makes it easier to write clear code. (Some
probably prefer to use zero and non-zero rather than explicit bool,
false, and true.)

Why would a "practical programmer" care whether there's direct hardware
support for bool? If the compiler handles it correctly, it just works.
In a very real sense, all hardware supports booleans, with more or less
work required by the compiler.

[Keith Thompson]

David Brown <david...@hesbynett.no> writes:
> On 24/08/2022 22:48, Ben Bacarisse wrote:
>> Keith Thompson <Keith.S.T...@gmail.com> writes:

[...]

>>> C23 will make bool, false, and true keywords.
>>>
>>> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n3047.pdf
>> I didn't know that, but I am not surprised because of the new course
>> C
>> is taking. I hope it does not run aground...
>>
>
> Some of the C23 changes are obvious and practical, such as "volatile
> semantics for lvalues" (embedded developers have been relying on this
> for decades, so it's nice to see it standardised), and the
> standardisation of "#warning" (again, something that people have used
> for decades).
>
> But there has definitely been a change in the principles. C23 makes
> "bool" the type and keyword, with "_Bool" as the "alternative
> spelling". Similarly we now have "static_assert", "alignas", etc.
> "void foo();" now means "void foo(void);". There are many things like
> this that arguably make C a slightly better and neater language, and
> will not harm anyone who has been writing decent C99 code over the
> past couple of decades. But C has a history older than that - and
> backwards compatibility is a prime reason the language is still alive
> and kicking.
>
> I suppose that we can rely on gcc to follow the fine tradition of
> supporting old, outdated and dangerous constructs when invoked without
> specific standards or warning flags - I expect it to still work with
> code that has "typedef int bool;" for a long time to come.

Remember that C99 removed implicit int, which in principle broke a lot
of existing code. Most compilers continued to accept implicit it in
some mode, perhaps with a non-fatal warning.

Code that uses bool, false, and true as identifiers is going to be a
little trickier to handle in lexical analysis and parsing.

[Malcolm McLean]

On Thursday, 25 August 2022 at 18:06:45 UTC+1, Keith Thompson wrote:
> Malcolm McLean <malcolm.ar...@gmail.com> writes:
> [...]
> > Computer science people would tend to think that it's important to have
> > a boolean type, because a lot of logic works on values which are inherently
> > true or false. Practical programmers would tend to say that it's not, because
> > most hardware won't support it. You will of course find exceptions.
> Many practical programmers would tend to say it's important to have a
> boolean type because it makes it easier to write clear code. (Some
> probably prefer to use zero and non-zero rather than explicit bool,
> false, and true.)
>

It does document that a value is logically bi-valued. So we can enable or disable
a button, but we can't have it in a half-enabled state. However the problem is
that when you look at C++ code which uses booleans, it's not clear what is
being passed
e.g. if you see
Button mybutton("OK", &rect, true);
Obviously this is creating a button. Obviously it's got the display text "OK". Obviously
rect is some sort of rectangle containing the position. But what is "true"?
If we make enabled / disabled an enum, then it's more clear what the code is doing.

>
> Why would a "practical programmer" care whether there's direct hardware
> support for bool? If the compiler handles it correctly, it just works.
> In a very real sense, all hardware supports booleans, with more or less
> work required by the compiler.
>

Well one issue is whether if (flag == true) works as expected. If the hardware supports
1 bit types, then it must work, because flag cannot have any bit pattern other than
bit clear / bit set. If bool is something provided by software, and the underlying type
is an integer, then it might hold unexpected values.
A theoretical person doesn't really have to worry about this, because in his world, all
bools are initialised to 1 or 0 and all operations on them yield 1 or 0. In the practical
programmer's world, things can get more messy, because some of the code might
be written in another language, for example.

[David Brown]

On 25/08/2022 18:16, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>
>> On Thursday, 25 August 2022 at 12:37:11 UTC+1, Ben Bacarisse wrote:
>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>
>>>> On Thursday, 25 August 2022 at 11:29:26 UTC+1, Ben Bacarisse wrote:
>>>>> "Alf P. Steinbach" <alf.p.s...@gmail.com> writes:
>>>>>
>>>>>> On 24 Aug 2022 22:48, Ben Bacarisse wrote:
>>>>>>> Keith Thompson <Keith.S.T...@gmail.com> writes:
>>>>>
>>>>>>>> C23 will make bool, false, and true keywords.
>>>>>>>>
>>>>>>>> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n3047.pdf
>>>>>>> I didn't know that, but I am not surprised because of the new course C
>>>>>>> is taking. I hope it does not run aground...
>>>>>>
>>>>>> It's apparently the same as with C++: not very practical academics in
>>>>>> charge,
>>>>> Who, in particular, do you mean?
>>>>>

A large proportion of the new features in C23 seem to have originated
with or been promoted by one person - Jens Gustedt. I don't know if he
should be considered an "academic", or a "practical programmer", or
both, or neither. But while most of the C standards committee tend to
be quite anonymous and avoid making changes to the standard (they all
have day jobs, after all), he seems to be working hard to change C and
bring it forward. People can have different opinions on whether that's
a good idea or not, and about the particular changes he has proposed,
but I think he is due a large share of the credit for C23.

>> Computer science people would tend to think that it's important to have
>> a boolean type, because a lot of logic works on values which are inherently
>> true or false.
>

When I did theoretical computer science at university, we used whatever
type was convenient and appropriate for the task at hand (and more often
than not it was "alpha" or "A", rather than any specific type). And
that was for "there's no need to test the code, because we prove it is
correct on the blackboard" programming, which is as academic as it comes.

In my job as a practical programmer - mostly low-level, but sometimes
high-level (however those terms might be defined), I use whatever type
is convenient and appropriate for the task at hand. And "bool" is one
of the most common types I use.

For my own coding, I don't really care whether "bool" is a typedef for
"_Bool" or a keyword in itself, nor do I care if "true" and "false" are
keywords, macros, enums, or whatever, as long as they work correctly.
However, if these are all keywords in a language, then it gives me a
guarantee that code from elsewhere uses these types and values in
exactly the same way. I don't need to check that the code I import has
defined "typedef enum { uninitialised, true, false } bool;", or some
other incompatible fun. So from that viewpoint, having these as
keywords can be helpful in practice.

But that's /my/ experience - Malcolm's is apparently different.

> C already has a Boolean type. The question was whether renaming it bool
> is the result of fanatical academic interference in the standard.
> That's what I was asking about.
>

I would have thought there were other changes in C23 (and even more so,
some of the proposals that didn't make it into the standard) were better
candidates for the title of "fanatical academic interference". But
perhaps Malcolm sees things differently.

[Keith Thompson]

Malcolm McLean <malcolm.ar...@gmail.com> writes:
> On Thursday, 25 August 2022 at 18:06:45 UTC+1, Keith Thompson wrote:
>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>> [...]
>> > Computer science people would tend to think that it's important to have
>> > a boolean type, because a lot of logic works on values which are inherently
>> > true or false. Practical programmers would tend to say that it's not, because
>> > most hardware won't support it. You will of course find exceptions.
>> Many practical programmers would tend to say it's important to have a
>> boolean type because it makes it easier to write clear code. (Some
>> probably prefer to use zero and non-zero rather than explicit bool,
>> false, and true.)
>>
> It does document that a value is logically bi-valued. So we can enable or disable
> a button, but we can't have it in a half-enabled state. However the problem is
> that when you look at C++ code which uses booleans, it's not clear what is
> being passed
> e.g. if you see
> Button mybutton("OK", &rect, true);
> Obviously this is creating a button. Obviously it's got the display text "OK". Obviously
> rect is some sort of rectangle containing the position. But what is "true"?
> If we make enabled / disabled an enum, then it's more clear what the code is doing.

Agreed -- but what does that have to do with what we were discussing?
You were talking about hardware support. The same considerations apply
to a built-in boolean type or to a 2-element enum.

>> Why would a "practical programmer" care whether there's direct hardware
>> support for bool? If the compiler handles it correctly, it just works.
>> In a very real sense, all hardware supports booleans, with more or less
>> work required by the compiler.
>>
> Well one issue is whether if (flag == true) works as expected. If the hardware supports
> 1 bit types, then it must work, because flag cannot have any bit pattern other than
> bit clear / bit set. If bool is something provided by software, and the underlying type
> is an integer, then it might hold unexpected values.
> A theoretical person doesn't really have to worry about this, because in his world, all
> bools are initialised to 1 or 0 and all operations on them yield 1 or 0. In the practical
> programmer's world, things can get more messy, because some of the code might
> be written in another language, for example.

First off, why would you write `if (flag == true)` rather than `if(flag)`?

But for a boolean type that's built into the language, like C's _Bool or
C++'s bool, none of that is an issue in the absence of memory
corruption. Conversions to bool always yield false or true (0 or 1).
If some of the code is written in another language, then *of course* you
have to make sure that anything converted to a native boolean is
normalized. Anything that stores a value other than 0 or 1 in a C or
C++ boolean object is buggy, and needs to be fixed.

None of this has anything to do with some distinction between
theoretical and practical programmers.

Sometimes I'm a theoretical programmer, and sometimes I'm a practical
programmer. In either role, I care that something is supported by the
combination of the hardware and the compiler. As long as the compiler
does its job, it works.

[David Brown]

On 25/08/2022 19:32, Malcolm McLean wrote:
> On Thursday, 25 August 2022 at 18:06:45 UTC+1, Keith Thompson wrote:
>> Malcolm McLean <malcolm.ar...@gmail.com> writes: [...]
>>> Computer science people would tend to think that it's important
>>> to have a boolean type, because a lot of logic works on values
>>> which are inherently true or false. Practical programmers would
>>> tend to say that it's not, because most hardware won't support
>>> it. You will of course find exceptions.
>> Many practical programmers would tend to say it's important to have
>> a boolean type because it makes it easier to write clear code.
>> (Some probably prefer to use zero and non-zero rather than explicit
>> bool, false, and true.)
>>
> It does document that a value is logically bi-valued. So we can
> enable or disable a button, but we can't have it in a half-enabled
> state. However the problem is that when you look at C++ code which
> uses booleans, it's not clear what is being passed e.g. if you see
> Button mybutton("OK", &rect, true); Obviously this is creating a
> button. Obviously it's got the display text "OK". Obviously rect is
> some sort of rectangle containing the position. But what is "true"?
> If we make enabled / disabled an enum, then it's more clear what the
> code is doing.

We've had the "No true Scotsman" argument, now we are onto
"Whataboutism". Are you planning on working your way through
Wikipedia's list of argument fallacies?

Keith said booleans can make code /clearer/ - he did not claim it
magically makes all code as clear as it could possibly be.
"mybutton("OK", &rect, true);" is a step up from "mybutton("OK", &rect,
1);". You could well say that "mybutton("OK", &rect,
button_state_enabled);" is better - but so what? That does not stop the
fact that a simple, standardised boolean type is a massive improvement
in clarity compared to either "int" or home-made types that differ wildly.

>>
>> Why would a "practical programmer" care whether there's direct
>> hardware support for bool? If the compiler handles it correctly, it
>> just works. In a very real sense, all hardware supports booleans,
>> with more or less work required by the compiler.
>>
> Well one issue is whether if (flag == true) works as expected. If the
> hardware supports 1 bit types, then it must work, because flag cannot
> have any bit pattern other than bit clear / bit set. If bool is
> something provided by software, and the underlying type is an
> integer, then it might hold unexpected values.

Sometimes I wonder if you actually do much programming in C (or C++).
Do you know how "bool" (or "_Bool") is defined in C? The standards say
how it must work, the compiler implements it. If "flag" is declared as
"bool", then when you read it, it either equals "false" or it equals
"true". There is no middle ground, no "unexpected" value, unless you
have screwed up your code so badly with bugs and undefined behaviour
that you really can't rely on anything.

> A theoretical person
> doesn't really have to worry about this, because in his world, all
> bools are initialised to 1 or 0 and all operations on them yield 1 or
> 0. In the practical programmer's world, things can get more messy,
> because some of the code might be written in another language, for
> example.

Practical programmers are concerned with writing correct code. And they
are concerned with writing clear and concise code - they follow the
rules of the language, and expect the compiler to follow its part of the
bargain. They know that a "bool" holds either "false" or "true",
because there is no valid way to put anything else into the bool, and
(baring bugs, when any assumption can be violated) they don't write code
that does something different.

[David Brown]

Yes, that is an example of gcc supporting old and dangerous constructs
even when nominally using standards that disallow it.

> Code that uses bool, false, and true as identifiers is going to be a
> little trickier to handle in lexical analysis and parsing.
>

I expect the gcc folks will figure out a way to handle it - at least in
cases where the "homemade" bool type and values are directly compatible
with the "real" type and values. (For the type, that would really just
mean manually doing "typedef _Bool bool;" or "#define bool _Bool", since
alternatives like enumerations, int, or char do not have the same
semantics.)

[Keith Thompson]

I wouldn't expect (or want) a compiler to handle a user-defined bool
differently depending on whether it thinks it's compatible with the
built-in bool.

But this discussion probably belongs in comp.lang.c anyway.

[Ben Bacarisse]

David Brown <david...@hesbynett.no> writes:

> When I did theoretical computer science at university, we used
> whatever type was convenient and appropriate for the task at hand (and
> more often than not it was "alpha" or "A", rather than any specific
> type). And that was for "there's no need to test the code, because we
> prove it is correct on the blackboard" programming, which is as
> academic as it comes.

Care to name and shame? That's an extraordinary thing to say (if it was
not a joke)?

--
Ben.

[David Brown]

"Beware of bugs in the above code; I have only proved it correct, not
tried it." (Donald Knuth)

Several of our courses covered provable code, with mathematical
derivation from specifications through to code. The "programming"
language was somewhat idealised and limited and had no implementation -
the idea was that if you wanted to use the code, you'd translate the
derived algorithm into a practical real language.

So if you want to look at sorting algorithms, for example, you start
with a list of items of some type (the type does not matter), and a post
condition that the list is sorted. You work through step by step, with
each step justified mathematically, until you have "executable" code at
the end. If you have made no mistakes underway, you have a proven
correct implementation of the specifications - not just one that has
passed some test cases.

(You can look up the book "Programming from Specifications" by Carroll
Morgan, which is freely available.)

I think the only programming language that we were actually taught was a
functional programming language very much like Haskell. When we had
practical work that involved actual programming on computers, we were
expected to learn whatever language the course tutor thought appropriate
for the task - C, Modula 2, and Occam, perhaps more.

[Ben Bacarisse]

David Brown <david...@hesbynett.no> writes:

> On 25/08/2022 22:32, Ben Bacarisse wrote:
>> David Brown <david...@hesbynett.no> writes:
>>
>>> When I did theoretical computer science at university, we used
>>> whatever type was convenient and appropriate for the task at hand (and
>>> more often than not it was "alpha" or "A", rather than any specific
>>> type). And that was for "there's no need to test the code, because we
>>> prove it is correct on the blackboard" programming, which is as
>>> academic as it comes.
>>
>> Care to name and shame? That's an extraordinary thing to say (if it was
>> not a joke)?
>
> "Beware of bugs in the above code; I have only proved it correct, not
> tried it." (Donald Knuth)

A well-known quote meaning pretty much the opposite of the remark that
piqued my interest.

> Several of our courses covered provable code, with mathematical
> derivation from specifications through to code. The "programming"
> language was somewhat idealised and limited and had no implementation
> - the idea was that if you wanted to use the code, you'd translate the
> derived algorithm into a practical real language.
>
> So if you want to look at sorting algorithms, for example, you start
> with a list of items of some type (the type does not matter), and a
> post condition that the list is sorted. You work through step by
> step, with each step justified mathematically, until you have
> "executable" code at the end. If you have made no mistakes underway,
> you have a proven correct implementation of the specifications - not
> just one that has passed some test cases.
>
> (You can look up the book "Programming from Specifications" by Carroll
> Morgan, which is freely available.)

There are few books on that sort of topic. Hoare's comes to mind.

> I think the only programming language that we were actually taught was
> a functional programming language very much like Haskell. When we had
> practical work that involved actual programming on computers, we were
> expected to learn whatever language the course tutor thought
> appropriate for the task - C, Modula 2, and Occam, perhaps more.

You could just have said "no"!

--
Ben.