Hi there :) I wish I was attending the conference. The talk start with a presentation of the speaker, his employer and the industrial applications for which they want to use C++. The toolchain and setup information starts at 14:08 The C++ stuff starts at 22:50 Great talk. Also I totally agree that, for non-trivial projects, spending time to get the right tools and workflow is totally worth it and is repaid x10 when comes the crunch time at the end of the project.
We have gone through the same hassle of getting an upstream gcc with cmake working. Was a medium-high amount of work but enabled a whole new workflow. However, we have not yet got clang to work for ARM CM0+, any pointers for that?
Strong types are IMO the best, and perhaps only reason, to contemplate using c++ in embedded applications. The risk of letting a bunch of c programmers loose on c++ scares me on an entirely different level.
Or use constexpr and if it has to be evaluated at runtime let the compiler choose whether or not to inline it. Now if you're not sure about doing that just do both and benchmark them. (Properly, with proper randomisation and statistics) Or… we can just look at the assembly right away and notice we're really doing the same in both C and C++: godbolt.org/z/ov8816 the only possible difference is that with the C++ version you can't ignore what `make_32()` return otherwise your compiler isn't gonna be happy. Remember last time you checked what `printf()` returned? I can remember always checking `fgets()` and `scanf()` (just don't use `scanf()`) but never `printf()`
there ia nothing about contemporary C++ here, not much about C++ in general. Not sure what was intended audience for the talk was. You can see people leaving and for the good reason
@@arkadigrosman7466 The "you know why" was for the presenter. See the video again a few times to know it too. :-) Pesonally I'd much more liked to get a how-to presentation. In my development work I have to invent an embedded library piece by piece as needed, or whenever that is to complex, just use C like all the others. I see the presentation more as a call to action to improve the sad state of embedded C++. But who might do it? GCC is available for some embedded processors, like ARM or AVR. But there are no libraries for the hardware interfaces. This should be a task for the hardware vendors, but who has enough buying power to convince them? The motor industy is an obvious choice, but with MISRA-C thex went another path, dumbing down the language for interns still in college instead of simple to use, expressive libraries. Lastly, a lot of hobbyists are using C++ probably without knowing it via the Arduino system, again without an expressive library. Any idea to improve the situation?
Hi there :) I wish I was attending the conference.
The talk start with a presentation of the speaker, his employer and the industrial applications for which they want to use C++.
The toolchain and setup information starts at 14:08
The C++ stuff starts at 22:50
Great talk. Also I totally agree that, for non-trivial projects, spending time to get the right tools and workflow is totally worth it and is repaid x10 when comes the crunch time at the end of the project.
Hey you're that guy!
We have gone through the same hassle of getting an upstream gcc with cmake working. Was a medium-high amount of work but enabled a whole new workflow.
However, we have not yet got clang to work for ARM CM0+, any pointers for that?
Interesting. It was pretty straightforward for me: gist.github.com/Trass3r/3b70ee33d9b1319bbe78de6bdb09c9dc
I have one issue with this: whitespace.
I get it, it's a slide but it's actually harder to read.
Strong types are IMO the best, and perhaps only reason, to contemplate using c++ in embedded applications. The risk of letting a bunch of c programmers loose on c++ scares me on an entirely different level.
This talk could be 20 minutes long
Or 10.
Or you use __inline instead of using macros.
Or use constexpr and if it has to be evaluated at runtime let the compiler choose whether or not to inline it. Now if you're not sure about doing that just do both and benchmark them. (Properly, with proper randomisation and statistics)
Or… we can just look at the assembly right away and notice we're really doing the same in both C and C++: godbolt.org/z/ov8816 the only possible difference is that with the C++ version you can't ignore what `make_32()` return otherwise your compiler isn't gonna be happy.
Remember last time you checked what `printf()` returned?
I can remember always checking `fgets()` and `scanf()` (just don't use `scanf()`) but never `printf()`
Liked. You know why. :-)
there ia nothing about contemporary C++ here, not much about C++ in general. Not sure what was intended audience for the talk was. You can see people leaving and for the good reason
@@arkadigrosman7466 The "you know why" was for the presenter. See the video again a few times to know it too. :-)
Pesonally I'd much more liked to get a how-to presentation. In my development work I have to invent an embedded library piece by piece as needed, or whenever that is to complex, just use C like all the others.
I see the presentation more as a call to action to improve the sad state of embedded C++. But who might do it? GCC is available for some embedded processors, like ARM or AVR. But there are no libraries for the hardware interfaces. This should be a task for the hardware vendors, but who has enough buying power to convince them?
The motor industy is an obvious choice, but with MISRA-C thex went another path, dumbing down the language for interns still in college instead of simple to use, expressive libraries.
Lastly, a lot of hobbyists are using C++ probably without knowing it via the Arduino system, again without an expressive library.
Any idea to improve the situation?
Best talk ever on not using c++ in embedded apps.
Another pc developer who does not understand the embedded world. Main function with args... Seriously? That's not embedded! Dammit!