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

(Boti Kis) #1

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

(Miloslav Číž) #2

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:

(Pharap) #3

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.

(Josh Goebel) #4

This is a pretty great lightning talk.

(Miloslav Číž) #5

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.

(Pharap) #6

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.

(Miloslav Číž) #7

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.