Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

"Pull the trigger and you're garbage." -- Lady Blue


devel / comp.arch.embedded / Re: C++, Ada, ...

SubjectAuthor
* C++, Ada, ...pozz
+* Re: C++, Ada, ...David Brown
|+* Re: C++, Ada, ...Tom Gardner
||`* Re: C++, Ada, ...David Brown
|| `* Re: C++, Ada, ...Niklas Holsti
||  `* Re: C++, Ada, ...David Brown
||   `* Re: C++, Ada, ...Niklas Holsti
||    +* Re: C++, Ada, ...David Brown
||    |`* Re: C++, Ada, ...Niklas Holsti
||    | `* Re: C++, Ada, ...David Brown
||    |  `* Re: C++, Ada, ...Niklas Holsti
||    |   +- Re: C++, Ada, ...Richard Damon
||    |   `* Re: C++, Ada, ...David Brown
||    |    `* Re: C++, Ada, ...Paul Rubin
||    |     `- Re: C++, Ada, ...David Brown
||    `* Re: C++, Ada, ...Paul Rubin
||     +* Re: C++, Ada, ...Niklas Holsti
||     |`* Re: C++, Ada, ...Paul Rubin
||     | `- Re: C++, Ada, ...Niklas Holsti
||     `- Re: C++, Ada, ...Tom Gardner
|+- Re: C++, Ada, ...Clifford Heath
|+* Re: C++, Ada, ...Niklas Holsti
||`* Re: C++, Ada, ...David Brown
|| `* Re: C++, Ada, ...Niklas Holsti
||  `* Re: C++, Ada, ...David Brown
||   +* Re: C++, Ada, ...Tom Gardner
||   |`* Re: C++, Ada, ...David Brown
||   | +* Re: C++, Ada, ...Tom Gardner
||   | |`- Re: C++, Ada, ...David Brown
||   | `* Re: C++, Ada, ...Niklas Holsti
||   |  +* Re: C++, Ada, ...Dimiter_Popoff
||   |  |`* Re: C++, Ada, ...Paul Rubin
||   |  | `* Re: C++, Ada, ...Niklas Holsti
||   |  |  `- Re: C++, Ada, ...David Brown
||   |  `- Re: C++, Ada, ...David Brown
||   `* Re: C++, Ada, ...Tom Gardner
||    `* Re: C++, Ada, ...David Brown
||     `* Re: C++, Ada, ...Tom Gardner
||      `* Re: C++, Ada, ...David Brown
||       +* Re: C++, Ada, ...Tom Gardner
||       |`* Re: C++, Ada, ...David Brown
||       | `- Re: C++, Ada, ...Tom Gardner
||       `* Re: C++, Ada, ...Tauno Voipio
||        `- Re: C++, Ada, ...David Brown
|`* Re: C++, Ada, ...pozz
| +- Re: C++, Ada, ...Paul Rubin
| +* Re: C++, Ada, ...Tom Gardner
| |`* Re: C++, Ada, ...Tauno Voipio
| | `- Re: C++, Ada, ...Tom Gardner
| `* Re: C++, Ada, ...David Brown
|  `* Re: C++, Ada, ...pozz
|   +* Re: C++, Ada, ...Paul Rubin
|   |`- Re: C++, Ada, ...David Brown
|   `- Re: C++, Ada, ...David Brown
+* Re: C++, Ada, ...Dave Nadler
|+- Re: C++, Ada, ...Don Y
|`- Re: C++, Ada, ...Tom Gardner
`- Re: C++, Ada, ...dalai lamah

Pages:123
C++, Ada, ...

<s5f01b$4j3$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=287&group=comp.arch.embedded#287

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: pozzu...@gmail.com (pozz)
Newsgroups: comp.arch.embedded
Subject: C++, Ada, ...
Date: Sat, 17 Apr 2021 17:48:59 +0200
Organization: A noiseless patient Spider
Lines: 25
Message-ID: <s5f01b$4j3$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sat, 17 Apr 2021 15:48:59 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="e19aa43d42622d54fb86d9940f101477";
logging-data="4707"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/aoaLiHlxF31Ws3hhuQWeMtBPZ743AK/0="
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.9.1
Cancel-Lock: sha1:bUtoBT0/JrlMHqgQq16rSEStxkI=
Content-Language: it
X-Mozilla-News-Host: news://news.eternal-september.org:119
 by: pozz - Sat, 17 Apr 2021 15:48 UTC

What do you think about different languages than usual C for embedded
systems?

I mean C++, Ada but also Python. Always more powerful embedded
processors are coming, so I expect new and modern languages will enter
in the embedded world.

Hardware are cheaper and more powerful than ever, but software stays
expensive. New and modern languages could reduce the software cost,
because they are simpler than C and much more similar to desktop/server
programming paradigm.

We embedded sw developers were lucky: electronics and technologies
change rapidly, but sw for embedded has changed slower than
desktop/mobile sw. Think of mobile app developers: maybe they already
changed IDEs, tools and languages ten times in a few years.
C language for embedded is today very similar than 10 years ago.

However I think this situation for embedded developers will change in
the very next years. And we will be forced to learn modern technologies,
such as new languages and tools.
Is it ok for me to study and learn new things... but it will be more
difficult to acquire new skills for real jobs.

What do you think?

Re: C++, Ada, ...

<s5f3c1$s06$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=289&group=comp.arch.embedded#289

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: david.br...@hesbynett.no (David Brown)
Newsgroups: comp.arch.embedded
Subject: Re: C++, Ada, ...
Date: Sat, 17 Apr 2021 18:45:52 +0200
Organization: A noiseless patient Spider
Lines: 63
Message-ID: <s5f3c1$s06$1@dont-email.me>
References: <s5f01b$4j3$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-15
Content-Transfer-Encoding: 7bit
Injection-Date: Sat, 17 Apr 2021 16:45:53 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="0add4463424a8564213ed2f08da3c485";
logging-data="28678"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/W4DVYRzFiXgUvplaJzurdKHtinLZXHYY="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
Thunderbird/68.10.0
Cancel-Lock: sha1:Roco3I50xrIiQJx4VIqqqfqitBQ=
In-Reply-To: <s5f01b$4j3$1@dont-email.me>
Content-Language: en-GB
 by: David Brown - Sat, 17 Apr 2021 16:45 UTC

On 17/04/2021 17:48, pozz wrote:
> What do you think about different languages than usual C for embedded
> systems?
>
> I mean C++, Ada but also Python. Always more powerful embedded
> processors are coming, so I expect new and modern languages will enter
> in the embedded world.
>
> Hardware are cheaper and more powerful than ever, but software stays
> expensive. New and modern languages could reduce the software cost,
> because they are simpler than C and much more similar to desktop/server
> programming paradigm.
>
> We embedded sw developers were lucky: electronics and technologies
> change rapidly, but sw for embedded has changed slower than
> desktop/mobile sw. Think of mobile app developers: maybe they already
> changed IDEs, tools and languages ten times in a few years.
> C language for embedded is today very similar than 10 years ago.
>
> However I think this situation for embedded developers will change in
> the very next years. And we will be forced to learn modern technologies,
> such as new languages and tools.
> Is it ok for me to study and learn new things... but it will be more
> difficult to acquire new skills for real jobs.
>
> What do you think?

You should probably add Rust to your list - I think its popularity will
increase.

Python is great when you have the resources. It's the language I use
most on PC's and servers, and it is very common on embedded Linux
systems (like Pi's, and industrial equivalents). Micropython is
sometimes found on smaller systems, such as ESP32 devices.

Ada involves a fair amount of change to how you work, compared to C
development. (Disclaimer - I have only done a very small amount of Ada
coding, and no serious projects. But I have considered it as an
option.) I really don't see it becoming much more common, and outside
of niche areas (defence, aerospace) it is very rare. Programming in Ada
often takes a lot more effort even for simple things, leading quickly to
code that is so wordy that it is unclear what is going on. And most of
the advantages of Ada (such as better typing) can be achieved in C++
with less effort, and at the same time C++ can give additional safety on
resources that is harder to get on Ada. (But Ada has some nice features
introspective that C++ programmers currently only dream about.)

C++ is not uncommon in embedded systems, and I expect to see more of it.
I use it as my main embedded language now. C++ gives more scope for
getting things wrong in weird ways, and more scope for accidentally
making your binary massively larger than you expect, but with care it
makes it a lot easier to write clear code and safe code, where common C
mistakes either can't happen or you get compile-time failures.

It used to be the case that C++ compilers were expensive and poor
quality, that the resulting code was very slow on common
microcontrollers, and that the language didn't have much extra to offer
small-systems embedded developers. That, I think, has changed in all
aspects. I use gcc 10 with C++17 on Cortex-M devices, and features like
templates, strong enumerations, std::array, and controlled automatic
conversions make it easier to write good code.

Re: C++, Ada, ...

<AaGeI.148580$qHh9.147135@fx18.ams4>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=294&group=comp.arch.embedded#294

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!usenet.goja.nl.eu.org!3.eu.feeder.erje.net!feeder.erje.net!fdcspool6.netnews.com!fdc3.netnews.com!news-out.netnews.com!news.alt.net!fdc2.netnews.com!peer04.ams1!peer.ams1.xlned.com!news.xlned.com!peer01.ams4!peer.am4.highwinds-media.com!news.highwinds-media.com!fx18.ams4.POSTED!not-for-mail
Reply-To: spamjunk@blueyonder.co.uk
Subject: Re: C++, Ada, ...
Newsgroups: comp.arch.embedded
References: <s5f01b$4j3$1@dont-email.me> <s5f3c1$s06$1@dont-email.me>
From: spamj...@blueyonder.co.uk (Tom Gardner)
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
Firefox/52.0 SeaMonkey/2.49.4
MIME-Version: 1.0
In-Reply-To: <s5f3c1$s06$1@dont-email.me>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 8
Message-ID: <AaGeI.148580$qHh9.147135@fx18.ams4>
X-Complaints-To: http://netreport.virginmedia.com
NNTP-Posting-Date: Sat, 17 Apr 2021 18:55:28 UTC
Organization: virginmedia.com
Date: Sat, 17 Apr 2021 19:55:28 +0100
X-Received-Bytes: 1154
 by: Tom Gardner - Sat, 17 Apr 2021 18:55 UTC

On 17/04/21 17:45, David Brown wrote:
> And most of
> the advantages of Ada (such as better typing) can be achieved in C++
> with less effort, and at the same time C++ can give additional safety on
> resources that is harder to get on Ada.

Interesting. Could you give a quick outline of that?

Re: C++, Ada, ...

<1676c5c9f9de470b$1$2159419$22dd286e@news.thecubenet.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=301&group=comp.arch.embedded#301

 copy link   Newsgroups: comp.arch.embedded
Subject: Re: C++, Ada, ...
Newsgroups: comp.arch.embedded
References: <s5f01b$4j3$1@dont-email.me> <s5f3c1$s06$1@dont-email.me>
From: no.s...@please.net (Clifford Heath)
Date: Sun, 18 Apr 2021 08:29:45 +1000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <s5f3c1$s06$1@dont-email.me>
Content-Type: text/plain; charset=iso-8859-15; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Message-ID: <1676c5c9f9de470b$1$2159419$22dd286e@news.thecubenet.com>
Lines: 37
Path: i2pn2.org!i2pn.org!aioe.org!news.uzoreto.com!tr1.eu1.usenetexpress.com!feeder.usenetexpress.com!tr1.iad1.usenetexpress.com!2a07:8080:119:fe::45.MISMATCH!news.thecubenet.com!not-for-mail
NNTP-Posting-Date: Sat, 17 Apr 2021 22:29:47 +0000
X-Received-Bytes: 2012
X-Complaints-To: abuse@thecubenet.com
Organization: theCubeNet - www.thecubenet.com
 by: Clifford Heath - Sat, 17 Apr 2021 22:29 UTC

On 18/4/21 2:45 am, David Brown wrote:
> On 17/04/2021 17:48, pozz wrote:
>> What do you think about different languages than usual C for embedded
>> systems?
>>
>> I mean C++, Ada but also Python. Always more powerful embedded
>> processors are coming, so I expect new and modern languages will enter
>> in the embedded world.
>>
>> Hardware are cheaper and more powerful than ever, but software stays
>> expensive. New and modern languages could reduce the software cost,
>> because they are simpler than C and much more similar to desktop/server
>> programming paradigm.
>>
>> We embedded sw developers were lucky: electronics and technologies
>> change rapidly, but sw for embedded has changed slower than
>> desktop/mobile sw. Think of mobile app developers: maybe they already
>> changed IDEs, tools and languages ten times in a few years.
>> C language for embedded is today very similar than 10 years ago.
>>
>> However I think this situation for embedded developers will change in
>> the very next years. And we will be forced to learn modern technologies,
>> such as new languages and tools.
>> Is it ok for me to study and learn new things... but it will be more
>> difficult to acquire new skills for real jobs.
>>
>> What do you think?
>
> You should probably add Rust to your list - I think its popularity will
> increase.

+1.

I've used C++ for over 30 years, but Rust is going to rule. It's not
really any harder, but vastly safer, especially for parallel coding.

CH

Re: C++, Ada, ...

<s5g0o9$upv$1@gioia.aioe.org>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=302&group=comp.arch.embedded#302

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!aioe.org!Tgip5Y7XolJj69PZynN/8Q.user.gioia.aioe.org.POSTED!not-for-mail
From: drn...@nadler.com (Dave Nadler)
Newsgroups: comp.arch.embedded
Subject: Re: C++, Ada, ...
Date: Sat, 17 Apr 2021 21:07:22 -0400
Organization: Aioe.org NNTP Server
Lines: 16
Message-ID: <s5g0o9$upv$1@gioia.aioe.org>
References: <s5f01b$4j3$1@dont-email.me>
NNTP-Posting-Host: Tgip5Y7XolJj69PZynN/8Q.user.gioia.aioe.org
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
X-Complaints-To: abuse@aioe.org
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.9.1
Content-Language: en-US
X-Notice: Filtered by postfilter v. 0.9.2
 by: Dave Nadler - Sun, 18 Apr 2021 01:07 UTC

On 4/17/2021 11:48 AM, pozz wrote:
> What do you think about different languages than usual C for embedded
> systems?
>
> I mean C++, Ada but also Python. Always more powerful embedded
> processors are coming, so I expect new and modern languages will enter
> in the embedded world.

Another +1 for C++. We started using C++ for embedded ~25 years ago, and
the tool quality (and language) is vastly better now. Main problem using
C++ is lack of available qualified staff - too many still only trained
in C. C++, even more than C, *requires* painful amount of knowledge of
how things work under the hood to use safely, not a good quality for any
tool in any realm. But for *qualified* developers, C++ certainly gives
faster development, produces better (ie faster/smaller) code, and
generally improves life (compared to C).

Re: C++, Ada, ...

<s5g3fv$932$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=303&group=comp.arch.embedded#303

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: blockedo...@foo.invalid (Don Y)
Newsgroups: comp.arch.embedded
Subject: Re: C++, Ada, ...
Date: Sat, 17 Apr 2021 18:53:46 -0700
Organization: A noiseless patient Spider
Lines: 46
Message-ID: <s5g3fv$932$1@dont-email.me>
References: <s5f01b$4j3$1@dont-email.me> <s5g0o9$upv$1@gioia.aioe.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sun, 18 Apr 2021 01:54:08 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="e9641e30b256448190f15a10d43b6d5f";
logging-data="9314"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+ou/Cj1oFhcOxysvziK+Nj"
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101
Thunderbird/52.1.1
Cancel-Lock: sha1:CPrjx7Zxakz+msokh4Q0BSwp/pw=
In-Reply-To: <s5g0o9$upv$1@gioia.aioe.org>
Content-Language: en-US
 by: Don Y - Sun, 18 Apr 2021 01:53 UTC

On 4/17/2021 6:07 PM, Dave Nadler wrote:

> Another +1 for C++. We started using C++ for embedded ~25 years ago, and the
> tool quality (and language) is vastly better now. Main problem using C++ is
> lack of available qualified staff - too many still only trained in C. C++, even
> more than C, *requires* painful amount of knowledge of how things work under
> the hood to use safely, not a good quality for any tool in any realm. But for
> *qualified* developers, C++ certainly gives faster development, produces better
> (ie faster/smaller) code, and generally improves life (compared to C).

This is exactly why I *don't* use C++ (or any "new fangled" languages)
for product development. I'm often the "Rev 1" author of a product.
Then, move on (to another product, another client, another application
domain).

I'm contractually obligated to fix bugs in my code (indefinitely and at no
charge) -- it's one of my selling points ("Yes, I'm *that* confident in the
code I've created for you!")

The last thing I need is some coder-wannabe tweeking my code with some
"harmless" change... then, defiantly claiming (to his management)
that the newly broken code is a consequence of my initial design
(he's just UNCOVERED a bug).

So, I get called back to *teach* the dweeb why what he's done
won't work. And, in the process, inevitably have to show him
how to do what he wants to do.

Yeah, I can bill the client -- which is countered with "but you said
you'd support your code, for free?" (yeah, but that wasn't MY code!).
Regardless, I'm not keen on spending my time as a tutor!

Or, swallow it as cost of doing business.

It's considerably easier to find multiple C coders (and hope one
of them will catch the guy's mistake) than a qualified C++, Erlang,
Python, etc. coder -- esp when you're dealing with small firms.

So, my strategy becomes: "Have you rebuilt MY sources using the
tools that *I* used? Does the product exhibit this bug? If not,
it's not my problem!"

[I can do this even with some other language. But, the dweeb will
inevitably claim -- to the owner/management -- that his changes are
benign. They, of course, won't want to think they hired an inept
employee, so...]

Re: C++, Ada, ...

<ie260rFghneU1@mid.individual.net>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=304&group=comp.arch.embedded#304

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!news.swapon.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: niklas.h...@tidorum.invalid (Niklas Holsti)
Newsgroups: comp.arch.embedded
Subject: Re: C++, Ada, ...
Date: Sun, 18 Apr 2021 10:39:07 +0300
Organization: Tidorum Ltd
Lines: 77
Message-ID: <ie260rFghneU1@mid.individual.net>
References: <s5f01b$4j3$1@dont-email.me> <s5f3c1$s06$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: individual.net 9Ptxk9YCOWIZSqepbZuj2Auyj1QjnpL5SO7nkr1Oe8WW4BSIVh
Cancel-Lock: sha1:aFjcaAYrLdsej4zL99kjNhJG0Fg=
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:78.0)
Gecko/20100101 Thunderbird/78.7.0
In-Reply-To: <s5f3c1$s06$1@dont-email.me>
Content-Language: en-US
 by: Niklas Holsti - Sun, 18 Apr 2021 07:39 UTC

On 2021-04-17 19:45, David Brown wrote:
> On 17/04/2021 17:48, pozz wrote:
>> What do you think about different languages than usual C for embedded
>> systems?
>>
>> I mean C++, Ada but also Python. Always more powerful embedded
>> processors are coming, so I expect new and modern languages will enter
>> in the embedded world.
>>
>> ...
>> Is it ok for me to study and learn new things... but it will be more
>> difficult to acquire new skills for real jobs.
>>
>> What do you think?
>
> ...
> Ada involves a fair amount of change to how you work, compared to C
> development. (Disclaimer - I have only done a very small amount of Ada
> coding, and no serious projects. But I have considered it as an
> option.) I really don't see it becoming much more common, and outside
> of niche areas (defence, aerospace) it is very rare. Programming in Ada
> often takes a lot more effort even for simple things, leading quickly to
> code that is so wordy that it is unclear what is going on.

That depends, I guess, on what one considers "simple", and also, of
course, on how familiar one is with the languages.

Perhaps it is time to link once again to the experience of C versus Ada
in an introductory embedded-programming class using a model rail-road
example, where the students using Ada fared much better than those using C:

http://archive.adaic.com/projects/atwork/trains.html

I am (as you guessed) an Ada fan, and find it a pleasure to write, even
if it takes more keystrokes than the equivalent in C.

For embedded systems in particular, I find portability to be a great
advantage of Ada. With few exceptions, the embedded program can be
exercised on the development host, and if the target supports the
standard Ada tasking system (or a subset of it), this applies even to
multi-threaded programs (without the need to emulate some embedded
RTK/OS on the host).

> And most of the advantages of Ada (such as better typing) can be
> achieved in C++ with less effort,

According to the link above, the main Ada advantage was the ability to
define one's own problem-oriented scalar types, such as integers with
specific value ranges. AIUI, this is not easily done in C++.

> and at the same time C++ can give additional safety on
> resources that is harder to get on Ada. (But Ada has some nice features
> introspective that C++ programmers currently only dream about.)

Can you be more specific on those points, please?

> It used to be the case that C++ compilers were expensive and poor
> quality, that the resulting code was very slow on common
> microcontrollers, and that the language didn't have much extra to offer
> small-systems embedded developers. That, I think, has changed in all
> aspects. I use gcc 10 with C++17 on Cortex-M devices, and features like
> templates, strong enumerations, std::array, and controlled automatic
> conversions make it easier to write good code.

AdaCore provides the gcc-based GNAT Ada compiler for several embedded
targets, free to use for open-source projects: libre.adacore.com.

Commercial projects can use Ada on other targets by means of the
(different) AdaCore compiler that generates C code as an intermediate
representation.

Re: C++, Ada, ...

<VhSeI.282208$hcZe.212291@fx46.ams4>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=305&group=comp.arch.embedded#305

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!news.uzoreto.com!news-out.netnews.com!news.alt.net!fdc2.netnews.com!peer01.ams1!peer.ams1.xlned.com!news.xlned.com!peer02.ams4!peer.am4.highwinds-media.com!news.highwinds-media.com!fx46.ams4.POSTED!not-for-mail
Reply-To: spamjunk@blueyonder.co.uk
Subject: Re: C++, Ada, ...
Newsgroups: comp.arch.embedded
References: <s5f01b$4j3$1@dont-email.me> <s5g0o9$upv$1@gioia.aioe.org>
From: spamj...@blueyonder.co.uk (Tom Gardner)
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
Firefox/52.0 SeaMonkey/2.49.4
MIME-Version: 1.0
In-Reply-To: <s5g0o9$upv$1@gioia.aioe.org>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 10
Message-ID: <VhSeI.282208$hcZe.212291@fx46.ams4>
X-Complaints-To: http://netreport.virginmedia.com
NNTP-Posting-Date: Sun, 18 Apr 2021 08:42:29 UTC
Organization: virginmedia.com
Date: Sun, 18 Apr 2021 09:42:29 +0100
X-Received-Bytes: 1332
 by: Tom Gardner - Sun, 18 Apr 2021 08:42 UTC

On 18/04/21 02:07, Dave Nadler wrote:
> Main problem using C++ is lack of available qualified staff - too many still
> only trained in C. C++, even more than C, *requires* painful amount of knowledge
> of how things work under the hood to use safely, not a good quality for any tool
> in any realm.

Yes indeed. Especially when coupled with inexperience leading
someone to believe they understand C or C++.

Your other (valid) caveats and points snipped for brevity.

Re: C++, Ada, ...

<s5h32f$edv$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=307&group=comp.arch.embedded#307

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: david.br...@hesbynett.no (David Brown)
Newsgroups: comp.arch.embedded
Subject: Re: C++, Ada, ...
Date: Sun, 18 Apr 2021 12:53:03 +0200
Organization: A noiseless patient Spider
Lines: 27
Message-ID: <s5h32f$edv$1@dont-email.me>
References: <s5f01b$4j3$1@dont-email.me> <s5f3c1$s06$1@dont-email.me>
<AaGeI.148580$qHh9.147135@fx18.ams4>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-15
Content-Transfer-Encoding: 8bit
Injection-Date: Sun, 18 Apr 2021 10:53:03 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="815fa31c42c5bf882c41f0a6a05b73f6";
logging-data="14783"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX189kqj5dLWkho1QBNKXSLBLfKwcSPmxwzw="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
Thunderbird/68.10.0
Cancel-Lock: sha1:SLE0WdhWKNv+jtUv5VzGRcRRx1A=
In-Reply-To: <AaGeI.148580$qHh9.147135@fx18.ams4>
Content-Language: en-GB
 by: David Brown - Sun, 18 Apr 2021 10:53 UTC

On 17/04/2021 20:55, Tom Gardner wrote:
> On 17/04/21 17:45, David Brown wrote:
>> And most of
>> the advantages of Ada (such as better typing) can be achieved in C++
>> with less effort, and at the same time C++ can give additional safety on
>> resources that is harder to get on Ada. 
>
> Interesting. Could you give a quick outline of that?
>

Which part?

My understanding of Ada classes is that, like Pascal classes, you need
to explicitly construct and destruct objects. This gives far greater
scope for programmers to get things wrong than when they are handled
automatically by the language.

On the other hand, some of Ada's type mechanisms make it a lot easier to
make new types with similar properties while remaining distinct (such as
subranges of integer types). You can do that in C++, but someone needs
to make the effort to make the appropriate class templates. Thus these
are more often used in Ada coding than in C++ coding.

On the third hand (three hands are always useful for programming), the
wordy nature of type conversions in Ada mean programmers would be
tempted to take shortcuts and skip these extra types.

Re: C++, Ada, ...

<mxnrpcjfwtqd.bud07bkgn6p.dlg@40tude.net>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=308&group=comp.arch.embedded#308

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!aioe.org!5MFsuqFaeTSnjCo5R36VPA.user.gioia.aioe.org.POSTED!not-for-mail
From: antonio1...@hotmail.com (dalai lamah)
Newsgroups: comp.arch.embedded
Subject: Re: C++, Ada, ...
Date: Sun, 18 Apr 2021 14:39:13 +0200
Organization: Aioe.org NNTP Server
Lines: 28
Message-ID: <mxnrpcjfwtqd.bud07bkgn6p.dlg@40tude.net>
References: <s5f01b$4j3$1@dont-email.me>
NNTP-Posting-Host: 5MFsuqFaeTSnjCo5R36VPA.user.gioia.aioe.org
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Complaints-To: abuse@aioe.org
User-Agent: 40tude_Dialog/2.0.15.1it
X-Notice: Filtered by postfilter v. 0.9.2
X-Face: #^0cuOKw--#Q:"y/,&C;}2$_tSLc]PEJ^{cm%=omYXmfR"cSLu`<R:LRUq0q8W)T~e20'Ri gN/ct+i_K+F~-u0lXixh"|ga@w^:D?@OdallB_O(Bg<4m39>9oxl2!tVF1/w
 by: dalai lamah - Sun, 18 Apr 2021 12:39 UTC

