Home >

Is C+ a safer C?

Niall Cooling- Watch Now - Duration: 42:06

Is C+ a safer C?
Niall Cooling
No, that's not a typo – C+ is a common programming model where effectively C is being written but compiled with a C++ compiler. Why would you do that? Surprisingly two very popular IoT programming platforms; Arduino (https://www.arduino.cc/) and Arm’s Mbed (https://os.mbed.com/) use this programming paradigm. C+ (C++ as C) brings with it several useful extensions to C that can help enhance program safety and security. This talk looks at some of the small, but significant, useful features that compiling with a C++ compiler brings, without any penalties to size or performance.
italicssurround text with
boldsurround text with
**two asterisks**
or just a bare URL
surround text with
strikethroughsurround text with
~~two tilde characters~~
prefix with

Score: 3 | 2 years ago | no reply

Very interesting presentation with lots of useful insight. I will probably watch this again to make sure I soak it all up.

Score: 1 | 2 years ago | 1 reply

Hi, Niall.
I really enjoyed your talk. I always enjoy hearing about specific implementations of new features in languages; sometimes just reading the "what's new" of code standard doesn't always help in understanding where/why/how you might use the new feature. And, in the case of your presentation, it's really distilled down ways to use some parts of C++ when moving from C.
Like Oliver, I miss a lot of C++ features that I used to use (in embedded programming) because my current employer only uses C. While I've advocated for moving to C++ long-term, it's not a language that most of the engineers here know. So I'm hoping that maybe I can use this presentation to help me help them make the transition more easily. ...or at least consider the transition!

Score: 0 | 2 years ago | no reply

Hi Greg,
I feel your pain ;-) Modern C++ now offers so many helpful/useful additions so, like you, I feel shackled when programming in good old plain C.
Fingers crossed, thanks for watching

Score: 2 | 2 years ago | 1 reply

Hi, thank you for the interesting talk. I really enjoyed listening to you.
When I started my last C-Project I was wondering if I should use C++ or C. I took C because the Libraries of my uC were written in that language.

I am missing lots of C++ features though and I think I might try your C+ approach (I didn't hear that term before). I am always crying that I can't use overloading of functions and I like the Idea behind the if-init structure you showed.

There is one thing I was stumbling over and I don't know if I'm just to stupid/ignorant to understand the usefulness. I'm still not convinced about the "auto" statement.

For me one of the best features of C and C++ is the type safety of the type system. I think it prevents lots of bugs, because I have to think about what I am doing and what type fits my cause. For me the auto feature takes away that safety net and I think your examples show the danger instead of the robustness.

This should be the code from slide 19 (please add slide numbers on your next presentation :-) )

std::uint8_t values[] = {1,2,3};
init main() {
for (auto v : values) {
printf("%u\n", v);

If I got you right you say in the example I can change my variables from 8 to 16 bit and I will not break the code while doing that. That ist why robustness is increased.

But my problem is, if I don't check the whole code I will not see that I can't use double or even int8_t without breaking my functionality. How does that fit the promise of robustness?

I understand that auto helps increasing readability on the side that it takes away clutter and lets me see the real purpose of my code. Especially in C++ that is very useful, because the types can become very long. I still think it is dangerous, because I might misinterpret what the compiler is doing.

In your example with the if-init construct (slide 25) could I use the following:
using PairOptional = std::optional;
if(ReturnedTwoDoubles result = solve_quadratic(1.0, 5.0, 6.0)){}

instead of the original line?
if(auto result = solve_quadratic(1.0, 5.0, 6.0)){}

Would you see that as a good solution or is it just a bad idea?

Thanks again for your talk, It was fun thinking about your solutions.

Score: 0 | 2 years ago | 1 reply

Hi Oliver,
Thanks for the question.
On the first point, yes the use of auto is a subjective matter. Type safety is central to safety and security and you rightly question the use of auto. In the example I used, the use as a read-copy-variable is, I believe, a good use of auto. Where you have a mutable (e.g. auto& ) then you'd certainly want to question that. Given this context I believe auto can eliminate other subtle problems where a value is being assigned that is loosing information in the assignment, and unless the correct warning flags are set can lead to other subtle problems.
On the second point, then yes can write

using PairOptional = std::optional<Pair>;
if(PairOptional result = solve_quadratic(1.0, 5.0, 6.0)){}

or just

if(std::optional<Pair> result = solve_quadratic(1.0, 5.0, 6.0)){}

whichever floats your boat.
Thanks again for watching,
Best regards,

Score: 0 | 2 years ago | no reply

"Given this context I believe auto can eliminate other subtle problems where a value is being assigned that is loosing information in the assignment, and unless the correct warning flags are set can lead to other subtle problems."
That's a good point. I think the compiler should complain there, but in your example it will probably complain as well.

Thank you for the answer :-)