boolean vs logical operators

This is a subject that has never been entirely clear in my mind.  What is the difference between boolean and logical operators?

Well, it can be subtle.  With a boolean you can perform "and" operations and you can also use "and" as a logical operator.  The results of both types of operations are frequently used in a similar fashion.

A boolean AND essential tests two boolean statements and returns true if both are true.

A logical AND typically takes two (or more) bytes or words and through the action of comparison returns a value of the same type with all one bits set where bits of both operands are one, and zeros corresonding bits are not the same.

In C# the boolean operator for AND is && while the logical operator for AND is &.  The use of similar symbols tends to add to the confusion.

It seems obvious that true && true == true.  Is it also true that true & true is true?

This code demonstrates that the answer is yes!

if (true && true)
 Console.WriteLine("\n{0} and {1} == {2}", true, true, true && true);

if (true & true)
 Console.WriteLine("\ntrue & true = {0}", true & true);

Try it.

interfaces

A C# class can inherit directly from only one class, which of course can inherit from others.  A C# class cannot inherit directly from more than one class.

The workaround for this is C# interfaces.  A class can inherit from more than one interface.

interface is a keyword that would replace the word class in what resembles an abstract class definition.  All methods declared in an interface are abstract by default.

This means that in an interface the methods are only defined with a method header, such as int myMethod(int myInt).

Data members can be included but the values must be assigned or retrieved with get and set properties.  The compiler will generate an error (for example, Interfaces cannot contain fields), if you try to create the same way you would create class variables.  Thus, something like  int myInt;  won't fit into a interface definition but int myInt { set; get; } will.

I could be wrong, but it appears that you can't really store anything in myInt when you define it as part of the interface.  You will have to create a variable in the class defintion that inherits from the interface if you want to store a value in an object.

I wish I understood the reasons for this approach to multiple inheritance.  I'm going to guess that it was a compromise between flexibility and compiler efficiency.

Delegates

This post is just notes I am taking from Day 13 in Teach Yourself C# in 21 Days regarding the introduction to delegates in the chapter titled "Making Your Program React with Delegates, Events, and Indexers"

This is a quote from p 445:  "A delegate is a reference type that defines the signature for a method call.  The delegate can then accept and execute methods that are of the same format as this signature."

In the example program provided for this section, the author  creates a function header within a class.  The header looks like this:

public delegate void Sort(ref int a, ref int b);

Note also that the delegate has no body within its class.

In addition, another method is defined in the same class:

public void DoSort(Sort ar)
{
    ar(ref val1, ref val2);
}

It appears that DoSort is going to be assigned

Further down, another class is defined that includes only two methods, both of which have similar definitions to the delegate Sort definition above and both of which include functioning code, in this case some simple testing and swapping.

The headers differ in that where Sort says delegate, the new class function say static and where Sort says Sort, the new class functions supply their own names.  Also the names of the reference parameters are changed.

Here is one of the two method headers defined in a public class called SortProgram

public static void Ascending( ref int first, ref int second)

The methods are void because the arguments are physically swapped as a result of being reference types and that's how the values are returned.

As with many other OOP features, the use of the delegate is not a self evident operation at all.  To use the delegate functions you need to instantiate the delegate objects.  Here's how the author does it:

Sort up = new Sort(Ascending);

Although this creates an object, the object is not doing an any work.  To put the object to work, it must be called by a class object of the type that defines the delegate.  In this case, the class that defines the delegate is called SortClass.  It is instantiated (SortClass doIT = new SortClass; and initialized SortClass.val1 = 310... and the actual sort is called as a class method in the form doIT.DoSort(up).  Seems overly complicated...

If you were to do this without delegates, you probably might need two methods in the main class definition.

The author assets "You could actually get around declaring a doIT object in Line 46 by declaring the DoSort method as static.  The DoSort method could then be accessed using the class name instead of an object:  SortClass.DoSort(...);" 

As an aside here, this technique or trick is presented in an abbreviated form considering the difficulty of the concept and complications of the presentation.  The discussion of the features seems to continue in the next section

About this blog

I'm trying to build some credibility as a C# programmer and so I'm creating this blog for the world to see.  I plan to include comments, notes, and observations about my progress in learning C#.  I will include snippets, not necessarily written by me, and short exercise programs or excerpts therefrom as examples and for discussion.

I'm learning C# from a book called SAMS Teach Yourself C# in 21 Days by Bradley L. Jones.  I am now past the halfway point, just beginning Day 12, a chapter called Tapping into OOP: Interfaces.

I am also practicing what I have learned with supplemental problems from TopCoder.com.

I'm coming at this subject from the standpoint of someone whose primary and favorite computer language is Python.  I wish I could say I am a Python Professional but in truth at the moment I'm just a enthusiast.  I will be keeping a separate blog on my progress in continuing to learn Python as well.