Un bel giorno pozz digitò:

> What do you think about different languages than usual C for embedded
> systems?
>
> I mean C++, Ada but also Python. Always more powerful embedded
> processors are coming, so I expect new and modern languages will enter
> in the embedded world.

I wouldn't include C++ in the list of "modern languages". One might as well
use C.

As for the "more modern" languages (Python, C#, Java etc) I've used most of
them and maybe it's the old man in me speaking, but I haven't felt any
inherent important advantages in using them. Their success is mostly due to
better support by popular development tools.

These days, smarter people praise functional programming languages
(Haskell, Clojure, etc...). They promise tangible advantages compared to
imperative languages, especially for maintainability and reliability. But I
think that even if they will gain popularity, years would pass before you
will see real applications in the embedded world.

Python is a "hybrid", it can be also used as a functional programming
language, and it will probably gain popularity in embedded systems.

--
Fletto i muscoli e sono nel vuoto.

Re: C++, Ada, ...

<s5hafg$g1$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=309&group=comp.arch.embedded#309

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: david.br...@hesbynett.no (David Brown)
Newsgroups: comp.arch.embedded
Subject: Re: C++, Ada, ...
Date: Sun, 18 Apr 2021 14:59:28 +0200
Organization: A noiseless patient Spider
Lines: 147
Message-ID: <s5hafg$g1$1@dont-email.me>
References: <s5f01b$4j3$1@dont-email.me> <s5f3c1$s06$1@dont-email.me>
<ie260rFghneU1@mid.individual.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-15
Content-Transfer-Encoding: 8bit
Injection-Date: Sun, 18 Apr 2021 12:59:28 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="815fa31c42c5bf882c41f0a6a05b73f6";
logging-data="513"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19ESrtq+imbvTgt69aH8VD25AchyAate/c="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
Thunderbird/68.10.0
Cancel-Lock: sha1:nf5c4hPP65B4pe1kHldadYM6iww=
In-Reply-To: <ie260rFghneU1@mid.individual.net>
Content-Language: en-GB
 by: David Brown - Sun, 18 Apr 2021 12:59 UTC

On 18/04/2021 09:39, Niklas Holsti wrote:
> On 2021-04-17 19:45, David Brown wrote:
>> On 17/04/2021 17:48, pozz wrote:
>>> What do you think about different languages than usual C for embedded
>>> systems?
>>>
>>> I mean C++, Ada but also Python. Always more powerful embedded
>>> processors are coming, so I expect new and modern languages will enter
>>> in the embedded world.
>>>
>>> ...
>>> Is it ok for me to study and learn new things... but it will be more
>>> difficult to acquire new skills for real jobs.
>>>
>>> What do you think?
>>
>>   ...
>> Ada involves a fair amount of change to how you work, compared to C
>> development.  (Disclaimer - I have only done a very small amount of Ada
>> coding, and no serious projects.  But I have considered it as an
>> option.)  I really don't see it becoming much more common, and outside
>> of niche areas (defence, aerospace) it is very rare.  Programming in Ada
>> often takes a lot more effort even for simple things, leading quickly to
>> code that is so wordy that it is unclear what is going on.
>
>
> That depends, I guess, on what one considers "simple", and also, of
> course, on how familiar one is with the languages.
>
> Perhaps it is time to link once again to the experience of C versus Ada
> in an introductory embedded-programming class using a model rail-road
> example, where the students using Ada fared much better than those using C:
>
> http://archive.adaic.com/projects/atwork/trains.html

Are there no newer examples? While this study was interesting, it is
some 30 years out of date and compares and old version of Ada with an
old version of C (perhaps not even C90). I'd rather see the pros and
cons of Ada 2012 compared to C++17.

>
> I am (as you guessed) an Ada fan, and find it a pleasure to write, even
> if it takes more keystrokes than the equivalent in C.

I had no need to guess - it's not the first time you have posted about
Ada here! I'm glad that someone with your Ada qualifications can chime
in here, and can correct my if I'm wrong.

>
> For embedded systems in particular, I find portability to be a great
> advantage of Ada. With few exceptions, the embedded program can be
> exercised on the development host, and if the target supports the
> standard Ada tasking system (or a subset of it), this applies even to
> multi-threaded programs (without the need to emulate some embedded
> RTK/OS on the host).
>

For suitable targets, I can see that being useful. C and C++ can be
used on a wider range of targets, and with a wider range of RTOS (if
any). Of course, code for widely differing target systems is often very
different anyway, so portability is not always a concern.

>
>> And most of the advantages of Ada (such as better typing) can be
>> achieved in C++ with less effort,
>
> According to the link above, the main Ada advantage was the ability to
> define one's own problem-oriented scalar types, such as integers with
> specific value ranges. AIUI, this is not easily done in C++.
>

Sure it can be done in C++.

<https://foonathan.net/2016/10/strong-typedefs/>

You can make types with specific ranges (with compile-time checks where
possible, optional run-time checks otherwise). You can choose which
operations you allow on them, and how they combine (so that multiplying
a speed and a time give you a distance automatically, but adding them is
not allowed). You can make integer types with different overflow
behaviour (wrapping, saturating, throwing errors, unspecified behaviour,
undefined behaviour) that can be used as easily as normal integers, and
mixed if and only if it is safe to do so or you make it explicit. You
can make array types that are indexed by enumerated types. It's all
possible - more so that in Ada, AFAIK.

Where you have a difference, however, is that many of the most
beneficial cases (such as strong subrange types) are simple to use in
Ada and built into the language, and therefore they are often used. In
C++, you need to find a suitable template library or make things
yourself, giving a much higher barrier to use.

A very interesting distinction when looking at language features and
safe coding is how much people /could/ use safety features, and how much
they /do/ use them. For example, with C programming you can get strong
type safety as long as you wrap all your new types in structs. The
compiler will complain for type mistakes, just as it would in Ada - but
the /use/ of such types is often very inconvenient in C.

>
>> and at the same time C++ can give additional safety on
>> resources that is harder to get on Ada.  (But Ada has some nice features
>> introspective that C++ programmers currently only dream about.)
>
>
> Can you be more specific on those points, please?
>

For the first point - my understanding is that in Ada, when you have
classes you need to manually call constructor and destructor
(initializer and finalizer) functions. RAII is thus harder, and it is
as easy to make mistakes as it is in C (with malloc and free). Does Ada
have the equivalent of std::unique_ptr, std::shared_ptr and other smart
pointers, or container classes that handle allocation?

For the second point, I am thinking of things like type attributes. I
would /really/ like C++ enumerations to have something matching the
"first" and "last" attributes! AFAIK, C++ won't get this until
reflection is added, probably not until C++26.

>
>> It used to be the case that C++ compilers were expensive and poor
>> quality, that the resulting code was very slow on common
>> microcontrollers, and that the language didn't have much extra to offer
>> small-systems embedded developers.  That, I think, has changed in all
>> aspects.  I use gcc 10 with C++17 on Cortex-M devices, and features like
>> templates, strong enumerations, std::array, and controlled automatic
>> conversions make it easier to write good code.
>
>
> AdaCore provides the gcc-based GNAT Ada compiler for several embedded
> targets, free to use for open-source projects: libre.adacore.com.
>
> Commercial projects can use Ada on other targets by means of the
> (different) AdaCore compiler that generates C code as an intermediate
> representation.
>

This means that Ada suffers from a similar barrier to adoption that C++
used to do. Big companies will happily pay the cost for the tools that
they think will lead to better development efficiency or reliability.
Smaller ones will have a much harder time trying to justify the expense,
especially as they will often have few developers who can use the tools.
A move from C to Ada is compounded by needing a complete change of the
code - with C to C++, you can re-use old code, and you can also use a
few of the C++ features rather than moving wholescale (though of course
you also miss out on corresponding benefits).

Re: C++, Ada, ...

<ie32luFlvghU1@mid.individual.net>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=316&group=comp.arch.embedded#316

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!news.swapon.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: niklas.h...@tidorum.invalid (Niklas Holsti)
Newsgroups: comp.arch.embedded
Subject: Re: C++, Ada, ...
Date: Sun, 18 Apr 2021 18:48:14 +0300
Organization: Tidorum Ltd
Lines: 56
Message-ID: <ie32luFlvghU1@mid.individual.net>
References: <s5f01b$4j3$1@dont-email.me> <s5f3c1$s06$1@dont-email.me>
<AaGeI.148580$qHh9.147135@fx18.ams4> <s5h32f$edv$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: individual.net U9LeMQks1BfrhmYDXrcOEgvcCMi6ejV1QfQgbeyr0fdpKzjLvd
Cancel-Lock: sha1:XSAAV8UrvTvGpD8Oj9tjxfJbls0=
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:78.0)
Gecko/20100101 Thunderbird/78.7.0
In-Reply-To: <s5h32f$edv$1@dont-email.me>
Content-Language: en-US
 by: Niklas Holsti - Sun, 18 Apr 2021 15:48 UTC

