Archive

Archive for December, 2005

What are the best development books?

December 29, 2005 Leave a comment
Picked up a thread on the MSDN blogs here. It is definitely Worth a read.
The book list summarized:
I should spend some time to update my favourites list with the great books from this list. 

Sl No. Title Author Publisher
1 Writing Solid Code: Microsoft’s Techniques for Developing Bug-Free C Programs Steve Maguire Microsoft Press
2 "Code Complete: A Practical Handbook of Software Construction , Second Edition " Steve McConnell Microsoft Press
3 The Pragmatic Programmer: From Journeyman to Master "Andrew Hunt, David Thomas" Addison-Wesley Professional
4 How Would You Move Mount Fuji? Microsoft’s Cult of the Puzzle – How the World’s Smartest Company Selects the Most Creative Thinkers William Poundstone "Little, Brown"
5 Programming .NET Components Juval Lowy O’Reilly
6 Rapid Development Steve McConnell Microsoft Press
7 The Career Programmer: Guerilla Tactics for an Imperfect World Christopher Duncan Apress
8 .NET-A Complete Development Cycle "Gunther Lenz, Thomas Moeller" Addison-Wesley Professional
9 Practical Software Engineering : Analysis and Design for the .NET Platform Enricos Manassis Addison-Wesley Professional
10 "Software Requirements, Second Edition " Karl E. Wiegers Microsoft Press
11 Coder to Developer: Tools and Strategies for Delivering Your Software Mike Gunderloy Sybex
12 Writing Effective Use Cases Alistair Cockburn Addison-Wesley Professional
13 Refactoring: Improving the Design of Existing Code "Martin Fowler, Kent Beck, John Brant, William Opdyke, Don Roberts " Addison-Wesley Professional
14 Test-Driven Development in Microsoft .NET "James W. Newkirk, Alexei A. Vorontsov" Microsoft Press
15 Programming Interviews Exposed: Secrets to Landing Your Next Job "John Mongan, Noah Suojanen" Wiley
16 "Peopleware : Productive Projects and Teams, 2nd Edition" "Tom Demarco, Timothy Lister " Dorset House
17 Dynamics of Software Development Jim McCarthy Microsoft Press
18 Clouds to Code Jesse Liberty Peer Information
19 "Writing Secure Code, Second Edition" "Michael Howard, David C. LeBlanc" Microsoft Press
20 Applied Microsoft .NET Framework Programming Jeffrey Richter Microsoft Press
21 Programming Microsoft .NET Jeff Prosise Microsoft Press
22 Effective Java Programming Language Guide Joshua Bloch Addison-Wesley Professional
23 Debugging by Thinking : A Multidisciplinary Approach (HP Technologies) Robert Charles Metzger Digital Press
24 Design Patterns: Elements of Reusable Object-Oriented Software "Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides " Addison-Wesley Professional
25 Patterns of Enterprise Application Architecture Martin Fowler Addison-Wesley Professional
26 Debugging Applications for Microsoft .NET and Microsoft Windows John Robbins Microsoft Press
27 Programming Applications for Microsoft Windows Jeffrey Richter Microsoft Press
28 Programming Server-Side Applications for Microsoft Windows 2000 "Jeffrey Richter, Jason D. Clark " Microsoft Press
29 "Inside Microsoft Windows 2000, Third Edition" "David A. Solomon, Mark E. Russinovich " Microsoft Press
30 "Programming Windows, Fifth Edition " Charles Petzold Microsoft Press
31 Transactional COM+: Building Scalable Applications Tim Ewald Addison-Wesley Professional
32 "Debugging the Development Process: Practical Strategies for Staying Focused, Hitting Ship Dates, and Building Solid Teams " Steve Maguire Microsoft Press
33 Managing Transitions: Making the Most of Change William Bridges Perseus Books Group
34 Software for Your Head: Core Protocols for Creating and Maintaining Shared Vision "Jim McCarthy, Michele McCarthy " Addison-Wesley Professional
35 "Programming Pearls, 2nd Edition" Jon Bentley Addison-Wesley Professional
36 How to Break Software: A Practical Guide to Testing James A. Whittaker Addison Wesley
37 The Inmates Are Running the Asylum : Why High Tech Products Drive Us Crazy and How To Restore The Sanity Alan Cooper Sams
38 "Enterprise Development with Visual Studio .NET, UML, and MSF " "John Erik Hansen, Carsten Thomsen " Apress
39 Practical Software Requirements: A Manual of Content and Style Benjamin L. Kovitz Manning Publications
40 The Guru’s Guide to Transact-SQL Ken Henderson Addison-Wesley Professional
41 "Unified Modeling Language User Guide, The, 2nd Edition" "Grady Booch, James Rumbaugh, Ivar Jacobson" Addison-Wesley Professional
42 Thinking Like An Entrepreneur: How To Make Intelligent Business Decisions That Will Lead To Success In Building And Growing Your Own Company Peter I. Hupalo HCM Publishing
43 Software Project Survival Guide Steve C McConnell Microsoft Press
44 Advanced .NET Remoting Ingo Rammer Apress
45 Waltzing With Bears: Managing Risk on Software Projects "Tom Demarco, Timothy Lister " Dorset House
46 Peer Reviews in Software: A Practical Guide Karl E. Wiegers Addison-Wesley Professional
47 "Professional Software Development: Shorter Schedules, Higher Quality Products, More Successful Projects, Enhanced Careers " Steve McConnell Addison-Wesley Professional

