i decided to practice classes,inheritance,keyword this and friendship and made myself a project "Synth constructor" @inspired_by_fallout the project's mission is to give an option to create a detailed description of the synth's body parts and than view the description as a whole.
The code i made seems to have no syntax errors and compiles with 0 errors but the problem is the second i run it it throws out a "program stopped working" and i don't think i have the skill to understand why yet.
detailed problem:
"ConsoleApplication1.exe has stopped working"
"A problem caused the program to stop working correctly.
Windows will close the program and notify you if a solution is available."
and it gives two opetions: "Debug" does nothing and "Close program" that does as said..
+ If anyone has a recommendation on what i should avoid ,which style to stick or how to make my code cleaner in the future it will be more than welcome.
Have you tried stepping through it in, a debugger to find out exactly where it crashes, and to examine the state of the memory at that point? I strongly recommend you do.
I know this is only an exercise for you to experiment with inheritance, but, from the names of the classes, it seems as though you've misunderstood what inheritance used for. At its most basic, it should be used to model "is-a" relationships; that is a relationship where the derived class is a specialised type of the base class.
For example, a dog is an animal, a cat is an animal, and a bird is an animal, so if you were creating classes for these, you might want to create an Animal base class, for all the behaviour and properties that are common to all animals. Then your Dog, Cat and Bird classes would inherit from Animal.
That isn't true of any of the base classes in your example. It would be wrong to say a synth is a head, or that a synth is a torso, or whatever. A synth has a head. A synth has a torso. This is composition, not inheritance.
Consider the following: what if you decided to make a synth with 2 heads? How would your design cope with that?
Memory was the next step in the fault finding and an additional aspect to debugging above is to comment out the classes and progressively reintroduce them to find the spot where memory or whatever is causing trouble. There might be a spot (surely) where it doesn't crash or was this all typed up in one slab of code?
A couple of aspects of the code catch my intuitive eye.
The friends syntax can be a notorious causes of problems, the use of 'this' in the constructors or whatever they are and elsewhere is interesting. construct_whatever(etc) returning void seems strange, are they meant to be constructors, where are the destructors?
Why this didn't show in running it in the shell is anyone's guess.
@kemort Those "constructors or whatever they are" are just oddly-named setter methods. I don't see anything troublesome about the use of this in them - it's just being used to distinguish between the object's data members, and method arguments of the same name.
Personally, I would make sure I didn't use the same names for my method args and my data members, but that's just stylistic issue.
Could you elaborate on why you think the use of this might be causing problems?
While playing with your original code, I tried commenting out all the friend forward declarations and the code at 135 - 138. once I did that the code compiled and ran with no problem.
Unless you are trying to overload the << operator and even then I see no use for it unless I have missed something. The program works with out it.
@MikeyBoy: if i would name synth as a "Body_Part" than would it be right to say a Body_Part is a head or a Body_Part is a Torso ?
+ i wanted to test how the program behaves if i make multiple base class with a derived class Synth_Model that has access to all of them so that in main i would need only one type (Synth_Model) to access all of the base members.
About the two heads i didn't mean to make the program that any user can access i wanted to create a test exercise in which i manually set everything and see if it works so i wont set 2 heads and it wouldn't be a problem.
+Question:can the problem be my IDE(microsoft visual studio) ? since it wont let me print std::string values i decided to overload operator<< and it fix the problem of "no operator << matches something something":
+On the topic of keyword "this" i mentioned at the top that i wanted to exercise this keyword it is not my style and personally i would avoid it as well.
@kemort as MikeyBoy said these are oddly-named setters and not constructors that is why there aren't any destructors .
+if you can run this program perfectly and i cant, can it be that my IDE (microsoft visual studio) isn't good ?
@Handy Andy: the use for overloading << is that without it i cant print out std::string values as it gives me "no operator << matches something something" error and overloading << seems to fix the error popup so i cant comment out the friend declarations as it wont let me go past compilation.
UPDATE:i downloaded code::blocks and ran the same code with no changes and it runs perfectly i think that microsoft visual studio just doesn't work properly.
+shell runs the code perfectly for me aswell
I don't want to belabour the point about design. I appreciate that this is an exercise for you to get familiar with the technique of inheritance in C++, not production code. But since you asked...
if i would name synth as a "Body_Part" than would it be right to say a Body_Part is a head or a Body_Part is a Torso ?
No. A head is a type of body part. A torso is a type of body part. Both of those classes would inherit from Body_Part - which is the opposite way around from the way you have Synth inheriting from all those classes.
i wanted to test how the program behaves if i make multiple base class with a derived class Synth_Model that has access to all of them so that in main i would need only one type (Synth_Model) to access all of the base members.
Yes, but in doing so, you're making the Synth object behave as if it were Torso, and a Head, and Legs, etc. You're giving that class the same interfaces of all the classes it derives from, when that probably isn't appropriate. Your Synth class should have the interface appropriate for the way calling code would interact with a Synth object - which may well not include the complete interfaces for all the components.
About the two heads i didn't mean to make the program that any user can access i wanted to create a test exercise in which i manually set everything and see if it works so i wont set 2 heads and it wouldn't be a problem.
Sure. I understand that. The purpose of my question was to illustrate just one reason why your design probably isn't appropriate for what it is you're trying to model.
if you can run this program perfectly and i cant, can it be that my IDE (microsoft visual studio) isn't good ?
If your code has undefined behaviour, then the fact that the MSVS build crashes makes it better, not worse. You want your bugs to be nice and obvious.
that's infinite recursion (stack overflow), ¿what function do you think `Out<<Data;' will call?
This would be fixed by #include <string> which provides the prototype and implementation to print strings to the screen.
As for why it works with GCC. `<string>' gets included by `<iostream>' (this is not required behaviour and you should not count on it). Then it uses std::ostream& operator<<(std::ostream& Out, const std::string &Data); instead of yours.
@ne555 thanks for the tip! i removed all of the friend calls and the friend function and added #include<string> and now it works perfectly in microsoft visual studio.
@MikeyBoy thanks for the explanation! i will use your tips further on and have a question do you have any source or tutorial by chance that will illustrate how to properly use inheritance?
(i know the basics but this sites tutorial doesn't seem to explain inheritance that in depth).
Check out http://www.learncpp.com/ chapter 8 and 9. I have found it to be very useful and easy to understand. I do not remember at the moment which part of chapter 8 covered inheritance
Ne55 found the part I missed, #include <string> . When I setup my main file I include one header file that includes <iostream> and <string> along with a couple of others. So, that’s why your program ran for me in Visual Studio 2015 and not for you. Since my file had the #include <string> everything worked, but the code for the operator ]code]>>[/code] overload was the only problem I had.