On 2021-04-18 13:53, David Brown wrote:
> On 17/04/2021 20:55, Tom Gardner wrote:
>> On 17/04/21 17:45, David Brown wrote:
>>> And most of
>>> the advantages of Ada (such as better typing) can be achieved in C++
>>> with less effort, and at the same time C++ can give additional safety on
>>> resources that is harder to get on Ada.
>>
>> Interesting. Could you give a quick outline of that?
>>
>
> Which part?
>
> My understanding of Ada classes is that, like Pascal classes, you need
> to explicitly construct and destruct objects. This gives far greater
> scope for programmers to get things wrong than when they are handled
> automatically by the language.

If you mean automatic allocation and deallocation of storage, Ada lets
you define types that have an "initializer" that is called
automatically, and can allocate memory if it needs to, and a "finalizer"
that is automatically called when leaving the scope of the object in
question. The finalizer does have to explicitly deallocate any
explicitly allocated and owned resources, and it may have to use
reference counting for that, for complex data structures.

AUI that also holds for C++, although I believe recent C++ standards may
have simplified the definition and use of reference-counted data structures.

> On the other hand, some of Ada's type mechanisms make it a lot easier to
> make new types with similar properties while remaining distinct (such as
> subranges of integer types). You can do that in C++, but someone needs
> to make the effort to make the appropriate class templates. Thus these
> are more often used in Ada coding than in C++ coding.

