Explore
For Enterprise
Join for Free
Log In

Arts and Humanities
Business
Computer Science
Data Science
Information Technology
Health
Math and Logic
Personal Development
Physical Science and Engineering
Social Sciences
Language Learning
Degrees
Certificates

Explore all of Coursera

Browse
Search
For Enterprise
Log In
Join for Free

4.5 Overloading and Function Selection

Loading...

C++ For C Programmers, Part A

University of California, Santa Cruz

4.4 (617 ratings) | 92K Students Enrolled

This course is for experienced C programmers who want to program in C++. The examples and exercises require a basic understanding of algorithms and object-oriented software.

Skills You'll Learn

Graph Theory, C++11, C++, Graph Algorithms

Reviews

4.4 (617 ratings)

5 stars
402 ratings
4 stars
138 ratings
3 stars
31 ratings
2 stars
20 ratings
1 star
26 ratings

AK

Jul 04, 2017

I like Prof. Ira a lot and wish to see more courses from him! I wish I was his student at SC. Best Regards to him and the Coursera team for the great work.

PK

Jul 18, 2018

I really loved this course. It is really helpul for my programming aspect. I have managed to develop my logical abilty and this course really helped me.

From the lesson

Module 4

Prim’s and Kruskal’s algorithms. Use of basic Container Classes. Tripod-Container, Iterator, Algorithm.

4.2 Jarnik-Prim MST11:50

4.3 Jarnik-Prim MST: Another Look11:07

4.4 Kruskal's Algorithm8:30

4.5 Overloading and Function Selection32:19

4.6 STL and STL C++1111:00

4.7 STL Example5:05

4.8 C++11 Feature: auto5:38

4.9 Vector Methods10:36

4.10 More Code8:50

4.11 C++11 Feature: for statement7:07

4.12 STL Input File11:30

4.13 Iterators Categories14:19

4.14 Output a Random Graph12:30

Taught By

Ira Pohl
Professor

Transcript

Okay, next topic.

When you get back to some core C++ ideas.

So, we've outlined the methods you need for the homework.

You can either use Prim or Kruskul or

do both, compare them if you have energy and time.

You're gonna add that to your pre-existing homework

where you have already done graph algorithms.

Try and refine whatever you learn from before, maybe your graph structure

will be more elegant and now that you've learned more C++ you can rebuild

even your basic graph class.

But in any case, the new problem is to do a Kruskal or

a Prim minimum spanning tree.

And now we wanna introduce further ideas from C++.

The critical ideas we want is a very neat idea.

Something that hasn't been put into Java, for example.

There are arguments over whether it's a good idea.

But in lots of arenas, it's a very valuable idea.

And that's called operator overloading.

And that's where we provide new meanings to existing C++ operators.

And, we've already used this as very rich idea in the IO community and

the IO package where we have operator overloading

of the left bit shift for doing output.

And we're gonna show how important yet another idea is that we haven't seen yet

in C++, which is using friend functions,

especially when we wanna provide operator overloading.

Okay, high level principle.

User defined types should be indistinguishable from native types.

Operator overloading is a mechanism that allows us, and conversion.

Those are mechanisms that allow us to implement this principle.

What do I mean by that?

In the native language, if I have two ints,

we all know what a+b means.

But let's say I decide to add from a library or

whatever a rational number.

For those of you that don't remember your highschool math,

a rational is just a number represented by two integers, q divided by b,

so two-thirds is irrational, three-quarters is irrational,

seven-elevens is irrational.

Pi is not a rational,

remember that the notion the other day of pi being transcendental.

It can't be represented precisely by, there are ways to represent pi.

There's a nearby rational, for example 7/22

is a fairly good approximation to pi when you have two small integers.

And you can approximate pi as closely as you want by a rational, but

you can't make it exact.

Anyway, if I all of a sudden had some kind of package for

doing rational arithmetic, I might also want to be able to have c + d.

Because now mathematicians can add rationals.

Again, if you remember your grade school work,

they probably told you how to do this kind of addition.

So your rational overloading of the plus operator would lead you to

provide the algorithm for doing rational arithmetic.

But, rationals can be used much like integers and doubles.

So you might also expect that you should be able to do a + c.

Where a was a normal int and c was a rational.

And have a resulting conversion and convert the a to a rational.

So now your rationals, this new thing, this new class that you've invented,

G gets used as conveniently as the native type.

That's part of the OOP principle.

When you add a type, you want to add a type in a way that is consistent

with pre-existing types in the C++ world.

So we're gonna add a type, we're gonna add the type point.

Points are very simple to type.

Here's a point,

we're going to think of a point as a pair in a two dimensional world, X and Y.

Maybe that's the point.

1,1.

