WEBVTT

00:00.150 --> 00:05.700
Hello again! In this video, we are going to look at overriding member functions. So we all know what

00:05.700 --> 00:10.530
overloading a function means. We just define another function which has the same name but a different

00:10.530 --> 00:16.240
signature. Perhaps different numbers or types of arguments. And we can do this with inherited member

00:16.260 --> 00:16.800
functions.

00:19.010 --> 00:23.390
So, for example, we have our Vehicle class, which has an accelerate() member function, which takes

00:23.390 --> 00:24.110
no arguments.

00:25.130 --> 00:30.140
And then in the Aeroplane class, the acceleration might depend on the height of the aeroplane.

00:30.710 --> 00:34.130
So we write another function, which takes the height as an argument.

00:38.190 --> 00:39.210
And you can do that.

00:39.690 --> 00:45.450
So we create an aeroplane object and call this function, and it all works.

00:48.270 --> 00:53.190
But there is one drawback, though, because of the way that C++ was designed many, many years ago.

00:54.360 --> 00:59.940
This parent class function, which takes no arguments, is inherited by the Aeroplane class.

01:00.480 --> 01:02.650
But you cannot actually call it from outside the class.

01:03.090 --> 01:08.100
So if we have our aeroplane objects, we can call the member function, which takes an argument, but

01:08.100 --> 01:13.320
we cannot call the version with no arguments. Even though the class has supposedly inherited it.

01:14.950 --> 01:20.260
And there we are. "Function does not to take zero arguments". (Double negatives are not unavoidable!)

01:20.980 --> 01:22.210
But anyway, this does not work.

01:26.080 --> 01:32.470
So if we overload an inherited function in the child class, then all the other inherited member functions

01:32.470 --> 01:33.370
are "hidden".

01:33.730 --> 01:35.440
They cannot be called from outside the class.

01:36.070 --> 01:37.230
And this is a big problem.

01:37.630 --> 01:40.660
It is not very consistent with object-oriented design principles.

01:41.320 --> 01:46.720
The idea is that the base class should be the interface to that hierarchy, to the rest of the code,

01:47.320 --> 01:50.410
and child classes should extend the interface.

01:50.740 --> 01:52.690
They should not remove things or hide things.

01:53.740 --> 01:54.760
So, what can we do?

01:57.270 --> 02:03.270
Well, one approach is to just go into the child class and define all these functions by hand. So we

02:03.270 --> 02:08.940
can go into Aeroplane, write an accelerate() member function, which takes no arguments and just calls the

02:08.940 --> 02:09.690
parent's function.

02:11.700 --> 02:12.660
And this will work.

02:13.110 --> 02:16.980
So there is our redefinition, in the child class.

02:19.780 --> 02:24.550
And then that compiles and runs correctly. But in a big hierarchy, that is going to be a lot of work.

02:24.910 --> 02:29.440
And if the base class keeps changing, it is going to be a bit of a nightmare keeping this up-to-date.

02:31.200 --> 02:36.210
So in C++11, we can actually get the compiler to generate all these definitions for us.

02:36.720 --> 02:39.180
And we do that by putting a "using" definition.

02:39.690 --> 02:42.630
So, "using Vehicle::accelerate()". This

02:42.670 --> 02:49.080
will cause the compiler to generate definitions for all the inherited member functions, apart from the overloaded

02:49.080 --> 02:49.290
one.

02:49.800 --> 02:51.690
So this means we can call them through the class again.

02:53.990 --> 03:01.430
So here we are, we have our "using" declaration in the Aeroplane class, and now that works as well.

03:01.820 --> 03:03.530
But that is going to be a lot easier to work with.

03:05.580 --> 03:07.140
OK, so that is it for this video.

03:07.560 --> 03:08.370
I will see you next time.

03:08.610 --> 03:10.560
Until then, keep coding!