(That relative ease in Ada was the point of my other response -- more to
come on that.)

> On the third hand (three hands are always useful for programming), the
> wordy nature of type conversions in Ada mean programmers would be
> tempted to take shortcuts and skip these extra types.

Huh? A normal conversion in C is written "(newtype)expression", the same
in Ada is written "newtype(expression)". Exactly the same number of
characters, only the placement of the () is different. The C form might
even require an extra set of parentheses around it, to demarcate the
expression to be converted from any containing expression.

Of course, in C you have implicit conversions between all kinds of
numerical types, often leading to a whole lot of errors... not only
apples+oranges, but also truncation or other miscomputation.

Re: C++, Ada, ...

<ie34olFmda9U1@mid.individual.net>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=317&group=comp.arch.embedded#317

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!news.swapon.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: niklas.h...@tidorum.invalid (Niklas Holsti)
Newsgroups: comp.arch.embedded
Subject: Re: C++, Ada, ...
Date: Sun, 18 Apr 2021 19:23:49 +0300
Organization: Tidorum Ltd
Lines: 229
Message-ID: <ie34olFmda9U1@mid.individual.net>
References: <s5f01b$4j3$1@dont-email.me> <s5f3c1$s06$1@dont-email.me>
<ie260rFghneU1@mid.individual.net> <s5hafg$g1$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-15; format=flowed
Content-Transfer-Encoding: 8bit
X-Trace: individual.net kR8z65UaTKc5qgUifSEjLQV5wnAt6ZViS//V+z/OEreFTysoml
Cancel-Lock: sha1:SXz7pgkxZbj9bVuoDeF1ZA1MCAc=
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:78.0)
Gecko/20100101 Thunderbird/78.7.0
In-Reply-To: <s5hafg$g1$1@dont-email.me>
Content-Language: en-US
 by: Niklas Holsti - Sun, 18 Apr 2021 16:23 UTC

On 2021-04-18 15:59, David Brown wrote:
> On 18/04/2021 09:39, Niklas Holsti wrote:
>> On 2021-04-17 19:45, David Brown wrote:
>>> On 17/04/2021 17:48, pozz wrote:
>>>> What do you think about different languages than usual C for embedded
>>>> systems?
>>>>
>>>> I mean C++, Ada but also Python. Always more powerful embedded
>>>> processors are coming, so I expect new and modern languages will enter
>>>> in the embedded world.
>>>>
>>>> ...
>>>> Is it ok for me to study and learn new things... but it will be more
>>>> difficult to acquire new skills for real jobs.
>>>>
>>>> What do you think?
>>>
>>>   ...
>>> Ada involves a fair amount of change to how you work, compared to C
>>> development.  (Disclaimer - I have only done a very small amount of Ada
>>> coding, and no serious projects.  But I have considered it as an
>>> option.)  I really don't see it becoming much more common, and outside
>>> of niche areas (defence, aerospace) it is very rare.  Programming in Ada
>>> often takes a lot more effort even for simple things, leading quickly to
>>> code that is so wordy that it is unclear what is going on.
>>
>>
>> That depends, I guess, on what one considers "simple", and also, of
>> course, on how familiar one is with the languages.
>>
>> Perhaps it is time to link once again to the experience of C versus Ada
>> in an introductory embedded-programming class using a model rail-road
>> example, where the students using Ada fared much better than those using C:
>>
>> http://archive.adaic.com/projects/atwork/trains.html
>
> Are there no newer examples?

I have none to hand, at least.

> While this study was interesting, it is some 30 years out of date

I would call it "30 years old". Whether it is "out of date" can be
debated -- I don't think the basic ideas of the two languages have
changed very drastically even in that time.

> and compares and old version of Ada with an old version of C (perhaps
> not even C90). I'd rather see the pros and cons of Ada 2012 compared
> to C++17.

So would I, but I haven't seen any such studies reported.

I can only point to the biased material at
https://www.adaic.org/advantages/.

And a recent Ada-adoption story from NVIDIA:

https://www.adacore.com/webinars/securing-future-of-embedded-software

but that is more about the AdaCore tools and the SPARK form of Ada than
about C-vs-Ada.

>>
>> I am (as you guessed) an Ada fan, and find it a pleasure to write, even
>> if it takes more keystrokes than the equivalent in C.
>
> I had no need to guess - it's not the first time you have posted about
> Ada here! I'm glad that someone with your Ada qualifications can chime
> in here, and can correct my if I'm wrong.
>
>>
>> For embedded systems in particular, I find portability to be a great
>> advantage of Ada. With few exceptions, the embedded program can be
>> exercised on the development host, and if the target supports the
>> standard Ada tasking system (or a subset of it), this applies even to
>> multi-threaded programs (without the need to emulate some embedded
>> RTK/OS on the host).
>>
>
> For suitable targets, I can see that being useful. C and C++ can be
> used on a wider range of targets, and with a wider range of RTOS (if
> any).

Ada can be used with other RTOSses too, although one loses both some
ease-of-use advantages and the portability advantage. Typical Ada
compilers for embedded systems also let one write Ada programs that do
not need an RTOS at all and run with a single thread.

> Of course, code for widely differing target systems is often very
> different anyway, so portability is not always a concern.
>
>>
>>> And most of the advantages of Ada (such as better typing) can be
>>> achieved in C++ with less effort,
>>
>> According to the link above, the main Ada advantage was the ability to
>> define one's own problem-oriented scalar types, such as integers with
>> specific value ranges. AIUI, this is not easily done in C++.
>>
>
> Sure it can be done in C++.
>
> <https://foonathan.net/2016/10/strong-typedefs/>

I did not see any mention of range-checked types there. But yes, they
can be constructed in C++, but not as easily as in Ada, as it seems we
agree. I should have said "/as/ easily" in the quote above.

> You can make types with specific ranges (with compile-time checks where
> possible, optional run-time checks otherwise). You can choose which
> operations you allow on them, and how they combine (so that multiplying
> a speed and a time give you a distance automatically, but adding them is
> not allowed). You can make integer types with different overflow
> behaviour (wrapping, saturating, throwing errors, unspecified behaviour,
> undefined behaviour) that can be used as easily as normal integers, and
> mixed if and only if it is safe to do so or you make it explicit. You
> can make array types that are indexed by enumerated types. It's all
> possible - more so that in Ada, AFAIK.

I admit that C++ templates allow the programming of more compile-time
activities than Ada allows.

> Where you have a difference, however, is that many of the most
> beneficial cases (such as strong subrange types) are simple to use in
> Ada and built into the language, and therefore they are often used. In
> C++, you need to find a suitable template library or make things
> yourself, giving a much higher barrier to use.

Yup.

> A very interesting distinction when looking at language features and
> safe coding is how much people /could/ use safety features, and how much
> they /do/ use them. For example, with C programming you can get strong
> type safety as long as you wrap all your new types in structs. The
> compiler will complain for type mistakes, just as it would in Ada - but
> the /use/ of such types is often very inconvenient in C.

Indeed.

>>> and at the same time C++ can give additional safety on
>>> resources that is harder to get on Ada.  (But Ada has some nice features
>>> introspective that C++ programmers currently only dream about.)
>>
>>
>> Can you be more specific on those points, please?
>>
>
> For the first point - my understanding is that in Ada, when you have
> classes you need to manually call constructor and destructor
> (initializer and finalizer) functions. RAII is thus harder, and it is
> as easy to make mistakes as it is in C (with malloc and free). Does Ada
> have the equivalent of std::unique_ptr, std::shared_ptr and other smart
> pointers, or container classes that handle allocation?

Answered in another message. The Ada "controlled" types have
automatically called initializer and finalizer operations. They can be
used to implement smart pointers, but no smart pointers are built into
Ada (perhaps mainly because they would then have to be thread-safe,
which would be a lot of overhead for a single-threaded program).

> For the second point, I am thinking of things like type attributes. I
> would /really/ like C++ enumerations to have something matching the
> "first" and "last" attributes! AFAIK, C++ won't get this until
> reflection is added, probably not until C++26.

Yes, good point in favour of Ada. I've seen some C++ programs that go to
great metaprogramming lengths to define "trait" templates to get the
equivalent of the "first", "last", "size" etc. attributes. So it is,
again, possible in C++, but not as easy as when it is built-in, as in Ada.

>>> It used to be the case that C++ compilers were expensive and poor
>>> quality, that the resulting code was very slow on common
>>> microcontrollers, and that the language didn't have much extra to offer
>>> small-systems embedded developers.  That, I think, has changed in all
>>> aspects.  I use gcc 10 with C++17 on Cortex-M devices, and features like
>>> templates, strong enumerations, std::array, and controlled automatic
>>> conversions make it easier to write good code.
>>
>>
>> AdaCore provides the gcc-based GNAT Ada compiler for several embedded
>> targets, free to use for open-source projects: libre.adacore.com.
>>
>> Commercial projects can use Ada on other targets by means of the
>> (different) AdaCore compiler that generates C code as an intermediate
>> representation.
>>
>
> This means that Ada suffers from a similar barrier to adoption that C++
> used to do. Big companies will happily pay the cost for the tools that
> they think will lead to better development efficiency or reliability.
> Smaller ones will have a much harder time trying to justify the expense,
> especially as they will often have few developers who can use the tools.
> A move from C to Ada is compounded by needing a complete change of the
> code - with C to C++, you can re-use old code, and you can also use a
> few of the C++ features rather than moving wholescale (though of course
> you also miss out on corresponding benefits).


Click here to read the complete article
Re: C++, Ada, ...

<s5hogv$77o$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=318&group=comp.arch.embedded#318

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: david.br...@hesbynett.no (David Brown)
Newsgroups: comp.arch.embedded
Subject: Re: C++, Ada, ...
Date: Sun, 18 Apr 2021 18:59:11 +0200
Organization: A noiseless patient Spider
Lines: 129
Message-ID: <s5hogv$77o$1@dont-email.me>
References: <s5f01b$4j3$1@dont-email.me> <s5f3c1$s06$1@dont-email.me>
<AaGeI.148580$qHh9.147135@fx18.ams4> <s5h32f$edv$1@dont-email.me>
<ie32luFlvghU1@mid.individual.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-15
Content-Transfer-Encoding: 8bit
Injection-Date: Sun, 18 Apr 2021 16:59:11 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="815fa31c42c5bf882c41f0a6a05b73f6";
logging-data="7416"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/RNYFE3avKSfs2QQdqRUqDM9IKw9uwUFg="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
Thunderbird/68.10.0
Cancel-Lock: sha1:wTipYhgL7ikiJA2Dl/3okrQRNUw=
In-Reply-To: <ie32luFlvghU1@mid.individual.net>
Content-Language: en-GB
 by: David Brown - Sun, 18 Apr 2021 16:59 UTC

