Creating different weapons in class

[Repeater]

These are all questions you can answer yourself by editing the code shown.

[Ch1156]

Ok sorry i was on my way to work when wrote that, im on my way home and will run it and mess with it when i get there.

[Ch1156]

Ok so I played around with the code a little bit, but I dont understand why do this:

    Base* pointer_to_base = &baseObject;
    pointer_to_base->speak();

    pointer_to_base = &d1obj;
    pointer_to_base->speak();

    pointer_to_base = &d2obj;
    pointer_to_base->speak();

When this can be done:

    Base baseObject;

    D1 d1obj;
    D2 d2obj;

    baseObject.speak();
    d1obj.speak();
    d2obj.speak();

Maybe i'm missing something but it just seems like 2 ways to do the same thing. Also i'm still unclear as to WHY virtual is needed. I did a google search and I found this:

When a Base Class has a virtual member function, any class that inherits from the Base Class can redefine the function with exactly the same prototype i.e. only functionality can be redefined, not the interface of the function.

So what exactly does that mean? That virtual functions with the same name can be re-written in child classes? Like if i have a generic fire function in base then redefine fire for a pistol, then for an assault rifle? I thought that was possible to do without virtual?


I found this fromt he same post as well in reference to the very first question above about using a pointer to base:

A Base class pointer can be used to point to Base Class Object as well as Derived Class Object. When the virtual function is called by using a Base Class Pointer, the Compiler decides at Runtime which version of the function i.e. Base Class version or the overridden Derived Class version is to be called. This is called Run time Polymorphism.

Post: https://www.quora.com/Why-do-we-need-virtual-function

So what exactly about a pointer allows for the compiler to decide this at run-time? is it because its in memory and not hard-coded?

[Repeater]

If it's not a virtual function, you have to know at compile time what kind of object you've got so you know exactly which function to call.

If it's a virtual function, you don't have to know at compile time exactly what kind of object you've got.

cout << "What kind of weapon do you want?";
cin >> choice;

weapon* p_playerWeapon = nullptr;
if (choice == "rifle")
{
  p_playerWeapon = new rifle;
}
else if (choice == "pistol")
{
  p_playerWeapon = new pistol;
}

// the exact function called might be rifle::fire or it might be
//  pistol::fire , depending on what the player chose above
p_playerWeapon.fire();

How would you do that without virtual functions? It can be done, but it's awkward and much more laborious than with virtual functions.

So what exactly about a pointer allows for the compiler to decide this at run-time?

An object that has virtual functions contains a look-up table of the actual, exact functions to call. When the object is built during execution of the programme, that look-up table is populated. The table is known as the "vtable". It's not anything to do with the pointer. It's in the object that was built.

[Ch1156]

An object that has virtual functions contains a look-up table of the actual, exact functions to call. When the object is built during execution of the programme, that look-up table is populated.

So a vtable is kind of like a switchboard, one of those old phone things that people had to sit in front of and put the right pin in to connect a call. It essentially just directs the program to the correct virtual function at runtime, right?

And a pointer just accesses that object on the vtable?

[TheIdeasMan]

Ch1156 wrote:

I got the bounds checking and the error throwing, I also broke everything up into separate files.

Well, you haven't really. What I meant about bounds checking, make this code do the right thing with error messages:

int main() {
  Pistol MyPistol(-100); // Can't have a negative value
  Pistol MyPistol(0);  // Ok, pistol empty
  Pistol MyPistol(10); // Ok 10 rounds loaded
  Pistol MyPistol(15); Ok, Pistol full 15 rounds
  Pistol MyPistol(100); // Too many, 15 loaded, 85 not loaded
}

To do this, you need code in the constructor. That is why I mentioned line 9 in JLBorges code. The ternary operator does checking, but you left it out altogether. To do more checking you need code in the braces of the constructor.

What we are doing here is testing the code, too see if it works for all kinds of input.

I was going to stay away from exceptions, it is another layer of complexity, trying to keep it simple. Just do a std::cout of an error message for now.

I don't see a Pistol.cpp, the code for the functions is supposed to go there.

I don't really see the point of writing all the code in the exercises. I appreciate the help, I just don't understand how to use virtual and inheritance properly, I think just bare functions with pseudo code could be more helpful as I have spent more time writing functions than I even have solving my problem.

