Page 1 of 1

More C++

PostPosted:Fri Jul 01, 2005 1:32 am
by Nev
I ought to be posting this on the BREW forums, but Kup is really good...of course I will sycophantically beg help from anyone who can answer... :) Besides, it's a general C++ question...

Are all constructors implicitly virtual?

I didn't think they were, but my base class constructor was getting implicitly called when its derived class's was.

And to add dumbassity to insult, when I *was* trying to call the base class constructor explicitly, it worked in MSVC++, but the ARM compiler apparently doesn't like it and crashes the phone.

PostPosted:Fri Jul 01, 2005 2:07 am
by Nev
And on the same note...

I am uber mack. I have programmed my own floating point class for our game, because ARM processors have no native floating point support. I actually had no idea that writing efficient floating-point routines was such a complex task. Holy awesome ass programmer, Batman...

A WINNER IS ME!!!!!!

EDIT: Sigh...if Kup wasn't a regular poster here, I might not even sound conceited... :)

PostPosted:Fri Jul 01, 2005 4:20 am
by SineSwiper
ARM processors have no floating point? Wow...those things suck.

Re: More C++

PostPosted:Fri Jul 01, 2005 10:28 am
by Kupek
Mental wrote:Are all constructors implicitly virtual?

I didn't think they were, but my base class constructor was getting implicitly called when its derived class's was.
Virtual, no, but they certainly get called.

A virtual function means that you call a member function that is defined in an interface, and at run time, the correct member function for the actual object that is referred to is called. This can never happen with a constructor because there is never any question, at compile time or at runtime, which is the correct member function. If I create a new <TT>thingy</TT> object, one of its constructors must be called.

However, if the object you're constructing is part of an inheritance hierarchy, then the constructor for each class it derives from (all the way up the tree) is called. This behavior is different from a virtual function because we call <i>all</i> of them, not just choosing one. It's also well defined what order they're called in: base class constructors first.

This order is necessary because an object from a class that is part of an inheritance hierarchy can be thought of as containing objects from its base classes. So when you construct the object from its derived class, it must first construct the base object(s) before it can construct the object itself. This order is consistent with the rules that members of an object are constructed before the object itself.
SineSwiper wrote:ARM processors have no floating point? Wow...those things suck.
They don't suck; they're embedded processors designed to work in a much more constrained environment than general purpose processors. Floating point operations are not needed to operate a cell phone, hence, it's not part of the design. Mental's job requires him to use this platform in a way that it was not originally designed for, so he has to find creative ways around those shortcomings.

PostPosted:Fri Jul 01, 2005 1:29 pm
by Nev
That is quite the good way to explain it. Since all inherited classes must contain the data contained in their base class, and the constructor is almost always used for data member initialization, it makes sense that all the constructors would have to be called.

I actually use that behavior a lot in member functions as well, believe it or not - calling base class functions first, then the derived class version of that function. For example, a general GameObject::Update(int ticksToUpdate) might be called within GenericEnemy::Update(int ticksToUpdate) - the first one does the necessary processing on the GameObject-level data, then the second does the processing on the GenericEnemy-level data. Is there a word to describe this in formal CS terms?

By the way, Kup, are you planning to become a professor?

PostPosted:Fri Jul 01, 2005 3:52 pm
by Kupek
Mental wrote:That is quite the good way to explain it. Since all inherited classes must contain the data contained in their base class, and the constructor is almost always used for data member initialization, it makes sense that all the constructors would have to be called.
Always used, actually. But it also makes sense from a data-hiding perspective. When you inherit from a class, its private members are still private to you. The only way you can interact with your base class(es) are through its (their) public and protected members. So its necessary for the base constructor to be called, because you're not allowed to touch the private members.
Mental wrote:I actually use that behavior a lot in member functions as well, believe it or not - calling base class functions first, then the derived class version of that function. For example, a general GameObject::Update(int ticksToUpdate) might be called within GenericEnemy::Update(int ticksToUpdate) - the first one does the necessary processing on the GameObject-level data, then the second does the processing on the GenericEnemy-level data. Is there a word to describe this in formal CS terms?
It's a common technique, but I'm not aware of any agreed-upon term to describe it.
Mental wrote:By the way, Kup, are you planning to become a professor?
It's a serious consideration. Basically, with a Ph.D., your choices are academia or industry. I'd like to teach, but the grant system that academics use to fund research is painful. Then again, industry has less research freedom, and of course, no teaching. I have been a lab TA for our introduction to programming course, and I enjoyed it immensely. The best compliment I got was two different students told me they didn't learn anything until they came to lab (lecture wasn't helping).

PostPosted:Fri Jul 01, 2005 7:45 pm
by Nev
You could be a prof at a smaller teaching college...

A good academic institution will probably find ways to fund your research, if that's important to you, especially if you can prove you can give back by doing a great job teaching. There was a teacher at my high school who did physics research on the side, for crying out loud. You could always go look around and shop schools to apply to for an assistant or associate professorship, and once you're there, I have no doubt that if you master all aspects of teaching (your explanations to me have always been incredibly clear, which is not something I've really found in CS teaching that often), both you and your institution would find it incredibly rewarding.

Seriously. I think we need more good CS teachers. If I get this game sold, I will probably go back to my high school and offer to guest-lecture in one of my old CS classes, just because 1. I've learned so much doing it, and 2. I think teaching can be one of the most rewarding professions there is.