On 18/04/2021 17:48, Niklas Holsti wrote:
> On 2021-04-18 13:53, David Brown wrote:
>> On 17/04/2021 20:55, Tom Gardner wrote:
>>> On 17/04/21 17:45, David Brown wrote:
>>>> And most of
>>>> the advantages of Ada (such as better typing) can be achieved in C++
>>>> with less effort, and at the same time C++ can give additional
>>>> safety on
>>>> resources that is harder to get on Ada.
>>>
>>> Interesting. Could you give a quick outline of that?
>>>
>>
>> Which part?
>>
>> My understanding of Ada classes is that, like Pascal classes, you need
>> to explicitly construct and destruct objects.  This gives far greater
>> scope for programmers to get things wrong than when they are handled
>> automatically by the language.
>
>
> If you mean automatic allocation and deallocation of storage, Ada lets
> you define types that have an "initializer" that is called
> automatically, and can allocate memory if it needs to, and a "finalizer"
> that is automatically called when leaving the scope of the object in
> question. The finalizer does have to explicitly deallocate any
> explicitly allocated and owned resources, and it may have to use
> reference counting for that, for complex data structures.

I had a little look for this (these discussions are great for inspiring
learning!). The impression I got was that it was possible, but what
takes a few lines of C++ (excluding whatever work must be done inside
the constructor and destructor bodies) involves inheriting from a
specific library type. And you don't have automatic initialisation of
subobjects and ancestors in a controlled order, nor automatic
finalisation of them in the reverse order.

Let's take a little example. And since this is comp.arch.embedded,
let's take a purely embedded example of disabling interrupts, rather
than shunned dynamic memory allocations:

static inline uint32_t disableGlobalInterrupts(void) {
uint32_t pri;
asm volatile(
" mrs %[pri], primask\n\t" // Get old mask
" cpsid i\n\t" // Disable interrupts entirely
" dsb" // Ensures that this takes effect before next
// instruction
: [pri] "=r" (pri) :: "memory");
return pri;
}

static inline void restoreGlobalInterrupts(uint32_t pri) {
asm volatile(
" msr primask, %[pri]" // Restore old mask
:: [pri] "r" (pri) : "memory");
}

class CriticalSectionLock {
private :
uint32_t oldpri;
public :
CriticalSectionLock() { oldpri = disableGlobalInterrupts(); }
~CriticalSectionLock() { restoreGlobalInterrupts(oldpri); }
};

You can use it like this:

bool compare_and_swap64(uint64_t * p, uint64_t old, uint64_t x)
{ CriticalSectionLock lock;

if (*p != old) return false;
*p = x;
return true;
}

This is the code compiled for a 32-bit Cortex-M device:

<https://godbolt.org/z/7KM9M6Kcd>

The use of the class here has no overhead compared to manually disabling
and re-enabling interrupts.

What would be the Ada equivalent of this class, and of the
"compare_and_swap64" function?

>
> AUI that also holds for C++, although I believe recent C++ standards may
> have simplified the definition and use of reference-counted data
> structures.
>
>
>> On the other hand, some of Ada's type mechanisms make it a lot easier to
>> make new types with similar properties while remaining distinct (such as
>> subranges of integer types).  You can do that in C++, but someone needs
>> to make the effort to make the appropriate class templates.  Thus these
>> are more often used in Ada coding than in C++ coding.
>
>
> (That relative ease in Ada was the point of my other response -- more to
> come on that.)
>
>
>> On the third hand (three hands are always useful for programming), the
>> wordy nature of type conversions in Ada mean programmers would be
>> tempted to take shortcuts and skip these extra types.
>
>
> Huh? A normal conversion in C is written "(newtype)expression", the same
> in Ada is written "newtype(expression)". Exactly the same number of
> characters, only the placement of the () is different. The C form might
> even require an extra set of parentheses around it, to demarcate the
> expression to be converted from any containing expression.
>
> Of course, in C you have implicit conversions between all kinds of
> numerical types, often leading to a whole lot of errors... not only
> apples+oranges, but also truncation or other miscomputation.

C also makes explicit conversions wordy, yes. In C++, you can choose
which conversions are explicit and which are implicit - done carefully,
your safe conversions will be implicit and unsafe ones need to be explicit.

(C++ suffers from its C heritage and backwards compatibility, meaning it
can't fix things that were always implicit conversion. It's too late to
make "int x = 123.4;" an error. The best C++ can do is add a new syntax
with better safety - so "int y { 123 };" is fine but "int z { 123.4 };"
is an error.)

Re: C++, Ada, ...

<s5hq48$k2e$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=319&group=comp.arch.embedded#319

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: david.br...@hesbynett.no (David Brown)
Newsgroups: comp.arch.embedded
Subject: Re: C++, Ada, ...
Date: Sun, 18 Apr 2021 19:26:31 +0200
Organization: A noiseless patient Spider
Lines: 287
Message-ID: <s5hq48$k2e$1@dont-email.me>
References: <s5f01b$4j3$1@dont-email.me> <s5f3c1$s06$1@dont-email.me>
<ie260rFghneU1@mid.individual.net> <s5hafg$g1$1@dont-email.me>
<ie34olFmda9U1@mid.individual.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-15
Content-Transfer-Encoding: 8bit
Injection-Date: Sun, 18 Apr 2021 17:26:32 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="815fa31c42c5bf882c41f0a6a05b73f6";
logging-data="20558"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/Y6qDVJUGgdQ376QdFywxvkBardUFKzYk="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
Thunderbird/68.10.0
Cancel-Lock: sha1:o3HOTrEKpw1rFJuX0CbKswAK9f8=
In-Reply-To: <ie34olFmda9U1@mid.individual.net>
Content-Language: en-GB
 by: David Brown - Sun, 18 Apr 2021 17:26 UTC

On 18/04/2021 18:23, Niklas Holsti wrote:
> On 2021-04-18 15:59, David Brown wrote:
>> On 18/04/2021 09:39, Niklas Holsti wrote:
>>> On 2021-04-17 19:45, David Brown wrote:
>>>> On 17/04/2021 17:48, pozz wrote:
>>>>> What do you think about different languages than usual C for embedded
>>>>> systems?
>>>>>
>>>>> I mean C++, Ada but also Python. Always more powerful embedded
>>>>> processors are coming, so I expect new and modern languages will enter
>>>>> in the embedded world.
>>>>>
>>>>> ...
>>>>> Is it ok for me to study and learn new things... but it will be more
>>>>> difficult to acquire new skills for real jobs.
>>>>>
>>>>> What do you think?
>>>>
>>>>    ...
>>>> Ada involves a fair amount of change to how you work, compared to C
>>>> development.  (Disclaimer - I have only done a very small amount of Ada
>>>> coding, and no serious projects.  But I have considered it as an
>>>> option.)  I really don't see it becoming much more common, and outside
>>>> of niche areas (defence, aerospace) it is very rare.  Programming in
>>>> Ada
>>>> often takes a lot more effort even for simple things, leading
>>>> quickly to
>>>> code that is so wordy that it is unclear what is going on.
>>>
>>>
>>> That depends, I guess, on what one considers "simple", and also, of
>>> course, on how familiar one is with the languages.
>>>
>>> Perhaps it is time to link once again to the experience of C versus Ada
>>> in an introductory embedded-programming class using a model rail-road
>>> example, where the students using Ada fared much better than those
>>> using C:
>>>
>>> http://archive.adaic.com/projects/atwork/trains.html
>>
>> Are there no newer examples?
>
>
> I have none to hand, at least.
>
>
>> While this study was interesting, it is some 30 years out of date
>
> I would call it "30 years old". Whether it is "out of date" can be
> debated -- I don't think the basic ideas of the two languages have
> changed very drastically even in that time.
>

C made a big leap, IMHO, with C99 - it became a significantly better
language, and it became easier to write safe, clear and efficient code
than with C90. (C11 and C17 add little in comparison.)

C++ is a completely different language now than it was 30 years ago.

And the tools for both C and C++ have changed hugely in that time.

But some programmers have not changed, and the way they write C code has
not changed. Again, it's a question of whether you are comparing how
languages /could/ be used at their best, or how some people use them at
their worst, or guessing something in between.

>
>> and compares and old version of Ada with an old version of C (perhaps
>> not even C90).  I'd rather see the pros and cons of Ada 2012 compared
>> to C++17.
>
> So would I, but I haven't seen any such studies reported.
>
> I can only point to the biased material at
> https://www.adaic.org/advantages/.

As an example of the bias, I looked at the "What constructs exist in Ada
that do not have an equivalent construct in C/C++?" page. First off,
anyone who talks about "C/C++" as though it were a single language is
either ignorant or biased. Some of their points are outdated (C++ has
"proper" array types in the standard library), and support for very nice
syntaxes for literals). Some are fair enough - strong type checking of
arithmetic types needs a good deal more effort (such as shown in the
"strong typedef" link from earlier). Some are absolutely a point to
Ada, such as named parameters. And the page is missing the "What
constructs exist in C++ that do not have an equivalent in Ada?" list :-)

>
> And a recent Ada-adoption story from NVIDIA:
>
> https://www.adacore.com/webinars/securing-future-of-embedded-software
>
> but that is more about the AdaCore tools and the SPARK form of Ada than
> about C-vs-Ada.
>
>>>
>>> I am (as you guessed) an Ada fan, and find it a pleasure to write, even
>>> if it takes more keystrokes than the equivalent in C.
>>
>> I had no need to guess - it's not the first time you have posted about
>> Ada here!  I'm glad that someone with your Ada qualifications can chime
>> in here, and can correct my if I'm wrong.
>>
>>>
>>> For embedded systems in particular, I find portability to be a great
>>> advantage of Ada. With few exceptions, the embedded program can be
>>> exercised on the development host, and if the target supports the
>>> standard Ada tasking system (or a subset of it), this applies even to
>>> multi-threaded programs (without the need to emulate some embedded
>>> RTK/OS on the host).
>>>
>>
>> For suitable targets, I can see that being useful.  C and C++ can be
>> used on a wider range of targets, and with a wider range of RTOS (if
>> any).
>
>
> Ada can be used with other RTOSses too, although one loses both some
> ease-of-use advantages and the portability advantage. Typical Ada
> compilers for embedded systems also let one write Ada programs that do
> not need an RTOS at all and run with a single thread.
>
>
>> Of course, code for widely differing target systems is often very
>> different anyway, so portability is not always a concern.
>>
>>>
>>>> And most of the advantages of Ada (such as better typing) can be
>>>> achieved in C++ with less effort,
>>>
>>> According to the link above, the main Ada advantage was the ability to
>>> define one's own problem-oriented scalar types, such as integers with
>>> specific value ranges. AIUI, this is not easily done in C++.
>>>
>>
>> Sure it can be done in C++.
>>
>> <https://foonathan.net/2016/10/strong-typedefs/>
>
> I did not see any mention of range-checked types there. But yes, they
> can be constructed in C++, but not as easily as in Ada, as it seems we
> agree. I should have said "/as/ easily" in the quote above.

Once you have made appropriate templates, they can be used as easily as
in Ada. But such templates are not in the C++ standard library.

>
>
>> You can make types with specific ranges (with compile-time checks where
>> possible, optional run-time checks otherwise).  You can choose which
>> operations you allow on them, and how they combine (so that multiplying
>> a speed and a time give you a distance automatically, but adding them is
>> not allowed).  You can make integer types with different overflow
>> behaviour (wrapping, saturating, throwing errors, unspecified behaviour,
>> undefined behaviour) that can be used as easily as normal integers, and
>> mixed if and only if it is safe to do so or you make it explicit.  You
>> can make array types that are indexed by enumerated types.  It's all
>> possible - more so that in Ada, AFAIK.
>
>
> I admit that C++ templates allow the programming of more compile-time
> activities than Ada allows.
>

