Teach me CS stuff for interviews

[Reincarnate]

So to take it to the other side: if I am calling the subclass' make_sound(), why have it present in animal?

[FissionMailed1]

If you don't have a make_sound() function in the Animal class, you will not be able to iterate over a container of generic Animal objects. You would only be able to call make_sound() for one type on animal, not multiple types.

[Reincarnate]

Sorry I am at work at the moment so I'm reading these posts at light speed, so I may be asking dumb questions here.

Does this polymorphism concept only apply to iteration? For instance if I instantiated a Cat inheriting from Animal and simply called make_sound() from it, which one does it invoke? What differentiates whether I call animal's make_sound() or the cat's?

[UserNameGoesHere]

If the Cat class implements a make_sound function, and you call make_sound on a Cat object, you are calling the make_sound from the Cat class unless you first cast the Cat object to be of type Animal (assuming Cat class inherits from Animal class), in which case you'd be calling the make_sound from Animal class.

If the Cat class does not implement a make_sound function, but inherits from an Animal class which does, and you call the make_sound function, you are calling the one from the Animal class.

[FissionMailed1]

Originally Posted by Reincarnate

Sorry I am at work at the moment so I'm reading these posts at light speed, so I may be asking dumb questions here.

Does this polymorphism concept only apply to iteration? For instance if I instantiated a Cat inheriting from Animal and simply called make_sound() from it, which one does it invoke? What differentiates whether I call animal's make_sound() or the cat's?

No, polymorphism doesn't apply to just iteration. I think it is the best example to explain it though, so that's why I used it. In regards to which make_sound() is called, it depends on whether make_sound in Animal is virtual or pure virtual. If it is either one, Cat's make_sound() will always be called. If make_sound() is not virtual, then the make_sound() that is called depends on the type that was initially declare, or if Cat declared make_sound() at all. For example:

Animal generic_animal = new Animal();
Cat generic_cat = new Cat();

generic_animal.make_sound();
generic_cat.make_sound();

This will behave exactly as you expect it to behave, and generic_animal's make_sound() will be called, followed by generic_cat's make_sound().

[Reincarnate]

I'm not sure what virtual/pure virtual really means so maybe that is impeding my understanding of this.

In my mind, the whole point of inheritance was to have some sort of logical structure of abstraction, where the parent (or whatever you call it, the class you inherit) class has methods/data attributes that a bunch of subclasses have in common. Like a Piece class in Chess or something where Rook, Queen, King etc all inherit from or something (just an example), as they all have their separate handling methods but they're all ultimately pieces that follow the same general rules.

So when we're talking about this polymorphism concept, I keep thinking "Why the heck is this even the case?" If I want to call a cat's make_sound, I would declare a cat and call make_sound. If I want to call some animal's make_sound, I would declare an animal object and call make_sound.

Unless this idea is to have a cat object that can "choose" somehow to all either its local make_sound or its parent class' make_sound? Am I anywhere close on any of this? What's the point of this polymorphism concept?

[FissionMailed1]

Well, if you have a "piece", but you want to call move() on that piece, how exactly does that piece move? You wouldn't know how to "move" unless you implemented a specific way to move depending on which type of piece it is (the subclass).

Your last questions are correct. You can choose which make_sound() is called.

Another example of polymorphism, using a function:

Piece* some_piece = new Rook()

move(some_piece*);

void move (piece* piece_to_move) {
// do some stuff to move in a generic way, disregarding which type of piece it is
}

This is all assuming that move() is either virtual or pure virtual.

[Reincarnate]

yeah I am not getting this, lol.

I'm still not seeing what the differentiating notion is here -- what this accomplishes that I can't already do by just localizing the move/make_sound functions to what they logically apply to.

All animals make sound, and all cats/dogs make sounds, too. But to me, this just implies that I could have make_sound in the animal class and have the sound variable/file/whatever localized to the cat and dog classes. That way when I call make_sound() on a cat object, it takes the sound variable in cat and plays it via the animal's make_sound() function. Or something to that logical effect.

[FissionMailed1]

Originally Posted by Reincarnate

That way when I call make_sound() on an animal object, it takes the sound variable in cat and plays it via the cat's make_sound() function. Or something to that logical effect.

This is the correct statement, but I think you are almost understanding it! It would call cat's make_sound() if the animal object is a pointer to a cat object.

EDIT: I think it would make more sense if we just assume that make_sound() is pure virtual in animal, so animal's make_sound() can never be directly called. It can only be called through its derived class.

[Reincarnate]

