Pages
    Calender
    <<  March 2010  >>
    MoTuWeThFrSaSu
    22232425262728
    1234567
    891011121314
    15161718192021
    22232425262728
    2930311234
    Ajander Singh , Created On 7. March 2009, 05:29

    As you know, a variable of a value type can never be null; it always contains the value type's value itself. In fact, this is why they call value types value types. Unfortunately, there are some scenarios in which this is a problem.

    Examples:

    Case 1: When designing a database, it's possible to define a column's data type to be a 32-bit integer that would map to the FCL's Int32 data type. But a column in a database can indicate that the value is nullable. That is, it is OK to have no value in the row's column. Working with database data by using the Microsoft .NET Framework can be quite difficult because in the common language runtime (CLR), thereis no way to represent an Int32 value as null.

    Case 2:  In Java, the java.util.Date class is a reference type, and therefore, a variable of this type can be set to null. However, in the CLR, a System.DateTime is a value type, and a DateTime variable can never be null. If an application written in Java wants  to communicate a date/time to a Web service running the CLR, there is a problem if the Java application sends null because the CLR has no way to represent this and operate on it.

    To improve this situation, Microsoft added the concept of nullable value types to the CLR. To understand how they work, we first need to look at the System.Nullable<T> class, which is defined in the FCL. Here is the logical representation of how the System.Nullable<T> type is defined:

     using System;
    namespace System
    {
        using System.Globalization;
        using System.Reflection;
        using System.Collections.Generic;
        using System.Runtime.CompilerServices;
        using System.Security;

        // Warning, don't put System.Runtime.Serialization.On*Serializ*Attribute
        // on this class without first fixing ObjectClone::InvokeVtsCallbacks
        // Also, because we have special type system support that says a a boxed Nullable<T>
        // can be used where a boxed<T> is use, Nullable<T> can not implement any intefaces
        // at all (since T may not). Do NOT add any interfaces to Nullable!
        //
        [TypeDependencyAttribute("System.Collections.Generic.NullableComparer`1")]
        [TypeDependencyAttribute("System.Collections.Generic.NullableEqualityComparer`1")]
        [Serializable()]
        public struct Nullable<T> where T : struct
        {
            private bool hasValue;
            internal T value;

            public Nullable(T value)
            {
                this.value = value;
                this.hasValue = true;
            }

            public bool HasValue
            {
                get { return hasValue; }
            }

            public T Value
            {
                get
                {
                    if (!HasValue)
                    {
                        ThrowHelper.ThrowInvalidOperationException(ExceptionResource.InvalidOperation_NoValue);
                    }
                    return value;
                }
            }

            public T GetValueOrDefault()
            {
                return value;
            }

            public T GetValueOrDefault(T defaultValue)
            {
                return HasValue ? value : defaultValue;
            }

            public override bool Equals(object other)
            {
                if (!HasValue)
                    return other == null;
                if (other == null)
                    return false;
                return value.Equals(other);
            }

            public override int GetHashCode()
            {
                return HasValue ? value.GetHashCode() : 0;
            }

            public override string ToString()
            {
                return HasValue ? value.ToString() : "";
            }

            public static implicit operator Nullable<T>(T value)
            {
                return new Nullable<T>(value);
            }

            public static explicit operator T(Nullable<T> value)
            {
                return value.Value;
            }

            // The following already obsoleted methods were removed:
            // public int CompareTo(object other)
            // public int CompareTo(Nullable<T> other)
            // public bool Equals(Nullable<T> other)
            // public static Nullable<T> FromObject(object value)
            // public object ToObject()
            // public string ToString(string format)
            // public string ToString(IFormatProvider provider)
            // public string ToString(string format, IFormatProvider provider)

            // The following newly obsoleted methods were removed:
            // string IFormattable.ToString(string format, IFormatProvider provider)
            // int IComparable.CompareTo(object other)
            // int IComparable<Nullable<T>>.CompareTo(Nullable<T> other)
            // bool IEquatable<Nullable<T>>.Equals(Nullable<T> other)
        }
    }

    As you can see, this class encapsulates the notion of a value type than can also be null. Since Nullable<T>  is itself a value type, instances of it are still fairly lightweight. That is, instances can still be on the stack, and an instance is the same size as the original value type plus the size of a Boolean field. Notice that Nullable's type parameter, T, is constrained to struct. This was done because reference type variables can already be null.

    So now, if you want to use a nullable Int32 in your code, you can write something like this:

    Nullable<Int32> x = 5;
    Nullable<Int32> y = null;
    Console.WriteLine("x: HasValue={0}, Value={1}",
    x.HasValue, x.Value);
    Console.WriteLine("y: HasValue={0} , Value={1}",
    y.HasValue, y.GetValueOrDefault());


    When I compile and run this code, I get the following output:

    x: HasValue=True, Value=5
    y: HasValue=False, Value=0

     

    C#'s Null-Coalescing Operator

    C# has an operator called the null-coalescing operator (??), which takes two operands. If the operand on the left is not null,  the operand's value is returned. If the operand on the left is null,  the value of the right operand is returned. The null-coalescing operator offers a very convenient way to set a variable's default value.

    A cool feature of the null-coalescing operator is that it can be used with reference types as well as nullable value types. Here is some code that demonstrates the use of the null-coalescing operator:

    private static void NullCoalescingOperator() {
        Int32? b = null;
        // The line below is equivalent to:
        // x = (b.HasValue) ? b.Value : 123
        Int32 x = b ?? 123;
        Console.WriteLine(x); // "123"
    }

     



    Be the first to rate this post

    • Currently 0/5 Stars.
    • 1
    • 2
    • 3
    • 4
    • 5
    Ajander Singh , Created On 5. October 2008, 20:17

    A String represents an immutable ordered set of characters. The String type is derived from Object, making it a reference type, and therefore, String objects (its array of characters) always live in the heap, never on a thread's stack. The String  type also implements several interface (IComparable/ IComparable<String>, ICloneable, IConvertible, IEnumerable/ IEnumerable<Char>, and IEquatable<String>). The String class is sealed no inheritance allowed and string is an alias for System.String in the .NET Framework.

    Once created, a string can never get longer, get shorter, or have any of its characters changed. It allows you  to perform operations on a string without actually changing the string. If you perform a lot of string manipulations, you end up creating a lot of String objects on the heap, which causes more frequent garbage collections, thus hurting your application's performance. To perform a lot of string manipulations efficiently, use the StringBuilder class.


    You can concatenate several strings to form a single string by using the C# + (plus) operator: 

    String  sObj=”Hi” + “  “ + “Gentleman”; 

    In this example all strings are literal strings so C# compiler concatenates them at compile time and end up just one string “Hi Gentleman” in the module's metadata. Using the + (plus)  operator on nonliteral strings causes the concatenation to be performed at run time. To concatenate several strings together at run time, avoid using the + operator as it creates multiple string objects on the garbage-collected heap. Instead, use the System.Text.StringBuilder type.


    Verbatim Strings (“@”)

    C# also offers a special way to declare a string in which all characters between quotes are considered part of the string. These special declarations are called verbatim strings and are typically used when specifying the path of a file or directory or when working with regular expressions. 

    // Specifying the pathname of an application 
    String file = "C:\\Windows\\System32\\pbrush.exe"; 

    // Specifying the pathname of an application by using a verbatim string 
    String file = @"C:\Windows\System32\pbrush.exe";

    The @ symbol before the string tells the compiler that the string is a verbatim string. In effect, this  tells the compiler to treat backslash characters as backslash characters instead of escape characters.



    Currently rated 4.0 by 1 people

    • Currently 4/5 Stars.
    • 1
    • 2
    • 3
    • 4
    • 5

    Garbage Collection

        The .NET Framework's garbage collector manages the allocation and release of memory for your application. Each time you use the new operator to create an object, the runtime allocates memory for the object from the managed heap. As long as address space is available in the managed heap, the runtime continues to allocate space for new objects. However, memory is not infinite. Eventually the garbage collector must perform a collection in order to free some memory. The garbage collector's optimizing engine determines the best time to perform a collection, based upon the allocations being made. When the garbage collector performs a collection, it checks for objects in the managed heap that are no longer being used by the application and performs the necessary operations to reclaim their memory.

    Note

        In the .NET Framework version 1.0, the common language runtime (CLR) has a separate memory manager for the large object heap. Under some circumstances this memory manager does not return unused memory to the operating system, and in a few cases it does not make the memory available for garbage collection. This results in failure to allocate memory due to virtual address space fragmentation. In the .NET Framework versions 1.1 and 2.0, the large object heap is composed of contiguous areas of memory called heap segments, properly aligned to minimize virtual memory fragmentation. During garbage collection, the space reclaimed from large objects is consolidated and placed in a free list. Heap segments containing only free list items are freed and the memory is returned to the operating system. These changes to the large object heap have effectively eliminated memory allocation failures due to virtual address space fragmentation.


    Important
        On servers with more than 2GB of memory, it may be necessary to specify the /3GB switch in the boot.ini file to avoid apparent out-of-memory issues while memory is still available to the system.

    Automatic Memory Management
       
     Automatic memory management is one of the servicesthat the common language runtime provides during Managed Execution. The common languageruntime's garbage collector manages the allocation and release of memory for anapplication. For developers, this means that you do not have to write code to performmemory management tasks when you develop managed applications. Automatic memorymanagement can eliminate common problems, such as forgetting to free an object andcausing a memory leak, or attempting to access memory for an object that has alreadybeen freed. This section describes how the garbage collector allocates and releasesmemory. 

     

    • Allocating Memory:-
            When you initialize a new process, the runtime reserves a contiguous region of address space for the process. This reserved address space is called the managed heap. The managed heap maintains a pointer to the address where the next object in the heap will be allocated. Initially, this pointer is set to the managed heap's base address. All reference types are allocated on the managed heap. When an application creates the first reference type, memory is allocated for the type at the base address of the managed heap. When the application creates the next object, the garbage collector allocates memory for it in the address space immediately following the first object. As long as address space is available, the garbage collector continues to allocate space for new objects in this manner. Allocating memory from the managed heap is faster than unmanaged memory allocation. Because the runtime allocates memory for an object by adding a value to a pointer, it is almost as fast as allocating memory from the stack. In addition, because new objects that are allocated consecutively are stored contiguously in the managed heap, an application can access the objects very quickly.

    • Releasing Memory:-
            The garbage collector's optimizing engine determines the best time to perform a collection based on the allocations being made. When the garbage collector performs a collection, it releases the memory for objects that are no longer being used by the application. It determines which objects are no longer being used by examining the application's roots. Every application has a set of roots. Each root either refers to an object on the managed heap or is set to null. An application's roots include global and static object pointers, local variables and reference object parameters on a thread's stack, and CPU registers. The garbage collector has access to the list of active roots that the just-in-time (JIT) compiler and the runtime maintain. Using this list, it examines an application's roots, and in the process creates a graph that contains all the objects that are reachable from the roots. 
              Objects that are not in the graph are unreachable from the application's roots. The garbage collector considers unreachable objects garbage and will release the memory allocated for them. During a collection, the garbage collector examines the managed heap, looking for the blocks of address space occupied by unreachable objects. As it discovers each unreachable object, it uses a memory-copying function to compact the reachable objects in memory, freeing up the blocks of address spaces allocated to unreachable objects. Once the memory for the reachable objects has been compacted, the garbage collector makes the necessary pointer corrections so that the application's roots point to the objects in their new locations. It also positions the managed heap's pointer after the last reachable object. Note that memory is compacted only if a collection discovers a significant number of unreachable objects. If all the objects in the managed heap survive a collection, then there is no need for memory compaction. To improve performance, the runtime allocates memory for large objects in a separate heap. The garbage collector automatically releases the memory for large objects. However, to avoid moving large objects in memory, this memory is not compacted.

     



    Currently rated 4.0 by 2 people

    • Currently 4/5 Stars.
    • 1
    • 2
    • 3
    • 4
    • 5
    Ajander Singh , Created On 1. May 2008, 21:06


    Download Visual Studio 2008 Professional Edition, Visual Studio Team System 2008 Team Suite and Visual Studio Team System 2008 Team Foundation Server from MSDN Evaluation Center.

    Download Visual Studio 2008



    Be the first to rate this post

    • Currently 0/5 Stars.
    • 1
    • 2
    • 3
    • 4
    • 5