C++ has got a lot stronger at compile-time work in recent versions. Not
only have templates got more powerful, but we've got "concepts" (named
sets of features or requirements for types), constexpr functions (that
can be evaluated at compile time or runtime), consteval functions (that
must be evaluated at compile time), constinit data (that must have
compile-time constant initialisers), etc. And constants determined at
compile-time are not restricted to scaler or simple types.

>
>> Where you have a difference, however, is that many of the most
>> beneficial cases (such as strong subrange types) are simple to use in
>> Ada and built into the language, and therefore they are often used.  In
>> C++, you need to find a suitable template library or make things
>> yourself, giving a much higher barrier to use.
>
>
> Yup.
>
>
>> A very interesting distinction when looking at language features and
>> safe coding is how much people /could/ use safety features, and how much
>> they /do/ use them.  For example, with C programming you can get strong
>> type safety as long as you wrap all your new types in structs.  The
>> compiler will complain for type mistakes, just as it would in Ada - but
>> the /use/ of such types is often very inconvenient in C.
>
>
> Indeed.
>
>
>>>> and at the same time C++ can give additional safety on
>>>> resources that is harder to get on Ada.  (But Ada has some nice
>>>> features
>>>> introspective that C++ programmers currently only dream about.)
>>>
>>>
>>> Can you be more specific on those points, please?
>>>
>>
>> For the first point - my understanding is that in Ada, when you have
>> classes you need to manually call constructor and destructor
>> (initializer and finalizer) functions.  RAII is thus harder, and it is
>> as easy to make mistakes as it is in C (with malloc and free).  Does Ada
>> have the equivalent of std::unique_ptr, std::shared_ptr and other smart
>> pointers, or container classes that handle allocation?
>
>
> Answered in another message. The Ada "controlled" types have
> automatically called initializer and finalizer operations. They can be
> used to implement smart pointers, but no smart pointers are built into
> Ada (perhaps mainly because they would then have to be thread-safe,
> which would be a lot of overhead for a single-threaded program).
>
>
>> For the second point, I am thinking of things like type attributes.  I
>> would /really/ like C++ enumerations to have something matching the
>> "first" and "last" attributes!  AFAIK, C++ won't get this until
>> reflection is added, probably not until C++26.
>
>
> Yes, good point in favour of Ada. I've seen some C++ programs that go to
> great metaprogramming lengths to define "trait" templates to get the
> equivalent of the "first", "last", "size" etc. attributes. So it is,
> again, possible in C++, but not as easy as when it is built-in, as in Ada.
>


Click here to read the complete article
Re: C++, Ada, ...

<qU_eI.237388$KHwf.234963@fx25.ams4>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=320&group=comp.arch.embedded#320

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!aioe.org!news.uzoreto.com!news-out.netnews.com!news.alt.net!fdc2.netnews.com!peer04.ams1!peer.ams1.xlned.com!news.xlned.com!peer02.ams4!peer.am4.highwinds-media.com!news.highwinds-media.com!fx25.ams4.POSTED!not-for-mail
Reply-To: spamjunk@blueyonder.co.uk
Subject: Re: C++, Ada, ...
Newsgroups: comp.arch.embedded
References: <s5f01b$4j3$1@dont-email.me> <s5f3c1$s06$1@dont-email.me>
<ie260rFghneU1@mid.individual.net> <s5hafg$g1$1@dont-email.me>
<ie34olFmda9U1@mid.individual.net> <s5hq48$k2e$1@dont-email.me>
From: spamj...@blueyonder.co.uk (Tom Gardner)
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
Firefox/52.0 SeaMonkey/2.49.4
MIME-Version: 1.0
In-Reply-To: <s5hq48$k2e$1@dont-email.me>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 16
Message-ID: <qU_eI.237388$KHwf.234963@fx25.ams4>
X-Complaints-To: http://netreport.virginmedia.com
NNTP-Posting-Date: Sun, 18 Apr 2021 18:29:42 UTC
Organization: virginmedia.com
Date: Sun, 18 Apr 2021 19:29:41 +0100
X-Received-Bytes: 1692
 by: Tom Gardner - Sun, 18 Apr 2021 18:29 UTC

On 18/04/21 18:26, David Brown wrote:
> But some programmers have not changed, and the way they write C code has
> not changed. Again, it's a question of whether you are comparing how
> languages/could/ be used at their best, or how some people use them at
> their worst, or guessing something in between.

That is indeed a useful first question.

A second question is "how easy is it to get intelligent
but inexperienced programmers to avoid the worst features
and use the languages well?" (We'll ignore all the programmers
that shouldn't be given a keyboard :) )

A third is "will that happen in company X's environment when
they are extending code written by people that left 5 years
ago?"

Re: C++, Ada, ...

<WU_eI.237389$KHwf.63256@fx25.ams4>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=321&group=comp.arch.embedded#321

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!4.us.feeder.erje.net!2.eu.feeder.erje.net!feeder.erje.net!newsfeed.xs4all.nl!newsfeed8.news.xs4all.nl!50.7.236.10.MISMATCH!news-out.netnews.com!news.alt.net!fdc2.netnews.com!peer04.ams1!peer.ams1.xlned.com!news.xlned.com!peer02.ams4!peer.am4.highwinds-media.com!news.highwinds-media.com!fx25.ams4.POSTED!not-for-mail
Reply-To: spamjunk@blueyonder.co.uk
Subject: Re: C++, Ada, ...
Newsgroups: comp.arch.embedded
References: <s5f01b$4j3$1@dont-email.me> <s5f3c1$s06$1@dont-email.me>
<ie260rFghneU1@mid.individual.net> <s5hafg$g1$1@dont-email.me>
<ie34olFmda9U1@mid.individual.net> <s5hq48$k2e$1@dont-email.me>
From: spamj...@blueyonder.co.uk (Tom Gardner)
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
Firefox/52.0 SeaMonkey/2.49.4
MIME-Version: 1.0
In-Reply-To: <s5hq48$k2e$1@dont-email.me>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 10
Message-ID: <WU_eI.237389$KHwf.63256@fx25.ams4>
X-Complaints-To: http://netreport.virginmedia.com
NNTP-Posting-Date: Sun, 18 Apr 2021 18:30:14 UTC
Organization: virginmedia.com
Date: Sun, 18 Apr 2021 19:30:13 +0100
X-Received-Bytes: 1543
 by: Tom Gardner - Sun, 18 Apr 2021 18:30 UTC

On 18/04/21 18:26, David Brown wrote:
> C++ has got a lot stronger at compile-time work in recent versions. Not
> only have templates got more powerful, but we've got "concepts" (named
> sets of features or requirements for types), constexpr functions (that
> can be evaluated at compile time or runtime), consteval functions (that
> must be evaluated at compile time), constinit data (that must have
> compile-time constant initialisers), etc. And constants determined at
> compile-time are not restricted to scaler or simple types.

Sounds wordy ;)

Re: C++, Ada, ...

<s5i441$tro$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=322&group=comp.arch.embedded#322

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: david.br...@hesbynett.no (David Brown)
Newsgroups: comp.arch.embedded
Subject: Re: C++, Ada, ...
Date: Sun, 18 Apr 2021 22:17:05 +0200
Organization: A noiseless patient Spider
Lines: 32
Message-ID: <s5i441$tro$1@dont-email.me>
References: <s5f01b$4j3$1@dont-email.me> <s5f3c1$s06$1@dont-email.me>
<ie260rFghneU1@mid.individual.net> <s5hafg$g1$1@dont-email.me>
<ie34olFmda9U1@mid.individual.net> <s5hq48$k2e$1@dont-email.me>
<WU_eI.237389$KHwf.63256@fx25.ams4>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-15
Content-Transfer-Encoding: 8bit
Injection-Date: Sun, 18 Apr 2021 20:17:06 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="815fa31c42c5bf882c41f0a6a05b73f6";
logging-data="30584"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+ZbKEHtkaqd7ANIH7C/P+HBbq8Mu9Oeo0="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
Thunderbird/68.10.0
Cancel-Lock: sha1:djsJVQEkpYRz730/eZYvP70XAk0=
In-Reply-To: <WU_eI.237389$KHwf.63256@fx25.ams4>
Content-Language: en-GB
 by: David Brown - Sun, 18 Apr 2021 20:17 UTC

On 18/04/2021 20:30, Tom Gardner wrote:
> On 18/04/21 18:26, David Brown wrote:
>> C++ has got a lot stronger at compile-time work in recent versions.  Not
>> only have templates got more powerful, but we've got "concepts" (named
>> sets of features or requirements for types), constexpr functions (that
>> can be evaluated at compile time or runtime), consteval functions (that
>> must be evaluated at compile time), constinit data (that must have
>> compile-time constant initialisers), etc.  And constants determined at
>> compile-time are not restricted to scaler or simple types.
>
> Sounds wordy ;)

Have you looked at the C++ standards documents? There are more than a
few words there!

I'm not suggesting C++ is a perfect language - not by a long way. It
has plenty of ugliness, and in this thread we've covered several points
where Ada can do something neater and clearer than you can do it in C++.

But it's a good thing that it has more ways for handling things at
compile time. In many of my C projects, I have had Python code for
pre-processing, for computing tables, and that kind of thing. With
modern C++, these are no longer needed.

An odd thing about the compile-time calculation features of C++ is that
they came about partly by accident, or unforeseen side-effects. Someone
discovered that templates with integer parameters could be used to do
quite a lot of compile-time calculations. The code was /really/ ugly,
slow to compile, limited in scope. But people were finding use for it.
So the motivation for "constexpr" was that programmers were already
doing compile-time calculations, and so it was best to let them do it in
a nicer way.

Re: C++, Ada, ...

<s5i4gh$nb$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=323&group=comp.arch.embedded#323

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: david.br...@hesbynett.no (David Brown)
Newsgroups: comp.arch.embedded
Subject: Re: C++, Ada, ...
Date: Sun, 18 Apr 2021 22:23:44 +0200
Organization: A noiseless patient Spider
Lines: 30
Message-ID: <s5i4gh$nb$1@dont-email.me>
References: <s5f01b$4j3$1@dont-email.me> <s5f3c1$s06$1@dont-email.me>
<ie260rFghneU1@mid.individual.net> <s5hafg$g1$1@dont-email.me>
<ie34olFmda9U1@mid.individual.net> <s5hq48$k2e$1@dont-email.me>
<qU_eI.237388$KHwf.234963@fx25.ams4>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-15
Content-Transfer-Encoding: 8bit
Injection-Date: Sun, 18 Apr 2021 20:23:45 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="815fa31c42c5bf882c41f0a6a05b73f6";
logging-data="747"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19WGELKbKruZFo0qJb9IfAt8tZQDoqXOV4="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
Thunderbird/68.10.0
Cancel-Lock: sha1:Nkzd6JtwcOj2Y/8jtfAPtAwJBKk=
In-Reply-To: <qU_eI.237388$KHwf.234963@fx25.ams4>
Content-Language: en-GB
 by: David Brown - Sun, 18 Apr 2021 20:23 UTC

On 18/04/2021 20:29, Tom Gardner wrote:
> On 18/04/21 18:26, David Brown wrote:
>> But some programmers have not changed, and the way they write C code has
>> not changed.  Again, it's a question of whether you are comparing how
>> languages/could/  be used at their best, or how some people use them at
>> their worst, or guessing something in between.
>
> That is indeed a useful first question.
>
> A second question is "how easy is it to get intelligent
> but inexperienced programmers to avoid the worst features
> and use the languages well?" (We'll ignore all the programmers
> that shouldn't be given a keyboard :) )
>
> A third is "will that happen in company X's environment when
> they are extending code written by people that left 5 years
> ago?"