As with good OO, we're gonna hide representation.

So the actual underlying representation will be a pair of doubles.

So we can also have the point 0.5, 0.5,

really we should be thinking of that as

1.0, 1.0.

So we're gonna use doubles.

We're gonna have a bunch of constructors.

Here's the constructor.

That's the constructor of one argument, which basically takes an argument,

makes it the x value, and leaves the y value as zero.

So a point here is going to,

if I wanna have a point whose value is initialized with three,

I'm gonna end up with the point 3,0 through this constructor.

This is gonna be important because this is

also what we call a conversion constructor.

So here's point s, we can think of it

as having value zero-zero if we define that class properly with a default.

And now we have a double, 3.5.

And we say assign to s, d.

Now d is a double, and we don't have a logic for assigning a double.

So there needs to be a conversion.

So d needs to be converted to the point 3.5,0.

Once it's converted, then we can have the.

Now, if we wanted to make that clearer, we could do it via an explicit assignment.

But actually, this works as well.

Why does it work?

Because C++ allows for implicit conversion.

In fact, I'm gonna go back to the previous slide because

I'm gonna show you something that you can keep in mind.

If you didn't want that behavior you would have to add the keyword.

Explicit.

An explicit in a way turns off

Implicit conversion opportunity.

So, there's lots of times that you don't really want that to happen because

adding conversion opportunities in this language

it's very sensitive because conversions allow signatures to be matched.

They allow expressions to be evaluated, and

you don't want that to happen inadvertently.

Now, what about converting a point to double?

Well, we know how to convert double to point.

The way we convert double to point, is we write a conversion instructive.

So, the argument, the double argument

becomes an argument of value to instantiate

some of the underlying data in point.

But we can't write a conversion constructor in

the native class double, double is a native type.

You could think of it as having its own code somewhere in the world,

it's really just built into the compiler.

But there isn't a way to inform the compiler

that I wanna change the rules about double.

So, because there's no access to that code.

So, C++ does provide an alternative, and we see the alternative here.

You can, inside the class point,

so again, we see that we have scoped

resolution to point by providing operator double.

The type to be converted to.

We allow a point to be converted to a double.

Now, whether that makes sense, whether that's a good idea,

it probably only should be used where it's natural to the semantics of that type.

What I mean by natural to the semantics of that type?

Which somebody who is used to a draftsman, who is used to using

two dimensional objects, two dimensional coordinates points.

If you told him that I wanted to convert a point to a double,

would he know what you meant?

He doesn't know what you mean.

If he doesn't know that you intend to use the distance, the vector is

from the origin, which is basically what we're doing here, then it's a bad idea.

Then you should probably provide something that's explicit,

like the length of a point from the origin.

You should have a name type.

So, these conversion opportunities can easily lead to obscure programming.

And they frequently should be very heavily justified and

the justification should come from the domain, in which the type is used.

But it's available, so now you can have

what might be called a narrowing conversion.

And you can turn a point into a double, or

you could turn a point similarly into anything else.

By providing it with whatever this type name is,

a type and some semantics to convert to that type.

And then you have conversion opportunities.

Pretty powerful stuff.

Oh, we've already talked a little bit about that.

I've already pointed this out.

Again, C++ 11, some of the earlier compilers already implemented,

this allowed an explicit keyword.

Once people started doings rampant operator overloading and

conversion was soon discovered that things

were happening subtly that nobody expected.

And so, the explicit key work got introduced so that could be turned off,

that opportunity could be turned off.

Now, remember that in C++,

one of the big changes from C is you have function overloading.

So in C, if we wanted the sum of an integer array,

we have call it sum if int array.

If we wanted the sum of a double array, we have to give it a different name.

We have to distinguish the name, even when the code read the same.

C++ provides a number of ways to keep the name for something that

where we're doing conceptually the same work using the same code.

The two principle methods are ordinary overloading of functions.

So, we can call both C adding of arrays of ints, and

the adding of arrays of doubles, or even the adding of arrays of rational sum.

And then they get discriminated by their signature.

I maybe just write it,

so if I want it, I could say,

double, sum, double.

Int, sum Int.

The code would probably look the same.

I could even do this with templates.

And the compiler has to have a way,

among the meanings available to it to choose which meaning.

Otherwise, it becomes ambiguous, so you can,

as a compiler error message, get the fact that the compiler is confused.

Now, the compiler has a very complex and

detailed way it as preferred selection.

So exact match, exact match is always preferred if would,

is passed in a set of arguments.

And it's looks a third type, and it says, oh, I have exactly code for

those types, then it picks that.

No problem, everybody understands it.

But now, we have all these promotions available.

So again, just like with square root,

remember square root is in the standard library, in the math library.