So many books to read, Hmmm…

Advertisements
Categories: Great Links

Microsoft EMEA Architect Workshop Presentations

December 28, 2005 Leave a comment
You can download the prestations from Microsoft EMEA Architect Workshop here
Great presentations
 
Categories: Great Links

‘Boxing’ and Unboxing

December 28, 2005 1 comment

‘Boxing’ and Unboxing

 

Boxing is the mechanism by which a value type is converted to a reference type.  

 

What happens during boxing?

  •       Memory is allocated from the managed heap. The amount of memory allocated is the size the value type requires plus any additional overhead to consider this value type to be a true object. The additional overhead includes a method table pointer and a SyncBlockIndex.
  •       The value type’s fields are copied to the newly allocated heap memory.
  •       The address of the object is returned. This address is now a reference to an object; the value type is now a reference type.

 

‘Unbox’ing is the mechanism by which you get a pointer to raw value type (data fields) contained within a reference type. A unbox IL instruction doesn’t copy the fields to the value type.  So an unbox will typically be followed by a copy.

 

What happens during ‘Unbox’ing?

 

  •       If the reference is null, a NullReferenceException is thrown.
  •       If the reference doesn’t refer to an object that is a boxed value of the desired value type, an InvalidCastException exception is thrown.
  •       A pointer to the value type contained inside the object is returned. The value type that this pointer refers to doesn’t know anything about the usual overhead associated with a true object: a method table pointer and a SyncBlockIndex. In effect, the pointer refers to the unboxed portion in the boxed object.

 

Let’s say that in a piece of code you want to grab the first element out of the ArrayList:

Point p = (Point) a[0];

 

Here you’re taking the reference (or pointer) contained in element 0 of the ArrayList and trying to put it into a Point value type, p. For this to work, all the fields contained in the boxed Point object must be copied into the value type variable, p, which is on the thread’s stack. The CLR accomplishes this copying in two steps. First the address of the Point fields in the boxed Point object is obtained. This process is called ‘Unbox’ing. Then the values of these fields are copied from the heap to the stack-base value type instance.

 

‘Unbox’ing is not the exact opposite of ‘box’ing. The ‘Unbox’ing operation is much less costly than ‘box’ing. ‘Unbox’ing is really just the operation of obtaining a pointer to the raw value type (data fields) contained within an object. So, unlike ‘box’ing, ‘Unbox’ing doesn’t involve the copying of any bytes in memory. However, an ‘Unbox’ing operation is typically followed by copying the fields, making these two operations the exact opposite of a ‘box’ing operation.

 

A scenario

Assume we have a value type:

public class ComplexNumber

{

            private double real;

            private double imaginary;

            public double Real

            {

                        get { return real; }

                        set { real = value; }

            }

            public double Imaginary

            {

                        get { return real; }

                        set { imaginary = value; }

            }

 

            public override void ToString()

            {

                        return   string.Format(“({0} + i{1})”, real, imaginary);

            }

}

 

public class Program

{

            public static void Main()

            {

                        ComplexNumber c = new ComplexNumber();

                        c.Real = 1;

                        c.Imaginary = 2;

                        Console.WriteLine(c.ToString());

                        Type t = c.GetType();

            }

}

 

How many ‘box’ing operations occur in the above code?

The ToString call doesn’t result in a box instruction. The GetType call results in a box instruction. Since the ComplexNumber provides an implementation to ToString and it cannot be overridden (complex number being a value type) the compiler makes a non virtual dispatch. Thus it doesn’t result in a box instruction.

The Complexnumber doesn’t provide and implementation for GetType and it is inherited from System.ValueType. To call this we need the MethodTable pointer and hence there is a box instruction.

Categories: .NET Framework

Pass by Value vs. Pass by Reference

December 27, 2005 2 comments

Pass by Value vs. Pass by Reference