So I could say "Animal* kitty = new Cat()" but what I am saying is that why couldn't I just do "Cat kitty = new Cat()" where Cat inherits Animal, and then when I call kitty.make_sound(), it calls the Animal's make_sound() function using the data attributes of the Cat() object?

[FissionMailed1]

It will call Animal's make_sound() function, yes. However, if Animal's make_sound() function is pure virtual, it will look at what type of object Animal is pointing to (in this case, a cat) and call that implementation of make_sound() instead. It will just the data attributes it inherited from animal (if there is any) and the data attributes from Cat when executing make_sound().

Oh, I should also mention, pure virtual is declared as follow:

virtual void foo() = 0;

EDIT: Sorry, I misread your post. my post is assuming that you are executing this:

Animal* kitty = new Cat();
kitty->make_sound();

EDIT 2: I need to go eat some food or something, not thinking straight. If you do something like this:

Cat* kitty = new Cat();
kitty->make_sound();

This would also be valid code as well, and will perform exactly the same as the code snippet in my first edit.

[Reincarnate]

Can't I just declare Cat kitty = new Cat()?

[FissionMailed1]

You could do Cat kitty = Cat();. You cannot declare kitty on the stack and then use new() because new allocates memory on the heap, so kitty would have to be a pointer to a Cat if you wanted to use new(). If you use Cat kitty = Cat();, you would write kitty.make_sound() rather then kitty->make_sound() because the -> operator is for object pointers.

[UserNameGoesHere]

Okay Reincarnate, I made some code for you :-P

#include <iostream>

class Animal {
public:
Animal();
~Animal();
/*virtual*/ void make_sound();
};

class Cat : public Animal {
public:
Cat();
~Cat();
void make_sound();
};

Animal::Animal(){}
Animal::~Animal(){}

void Animal::make_sound(){
	std::cout << "ROAAAAARRRR" << std::endl;
}

Cat::Cat(){}
Cat::~Cat(){}

void Cat::make_sound(){
	std::cout << "Meow" << std::endl;
}

int main(int argc, char* argv[]){
	std::cout << "Testing animals" << std::endl;
	
	Animal* animal = new Animal();
	Cat* cat = new Cat();
	Animal* catanimal = dynamic_cast<Animal*>(new Cat());

	std::cout << "animal says "; animal->make_sound();
	std::cout << "cat says "; cat->make_sound();
	std::cout << "catanimal says "; catanimal->make_sound();

	delete animal;
	delete cat;
	delete catanimal;

	return 0;
}

If you declare without the virtual keyword (as is above, where it is commented-out) you get as output

Testing animals
animal says ROAAAAARRRR
cat says Meow
catanimal says ROAAAAARRRR

But if you do declare the virtual keyword (remove the commenting) you get as output

Testing animals
animal says ROAAAAARRRR
cat says Meow
catanimal says Meow

Or, basically, yes the virtual keyword does matter a whole lot, and FissionMailed is right.

[Reincarnate]

[UserNameGoesHere]

Also, I think a lot of people miss the point of implementing things like linked lists, hash tables, etc...

Yes, they've been done before. Yes, you could find a code somewhere and copy/paste. But that's not the point. The point isn't to implement those specific things with known solutions, but to see if you can problem solve just in general, to see if you could possibly solve problems which don't have known solutions, which are interesting.

If you can't implement the simple stuff then how can you be expected to implement anything more complex?

[FissionMailed1]

LMFAO, that gif. I've been where you are before, and I understand your frustration. It took me a while to understand polymorphism as well, especially in the context of C++. I can give you java examples if you want and it might be easier to understand, but the reason I gave C++ examples is so the details of what exactly is going on aren't hidden by the programming language.

[Reincarnate]

UNGH: If anyone made that argument to me in person, I'd just tell them, "Go beat PE 344, 361, and 415 -- and see if you can beat my runtime, code length, and clarity"

FM: Nah I've only used C++ IME, no Java yet although I should learn that too.

[FissionMailed1]

Java isn't drastically different from C++ at a rudimentary level, so I don't think you would have that much of an issue learning it very quickly. The main difference is that it doesn't have as many low level operations as C++ does, and is a bit more verbose; that's pretty much it though. It is very object-oriented by design so it has interfaces and abstract classes built into the language, among other things.

[Reincarnate]

yeah, according to the video playlist posted earlier, Java programming doesn't revolve much around pointer management but instead Java has references which are automatically handled by the garbage collector when things go out of scope. A lot of the syntax between Java and C++ is the same (or similar), too