Original Post
📌 Pinned
🔒 Locked
C# Workshop - Week 2 (Ch. 5 - 6)
Advertisement
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?
Yes you must call the base constructor for the base constructor to get used, it is called constructor chaining. All other ones as long as they are protected or public can be called in the inherited class. Private members of the base class are still not accessible by the inherited class.
theTroll
theTroll
When will the exercises be coming?
Helo JWalsh,
Just wanted to drop a message and thank you for all the hard work.
I currently have only one question...
Are there going to be any best practices type suggestions, such as organization of cs files etc in a project. I'm a C/C++ programmer and so I'm inclined to seperate functional units into seperate cs files. This is still a good practice right ??
J
Just wanted to drop a message and thank you for all the hard work.
I currently have only one question...
Are there going to be any best practices type suggestions, such as organization of cs files etc in a project. I'm a C/C++ programmer and so I'm inclined to seperate functional units into seperate cs files. This is still a good practice right ??
J
[opinion]
My preference is one file per class. With a few exceptions to the rule. If I have an exception class for a class then I normally keep the exception class and the class in a single file. If I have a struct that is only used with a single class then I will put it in the class file.
I also always name the .cs file after the class. That way I can glance at the .cs files and know which ones are which.
I have a habit about reusing classes from project to project, so that helps a lot to have well named single class files.
theTroll
[/opinion]
My preference is one file per class. With a few exceptions to the rule. If I have an exception class for a class then I normally keep the exception class and the class in a single file. If I have a struct that is only used with a single class then I will put it in the class file.
I also always name the .cs file after the class. That way I can glance at the .cs files and know which ones are which.
I have a habit about reusing classes from project to project, so that helps a lot to have well named single class files.
theTroll
[/opinion]
People are welcome to post "best practices" questions. I only ask that people answering those put the answer in [opinion] tags, so that readers understand that while "best practices" may not be hard, fast rules by nature, they are also highly subjective.
My understanding or rules for "best practices" may not be the same as someone elses. We've all got different educations and backgrounds.
[opinion]
I, however, tend to separate code into 1 class per .cs file whenever possible. It makes it easier to find code when you need it by simply heading to the appropriately named file.
For enums or structs its more flexible. I generally have 1 file for all of my enums, and I tend to store structs in the same file as their primary handlers.
[/opinion]
Also, Microsoft has a C# style Guideline online which covers many style and organizational topics of the language. You can find it Here.
My understanding or rules for "best practices" may not be the same as someone elses. We've all got different educations and backgrounds.
[opinion]
I, however, tend to separate code into 1 class per .cs file whenever possible. It makes it easier to find code when you need it by simply heading to the appropriately named file.
For enums or structs its more flexible. I generally have 1 file for all of my enums, and I tend to store structs in the same file as their primary handlers.
[/opinion]
Also, Microsoft has a C# style Guideline online which covers many style and organizational topics of the language. You can find it Here.
While attempting to set my console title I received the following error (using Ubuntu//MonoDevelop):
Am I missing a certain file?
Here is my code:
[Task:File=/home/matt/workshop/workshop/Main.cs, Line=9, Column=2, Type=Error, Description=`System.Console' does not contain a definition for `Title'(CS0117)Am I missing a certain file?
Here is my code:
using System;//Read up on:// - namespacesclass Program{ static void Main() { Console.Title = "TEST"; string welcomemessage = "Welcome to The C# Maze Generator Program"; Console.WriteLine(welcomemessage); }}Quote:
Original post by Gallivan
While attempting to set my console title I received the following error (using Ubuntu//MonoDevelop):
Am I missing a certain file?
Last I checked, .NET 2.0 was sketchy at best on unixlikes. Console.Title was added with 2.0
I actually switched my Runtime from 1.1 to 2.0 and it compiled without error, however the console title set as:
workshop.exe ;echo; read -p 'Press any key to continue'...
This is all to due with Linux, or did I miss some sort of library download?
workshop.exe ;echo; read -p 'Press any key to continue'...
This is all to due with Linux, or did I miss some sort of library download?
Hi, i know this workshop has ended but I was just wondering if anyone could clear up some of my questions regarding Chapter 5.
Quoting from page 27:
But you can‘t have assignment statements outside of methods. This code doesn‘t compile at all:
class Program
{
static string strDisplay;
strDisplay = "Hello, Microsoft .NET Framework";
static void Main()
{
System.Console.WriteLine(strDisplay);
}
}
The compiler error message is "Invalid token '=' in class, struct, or inter-face member declaration," meaning that when the C# compiler was parsing the program, everything appeared OK until it got to the equal sign.
You can use the same name for fields and local variables:
class Program
{
static string strDisplay = "This is a field";
static void Main()
{
string strDisplay = "This is a local variable";
System.Console.WriteLine(strDisplay);
}
}
I do not understand how in the first example assigning a value to strDisplay outside Main is not valid but in the 2nd example it is also assigning a value but it is still valid.
Could someone explain this to me, thanks in advance
Quoting from page 27:
But you can‘t have assignment statements outside of methods. This code doesn‘t compile at all:
class Program
{
static string strDisplay;
strDisplay = "Hello, Microsoft .NET Framework";
static void Main()
{
System.Console.WriteLine(strDisplay);
}
}
The compiler error message is "Invalid token '=' in class, struct, or inter-face member declaration," meaning that when the C# compiler was parsing the program, everything appeared OK until it got to the equal sign.
You can use the same name for fields and local variables:
class Program
{
static string strDisplay = "This is a field";
static void Main()
{
string strDisplay = "This is a local variable";
System.Console.WriteLine(strDisplay);
}
}
I do not understand how in the first example assigning a value to strDisplay outside Main is not valid but in the 2nd example it is also assigning a value but it is still valid.
Could someone explain this to me, thanks in advance
Hi SpiderPig. The problem with your code is that you want to make a value assignment outside a method. The second example is treated as initialization of the variable and not as an assignment.
[Edited by - Razvan1024 on October 9, 2007 4:18:30 AM]
[Edited by - Razvan1024 on October 9, 2007 4:18:30 AM]
Topic Locked
This topic has been locked by a moderator. New replies are not allowed.
Sign in to reply to this topic.
Advertisement