Video - 7 Features of C++ You Can Adopt Today

Found this on yt. I had to leave it here. :slight_smile:

4 Likes

Nice, very brief and to the point – that’s how all talks should be.

override I use and recommend, the other stuff was mostly new :slight_smile:

1 Like

I’d upovte once for each point if I could.
Very good points, and I’m glad he’s telling people not to fear the new stuff, because a lot of people genuinely do have a fear of the new features.
A lot of people have an illogical preconception that “it’s new, therefore it must be slower and cost more memory than the old features”.

I think they’re thinking “this was written for use on a less powerful computer so it must be better for that environment”, but what they should be thinking is “we’ve learnt a heck of a lot in the last few decades, compiler technology and language theory are so much better now than they were back then”.

Using the new C++11 features actually makes your code safer and faster than C++03 code in 90% of cases.

Remember, new features != more overhead/more bulk.


I make use of all of the first 6.

I haven’t used typedef since my first year of C++, I always use using now because it’s so much easier.
I’ve been using #6 (the constexpr array length technique) in my Arduboy code for at least 8 months if not more,
here in Minesweeper and here in EasterPanic.


The only one I’m not entirely happy with is #7.

I agree that using an explicit cast to bool is better than the old safe bool idioms, but I disagree with why people want it.

I think people should be doing if(ptr != nullptr) instead of if(ptr) and if(number != 0) instead of if(number).
The latter is easier for the programmer to write, but it becomes harder to read because you have to stop and think “is this a number or is this a pointer, or is it something else entirely?”.

For the sake of a bit of extra typing, you’re saving other people a lot of head-scratching time - and that person scratching their head could one day be you when you come along in 8 months and you’ve forgotten how your old project works.

1 Like

This is a pretty great lightning talk.

1 Like

The reason I didn’t use many of these features is I didn’t know about them. It’s not about being concerned about performance for me.

Really, I lived happily without knowing about underlying types for enums, never encountered a situation where I’d say “I really need this”. Though now that I know about it, I might probably start using it.

Another reason I don’t use new features is backwards compatibility – if I can achieve the same thing with C instead of C++, with negligible added effort/consequences, I’ll do it with C, because then it can run on more platforms and can be reused in more programs, which is important to me. The same goes for new vs old C++: if I can write a class with old C++ just as well as with the new one, I’ll do it with the old.

Then any enums you’ve been writing will be twice as big as they need to be.
The AVR compiler will chose int as a backing type by default.

The following should fail with the message “The enum is 2 bytes large”:

enum Test { A, B };

static_assert(sizeof(Test) != 1, "The enum is 1 byte large");
static_assert(sizeof(Test) != 2, "The enum is 2 bytes large");
static_assert(sizeof(Test) != 4, "The enum is 4 bytes large");

Are you sure about that?

Modern compilers are still able to write code for older platforms in a lot of cases,
and a lot of embedded platforms support a C++ compiler.
Failing that, C++ to C compilers exist (e.g. LLVM).

Don’t forget, even C has added new features over time (C90, C95, C99, C11, C18) so to be truly portable you’d have to leave out things like restrict and variable length arrays.

1 Like

Until Arduboy I never really had to care about this. But now it does come in handy.

Well if I write a code that’s both C and C++ (I know, C is not a subset :slight_smile:) it’s more portable than just C++. All I am saying.