🎉 Celebrating 25 Years of GameDev.net! 🎉
Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!
C# Workshop - Week 2 (Ch. 5 - 6)
As I will be out of town from Tomorrow afternoon until Tuesday, I wanted to go ahead and post the chapter thread for week 2 now. I will be filling in the overview and exercises for week 2 from my laptop as I get them finished - and get access to the internet.
great Job man, i have been having a lot of fun getting into c#. I hope your weekend goes fine and i will be waiting for this weeks assignments ;)
Awesome Jeromy, thanks a lot! I'll definitely read through the material, but the review questions are scaring me... 100? That's double week one! >_>
Variables are a large topic, and one that should be completely understood before moving on to anything else. Without a good foundation with variables, you will be way over your head with the rest of the stuff.
However, if you have done programming in another language, this chapter should probably be pretty easy for you. There are several nuances to C# variables, but for the most part they behave like other languages.
I would also like to applaud JWalsh for the amazing amount of work he is doing writing out these overviews, organizing the whole thing, and writing review questions. I know I wouldn't have the time to do it!
However, if you have done programming in another language, this chapter should probably be pretty easy for you. There are several nuances to C# variables, but for the most part they behave like other languages.
I would also like to applaud JWalsh for the amazing amount of work he is doing writing out these overviews, organizing the whole thing, and writing review questions. I know I wouldn't have the time to do it!
I had to be away from my computer for five days so I thought I would've had to play catchup for a while. Didn't have any idea you would delay week 2, guess I caught a break there. :D
So what happens to the inherited declarations anyways? Does the declaration space for the inherited class get a copy of all its base class declarations, or are you essentially calling base.Member everytime you use a base class's members?
Quote:
Note that base classes do not contribute to the declaration space of a class, and base interfaces do not contribute to the declaration space of an interface.
So what happens to the inherited declarations anyways? Does the declaration space for the inherited class get a copy of all its base class declarations, or are you essentially calling base.Member everytime you use a base class's members?
The derived class does receive a "copy" of sorts of all methods and variables from the base class. The only time you need to use the base keyword is when you are overriding a base class's property or method, and you want to call the base class's implementation.
Quote: Original post by Menace2Society
I had to be away from my computer for five days so I thought I would've had to play catchup for a while. Didn't have any idea you would delay week 2, guess I caught a break there. :DQuote:
Note that base classes do not contribute to the declaration space of a class, and base interfaces do not contribute to the declaration space of an interface.
So what happens to the inherited declarations anyways? Does the declaration space for the inherited class get a copy of all its base class declarations, or are you essentially calling base.Member every time you use a base class's members?
The inherited class uses the base class public and protected methods and members as long as it has not overridden or hid the methods. This is done without the programmer having to explicitly call the base class method. It does not really get a "copy" of the methods. It just calls the base class methods.
theTroll
Quote: So what happens to the inherited declarations anyways? Does the declaration space for the inherited class get a copy of all its base class declarations, or are you essentially calling base.Member everytime you use a base class's members?
You are indirectly calling base.Member every time you use a base class's member - well, a base class's methods, anyways. Fields are a bit different.
You see, programming languages such as C++ and C# use something called a Dispatch Table or Virtual Table (vtable for short). This vtable is a hidden member of all classes which holds the addresses to each of the dynamically bound methods of the class. In this way, every object of a related type shares a similar vtable and the memory required to store a method's implementation isn't duplicated.
Whenever you inherit from a base class the public, protected, and private fields are added to the classes scope and internal layout, while methods, indexers, etc...are added to the derived class's vtable.
It's important, however, to keep in mind the distinction between a member's declaration space and a member's scope. You see, scope simply defines where a member is accessible without requiring qualification.
When you inherit a base class, the derived class's scope is increased to include the members of it's base class. In this way it can refer to those members directly. Meanwhile, the members of the base and derived class remain in separate deceleration spaces. This means it is not possible to add members to a base class from within a derived class. It also means that you can create members in the derived class with the same name as members in the base class, thus allowing for name hiding. (See section 3.7.1 for more info on Name Hiding)
So to summarize, scope is increased in the derived class to include the base class, this allows for referring to the base classes members by name. The fields of the base class are added to the derived class, while methods, indexers, properties, etc...are added to the derived class's virtual table. Even though scope has increased, the deceleration space remains distinct, thus allowing for name hiding.
Cheers!
Quote: Original post by TheTroll
The inherited class uses the base class public and protected methods and members as long as it has not overridden or hid the methods. This is done without the programmer having to explicitly call the base class method. It does not really get a "copy" of the methods. It just calls the base class methods.
theTroll
Okay so if this is the case, then what does it really mean to say that a constructor isn't inherited but everything else is? Since to access any inherited class members you'd have to call on the base class, does that mean the only real difference is you have to explicitly call a base class constructor while every other element is accessed implicitly?
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement