[cageface]

C++ is a mess but it's one of the few languages that gives you low-level control of memory and fast code with zero or near zero cost abstractions. So for a certain class of application it's still the best choice. Music software, for example, is pretty much exclusively written in C++. I don't enjoy C++ the language very much but you can build some very cool things with it.

Personally I'm hoping Rust displaces it from most of these remaining niches but even if it does it will probably happen slowly.

[notacoward]

> it's one of the few languages that gives you low-level control of memory and fast code with zero or near zero cost abstractions. So for a certain class of application it's still the best choice.

For a certain class of program, you mean. For applications specifically, the advantages you mention are barely relevant. Usually only small parts of a whole application need low-level control of memory etc. Those can be written in C, with the rest written in a cleaner higher-level language that interfaces easily with C (there are many such)

C++ is proof that a single language can't satisfy all needs. It tries to do the low-level stuff as well as C, and fails because it can't produce libraries that are as easy to link to. Then it tries to do all the high-level stuff as well as other languages, and utterly fails because it can't get away from its low-level roots. D, Rust, and Nim all make better compromises that suit just about all C++ use cases. Go and Pony do a better job for some but not others. I won't say there's no room for C++ in a sane computing world, but its legitimate niche is very small indeed.

[carlmr]

>For a certain class of program, you mean. For applications specifically, the advantages you mention are barely relevant. Usually only small parts of a whole application need low-level control of memory etc.

I'd say Rust has a similar level of control. I just rewrote our longest build step (37 minutes on a normal build) in Rust. By having control over when things are allocated I could get it down to about 20 seconds. The previous software is written in Java.

If you want speed you need to choose C, C++ or Rust. If you want it safely, then Rust. I'd argue in my case that Rust was probably the fastest choice. As I probably would have copied more in C/C++. In Rust I can trust that my memory is intact.

I'd also choose C over C++ though. I find it's a much more manageable language. I never found it hard to make the right abstractions in it, except for maybe a lack of generics (which C11 kind of solves for).

[pjmlp]

We are starting to see that trend on GUI frameworks and game engines.

C++ is still there, doing what it does best, driving pixels around with maximum performance.

But the upper layer, exposed to app developers and game designers, is done in another language.

[pjmlp]

Very very slowly.

Only now embedded development is starting to accept C++, and C still rules there anyway.

Which means it took about 20 years to reach this point.

And still Rust will need to go through the same certification processes that C, C++, Ada and Java enjoy for such scenarios.

[srcmap]

I used C++ for embedded CPU 68332 (25 MHz CPU) with 4MB of SRAM in ~1996 for DNA sequencer machine.

~100 + classes, single inheritance, 1,2, 3 Axis motor controls, CCD Camera, Laser, serial com channel, scripting engines, etc.

No template, no virtual functions. Worked very well at that time.

The compiler setup at that time is AT&T cfront generate C from C++ code ran in Mac and embedded C cross compiler generated the target code.

The classes are shared within company for different machines (biotech robots) to maximize code reuse.

[pjmlp]

Very interesting, thanks.

I got introduced to C++ via Turbo C++ 1.0 for MS-DOS, in 1993.

So if it was good enough for 640 KB max, with 64KB executables, it shouldn't be an issue in most micro-controllers, but the biggest issue is the existing dev culture.

[srcmap]

Forgot to mention couple other design decisions:

  No new, delete operators in any C++ code. 
  ISR code was also in C++.

  All objects are statically allocated - with 4MB of SRAM, one can easily see why.   It allows tightly control memory usage by the developer. 

  All regression tests are automated.   There were test scripts for all functional HW/SW components.  Found one bug triggered  in 24.9 days time frame (31 bit timer counter wrap around for 10 milliseconds timer call) - from that point on - all firmware release pass 3 months continuous test on multiple systems before release.  


  Agree with your point: Dev culture matter a lot.   This was a mac (powerpc mac) base dev house.   C++ was the big thing in the SW (Mac) side of the dev team.    


  In my career, I worked on  15+ projects - most were embedded system projects.   Only two projects are C++.   The other project only small subset is C++.   On this project - 90% of code base running in target are C++ and full OO design and 80% of the classes reuse from other projects.

[pjmlp]

Thanks for sharing.

I eventually moved into Java/.NET stacks, but still follow on C++, as my to go tool when they need some unmanaged help.

[mrpippy]

Very interesting. Was the build environment all inside MPW?

[srcmap]

I don't remember. Long time ago.... Likely just steps inside makefile.

Not really a big fan of the Mac at that time - It was before Steve Jobs came back and merge the OS with Next? The Mac was very unstable. I remember it crash 3-5 times a day for my daily tasks - editing, cross compile.

[PopsiclePete]

The C++ you wrote in 1996 is basically a different language from the C++ that you're encouraged to write today.

[DoofusOfDeath]