Square root will work on an integer, even though it's intended to work on doubles.

Why?

Because the integer will be promoted automatically silently to a double.

So again, what happens is, an overloading standard promotions,

which are the safest kinds of promotions, are preferred over anything else.

And so, if there's a signature and it requires a standard promotion,

and there's no exact match, then this would be tried.

The next in line is standard type conversions, including demotions.

Then there are user defined conversions, much like those,

the conversions we defined on point.

And then there's a match to see if there's an ellipsis signature, and

that's the worst.

Now, if you're following any of this in my text, there's description of it.

Page 198 to 200 with a detailed

example using rational numbers, but it can be very complicated.

And you can see where you have all these additional

user defined conversion opportunities that you have to be very, very careful.

Hence, the introduction of explicit to avoid silently

ending up with execution of code that was uninvented.

Friends, next big topic, we have these things called friends functions.

There is a couple of friends, they're my own cats they're named Googly and Hamster.

They're friends, though they're more frienemies than friends.

They, cats being, even domesticated cats seem to be fairly territorial.

So, they do hiss at each other, and they especially fight over their food bowls.

But a critical thing about friends, and that's going to be true in C++ is, if

you're a really good friend of mine, I'm gonna let you look at my private stuff.

I'm gonna let you look at the private implementation of my class,

that gives me the opportunity to act on your class,

almost as if I was a member function.

So a friend function has access as if it was a member function,

but it's not a member function.

If it's not a member function that means it has no access to what?

Think about that.

Is one thing that member functions always get, ordinary member functions always get,

that functions that are called

with arguments on the class don't get, and that's the disc pointer.

Remember, a member function is activated through the disc pointer.

Friend function get's to treat the private parts as if it was a member function,

but doesn't get to directly access because that's not

pass in an argument through the dot notation.

There's a class point, and again,

because the C object oriented idiom,

we want the behavior of the bit shift operator to be used for IO.

Again, here we see the IO signature that's our idiom.

We need this call by reference, we pass back out call by reference.

We have a non-mutated object passed by reference.

And it's semantics are that we're gonna prevent a point looking like this.

So, what we would see as output for

a point that had hidden representation 1.0,

2.5 would be (1.0, 2.5), but this is going to fail.

So, if we were in regular code and saying,

C out, blah, blah, and the point name was q.

We would get a compiler error, and

the compiler error would say wouldn't have access to x and y.

Why?

X and y are private.

This is an ordinary method.

It does not have the ability to access hidden representation,

can't make use of this.

Well, oo says, that this must remain restricted, data hiding principle.

So, the way around this, well,

one idea you could try is to make this a member function.

But, recall a member function has a default first argument.

A default first argument has to be an object of type point.

But for this to work in the syntax that's expected,

the first argument has to be an ostream.

It has to be in most an ostream, like C out.

So, we can't make it a member function.

A member function would solve the problem of getting access, but

it wouldn't solve the problem of having the wrong argument order.

And C++, courtesy of invented a way around to this kind of access problem,

and that was to create friend functions.

There is were friend becomes important.

I use this special keyword friend that informs

the compiler that it's got these privileges.

It breaks the normal data hiding, so it should be used very carefully.

Friend should be used very carefully.

We allow it to have these important access privileges, and

unlike a class method it does not have the dot argument.

So, now we're going to pass in both arguments.

We're gonna pass in an ostream and a point.

And that'll be passed in through the argument list,

which is another thing to consider.

Because when we pass stuff in through the argument list,

they're subject to conversion opportunities.

So that's another point, very important and subtle point,

that deals with the use of friends when we overload operators.

Friends overload operators by

having the arguments always go through the parameter list.

A member functions overload the arguments by having your

first argument be the class argument, namely at this point your argument,

that is not overloaded to have conversion opportunity.

So only a second, or other argument would have a conversion opportunity that

leads to a different behavior, even when we can overload the same operator.

And have the choice between friend overloading,

member function overloading, we frequently choose friend overloading.

I'm gonna make that point a couple of times cuz it's very subtle and

important point.

We do that to maintain symmetry.

A friend overloading lets us use the argument list,

the argument list means for binary operators,

we get all the conversion opportunities symmetrically on both arguments.

Here is a member function overloading of the operator +.

So, think of what you're doing.

You have two points, let's say we have (2,

1) and (1/2, 0).

And we want, maybe that's an a, and that's a b.

And we wanna be able to because that's what we are used to as mathematicians,

be able to write naturally a + b.

And we can see what we want that to be, that result.

Let's call it c, we want c to

come out (2 1/2, 1).

And the way we do that is If we're overloading

this with the notion that we have a plus b,

we really are calling through to this point of a,

and through the argument was b.

That's really how this is getting activated.

So, that's why x and y are without.