Update:Fixed some errors pointed to by Manu.

I am sure we all know what it means to pass a parameter by value and by reference. Let us see an example of this, all I am trying to do is add another dimension to this – namely value types and reference types. 

Scenario 1:

public class Person

{

            private string name;

            private int age;

           

            public string Name

            {

                        get { return name; }

                        set { name = value; }

            }

 

            public int Age

            {

                        get { return age; }

                        set { age = value }

            }

}

 

public class Program

{

            public static void Main()

            {

                        Persona p = new Person();

                        p.Name = “Sendhil”;

                        p.Age = 28;

                        DoSomething(p);

                        // What is the value of p.Age

            }

            private static DoSomething(Person p)

            {

                        p.Age = 29;

            }

}

In this scenario, we have a reference type passed by value. Will the caller (Program.Main in our case) reflect the changes made to the parameter (Person instance p in our case) in the Callee (Program.DoSomething in our case)? The answer is yes.  What is the meaning of passing by reference for a reference type then? Let us see another scenario

Scenario 2:

public class Program

{

            public static void Main()

            {

                        Persona p = new Person();

                        p.Name = “Sendhil”;

                        p.Age = 28;

                        DoSomething(ref p);

                        // What is the value of p

            }

            private static DoSomething(ref Person p)

            {

                        p = new Person();

                        p.Name = “Sachin”;

                        p.Age = 29;

            }

}

 

What will be the value of p.Age in this case. The new call in the callee is local to the callee and is lost when the method returns. When we need the ability to assign a new instance to a reference type we need to pass it by reference.

 To conclude

When we pass a parameter by reference a pointer to the actual value is passed rather the actual value. In case of reference types passed by value the object handle gets passed (scenario 1) and in case of reference types passed by reference a pointer to the handle gets passed (scenario 2). Thus when you pass a reference type by reference you can reinitialize the handle and the caller gets affected.

Categories: .NET Framework

Value Types and Reference Types

December 27, 2005 3 comments

Value Types and Reference Types

Value Types

Value types have value semantics, meaning what you have is the value.

int i = 3; means the value of 3 is stored in the variable i.  Examples of value types include in built data types like int, double, float, datetime etc (barring string, delegate). Examples user-defined value types include enums and structures. All value types inherit from System.ValueType either directly or indirectly. Value types are sealed by default, you cannot inherit a value type from another value type. Value type methods cannot be virtual or abstract. Value types cannot have finalizers. Value types cannot have a user-defined default constructor.

 

Reference Types

Reference types store a reference to the actual value.  For example

public class Person

{

            private string name;

            private int age;

           

            public string Name

            {

                        get { return name; }

                        set { name = value; }

            }

 

            public int Age

            {

                        get { return age; }

                        set { age = value }

            }

}

 

public class Program

{

            public static void Main()

            {

                        Persona p = new Person();

                        p.Name = “Sendhil”;

                        p.Age = 28;

                        Person anotherPerson;

                        anotherPerson = p;

                        anotherPerson.Age = 29;

            }

}

Person is reference type. p and anotherPerson are references to the person instance. In this case both p and anotherPerson point to or refer to the same person instance on the heap.  Built-in types like string, delegate and user-defined types like classes, interfaces are examples of reference types. Reference types are always allocated on the Heap.

 

Common Mis-conception

There is always a misconception like value types are always allocated on the stack. This is not true. Value types cannot be allocated as distinct entities on the CLR heap never-the-less or however, value types can be allocated on the heap in the following circumstances:

  • An array of value types
  • A member variable on a reference type

A value type is allocated on the stack when it is a local variable (declared within a method).

What about a reference type which is a local variable. The reference (the object handle) is allocated on the stack whereas the actual object instance is allocated on the heap.

 

A weird scenario

What will be the case when a value type implements an interface? We all know that interface is a reference type. Suppose my struct implements an interface. How does this work? When you have a struct which implements an interface and you use the interface reference to call a method a box operation happens and the value type is boxed into a reference type and placed on the heap. (More on boxing and un-boxing later)

 

To summarize the differences:

 

Value Types

Reference Types

Directly store the value

A reference to the value is what you have.

Inherit directly or indirectly from System.ValueType

No such thing

Sealed

Not sealed unless specified

No virtual dispatch, no abstract methods

Virtual dispatch and abstract method support

No default constructors

Default constructor support

Cannot be allocated as distinct entities on the heap

Always allocated on the heap

Can’t have finalizers

Can have finalizers

Can’t be assigned to null

Can be null

 

 

Also value types and reference types have a slight difference when passed as parameters. We will see that in a separate article. Also we’ll see boxing and un-boxing in a separate article.

Update

A good write-up on the same topic:

Via Amit
 

Categories: .NET Framework

Delegates

December 27, 2005 3 comments

Delegates

Definition and Explanation of it

Delegates are often defined as Object Oriented Function Pointers. What the heck is this definition anyway? Let us dissect what each means. In a traditional procedural language like C, a function pointer is just a memory address where to begin execution. But when it comes to OO languages a memory address isn’t sufficient. Objects have both behavior as well as data. A function call doesn’t make sense unless we can associate it with the state of the object instance. In a procedural language all the state is passed as parameters. In an OO environment some of the state could be parameters, where as some could be instance state.

So to call a function in the OO world we need

  • the method address
  • the object instance handle or the this pointer

This is why a delegate is often referred to as an object oriented function pointer. Now you know what this definition really means.

 

Why do we need delegates?

A delegate is required for a call back or for an event handler. 

 

A call back is a case you provide someone with a function pointer / delegate and that someone calls you back. Assume you have cached some object (say it represents the configuration information stored in a file). Let us say the file changes and this object in cache is invalid. You need some way of reloading this object when this file changes. What you need to do is provide the framework with a function pointer / delegate and the framework will call you back when the file changes.

 

An event is a notification that occurs when something of concern happens. A good example of an event is a button click.

 

Event is sort of an anonymous broadcast in contrast to a callback which is a sort of handshake.

 

Example

Still not clear, well assume you are the author of a button control. You need to call user code when the button is clicked. The user could name his method anything and this method could belong to any class. How does Microsoft know what I am going to name my class and method? A delegate encapsulates the things needed for making the call into an object. What are the things needed for making this call?

  • Your type details like class name, this pointer etc (_target variable)
  • Your method details like method signature, address etc (_methodPtr variable)

How is a delegate implemented?

(Internals, skip this if you want)

When we declare a delegate what we actually do is define a class.

public delegate void ClickEventHandler(object sender, EventArgs e);

results in the compiler generating a class like this:

public class ClickEventHandler : MultiCastDelegate

{

            // Constructor

         public ClickEventHandler(Object target, Int32 methodPtr);

 

        // Method with same prototype as specified by the source code

        public void virtual Invoke(object sender, EventArgs e);

 

       // Methods allowing the callback to be called asynchronously

       public virtual IAsyncResult BeginInvoke(

       object sender, EventArgs e, AsyncCallback callback, Object object);

 

       public virtual void EndInvoke(IAsyncResult result);

}

 

The actual implementations of the methods are synthesized by the runtime. The CLR-synthesized Invoke implementation for IA-32 is simply an eight-instruction shim that replaces the ‘this’ pointer in ‘ecx’ register with that of the target object reference. The shim then jmps directly to the target method address. After the jmp occurs, the target method begins execution as if it were invoked directly by the caller. In fact, because the caller’s return address is still on the stack, the target method will return directly to the caller, bypassing the delegate machinery altogether. The shim used by the Invoke method is capable of working generically because the signature of the target method is guaranteed to match that of the Invoke method exactly. All this makes delegate based invocation slightly costlier than normal method invocation.

 

The multicast delegate provides chaining capability to delegates. The multicast delegate class inherits from the Delegate class and adds the chaining feature to delegates. The compiler does the dirty work of translating the delegate wiring (creation) and the delegate call to a dispatch to the invoke method.

 

Other trivia

Delegate is immutable. The same scenario can be handled using interfaces too. Microsoft can define an interface and you class has to implement the interface. Once you implement the interface Microsoft can call your code using the interface. This is the approach java takes as there is no in-built language support for delegates.

Further Reading

An Introduction to Delegates – Jeffrey Richter
http://msdn.microsoft.com/msdnmag/issues/01/04/net/default.aspx

Delegates, Part 2 – Jeffrey Richter
http://msdn.microsoft.com/msdnmag/issues/01/06/net/default.aspx

Implementation of Events with Delegates – Jeffrey Richter
http://msdn.microsoft.com/msdnmag/issues/01/08/net/default.aspx

The Truth About Delegates, Microsoft Answer to Sun’s whitepater on Delegates
http://msdn.microsoft.com/vjsharp/productinfo/visualj/visualj6/technical/articles/general/truth/default.aspx

Hejlsberg’s interview on C# Delegates and Components
http://www.artima.com/intv/simplexityP.html

About Type-Safety of Delegates
http://www.geocities.com/csharpfaq/delegates.html

Events vs Callbacks
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dncomg/html/msdn_evntvscb.asp

Categories: .NET Framework

Agile Development Conference

December 27, 2005 Leave a comment
Categories: Great Links