sorry, I don't see anything in that post that could make above code work. Could be my shortcoming, as I'm not that of an expert on C++.
Is there anybody that can make above code work ?
Remove line poly = CRectangle.CPolygon;? I still not understand what you are trying to do on that line so I don't know if removing it is the correct answer but at least it will let you compile the code.
Maybe the OP wants to copy objects? For that he needs a copy constructor.
Speaking of constructors, there aren't any, not even default ones, so that definitely won't work for inheritance because there is no base class constructor to call. I always have default constructors & destructors, my IDE creates them for me when create a new class.
Possibly he just wants another rectangle? Maybe not, has already created one so it should be easy to create another.
Maybe he wants another rectangle class that is different to the first one?
LOL I can't belive none of you know what it means! Maybe this example will clear it up:
1 2 3 4 5 6 7 8 9 10 11 12 13
struct base
{
int a=1;
};
struct derived: base
{
int a=2;
void foo()
{
cout<<base::a;
}
};
Bu still that's bad using, since(I belive, but I'm not sure it's right, so don't attack me if I'm wrong, it's just maybe) in that case, derived's "base" is a namespace in which are all the base's components! Sure, it's very misused etc., but I though it bas obvious he meant that. poly=rect would be better.
I am confused by the last post, especially by the namespace stuff. To me the base and derived structs are the same thing as classes in C++. The base::a is just a scope resolution to get at base's variable a. I don't get how that relates to the OP's syntax at all. The only other thing I can think of which is similar is calling a base class constructor in the definition of the derived class constructor, but the OP doesn't have any constructors.
To do this poly=rect , I thought that a copy constructor was needed.
Maybe I am really confused, I hope I am not the only one.
@TheIdeasMan
If no constructor is defined a default constructor is implicitly defined for the class. A copy constructor and copy assignment operator is always implicit defined if not explicitly defined.
I'm working out some example C++ code (I'm amongst others a C programmer), and run into below where I thought of using above for.
My main is calling a methodA of a class, which returns a boolean. When the boolean is false something went wrong in methodA (or something went wrong in other functions, methods etc. called by methodA).
So I wanna to find out what went wrong, by means of a error-message (string). Could be all kinds of different errors: application-error, IO-error, param-error etc. etc. My main determines what to do with the error (display, write to a file etc.).
To be able to set the errors I was thinking of dedicated classes per error (app-error class, param-error class etc. etc.). In that case the programmer knows exactly wat he has to set (via the setters).
Those dedicated error-classes inherit a general error-class (GENERR), which :
- has all the information set via the dedicated classes
- has the error-message (different per type of error).
So my main can, when the boolean returned by methodA is false, use simply one getter to get the GENERR-class. An do with it what he wants. When he wants to display an errormessage, he just gets it from GENERR via a getter. Furthermore, all the information off all errortypes is available in GENERR.
That was the thought behind it. Perhaps there are many other ways to do it. When I think of it now, another way would be to have one error-class that has a public struct which has all error-types and behind each error-type the items that can be set per error.
So you're "TheIdeasMan" :-) ... what would be the C++ way of handling all kinds of different errors, in all kind of places, when you want the main to decide what to do with it ?
what would be the C++ way of handling all kinds of different errors, in all kind of places, when you want the main to decide what to do with it ?
Exceptions.
As to the OP's question: If you were actually using inheritance, you'd have to provide a separate "copy" or "clone" method. The reason you can't use a copy constructor in that scenario should be obvious.
A good IDEA - not mine though :-D ( good work hanst99)
One unrelated thing that I have found to be very convenient, is the idea that a pointer to a derived class is a valid pointer to a base class. I found this to be very handy for pure virtual functions in a base class that have an argument that is a pointer to the base class. After I redefine the function in the derived classes (I have to do this to be able to make an object of that class), I call the function with a pointer to the derived class. This is great because now I only need 1 pure virtual function in the base class, not an overloaded one for every derived class.