On Tue, 2004-03-16 at 04:37, Mr. Deepak P N wrote: <snip/> > Since the WaitHandle class is an abstract class, we obviously cannot > instantiate an instance of its type. So, how can there be an > implementation of a constructor.
Simple. The fact that a class is abstract has NO bearing on whether it can have constructors. An abstract class just cannot be directly instantiated, but concrete subclasses can be, and they will need to invoke the abstract classes constructor. All classes have at least one constructor, even if it's the compiler-generated default constructor, so all derived class constructors will *always* invoke their base class constructor, regardless of the abstract status of the base class. I will admit that it doesn't make sense to have a public constructor on an abstract class, which is why abstract class constructors are typically protected, to further emphasize that the class must be derived from. It's still *valid* to have public constructors on abstract classes. > Even the MSDN documentation seems to mislead us by saying that > WaitHadle() constructor Initializes a new instance of the WaitHandle > class. They're not misleading you. WaitHandle has a constructor. The WaitHandle constructor would be responsible for creating the underlying (OS-native) semaphore/critical-section/lock. Sub-classes would override the various virtual/abstract functions (Close(), WaitOne(), etc.), to change behavior as they see fit, but base their behavior on the lock OS-lock held by the WaitHandle class. The WaitHandle finalizer would be responsible for freeing the unmanaged resources allocated in the constructor. This keeps things sane, as all resource acquisition and release is done in the same class. - Jon _______________________________________________ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
