Why does ARM mbed rely on C++? Is C++ the future?

[legacy]

About Ada ...

bad news: gnat-gcc got removed from a few linux-distros in favor of gnat-gpl whose quality is inferior, and this breaks dependencies especially on PowerPC/BE (e.g. PowerMachintosh G4 and G5)

IBM POWER9/LE (promoted and used by DARPA, in USA) is also affected, and, even if they have their copy of Gnat-Commercial-version, every Gnat-gpl version I have tried has miserably failed

(and Java got removed, too  .... except IBM-JDK that comes with a terrible license )

Code: [Select]

2018-03-24--15-00-48---2018-03-24--15-07-58 - [ dev-lang/gnat-gpl ] - failure - root@dev2.29.1/7.3.0
2018-03-24--15-13-52---2018-03-24--15-14-06 - [ dev-lang/gnat-gpl ] - failure - root@dev2.29.1/7.3.0
2018-03-24--15-18-03---2018-03-24--15-20-44 - [ dev-lang/gnat-gpl ] - failure - root@dev2.29.1/6.4.0
2018-03-24--15-28-44---2018-03-24--15-30-31 - [ dev-lang/gnat-gpl ] - failure - root@dev2.29.1/6.4.0
2018-03-24--15-33-03---2018-03-24--15-34-48 - [ dev-lang/gnat-gpl ] - failure - root@dev2.29.1/5.4.4
2018-03-24--18-43-31---2018-03-24--19-17-03 - [ dev-lang/gnat-gpl ] - failure - root@dev2.29.1/5.4.4
2018-03-24--20-43-26---2018-03-24--23-59-49 - [ dev-lang/gnat-gpl ] - failure - root@dev2.29.1/4.4.7
2018-03-25--00-22-40---2018-03-25--00-24-48 - [ overlay/gnat-gcc ] - failure -root@dev2.29.1/4.4.7
2018-03-25--01-40-42---2018-03-25--02-14-15 - [ overlay/gnat-gcc ] - failure - root@dev2.29.1/4.4.7
2018-03-25--13-29-49---2018-03-25--16-47-39 - [ overlay/gnat-gcc ] - failure - root@dev2.29.1/4.4.7
    NOTE: GCC back-end/PPC32.BE generated  by gnat-ppc/x86, compiled with commercial GNAT Version
2018-03-27--15-38-02---2018-03-27--17-52-54 - [ overlay/gnat-gcc ] - success - root@dev2.29.1/4.4.7


Anyway, I have bought the commercial version of gnat (x86/32bit), and I am moving it to my own Softcore intended to directly support high-level language features in hardware such as tagged, boundary-protected memory.

That is very elegant, powerful, and makes me feel comfortable with the debugger since it simplifies a lot of stuff.

I will also ask some companies with skills at stickers making, to prepare a nice one "Ready for Ada" to then stick it (with "pride"  ) on the plastic box that will contain the fpga whose bitstream maybe, soon or later, will be able to be uploaded with the output of an Ada-cross-compiler from my PowerMac




Oh, does it mean (at least for me) that the future is Ada? 

[Gibson486]

All those arguments on C++ were true years ago, but 32 bit MCUs make it a non factor. Yes, you can get carried away with objects if you are not careful, but the whole argument of objects taking lots of space is now moot with MCUs that have way over 2 KB of ram space. At the end of the day, yes, C is still the choice I go to, but making an object can just simply things so much.

[Bruce Abbott]

the whole argument of objects taking lots of space is now moot with MCUs that have way over 2 KB of ram space.

Yes, the argument is moot with MCUs that have way over 2K of RAM, but a lot don't. 'So just use a bigger chip!' But a bigger chip costs more. The cheapest STM32s only have 4k, and after you have used most of that for essential data it's not enough to support an inefficient 'higher level' language.

Of course this won't matter in the future, because everyone will need Megabytes of RAM to run their favorite bloated language. The minimum supported platform will be a Raspberry Pixxx running Linux. It will have embedded WiFi to access the Cloud because your code won't work standalone, need constant firmware updates to fix vulnerabilities, and next week it will stop working if you haven't paid the subscription!

[westfw]