Those fields are discriminable.

See, these are really, this points at x, plus p of x.

And that leads to two and a half, and similarly for the y, okay,

if you understand everything I've just said, you're really getting all this.

If you don't understand what I've just said, you gotta work with this.

You gotta do your own stuff.

You gotta overload operators.

And see how that works.

So this is very critical that what I just said, is clear to you.

So here you've seen how to overload the binary plus using a member function,

and here i'm just repeating what I said on the other with a different example,

I have three points, I'm adding to a, b plus c,

a is gonna end up being two and

a half, seven.

But, if instead that operator got

overloaded in a way that we use the friend function instead of a member function,

its invocation, Would instead call a friend function.

And both b and c would be passed instead of this pointer.

And an argument.

This would be arg 1 and arg 2, and they would be completely symmetric.

So in the completely symmetric case, all of the available conversion opportunities.

So for example, remember, we can convert an ordinary double to a point.

So that would mean, if you're following me,

that if d was a double, and I did d + b

This wouldn't work.

Or member overloading.

And that gives you the reason why you want it as a friend function.

Friends are really important.

They're really important especially when you're doing operator overloading.

They're important in other considerations too,

when you have two very strongly linked classes.

Gotta warn you about operator overloading, people get infatuated with it, why?

Cause it's a way to have a secret calculus.

Everybody loves making their own secret notation.

That's okay.

If you're just playing with the stuff, and you're not in a company, and

you're not using it professionally, where other people will need to interact

with your code, do operating overloading to your heart's content.

Maybe you can even come up with something close to APL if you remember this hugely

powerful early IBM language, a man named Iverson, invented

the language in which there was super powerful overloaded operators in effect.

That worked very well with linear algebra calculations.

And from what I recall, I may be wrong about it, somebody can write into a forum

on this, I believe you could write out a linear programming

algorithm using the Iverson notation.

In relatively few lines of code, whereas if you had to use the language

of the day such as Four Train and PL1, it would be a considerable amount of code.

So you would have this enormously dense,

powerful operator language, and this could be replicated.

With operator overloading, but using this,

one expects to conform to the rules of math.

You generally are going to use it in domains for

which people know what the meaning is.

You don't want to have to explain that plus is something that it isn't.

What does times mean in a domain where you are talking about clocks?

Let's say you decide to design a package called a clock, and

clocks have minutes, seconds, and hours.

Well it's pretty easy to understand how, you know,

I have an appointment a half an hour from now.

So I want to know what time that's going to be.

But now what's the times operator gonna be?

Can I multiply two clock times, is that reasonable?

So, you gotta be very careful, and you need to be comprehensive.

So you're not going to go and overload + in a normal domain,

in which- is understood as being the inverse operation.

So normally you're gonna overload the complete algebra.

You have to do what's expected.

You have to do what's natural.

And you have to do what fits in with the native C++ types.

Okay, here's a quiz to this section.

Not all operators are overloadable.

Most operators in C++ are overloadable.

Some operators like scope resolution remember that's colon colon.

That's not overloadable.

Why?

That would cause capacitor fee.

If you gave it a different meaning from what it needs to be.

Which is scope resolution.

It would for one thing it's very hard to imagine what that meaning could be.

So it's not overloadable.

Another operator that's not overloadable is ternary operator and

there is a single ternary operator and what I'm asking you is,

to explain what it is and why it's not overloaded.

Answer, the ternary operator is question mark equal so

the typical thing is you have some lets write out something just so

you remember, there are many people who will rarely use this operator.

say something like (a < b)?

a :b, so these are the three arguments,

arg 1, arg 2, arg 3.

The normal language says test this for truth.

And true, this is the true result.

And this is the false result.

So, many people prefer to just do these things with, miscalculations.

No reason that this is overloadable is [INAUDIBLE] didn't wanna bother with it.

It's already not that used in operator.

It's generally not an operator you'd expect in any algebra.

It would be ugly, so it's not overloadable.

Maybe there's some other reason.

Okay, that's it for today, we've packed in a lot, and I will see you next time.

Explore our Catalog

Join for free and get personalized recommendations, updates and offers.

Coursera provides universal access to the world’s best education, partnering with top universities and organizations to offer courses online.

© 2019 Coursera Inc. All rights reserved.

Download on the App Store

Get it on Google Play

Coursera
About
Leadership
Careers
Catalog
Certificates
MasterTrack™ Certificates
Degrees
For Enterprise
For Government

Community
Learners
Partners
Developers
Beta Testers
Translators

Connect
Blog
Facebook
LinkedIn
Twitter
Instagram
YouTube
Tech Blog

More
Terms
Privacy
Help
Accessibility
Press
Contact
Directory
Affiliates