quote:
Original post by Dauntless
flarelocke-
arrgghh, my head''s sorta spinning, but I think I get it. tobase* is a pointer of a ''base'' class, but you have created an object of type derived, which is a subclass of base. So when you called tobase->myfunc, even though it holds the address of a derived object, it''s really calling the base::myfunc (instead of derived::myfunc.....oww, my head really hurts now...). And since tovbase is a pointer to a vbase type but holds the address of a vderived type, it is doing the same thing. But since vbase has it''s method declared as virtual, when tovbase->myfunc is called, it''s overridden(?) and you get the print out of vderived::myfunc, instead of vbase::myfunc as before (since the pointer is actually holding the address of a vbase type).
Wow, that took me like 30 minutes to get through my head...and I''m still not sure if I really understand it.
If what you said is any indication, then yes, you do. It''s not usually something you''ll "try" to understand. You''ll use it one day and expect it to work that way, it won''t, and then you''ll add the virtual keyword, and then it will seem extremely natural to you to do it this way. Or you could write an abstract base class, and realize that doing so is essentially useless or worse, nonsensical, if this was not the behavior.
quote:
Oluseyi-
I''m still trying to get a handle on your code for the UnitAggregation. Does the Unit::SignalAddedtoAggregation method mark that the Unit class has been...hmm, searching for words here...."joined" to the UnitAggregation? Part of my trouble is I forgot what the this-> pointer is (is it a pointer to the default constructor?), and I''m not familiar with the std::list standard C library function. Can you explain what''s going on for a neopphyte programmer?
The this pointer points to the object calling it. It''s pretty useless except when you''ve got an argument to a member function that has the same name as a member variable of the class to which the function is a member as well. Then, the compiler doesn''t know whether you''re talking about the argument or member variable, so it just assumes you''re talking about the argument. So you have to use this->a = a to show that you want to assign the member variable to the argument of the member function. Also sometimes used as a more pleasant alternative to prefixing all member variables with m_, so you get the same benefit, but only have to write it once per function. Also useful when you need to pass a pointer to the calling instance to an outside function inside one of the instance''s member functions.
The std::list function is just a container(you can think of it as a sort of glorified array the size of which can vary as you push_back() more variables onto the array). Not to be nitpicky, but it''s part of the standard template library, which is, IIRC, part of the standard C++ library(not the standard C library).
Basically, a unit hands off its stuff to the unit aggregation when it dies. The unit aggregation may or may not have a visible analog; there isn''t enough code to say for sure. It could be a purely abstract concept used to store ammo for the dead, or it could be a platoon, and the platoon gets use(in the programming sense; not necessarily given to an arbitrary unit within the platoon for their use, but the platoon code could decide to do so, or to just leave it there until the platoon is completely destroyed(forgotten equipment disappears?).) of the dead unit''s ammo.
quote:
P.S. how do you guys add the code snippets into the post? What tags do you use?
We use the source tag, square bracketed in a manner similar to the code and/or quote tags. Please don''t use it for short and/or few lines of code. Having a 400 pixel tall ugly iframe where I could see a 10 pixel tall line of code is annoying.
It''s technically in the faq, but the faq isn''t very well written, so it''s somewhat difficult to find.
ython), and Ruby seems positively superfluous. Of course, some people say that about Python, with respect to Perl.