I might also point out that in something like the Arduino core (with it's somewhat "mild" use of C++ features), more of the inefficiencies that people complain about are due to design choices (or mistakes) of the programmers, rather than limits imposed by C++
(It ought to be easy to check mbed for similar?)

[SiliconWizard]

And it will take ages to start. Forget the ability for your systems to be operational within a couple ms after power-up/reset.

There will still be a lot of areas - outside of general-purpose computing -  where software bloat won't be acceptable, be it for performance or for validation reasons.

People favoring a reduction of coding time by using bloated dev solutions obviously have never been concerned with software validation. When validation is required, the time spent for coding is actually such a small part of your overall schedule that it doesn't really matter and trying to reduce it would be completely vain.

Of course, in companies shipping stuff that barely works, the time spent coding does matter. All depends on your perspective.

[nctnico]

the whole argument of objects taking lots of space is now moot with MCUs that have way over 2 KB of ram space.

Yes, the argument is moot with MCUs that have way over 2K of RAM, but a lot don't. 'So just use a bigger chip!' But a bigger chip costs more. The cheapest STM32s only have 4k, and after you have used most of that for essential data it's not enough to support an inefficient 'higher level' language.

Saving a few cents on a microcontroller is often bad economy because you'll spend way more on development time. I've written it before and I'll write it again: the cost of hardware is usually pretty clear but the real costs of software development is often severely under estimated. You need to move a lot of units to reduce the software development costs to several cents per unit.

[andyturk]

And it will take ages to start. Forget the ability for your systems to be operational within a couple ms after power-up/reset.

What will take ages to start? Are you talking about a language or an operating system?

[Vasi]

C++ on 8 and 32bit micros is a masked way to differentiate the final code of the beginner from a commercial application that has a corporate behind.

Who migrated from Arduino Wiring language to the bare metal C language knows the difference. It is the same on Arduino Wiring language written on top of HAL that in itself is also a masked way to increase your final code size. For STM32 the best solutions are SPL or LL. LL has some support on the STM32CubeMX "designer" but lots of errors and HAL is pushed strongly forward.

Let C++ and Ada (used it on ATmega but dropped it seeing the huge code size it generates - no need for extra activities and checking on a small micro that has to switch a relay, read a sensor and light a LED) be used for PC applications where the final data processing is done.

[hans]

the whole argument of objects taking lots of space is now moot with MCUs that have way over 2 KB of ram space.

Yes, the argument is moot with MCUs that have way over 2K of RAM, but a lot don't. 'So just use a bigger chip!' But a bigger chip costs more. The cheapest STM32s only have 4k, and after you have used most of that for essential data it's not enough to support an inefficient 'higher level' language.

Saving a few cents on a microcontroller is often bad economy because you'll spend way more on development time. I've written it before and I'll write it again: the cost of hardware is usually pretty clear but the real costs of software development is often severely under estimated. You need to move a lot of units to reduce the software development costs to several cents per unit.

I think it depends on the industry. If you're making very simple and "dumb" devices then perhaps you don't want/need the extra tools that a language like C++ has to offer, especially if they will cost you memory which @ 10M units can be worth a few months of engineering salary.

But I think few people in "high tech" will find themselves in that position. The trend for electronics is that embedded software is used as a sponge for sucking up the complexity. Analog designs get pushed into digital domain, we have more and faster communication interfaces, more options, graphical user interfaces, feature creep, etc. It does not make sense to then not invest in good tools that scale well, i.e. the classic "struct with function pointer" vs C++ classes argument.

[SiliconWizard]

And it will take ages to start. Forget the ability for your systems to be operational within a couple ms after power-up/reset.

What will take ages to start? Are you talking about a language or an operating system?

I was actually replying to this:

Of course this won't matter in the future, because everyone will need Megabytes of RAM to run their favorite bloated language. The minimum supported platform will be a Raspberry Pixxx running Linux. It will have embedded WiFi to access the Cloud because your code won't work standalone, need constant firmware updates to fix vulnerabilities, and next week it will stop working if you haven't paid the subscription!

[tggzzz]

And it will take ages to start. Forget the ability for your systems to be operational within a couple ms after power-up/reset.

What will take ages to start? Are you talking about a language or an operating system?

I was actually replying to this:

Of course this won't matter in the future, because everyone will need Megabytes of RAM to run their favorite bloated language. The minimum supported platform will be a Raspberry Pixxx running Linux. It will have embedded WiFi to access the Cloud because your code won't work standalone, need constant firmware updates to fix vulnerabilities, and next week it will stop working if you haven't paid the subscription!

Note to everybody: that's why including context is so helpful -- and why stackexchange will never be useful for more than "which button should I press" questions.

[SiliconWizard]

Note to everybody: that's why including context is so helpful -- and why stackexchange will never be useful for more than "which button should I press" questions.

Yeah. I usually always include a quote in my replies, but sometimes tend to avoid quoting when my reply is directly to the last post, to avoid... bloated threads.
Unfortunately someone else just posted something right before I submitted my own post and I didn't notice. My bad.

[NorthGuy]

Saving a few cents on a microcontroller is often bad economy because you'll spend way more on development time.

Why do you think that designing bloated software is cheaper than doing efficient designs?

[C]

When talking about higher level languages there is one thing I do not see being talked about.

Where a thing , idea or concept is done.
For example type checking can be done at compile time. Some languages push this to run time. At compile time you have no effect on CPU running program.
Pushing type checking to running CPU can sometimes make running code better.

So I think
C would be lower level, Pascal a step up and the language that gives programmer a choice, another step up.

Other changes could be classed as adding an identifier to a use.
You use call back functions. Changing the word function to callback improves readability of source and lets more checks happen with little happening to code generator. Lack of word change makes these checks much harder to do. What could be a two pass code generator becomes a three pass or mess.
Think that keep it simple should apply to language user and as much as passable to the code generator.

Think of how much time is saved by more readable code.


And some push

[andyturk]

Think of how much time is saved by more readable code.

Yeah, the worst thing ever is shitty code that works.

Code that doesn't work (shitty or not) is replaced. It doesn't last long, so doesn't cost that much. But if some chunk of code works well enough to survive the prototyping phase, it puts down roots and starts attaching itself to other parts of the codebase. Bad code exerts an influence on everything around it through APIs and data structures.

At some point, the original developer leaves and someone else has to fix the shitty code that formerly "worked". Then you're stuck because as the engineer tasked with fixing a problem, you don't want to (or can't) re-write vast parts of the system to deal with a bad decision in one place. So you end up having to fix the problem (and possibly add new features requested by marketing) with the added requirement of "maintain the original, shitty API". 

How to avoid this? IMO, one has to set a high standard for what is acceptable in code, and don't relax that standard when a project is in the early stages. If anything, you get more bang for the buck by being a stickler at the start than when the horse has already left the barn (or the product shipped).

[technix]

I really want to mention the Swift-compatible-Objective-C and Swift language again. Since its memory management is implemented as compile-time static code analysis on those languages, the same code analyzer Apple pushed into clang actually also checks for various code smells and bad forms. Just tru run your code, even just plain C or C++ code, through the latest version of clang with -Wall -Wextra flags, and see the static analyzer catching those code smells and emit warnings for you.

[C]

How to avoid this? IMO, one has to set a high standard for what is acceptable in code, and don't relax that standard when a project is in the early stages. If anything, you get more bang for the buck by being a stickler at the start than when the horse has already left the barn (or the product shipped).

You are talking the great non standard standard to fix a problem.
Think the better choice  letting you specify this in the language. Then the language can assist in checking.
Just how hard it it to type
Interrupt
Callback
Thread
Event
and many more in place of "function".

A simple word change gives you a lot.

[nctnico]

Saving a few cents on a microcontroller is often bad economy because you'll spend way more on development time.

Why do you think that designing bloated software is cheaper than doing efficient designs?

You need to define efficient first. Not needing to do optimisation for speed and/or size saves a lot of time. Using a well tested (trusted) but bloated library which speeds up the software development phase considerably can be well worth the extra hardware costs. The most efficient way is the one which -in the end- results in the most profit.

[andyturk]

You are talking the great non standard standard to fix a problem.
Think the better choice  letting you specify this in the language. Then the language can assist in checking.
Just how hard it it to type
Interrupt
Callback
Thread
Event
and many more in place of "function".

A simple word change gives you a lot.

Well, I wasn't addressing the language issue at all, but rather the social issues that lead to "bloated code". Which programming language you use is only part of it.

To your point, having a naming convention that clearly distinguishes "Interrupt" (a hardware thing) from "Callback" (a coding technique) is a great idea.

[NorthGuy]

You need to define efficient first.

Efficient design is simple. You take your time in the beginning to simplify things. Then you spend less money on the hardware, less time on the software development, and finally you get something which is cheaper and much easier to work with.

If your design uses 3% of MCU resources, this is grossly inefficient. Chances are that by using more resources you can make your design simpler and thereby better.

If you use 100% of MCU resources and now you're forced to crumble your design to fit into the allotted space, this is grossly inefficient too. You should have thought of this situation before you started the design.

Not needing to do optimisation for speed and/or size saves a lot of time.

This is because the design was made backwards. You didn't analyze your timing (or your memory usage) well enough, and now you created something which you have to optimize. One of the problems with using huge libraries is that you don't know the insides of these libraries well and thus cannot think the entire design through. Therefore, you either use lot more resources than you actually need (like you buy a Ferrari when you actually need a tricycle), or you're risking getting into the situation where you need to optimize. However, it is hard to optimize if you don't know the internals of your libraries and you cannot really alter them. In such conditions, your "optimization" will be very hard and very time consuming - it's like trying to catch a black cat in the dark room. No wonder you hate it.

Using a well tested (trusted) but bloated library which speeds up the software development phase considerably can be well worth the extra hardware costs.

Is there such thing as "trusted"? The libraries get developed over time and new bugs are just around the corner. Sticking with older versions of libraries is not fun neither - they have known bugs and exploits you do not want. What you're really using is a black box, which can easily bring you any surprises, and such surprises may eat months of your development time. And here's where the bloat comes into the picture - the bigger the library, the more is the probability of surprises, hidden bugs, potential exploits etc. Using something lean is much safer, and much more predictable.

[nctnico]

You need to define efficient first.

Efficient design is simple. You take your time in the beginning to simplify things. Then you spend less money on the hardware, less time on the software development, and finally you get something which is cheaper and much easier to work with.

Time = money so your method isn't efficient by definition if you start by taking time. Read up on agile software development and how a shorter time to market makes a product more profitable. You could nerd out on a design to make it fit on the smallest hardware and getting maximum performance but then the result will be too little, too late and too expensive. Also changing customer requirements during the development phase may throw a wrench in the wheel. The biggest challenge is to choose a solution which allows some flexibility in the design so when a last minute change comes in it doesn't mean the hardware doesn't fit and / or entire software must be rewritten. Nowadays products aren't designed from A to Z before the coding starts because it has been proven that such a method doesn't work: the end result doesn't fit the customer's needs and development takes too long.

[C]

Some people think writing code is doing something. Making a huge program.

Think of what  you want a computer to do, it's not run programs, it is to process data.

A poor decision can lead to a huge program that is actually slower then simple.
Smoke & Mirrors,
RISC processors are great, truth should add bad for memory. Cache is what lets RISC work.

So think of simple foundations that have existed and apply that knowledge to today.

A run time is not good or bad. It becomes bad if you only need a little part of huge run time. Cure is really simple in just compiling what is needed, linking what is needed.

You should be asking why C programs are so huge. Why there are so many patches to C programs.
Simple answer is that C makes the programmer manage a lot of details and offers little help.
Not seeing a typo is easy. Not adding a range check is easy.

The more you type that the language defines the better the program.
To me type checking is a huge deal. Takes little time to state that this var is a temperature and this var is a pressure and getting an error message from compiler when I goof.

With a little work on my part, I make the language and compiler work for me. But compiler need facts & knowledge to do this.

When I look at C++ source, I am seeing more readable source & better chance of compiler working for me.
That format does not have to mean multiple inhabitance or some kind of garbage collection.

Today you often deal with out of box needs.
changing from Function to Request gains many things.
Very simple for compiler writer to copy a chunk of code and make a few changes to become Request.
Just name change gains more readable source. Compiler changes gets you some error checking and you have not touched the code generator. You could even make this part better.

Simple things
In C you have a header file and a code file and get an object file that is then linked.
Poor linker causes C to mangle names. Now C is haveing to somehow find out if two mangled names are the same because it's not using the source names directly.
Then you have does that header file really belong to that object file. If not positive waste time.

Some compilers play the magic guess game. You have the magic guess as to what file contains ___. With some you get a magic guess as to what shortened var name is expanded to. Think about this two or more libraries that have the same short var name. Does the language force you to use the long name?

There are all kinds of foundation problems. You should ask/check how much of the latest standard change is patching past problems. Latest standard should be simple, we added these key words and enabled these checks. I think more is a sign of a bad foundation that is likely wasting some of your time.

So if a language like C is so great, why is something mainly written in C so complicated? The Oberon system is small by comparison, what is the differences?

The Pascal compiler I was using in the 1980's was very small. Changing just one bit or byte flag turned it into a System compiler that let you create operating system with Pascal's error checking still enabled.
Part of the reason is that Pascal has good syntax & good rules.
Granted there were some things missing.
It's nice to think compiler give no errors so if logic is good you have a good program.

Need to ask if that API connects to simple code or a mess.
Think of those define statements and how many versions of code they create. Then ask how many have been tested?

Where is that define pin = x range checked. Little hard for a program to change a pin on package that does not exist.

Little things add up.

[technix]

Actually the latest C compilers can catch a lot of those errors the poster C above said and emit warnings (especially at -Wall and -Wextra levels,) but the big problem is that a lot people doesn't read through all the warnings and determine if they hint at a problem - the code builds and it is good to go - NOT if you don't iron out the warnings. If you have a deadline to meet maybe you can let warnings slip, but before anything regarding the next revision can be done you need to iron out those warnings first.

This is also part of the management's fault, since way too many managers consider delivery of product the finish of the task. Sure the team must deliver before the deadline and have to let some warnings slip to production, but before adding any new feature you need to iron out existing bugs, or they may become so deep in the design that it becomes permanent in the code and brew a maintenance hell. Especially in this day and age of Internet of Things, it is becoming of so simple to implement over-the-air software upgrades even in the tiniest of places, and long-term maintenance through OTA isn't unheard of.

Time = money so your method isn't efficient by definition if you start by taking time. Read up on agile software development and how a shorter time to market makes a product more profitable. You could nerd out on a design to make it fit on the smallest hardware and getting maximum performance but then the result will be too little, too late and too expensive. Also changing customer requirements during the development phase may throw a wrench in the wheel. The biggest challenge is to choose a solution which allows some flexibility in the design so when a last minute change comes in it doesn't mean the hardware doesn't fit and / or entire software must be rewritten. Nowadays products aren't designed from A to Z before the coding starts because it has been proven that such a method doesn't work: the end result doesn't fit the customer's needs and development takes too long.

If all the project is an one-shot job, sure you can cut all the corners you like. A lot of people misunderstood agile development as cutting corners, instead of using the best tools and build on the best foundation possible to the project without reinventing any wheels. If you don't use a solid foundation you are cutting corners, and the project will crumble. If there is any long-term plan involved taking the quick route can screw you over when you have to touch upon the code two years down the road.

[nctnico]

Time = money so your method isn't efficient by definition if you start by taking time. Read up on agile software development and how a shorter time to market makes a product more profitable. You could nerd out on a design to make it fit on the smallest hardware and getting maximum performance but then the result will be too little, too late and too expensive. Also changing customer requirements during the development phase may throw a wrench in the wheel. The biggest challenge is to choose a solution which allows some flexibility in the design so when a last minute change comes in it doesn't mean the hardware doesn't fit and / or entire software must be rewritten. Nowadays products aren't designed from A to Z before the coding starts because it has been proven that such a method doesn't work: the end result doesn't fit the customer's needs and development takes too long.

If all the project is an one-shot job, sure you can cut all the corners you like. A lot of people misunderstood agile development as cutting corners, instead of using the best tools and build on the best foundation possible to the project without reinventing any wheels. If you don't use a solid foundation you are cutting corners, and the project will crumble. If there is any long-term plan involved taking the quick route can screw you over when you have to touch upon the code two years down the road.

You are also misunderstanding / twisting words. I'm not saying to cut corners. I'm saying to take the least costly route to get to a good end product. That is what agile software development is about (among other things)!

My initial statement was that people tend to go for lowest cost hardware and then ending up needing to do a lot of optimisation to make the software fit on the hardware. This either means missing the deadline or releasing a half baked product.

[technix]

You are also misunderstanding / twisting words. I'm not saying to cut corners. I'm saying to take the least costly route to get to a good end product. That is what agile software development is about (among other things)!

My initial statement was that people tend to go for lowest cost hardware and then ending up needing to do a lot of optimisation to make the software fit on the hardware. This either means missing the deadline or releasing a half baked product.

Way too many managers in China have that kind of understanding though - agile development = cut corners whenever possible. *sigh*

When the lowest cost hardware is estimated to sell like hot cakes, it might make economical sense to force the engineering through that route even though it may take slightly longer, since the lower manufacturing cost will offset the higher R&D. Here in China general consumer electronic product sales are counted, by default, in millions - you don't break the million mark = you failed.