Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #30495
| From | Niklas Holsti <niklas.holsti@tidorum.invalid> |
|---|---|
| Newsgroups | comp.arch.embedded |
| Subject | Re: C++, Ada, ... |
| Date | 2021-04-18 19:23 +0300 |
| Organization | Tidorum Ltd |
| Message-ID | <ie34olFmda9U1@mid.individual.net> (permalink) |
| References | <s5f01b$4j3$1@dont-email.me> <s5f3c1$s06$1@dont-email.me> <ie260rFghneU1@mid.individual.net> <s5hafg$g1$1@dont-email.me> |
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). Of course you can move from C to Ada without a full re-write, because all Ada compilers provide inter-linking with C code, and most data structures can be mapped between the two languages. (For some Ada compilers like GNAT, this even holds for C++ and Ada) In fact, there is another C-vs-Ada study, http://archive.adaic.com/intro/ada-vs-c/cada_art.html where an Ada compiler vendor incrementally moved their Ada compiler from being written in C to being written in Ada, and found a steady increase of quality and decrease of cost-to-repair as modules were moved from C to Ada. But it is from 1995, so perhaps "out of date" :-)
Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
C++, Ada, ... pozz <pozzugno@gmail.com> - 2021-04-17 17:48 +0200
Re: C++, Ada, ... David Brown <david.brown@hesbynett.no> - 2021-04-17 18:45 +0200
Re: C++, Ada, ... Tom Gardner <spamjunk@blueyonder.co.uk> - 2021-04-17 19:55 +0100
Re: C++, Ada, ... David Brown <david.brown@hesbynett.no> - 2021-04-18 12:53 +0200
Re: C++, Ada, ... Niklas Holsti <niklas.holsti@tidorum.invalid> - 2021-04-18 18:48 +0300
Re: C++, Ada, ... David Brown <david.brown@hesbynett.no> - 2021-04-18 18:59 +0200
Re: C++, Ada, ... Niklas Holsti <niklas.holsti@tidorum.invalid> - 2021-04-19 13:51 +0300
Re: C++, Ada, ... David Brown <david.brown@hesbynett.no> - 2021-04-19 14:22 +0200
Re: C++, Ada, ... Niklas Holsti <niklas.holsti@tidorum.invalid> - 2021-04-19 19:16 +0300
Re: C++, Ada, ... David Brown <david.brown@hesbynett.no> - 2021-04-19 22:19 +0200
Re: C++, Ada, ... Niklas Holsti <niklas.holsti@tidorum.invalid> - 2021-04-20 01:03 +0300
Re: C++, Ada, ... Richard Damon <Richard@Damon-Family.org> - 2021-04-19 18:09 -0400
Re: C++, Ada, ... David Brown <david.brown@hesbynett.no> - 2021-04-20 06:58 +0200
Re: C++, Ada, ... Paul Rubin <no.email@nospam.invalid> - 2021-04-19 23:18 -0700
Re: C++, Ada, ... David Brown <david.brown@hesbynett.no> - 2021-04-20 09:36 +0200
Re: C++, Ada, ... Paul Rubin <no.email@nospam.invalid> - 2021-04-19 12:20 -0700
Re: C++, Ada, ... Niklas Holsti <niklas.holsti@tidorum.invalid> - 2021-04-20 00:26 +0300
Re: C++, Ada, ... Paul Rubin <no.email@nospam.invalid> - 2021-04-19 16:01 -0700
Re: C++, Ada, ... Niklas Holsti <niklas.holsti@tidorum.invalid> - 2021-04-20 10:47 +0300
Re: C++, Ada, ... Tom Gardner <spamjunk@blueyonder.co.uk> - 2021-04-19 23:30 +0100
Re: C++, Ada, ... Clifford Heath <no.spam@please.net> - 2021-04-18 08:29 +1000
Re: C++, Ada, ... Niklas Holsti <niklas.holsti@tidorum.invalid> - 2021-04-18 10:39 +0300
Re: C++, Ada, ... David Brown <david.brown@hesbynett.no> - 2021-04-18 14:59 +0200
Re: C++, Ada, ... Niklas Holsti <niklas.holsti@tidorum.invalid> - 2021-04-18 19:23 +0300
Re: C++, Ada, ... David Brown <david.brown@hesbynett.no> - 2021-04-18 19:26 +0200
Re: C++, Ada, ... Tom Gardner <spamjunk@blueyonder.co.uk> - 2021-04-18 19:29 +0100
Re: C++, Ada, ... David Brown <david.brown@hesbynett.no> - 2021-04-18 22:23 +0200
Re: C++, Ada, ... Tom Gardner <spamjunk@blueyonder.co.uk> - 2021-04-18 23:09 +0100
Re: C++, Ada, ... David Brown <david.brown@hesbynett.no> - 2021-04-19 08:56 +0200
Re: C++, Ada, ... Niklas Holsti <niklas.holsti@tidorum.invalid> - 2021-04-19 14:04 +0300
Re: C++, Ada, ... Dimiter_Popoff <dp@tgi-sci.com> - 2021-04-19 15:16 +0300
Re: C++, Ada, ... Paul Rubin <no.email@nospam.invalid> - 2021-04-19 12:47 -0700
Re: C++, Ada, ... Niklas Holsti <niklas.holsti@tidorum.invalid> - 2021-04-20 00:37 +0300
Re: C++, Ada, ... David Brown <david.brown@hesbynett.no> - 2021-04-20 07:50 +0200
Re: C++, Ada, ... David Brown <david.brown@hesbynett.no> - 2021-04-19 14:26 +0200
Re: C++, Ada, ... Tom Gardner <spamjunk@blueyonder.co.uk> - 2021-04-18 19:30 +0100
Re: C++, Ada, ... David Brown <david.brown@hesbynett.no> - 2021-04-18 22:17 +0200
Re: C++, Ada, ... Tom Gardner <spamjunk@blueyonder.co.uk> - 2021-04-18 23:17 +0100
Re: C++, Ada, ... David Brown <david.brown@hesbynett.no> - 2021-04-19 08:52 +0200
Re: C++, Ada, ... Tom Gardner <spamjunk@blueyonder.co.uk> - 2021-04-19 10:08 +0100
Re: C++, Ada, ... David Brown <david.brown@hesbynett.no> - 2021-04-19 12:15 +0200
Re: C++, Ada, ... Tom Gardner <spamjunk@blueyonder.co.uk> - 2021-04-19 12:00 +0100
Re: C++, Ada, ... Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2021-04-19 16:15 +0300
Re: C++, Ada, ... David Brown <david.brown@hesbynett.no> - 2021-04-19 15:43 +0200
Re: C++, Ada, ... pozz <pozzugno@gmail.com> - 2021-04-19 18:38 +0200
Re: C++, Ada, ... Paul Rubin <no.email@nospam.invalid> - 2021-04-19 10:48 -0700
Re: C++, Ada, ... Tom Gardner <spamjunk@blueyonder.co.uk> - 2021-04-19 19:33 +0100
Re: C++, Ada, ... Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2021-04-20 15:09 +0300
Re: C++, Ada, ... Tom Gardner <spamjunk@blueyonder.co.uk> - 2021-04-20 15:29 +0100
Re: C++, Ada, ... David Brown <david.brown@hesbynett.no> - 2021-04-19 22:48 +0200
Re: C++, Ada, ... pozz <pozzugno@gmail.com> - 2021-04-19 23:17 +0200
Re: C++, Ada, ... Paul Rubin <no.email@nospam.invalid> - 2021-04-19 15:55 -0700
Re: C++, Ada, ... David Brown <david.brown@hesbynett.no> - 2021-04-20 08:21 +0200
Re: C++, Ada, ... David Brown <david.brown@hesbynett.no> - 2021-04-20 08:20 +0200
Re: C++, Ada, ... Dave Nadler <drn@nadler.com> - 2021-04-17 21:07 -0400
Re: C++, Ada, ... Don Y <blockedofcourse@foo.invalid> - 2021-04-17 18:53 -0700
Re: C++, Ada, ... Tom Gardner <spamjunk@blueyonder.co.uk> - 2021-04-18 09:42 +0100
Re: C++, Ada, ... dalai lamah <antonio12358@hotmail.com> - 2021-04-18 14:39 +0200
csiph-web