Well I am trying to make it simple for you, make you think about what you are doing, and you don't see the point You are jumping ahead again, the question about rifles etc is pretty much the same as what is in exercise 6. You haven't fully understood exercise 3 yet. You want to jump into virtual polymorphism, when you don't yet understand constructors, or the concept of validating input.

You are proving difficult to teach, maybe the reason you haven't got very far in the last 11 years is because you have trouble following / focusing on simple instructions. How can we teach you, if you jump around and ignore instructions?

If your disability is not comprehending a paragraph of text, then perhaps you should copy it out using pen and paper. I am talking about the overall instructions I wrote for the whole project. I am serious, it means the brain actually processes the information multiple times in order to write it down. There is a better chance to remember it. Post a link to a photo of the handwritten text. Please don't tell me that you are 27, don't have a phone camera or know anyone who does. Don't tell me you don't have pen and paper.

When I say I want you to investigate something or do your own research, that doesn't mean ask someone else. It means do Google / Wiki searches, read articles, take notes. This will help you learn.

I am not, or we are not going to write functions with pseudo code in them, why can't you show us your attempt at pseudo code? Again this will make you think, and learn. Writing pseudo code for these functions is no more difficult than writing pseudo code for making a cup of tea.

I purposely stayed away from having a Weapon class for now, it could encompass anything from a peashooter to a nuclear missile. I wanted you to see what happens when we start with 1 class, then gradually make it bigger and more complex.

Please do something to demonstrate that we are not wasting our time.

[Ch1156]

I'll work on this Wednesday, as that day I have off. I have already gotten a better understanding of virtual through my conversation with Repeater and people on other boards so I understand that much better now at least, I think that will help.

I think another problem is that I don't really ask questions about things I don't get, when I was asking Repeater, I asked him to explain it in a simple way and that helped tremendously for me to understand. When technical speak is used, it really confuses me. I'm going to start taking notes on stuff and keep that in a google doc and reference it when i'm confused.


I'll continue asking any more questions about virtual or anything else in a different thread and keep this strictly for the exercises.

[TheIdeasMan]

Just to reiterate this, really pay attention to these things:

TheIdeasMan wrote:

Here are some concepts about what I am expecting for the way you to go about doing this project:

* Keep it simple
* Follow the instructions
* Do 1 exercise at a time, get that working and complete with all the features and style requirements I am mentioning here. Only then move onto the next exercise.
* When starting with a new exercise, start with the code you had in the previous exercise. Save each exercise in a different folder on your computer. There are going to be multiple *.hpp and *.cpp files (multiple classes), so it will be best to copy the whole folder to help avoid confusion. In your IDE, each exercise will be a separate project. Find out how to import existing files into the new project.
* Think about the code you are writing, be self critical of it. Don't spend 3 minutes writing the code, then post it. Instead review each line of code (LOC), see if you can see any potential problems with it. Are you mixing types? Is the LOC going to work for different values, are there any values which might cause it to fail? Remember the goal of always striving to write code that doesn't fail.
* There is going to be some planning / design required. That is, you might need to write down ideas, draw pictures to organise the design of the code, before writing any code.
* when writing the code, write comments about what the code is going to do. Then go back and write the actual code for each comment. Leave the comments in the code as a bit of documentation. This is going to help you organise your thoughts. I might ask to see all the comments first, before you write any actual code.
* For each function, write 3 lines of comments about what the function does
* For each function argument, write a comment about what the valid range of values is.
* This project is about real life objects (A pistol, so far) , think about what happens in real life, make you code work that way. That is, actions one would carry out in real life become functions in the code. As the project moves forward, there will be more objects and classes.
* Choose meaningful names for variables and functions. Good code should be mainly self documenting on the names you choose, it should tell a story of what is happening, just by the names of the variables and functions.
* Functions should only do one conceptual thing, and they should be relatively short - at the most say 30 LOC.
* There will be times where you need to do your own research. Even though we are helping you in detail, you should be able to go and look things up yourself. We don't want to write a brand new wiki with everything there is to know about C++.
* As the project gets more complex, hopefully it is instructive to see how the code changes. This project is different to a real life project in that we are starting very small (1 class) then gradually adding stuff. In real projects, modules worth of things are designed and coded all at once, so there is much less change in the code.