Here's the best explaination of interfaces that I've ever recieved:

"Interfaces define behavior while classes implement behavior."

Simple, to the point, and easy to remember. For a little bit more of an explaination (while still trying to keep it simple), an interface will guarantee that an object can do something while the class that implements that interface can do that something any way it wants to.

And abstract classes do what?

edit: well on to Chapter 2...

edit2: since I can't make a thread here. Are we during this Workshop going to talk about functors? Or should there be a Data Structure Workshop for that?

Quote: Original post by Alpha_ProgDes
And abstract classes do what?

It's a class that you can't instantiate, but you can inherit from it. Think of it as an interface that can't be multiply inherited, but it can have method definitions and other fields.

Just came across this little bit (page 44, chapter 2.5.1):

Quote: An implication of this is that #define and #undef directives in one source file have no effect on
other source files in the same program.

Does this mean that the C++ style encapsulating a source file in



to prevent the multiple inclusion of the same source file doesn't work?


Edit:

Never read chapter 2 before chapter 1 !

Quote: Because an assembly is a self-describing unit of functionality containing both code and metadata, there is no
need for #include directives and header files in C#.

[Edited by - Gyna on July 2, 2007 3:07:59 PM]

From what I understand, C# doesn't need inclusion guards to prevent multiple inclusion of a source file. It does it automagically.

Quote: Original post by Alpha_ProgDes
From what I understand, C# doesn't need inclusion guards to prevent multiple inclusion of a source file. It does it automagically.

Correct. C# doesn't need "include" statements like C++, because meta-data is generated which helps the compiler determine where symbols are located. Since there are no "includes" there is no need for include guards.

2.5.1 in the specification is talking about the #if, #elif, #else, and #endif pre-processing directives which are used for conditional compilation. That is, for determining what parts of a source file will be compiled based on symbols which are either defined within the file, or externally via a compiler option.

To define symbols within a single file you use the #define and #undef pre-processing directives. All they are stating in the quote you provided is that if you use #define to define a symbol within a source file, that symbol will only be defined within THAT source file. If you want the symbol to be defined in other source files, you must use compiler flags.

In C++ people used conditional compilation as a way to avoid circular inclusions. In C# this isn't necessary, so people can use conditional compilation for the purpose in which it was intended.

Cheers!

JWalsh (or anybody who knows) could you clear up virtual functions, abstract classes and interfaces. I'm getting confused about them just as password was about ref and out.

Quote: Original post by Alpha_ProgDes
JWalsh (or anybody who knows) could you clear up virtual functions, abstract classes and interfaces. I'm getting confused about them just as password was about ref and out.

Are you familiar with C++'s virtual? What languages are you familiar with?
It's the kind of question that is easier to answer if I can use other language's concepts.

This is an abstract class in C++, correct?
And an interface in C++ would have virtual void foobar()=0 for all functions.

Quote: Original post by Alpha_ProgDes
JWalsh (or anybody who knows) could you clear up virtual functions, abstract classes and interfaces. I'm getting confused about them just as password was about ref and out.

The virtual keyword in C# is used to indicate that a method may be re-implemented by an inheritor. If you have a reference to a class Foo, the actual instance referred to may be Foo or anything that inherits from Foo. Calling Foo.Method() will execute Foo.Method() if virtual [edit: or abstract] is not specified. Otherwise it will progress along the inheritance tree and execute the "most derived" implementation of Method() it can find. In practical terms, that means the Method() of whatever class is actually referred to (which inherits, but is not necessarily... Foo)

As I mentioned earlier, Interfaces are a compromise for not allowing multiple inheritance. They allow a subset of what a class is; the subset that allows them to be unambiguously multiply inherited. They allow methods, properties, events, and indexers. Which means they don't allow actual variables, delegate definitions, actual implementations, or non-public anything.

Interfaces are used when you need a type which gives you access to call a few common methods, but don't particularly care what you're calling.

Abstract Classes are classes which are not complete. They allow everything a class does except the ability to instantiate them. Thus you can supply variables, method implementations, non-public stuff, and delegate definitions. The catch is that you cannot multiply inherit them like you can with interfaces.

Quote:
Are we during this Workshop going to talk about functors?

I can't imagine going through the chapter on delegates without at least discussing the concept of classes whose sole purpose is to tie data to a method.