All good questions.

Another is what will happen to the company when the one person that
understood the language at all, leaves? With C++, you can hire another
qualified and experienced C++ programmer. (Okay, so you might have to
beat them over the head with an 8051 emulator until they stop using
std::vector and realise you don't want UCS2 encoding for your 2x20
character display, but they'll learn that soon enough.) With Ada, or
Forth, or any other minor language, you are scuppered.

These are important considerations.

Re: C++, Ada, ...

<a62fI.433317$qNp.204340@fx39.ams4>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=324&group=comp.arch.embedded#324

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!aioe.org!news.uzoreto.com!news-out.netnews.com!news.alt.net!fdc3.netnews.com!peer03.ams1!peer.ams1.xlned.com!news.xlned.com!peer03.ams4!peer.am4.highwinds-media.com!news.highwinds-media.com!fx39.ams4.POSTED!not-for-mail
Reply-To: spamjunk@blueyonder.co.uk
Subject: Re: C++, Ada, ...
Newsgroups: comp.arch.embedded
References: <s5f01b$4j3$1@dont-email.me> <s5f3c1$s06$1@dont-email.me>
<ie260rFghneU1@mid.individual.net> <s5hafg$g1$1@dont-email.me>
<ie34olFmda9U1@mid.individual.net> <s5hq48$k2e$1@dont-email.me>
<qU_eI.237388$KHwf.234963@fx25.ams4> <s5i4gh$nb$1@dont-email.me>
From: spamj...@blueyonder.co.uk (Tom Gardner)
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
Firefox/52.0 SeaMonkey/2.49.4
MIME-Version: 1.0
In-Reply-To: <s5i4gh$nb$1@dont-email.me>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 43
Message-ID: <a62fI.433317$qNp.204340@fx39.ams4>
X-Complaints-To: http://netreport.virginmedia.com
NNTP-Posting-Date: Sun, 18 Apr 2021 22:09:10 UTC
Organization: virginmedia.com
Date: Sun, 18 Apr 2021 23:09:10 +0100
X-Received-Bytes: 2856
 by: Tom Gardner - Sun, 18 Apr 2021 22:09 UTC

On 18/04/21 21:23, David Brown wrote:
> On 18/04/2021 20:29, Tom Gardner wrote:
>> On 18/04/21 18:26, David Brown wrote:
>>> But some programmers have not changed, and the way they write C code has
>>> not changed.  Again, it's a question of whether you are comparing how
>>> languages/could/  be used at their best, or how some people use them at
>>> their worst, or guessing something in between.
>>
>> That is indeed a useful first question.
>>
>> A second question is "how easy is it to get intelligent
>> but inexperienced programmers to avoid the worst features
>> and use the languages well?" (We'll ignore all the programmers
>> that shouldn't be given a keyboard :) )
>>
>> A third is "will that happen in company X's environment when
>> they are extending code written by people that left 5 years
>> ago?"
>
> All good questions.
>
> Another is what will happen to the company when the one person that
> understood the language at all, leaves? With C++, you can hire another
> qualified and experienced C++ programmer. (Okay, so you might have to
> beat them over the head with an 8051 emulator until they stop using
> std::vector and realise you don't want UCS2 encoding for your 2x20
> character display, but they'll learn that soon enough.) With Ada, or
> Forth, or any other minor language, you are scuppered.
>
> These are important considerations.

They are important considerations, indeed.

I'm unconvinced that it is practical to rely on hiring
another C++ programmer that is /actually/ qualified
and experienced - and wants to work on someone else's
code.

The "uncanny valley" is a major problem for any new tech,
languages included.

We've all seen the next better mousetrap that turns
out to merely have exchanged swings and roundabouts.

Re: C++, Ada, ...

<Kd2fI.273342$zV01.166134@fx49.ams4>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=325&group=comp.arch.embedded#325

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!newsreader4.netcologne.de!news.netcologne.de!peer03.ams1!peer.ams1.xlned.com!news.xlned.com!peer03.ams4!peer.am4.highwinds-media.com!news.highwinds-media.com!fx49.ams4.POSTED!not-for-mail
Reply-To: spamjunk@blueyonder.co.uk
Subject: Re: C++, Ada, ...
Newsgroups: comp.arch.embedded
References: <s5f01b$4j3$1@dont-email.me> <s5f3c1$s06$1@dont-email.me>
<ie260rFghneU1@mid.individual.net> <s5hafg$g1$1@dont-email.me>
<ie34olFmda9U1@mid.individual.net> <s5hq48$k2e$1@dont-email.me>
<WU_eI.237389$KHwf.63256@fx25.ams4> <s5i441$tro$1@dont-email.me>
From: spamj...@blueyonder.co.uk (Tom Gardner)
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
Firefox/52.0 SeaMonkey/2.49.4
MIME-Version: 1.0
In-Reply-To: <s5i441$tro$1@dont-email.me>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 50
Message-ID: <Kd2fI.273342$zV01.166134@fx49.ams4>
X-Complaints-To: http://netreport.virginmedia.com
NNTP-Posting-Date: Sun, 18 Apr 2021 22:17:14 UTC
Organization: virginmedia.com
Date: Sun, 18 Apr 2021 23:17:14 +0100
X-Received-Bytes: 3387
 by: Tom Gardner - Sun, 18 Apr 2021 22:17 UTC

On 18/04/21 21:17, David Brown wrote:
> On 18/04/2021 20:30, Tom Gardner wrote:
>> On 18/04/21 18:26, David Brown wrote:
>>> C++ has got a lot stronger at compile-time work in recent versions.  Not
>>> only have templates got more powerful, but we've got "concepts" (named
>>> sets of features or requirements for types), constexpr functions (that
>>> can be evaluated at compile time or runtime), consteval functions (that
>>> must be evaluated at compile time), constinit data (that must have
>>> compile-time constant initialisers), etc.  And constants determined at
>>> compile-time are not restricted to scaler or simple types.
>>
>> Sounds wordy ;)
>
> Have you looked at the C++ standards documents? There are more than a
> few words there!

No. I value my sanity.

> I'm not suggesting C++ is a perfect language - not by a long way. It
> has plenty of ugliness, and in this thread we've covered several points
> where Ada can do something neater and clearer than you can do it in C++.
>
> But it's a good thing that it has more ways for handling things at
> compile time. In many of my C projects, I have had Python code for
> pre-processing, for computing tables, and that kind of thing. With
> modern C++, these are no longer needed.

The useful question is not whether something is good,
but whether there are better alternatives. "Better",
of course, can include /anything/ relevant!

> An odd thing about the compile-time calculation features of C++ is that
> they came about partly by accident, or unforeseen side-effects. Someone
> discovered that templates with integer parameters could be used to do
> quite a lot of compile-time calculations. The code was /really/ ugly,
> slow to compile, limited in scope. But people were finding use for it.
> So the motivation for "constexpr" was that programmers were already
> doing compile-time calculations, and so it was best to let them do it in
> a nicer way.

Infamously, getting a valid C++ program that cause the
compiler to generate the sequence of prime numbers during
compilation came as an unpleasant /surprise/ to the C++
standards committee.

The code is short; whether it is ugly is a matter of taste!
https://en.wikibooks.org/wiki/C%2B%2B_Programming/Templates/Template_Meta-Programming#History_of_TMP

Re: C++, Ada, ...

<s5j9bk$ced$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=326&group=comp.arch.embedded#326

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: david.br...@hesbynett.no (David Brown)
Newsgroups: comp.arch.embedded
Subject: Re: C++, Ada, ...
Date: Mon, 19 Apr 2021 08:52:36 +0200
Organization: A noiseless patient Spider
Lines: 93
Message-ID: <s5j9bk$ced$1@dont-email.me>
References: <s5f01b$4j3$1@dont-email.me> <s5f3c1$s06$1@dont-email.me>
<ie260rFghneU1@mid.individual.net> <s5hafg$g1$1@dont-email.me>
<ie34olFmda9U1@mid.individual.net> <s5hq48$k2e$1@dont-email.me>
<WU_eI.237389$KHwf.63256@fx25.ams4> <s5i441$tro$1@dont-email.me>
<Kd2fI.273342$zV01.166134@fx49.ams4>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-15
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 19 Apr 2021 06:52:36 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="f21b347e432a7da8c8112e546840e277";
logging-data="12749"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18MFQ+HvjZDGqJUlpA001fxmX3689HIdis="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
Thunderbird/68.10.0
Cancel-Lock: sha1:v7dXB07qm32oYdlIDmJbBw9qs/s=
In-Reply-To: <Kd2fI.273342$zV01.166134@fx49.ams4>
Content-Language: en-GB
 by: David Brown - Mon, 19 Apr 2021 06:52 UTC

On 19/04/2021 00:17, Tom Gardner wrote:
> On 18/04/21 21:17, David Brown wrote:
>> On 18/04/2021 20:30, Tom Gardner wrote:
>>> On 18/04/21 18:26, David Brown wrote:
>>>> C++ has got a lot stronger at compile-time work in recent versions. 
>>>> Not
>>>> only have templates got more powerful, but we've got "concepts" (named
>>>> sets of features or requirements for types), constexpr functions (that
>>>> can be evaluated at compile time or runtime), consteval functions (that
>>>> must be evaluated at compile time), constinit data (that must have
>>>> compile-time constant initialisers), etc.  And constants determined at
>>>> compile-time are not restricted to scaler or simple types.
>>>
>>> Sounds wordy ;)
>>
>> Have you looked at the C++ standards documents?  There are more than a
>> few words there!
>
> No. I value my sanity.

I have looked at it, and come back as sane as ever (apart from the
pencils up my nose and underpants on my head). But I've worked up to it
through many versions of the C standards.

More seriously, if I need to look up any details of C or C++, I find
<https://en.cppreference.com/w/> vastly more user-friendly.

>
>
>> I'm not suggesting C++ is a perfect language - not by a long way.  It
>> has plenty of ugliness, and in this thread we've covered several points
>> where Ada can do something neater and clearer than you can do it in C++.
>>
>> But it's a good thing that it has more ways for handling things at
>> compile time.  In many of my C projects, I have had Python code for
>> pre-processing, for computing tables, and that kind of thing.  With
>> modern C++, these are no longer needed.
>
> The useful question is not whether something is good,
> but whether there are better alternatives. "Better",
> of course, can include /anything/ relevant!
>

Yes - and "better" is usually highly subjective.

In the case of compile-time calculations, modern C++ is certainly better
than older C++ versions or C (or, AFAIK, Ada). It can't do everything
that I might do with external Python scripts - it can't do code
generation, or make tables that depend on multiple source files, or make
CRC checks for the final binary. But it can do some things that
previously required external scripts, and that's nice.

>
>
>> An odd thing about the compile-time calculation features of C++ is that
>> they came about partly by accident, or unforeseen side-effects.  Someone
>> discovered that templates with integer parameters could be used to do
>> quite a lot of compile-time calculations.  The code was /really/ ugly,
>> slow to compile, limited in scope.  But people were finding use for it.
>>   So the motivation for "constexpr" was that programmers were already
>> doing compile-time calculations, and so it was best to let them do it in
>> a nicer way.
>
> Infamously, getting a valid C++ program that cause the
> compiler to generate the sequence of prime numbers during
> compilation came as an unpleasant /surprise/ to the C++
> standards committee.

I don't believe that the surprise was "unpleasant" - it's just something
they hadn't considered. (I'm not even sure of that either - my feeling
is that this is an urban myth, or at least a story exaggerated in the
regular retelling.)

>
> The code is short; whether it is ugly is a matter of taste!
> https://en.wikibooks.org/wiki/C%2B%2B_Programming/Templates/Template_Meta-Programming#History_of_TMP
>