> The C++ you wrote in 1996 is basically a different language from the C++ that you're encouraged to write today.

We can differentiate between (a) what the language spec says, and (b) what various individuals advocate.

The code we write is generally constrained by (a), but we can usually substitute our own best judgment for (b).*

* Except when the people mentioned in group (b) have sway over the C++ standard.

[blt]

Sounds like a sweet spot kind of project for C++.

[tzhenghao]

There has been recent pushes to use Rust in embedded systems, but I agree it'll take a long time. Check out this blog [1].

[1] - http://blog.japaric.io/

[pjmlp]

Thanks.

[antonvs]

What do you mean by embedded systems?

Here's an article from 1998 that gives an example of C++ being used in military avionics systems:

http://www.cs.wustl.edu/~schmidt/TAO-boeing.html

It's been used in civilian avionics for a long time, too. Not that it's necessarily the best choice in those environments, but "starting to accept" seems like a mischaracterization.

[pjmlp]

I mean the embedded systems where Assembly and C89 still rule, and there is very hard to change, because the problem of adopting anything else is cultural.

Basically, while there are projects being done in C++, and many companies are finally migrating from C to C++, the large majority is sticking with C.

If you prefer to listen to someone actually relevant in the C++ embedded community, here is what Dan Saks has to say about it.

https://youtu.be/D7Sd8A6_fYU

http://cppcast.com/2016/10/dan-saks/

[jdblair]

The embedded world has accepted c++ for all but the smallest microcontrollers. I was using c++ for embedded development 6 years ago and I was late to the party. All that prevented adoption be me before that was the cost of RAM.

[AnimalMuppet]

Depends on the embedded system. I've worked on embedded systems running embedded Linux, with megabytes to gigabytes of storage, for the last dozen years, using C++.

If you're still dealing with an 8051, I'll agree that you're less likely to have moved to C++.

One other thought: Embedded toolchains are typically set at the start of the (original) project. I don't remember ever seeing a compiler upgrade happen in an existing embedded code base. And some embedded code bases live for decades.

[pjmlp]

I fully agree with you, and given my preference for type safe languages, I find interesting that other languages are also an alternative, depending on the use case constraints.

However from a few CppCon and Meeting C++ talks, it appears that in such scenarios moving beyond C, is more of a cultural issue than technology one.

[kamaal]

>>Only now embedded development is starting to accept C++

Well largely on RaspberryPi kind of platforms, which aren't even even embedded systems. More like miniaturized desktops.

Then there is just C and only C. C dominance there isn't going to be replaced anytime soon, if ever.

[pjmlp]

During 2017, BMW among other car companies, and Sony have migrated from C to C++ as their main language for embedded development.

https://archive.fosdem.org/2017/schedule/event/succes_failur...

https://www.autosar.org/

"Developing Audio Products with Cortex-M3/NuttX/C++11"

https://www.youtube.com/watch?v=T8fLjWyI5nI

Unless you consider their devices Raspberry Pi kind of platforms

Of course with companies like Microchip still focusing on Assembly and C89, C is going to stay around for a very long time

What is done in C and macros, can be safer done with C++ and constexpr templates and better optimized, problem is to change the culture of those companies.

[jcelerier]

> Well largely on RaspberryPi kind of platforms, which aren't even even embedded systems

no, for instance Arduino uses C++ as a main language. And an arduino pico has 2.5kb of ram... that's firmly in the "embedded" scale of things.

[Gibbon1]

I feel like embedded development should just avoid c++ and go with a managed languages. I was hopeful abut go, but they kinda wrecked it for embedded.

The thing with embedded is you have two cases, hard real time and just don't care.

[pjc50]

Embedded devs always care. Managed languages with non-deterministic GC will never be popular there.

What embedded devs end up needing are:

- ability to shove bits directly in and out of a particular memory address

- ability to write interrupt handlers with low and bounded latency (i.e. emit a different function pre/postamble)

- global mutable state

[pjmlp]

They go with Java in very specific cases, but you need big bucks to pay for something like PTC Perc Ultra, JamaicaVM or WebSphere Real Time.

Then there is microEJ as well, but their target is that performance critical code is anyway written in C and exposed to Java.

Also depending how embedded one might consider mobile phone hardware, there is Android and Android Things.

Then there are some OEMs still selling Basic, Pascal and Oberon compilers.

But in what concerns embedded domains where only Assembly and C get used, currently C++ seems to be the only one that they care to adopt. Specially given that it already enjoys the same kind of safety regulations (MISRA, DOJ and similar).

And not everyone mind you, C++ conferences keep having sessions on how to advocate to those devs.

[Gibbon1]

I've seen some people using MicroPython combined with C in embedded devices. Or plain Python on embedded Linux doohickeys. Company I work for has a few embedded Linux devices running Python.

[TheArcane]

Robotics is pretty much exlusively in C++ as well.