Why C# doesn’t supports multiple inheritance?

C# doesn’t Supports Multiple Inheritance by Implementation inheritance but supports using Interface  Implementation.  Sounds confused??  have a look at it…
Basic Inheritance

Two types of Inheritance:
1.    Implementation Inheritance: in which class inherits one class and implement/override its methods and properties for example Control object in which System.Windows.Forms.Textbox,System.Windows.Forms.Button both inherits their self from control class. But provides different functionality
2.    Interface inheritance: in which a class inherits from Interface. For example IDisposable. It just inherits definition not implementation. Any type which does interface inheritance it means that it will provide defined functionality called as “Contract”.

Multiple Inheritance:
A class derives from more than one class it is called Multiple inheritance
Multiple inheritance allows a class to take on functionality from multiple other classes, such as allowing a class named StudentMusician to inherit from a class named Person, a class named Musician, and a class named Worker. This can be abbreviated StudentMusician : Person, Musician, Worker.
Ambiguities arise in multiple inheritance, as in the example above, if for instance the class Musician inherited from Person and Worker and the class Worker inherited from Person. There would then be the following rules:
StudentMusician: Person, Musician, Worker
Musician : Person, Worker
Worker: Person
If a compiler is looking at the class StudentMusician it needs to know whether it should join identical features together, or whether they should be separate features. For instance, it would make sense to join the “Age” features of Person together for StudentMusician. A person’s age doesn’t change if you consider them a Person, a Worker, or a Musician. It would, however, make sense to separate the feature “Name” in Person and Musician if they use a different stage name than their given name. The options of joining and separating are both valid in their own context and only the programmer knows which option is correct for the class they are designing.

Debate
There is debate as to whether multiple inheritance can be implemented simply and without ambiguity. It is often criticized for increased complexity and ambiguity, as well as versioning and maintenance problems it can cause (often summarized as the diamond problem).[1] Detractors also point out multiple inheritance implementation problems such as not being able to explicitly inherit from multiple classes and the order of inheritance changing class semantics. There are languages that address all technical issues of multiple inheritance, but the main debate remains whether implementing and using multiple inheritance is easier than using single inheritance and software design patterns.

Multiple Inheritance arises Diamond Problem

 

programming languages with multiple inheritance and knowledge organization, the diamond problem is an ambiguity that arises when two classes B and C inherit from A, and class D inherits from both B and C. If a method in D calls a method defined in A (and does not override it), and B and C have overridden that method differently, then via which class does it inherit: B, or C?
For example, a class Button inherits from both classes Rectangle (for appearance) and Mouse (for mouse events), and classes Rectangle and Mouse both inherit from the Object class. Now if the equals method is called for a Button object and there is no such method in the Button class but there is an over-ridden equals method in both Rectangle and Mouse, which method should be called?
It is called the “diamond problem” because of the shape of the class inheritance diagram in this situation. Class A is at the top, both B and C separately beneath it, and D joins the two together at the bottom to form a diamond shape.

Source: Kiran Patils post on word press

Window Service in .NET

Work is on Progress...

Using Dictionary in C#

Work is on Progress...

How to use App.config

Work is on Progress...

FileSystemWatcher Class and its Problem

Listens to the file system change notifications and raises events when a directory, or file in a directory, changes.

File system watcher listens to the file system change notifications and raises events when a directory, or file in a directory, changes. A very useful tool since it notifies exactly at the moment when a file or directory is created, changed or deleted, without having to do polling on that directory. It can watch sub-directories too.
If that wasn’t enough it also provides filters. For instance u just want notifications about text files then you can provide a filter “*.txt”, now event will be raised only for text files.

The Problem

However there is a downside. The file system watcher is not entirely reliable for working with large volumes of files. The reason for this is that there is a fixed buffer allocated to each file system watcher which is used to store the details such as file location for each file that raises an event. However when a large number of files raise an event then this buffer gets full.

Default size of the buffer is 4 KB, so obviously the immediate solution would be to increase this size. But again there is a downside the buffer is located in a portion of memory which cannot be swapped, in other words the memory will be allocated by default whether it is use or not. So it not advisable to not allocate large memory sizes.

The Solution

If you Google for the solution to this problem you will find a large number of articles. In this article however we take an entirely different approach.
Now the buffer discussed above holds the information for each event until the event is handled. The idea is to handle the event as quickly as possible so that the buffer is cleared.
But that’s easier said than done. To do some complex processing on the file would take some time, some CPU cycles, and the buffer will have to hold the data till the processing is over.
So instead of we do not write the proceeding logic in the handler instead the handler simply queues the file in a work queue. This queue is processed by an entirely independent thread. So the actual work done by the handler is just queuing and the control moves out of the handler thus releasing the buffer.