Template-based calculations were certainly very convoluted - they needed
a functional programming style structure but with much more awkward
syntax (and at the height of their "popularity", horrendous compiler
error messages when you made a mistake - that too has improved greatly).
And that is why constexpr (especially in latest versions) is so much
better.

Template-based calculations are a bit like trying to do calculations and
data structures in LaTeX. It is all possible, but it doesn't roll off
the tongue very easily.

(I wonder if anyone else understands the pencil and underpants
reference. I am sure Tom does.)

Re: C++, Ada, ...

<s5j9j3$djk$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=327&group=comp.arch.embedded#327

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: david.br...@hesbynett.no (David Brown)
Newsgroups: comp.arch.embedded
Subject: Re: C++, Ada, ...
Date: Mon, 19 Apr 2021 08:56:34 +0200
Organization: A noiseless patient Spider
Lines: 60
Message-ID: <s5j9j3$djk$1@dont-email.me>
References: <s5f01b$4j3$1@dont-email.me> <s5f3c1$s06$1@dont-email.me>
<ie260rFghneU1@mid.individual.net> <s5hafg$g1$1@dont-email.me>
<ie34olFmda9U1@mid.individual.net> <s5hq48$k2e$1@dont-email.me>
<qU_eI.237388$KHwf.234963@fx25.ams4> <s5i4gh$nb$1@dont-email.me>
<a62fI.433317$qNp.204340@fx39.ams4>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-15
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 19 Apr 2021 06:56:35 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="f21b347e432a7da8c8112e546840e277";
logging-data="13940"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+mkZHShmiDtqSFm3NV8bIuvXY2+ee55B4="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
Thunderbird/68.10.0
Cancel-Lock: sha1:3fP5oiOl5p73pXeRLK6ikHVtFkQ=
In-Reply-To: <a62fI.433317$qNp.204340@fx39.ams4>
Content-Language: en-GB
 by: David Brown - Mon, 19 Apr 2021 06:56 UTC

On 19/04/2021 00:09, Tom Gardner wrote:
> On 18/04/21 21:23, David Brown wrote:
>> On 18/04/2021 20:29, Tom Gardner wrote:
>>> On 18/04/21 18:26, David Brown wrote:
>>>> But some programmers have not changed, and the way they write C code
>>>> has
>>>> not changed.  Again, it's a question of whether you are comparing how
>>>> languages/could/  be used at their best, or how some people use them at
>>>> their worst, or guessing something in between.
>>>
>>> That is indeed a useful first question.
>>>
>>> A second question is "how easy is it to get intelligent
>>> but inexperienced programmers to avoid the worst features
>>> and use the languages well?" (We'll ignore all the programmers
>>> that shouldn't be given a keyboard :) )
>>>
>>> A third is "will that happen in company X's environment when
>>> they are extending code written by people that left 5 years
>>> ago?"
>>
>> All good questions.
>>
>> Another is what will happen to the company when the one person that
>> understood the language at all, leaves?  With C++, you can hire another
>> qualified and experienced C++ programmer.  (Okay, so you might have to
>> beat them over the head with an 8051 emulator until they stop using
>> std::vector and realise you don't want UCS2 encoding for your 2x20
>> character display, but they'll learn that soon enough.)  With Ada, or
>> Forth, or any other minor language, you are scuppered.
>>
>> These are important considerations.
>
> They are important considerations, indeed.
>
> I'm unconvinced that it is practical to rely on hiring
> another C++ programmer that is /actually/ qualified
> and experienced - and wants to work on someone else's
> code.

You don't tell the new guy that he or she must maintain old code! You
spring that as a surprise, once you've got them hooked on the quality of
your coffee machine.

>
> The "uncanny valley" is a major problem for any new tech,
> languages included.
>
> We've all seen the next better mousetrap that turns
> out to merely have exchanged swings and roundabouts.

Indeed.

But code written in the latest fad language is not the worst. I've had
to deal with code (for a PC) written in ancient versions of a propriety
"RAD tool" where the vendor will no longer sell the outdated version and
the new tool version is not remotely compatible. I'd pick Ada over that
any day of the week.

Re: C++, Ada, ...

<BMbfI.171837$9Poc.19162@fx24.ams4>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=328&group=comp.arch.embedded#328

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!paganini.bofh.team!news.dns-netz.com!news.freedyn.net!newsfeed.xs4all.nl!newsfeed8.news.xs4all.nl!50.7.236.10.MISMATCH!news-out.netnews.com!news.alt.net!fdc2.netnews.com!peer01.ams1!peer.ams1.xlned.com!news.xlned.com!peer02.ams4!peer.am4.highwinds-media.com!news.highwinds-media.com!fx24.ams4.POSTED!not-for-mail
Reply-To: spamjunk@blueyonder.co.uk
Subject: Re: C++, Ada, ...
Newsgroups: comp.arch.embedded
References: <s5f01b$4j3$1@dont-email.me> <s5f3c1$s06$1@dont-email.me>
<ie260rFghneU1@mid.individual.net> <s5hafg$g1$1@dont-email.me>
<ie34olFmda9U1@mid.individual.net> <s5hq48$k2e$1@dont-email.me>
<WU_eI.237389$KHwf.63256@fx25.ams4> <s5i441$tro$1@dont-email.me>
<Kd2fI.273342$zV01.166134@fx49.ams4> <s5j9bk$ced$1@dont-email.me>
From: spamj...@blueyonder.co.uk (Tom Gardner)
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
Firefox/52.0 SeaMonkey/2.49.4
MIME-Version: 1.0
In-Reply-To: <s5j9bk$ced$1@dont-email.me>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 67
Message-ID: <BMbfI.171837$9Poc.19162@fx24.ams4>
X-Complaints-To: http://netreport.virginmedia.com
NNTP-Posting-Date: Mon, 19 Apr 2021 09:08:49 UTC
Organization: virginmedia.com
Date: Mon, 19 Apr 2021 10:08:49 +0100
X-Received-Bytes: 4526
 by: Tom Gardner - Mon, 19 Apr 2021 09:08 UTC

On 19/04/21 07:52, David Brown wrote:
> On 19/04/2021 00:17, Tom Gardner wrote:
>> Infamously, getting a valid C++ program that cause the
>> compiler to generate the sequence of prime numbers during
>> compilation came as an unpleasant /surprise/ to the C++
>> standards committee.
>
> I don't believe that the surprise was "unpleasant" - it's just something
> they hadn't considered. (I'm not even sure of that either - my feeling
> is that this is an urban myth, or at least a story exaggerated in the
> regular retelling.)

I was thinking of "unpleasant" /because/ it was a surprise.
Bjarne dismissed the possibility before being stunned a
couple of days later.

Here's a google (mis)translation of the Erwin Unruh's account at
http://www.erwin-unruh.de/meta.html

Temple meta programming

The template meta programming is a way to carry out calculations already in C
++ during the translation. This allows additional checks to be installed. This
is particularly used to build efficient algorithms.
In 2000, a special workshop was held for this purpose.

This started with the C ++ standardization meeting in 1994 in Sandiego. Here
is my personal memory:

We discussed the possibilities of determining template arguments from a
template. The question came up as to whether the inverse of a function could be
determined. So if "i + 1 == 5" could be closed, that "i == 4". This was
denied, but the question inspired me to the idea to calculate primes during the
translation. The first version I crafted on Monday, but she was fundamentally
wrong. Bjarne Strouffup said so something would not work in principle.
This stacked my zeal, and so I finished the scaffolding of the program
Wednesday afternoon. On Wednesday evening another work meeting was announced
where I had some air. There I met Tom Pennello, and we put together. He had
his notebook and we tapped my program briefly. After some crafts, the program
ran. We made a run and printed program and error message. Then Tom came to the
idea of ​​taking a more complicated function. We chose the Ackermann function.
After a few hours, this also ran and calculated the value of the Ackermann
function during the translation.
On Thursday I showed the term Bjarne. He was extremely stunned. I then made
copies for all participants and officially distributed this curious program. I
kept the whole thing for a joke.

A few weeks later, I developed a proof that the template mechanism is
turbine-complete. However, since this proof was quite dry, I just put it to the
files. I still have the notes. On the occasion, I will tempt this time and
provide here.

Later, Todd Veldhuizen picked up the idea and published an article in the C ++
Report. This appeared in May 1995. He understood the possibilities behind the
idea and put them in concrete metatograms that make something constructive.
This article was the basis on which template meta programming was built.
Although I gave the kick-off, but did not recognize the range of the idea.

Erwin Unruh, 1. 1. 2002

> Template-based calculations are a bit like trying to do calculations and
> data structures in LaTeX. It is all possible, but it doesn't roll off
> the tongue very easily.

Being perverse can be fun, /provided/ it doesn't happen
accidentally in everyday life.

Re: C++, Ada, ...

<s5jl7g$sdh$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=329&group=comp.arch.embedded#329

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: david.br...@hesbynett.no (David Brown)
Newsgroups: comp.arch.embedded
Subject: Re: C++, Ada, ...
Date: Mon, 19 Apr 2021 12:15:11 +0200
Organization: A noiseless patient Spider
Lines: 42
Message-ID: <s5jl7g$sdh$1@dont-email.me>
References: <s5f01b$4j3$1@dont-email.me> <s5f3c1$s06$1@dont-email.me>
<ie260rFghneU1@mid.individual.net> <s5hafg$g1$1@dont-email.me>
<ie34olFmda9U1@mid.individual.net> <s5hq48$k2e$1@dont-email.me>
<WU_eI.237389$KHwf.63256@fx25.ams4> <s5i441$tro$1@dont-email.me>
<Kd2fI.273342$zV01.166134@fx49.ams4> <s5j9bk$ced$1@dont-email.me>
<BMbfI.171837$9Poc.19162@fx24.ams4>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 19 Apr 2021 10:15:12 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="f21b347e432a7da8c8112e546840e277";
logging-data="29105"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/BcQwNzHZ4u5mUfmfs83cAkNZkGtEEl2c="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
Thunderbird/68.10.0
Cancel-Lock: sha1:mLGe1rk9ze/d0qVLjgA2uGpyW+E=
In-Reply-To: <BMbfI.171837$9Poc.19162@fx24.ams4>
Content-Language: en-GB
 by: David Brown - Mon, 19 Apr 2021 10:15 UTC

On 19/04/2021 11:08, Tom Gardner wrote:
> On 19/04/21 07:52, David Brown wrote:
>> On 19/04/2021 00:17, Tom Gardner wrote:
>>> Infamously, getting a valid C++ program that cause the
>>> compiler to generate the sequence of prime numbers during
>>> compilation came as an unpleasant /surprise/ to the C++
>>> standards committee.
>>
>> I don't believe that the surprise was "unpleasant" - it's just something
>> they hadn't considered.  (I'm not even sure of that either - my feeling
>> is that this is an urban myth, or at least a story exaggerated in the
>> regular retelling.)
>
> I was thinking of "unpleasant" /because/ it was a surprise.
> Bjarne dismissed the possibility before being stunned a
> couple of days later.
>
> Here's a google (mis)translation of the Erwin Unruh's account at
> http://www.erwin-unruh.de/meta.html
>
> Temple meta programming

<snip for brevity>

>
>
>> Template-based calculations are a bit like trying to do calculations and
>> data structures in LaTeX.  It is all possible, but it doesn't roll off
>> the tongue very easily.
>
> Being perverse can be fun, /provided/ it doesn't happen
> accidentally in everyday life.

Usually it is not a problem when you discover something has extra
features or possibilities beyond what you imagined. About the only
disadvantage of "turbine-complete" templates is that compilers need to
have limits to how hard they will try to compile them - it would be
quite inconvenient to have your compiler work for hours trying to
calculate Ackerman(5, 2) before melting your processor.

(I've done "perverted" stuff in LaTeX - but it wasn't an accident.
Fortunately I don't have to do it /every/ day.)

Pages:123
server_pubkey.txt

rocksolid light 0.9.7
clearnet tor