// TODO: create a form with loads of crap on it// TODO: calculate total cost based on requirements// TODO: reset form, repeat calculations with new data
I've left out a few minor details, so just fill those in and you're ready to go!
Or better yet make an attempt yourself at solving the assignment and ask for help with specific problems that arise, not just posting your homework and hoping someone will do it for you.
That's not even right the immediate base of class3 is class2 not class1.
And who wants to pollute their code with a bunch of extra methods when there should a be a way to syntactically statically bind to any method in the inheritance tree.
Yes it's not something you need to do often and it might mean that there is something wrong with your design but there still should be a way to do it, it's not unsafe.
if you have a Base object or a Base-derivative pointed to by a Base reference,
it will do the virtual call, as intended by the virtual keyword.
there is the "base" keyword, but its use is restricted (see paragraph 7.5.8 in the C# ref man)
to a few places, all inside classes that derive from the base class.
So yoy cant do myObject.base.methodname()
Conclusion: the virtual stuff really hides the base methods/properties.
And my first impression is that is how it should be.
Why is it you want to get at the base implementation from outside of the class anyway ?
There is of course a trick to do it, by providing a Clone() method in the base class,
something that takes a Base or Base-derivative and creates a new Base object, equivalent
to the base-part of the object (similar to a copy constructor), stripping off all
Thanks for the reply and that's pretty much what I thought that you can't.
This kind of came up from a friend of mine who is trying to impliment something like the boost serialization library in C# in that he has a secondary class that is walking the inheritance tree of the class to serialize by exlicitly serializing the base classes states. It kind of does this in a funny way and I'm not entirely convinced it's the right way.
Beyond that I have run into times where it was handy to do this, usually because something beyond my control was implimented improperly.
with a spoonful of lateral thinking I read your sentence "Note that it is possible to invoke the hidden virtual method by accessing an instance of D through a less derived type in which the method is not hidden" as "WTF just give the method a name that remains visible...".
The standard thread pool allows 25 threads per processor, but there are a number of improved thread pool implementations that allow you to go beyond this. You may want to look at this[^] implementation.