I've been using static classes for singleton's. Is this a bad approach? Are static constructor's unreliable? Don't you automatically get one instance of a static class in each app-domain? Maybe that's the issue...
Thanks, Shawn Wildermuth [EMAIL PROTECTED] > -----Original Message----- > From: Moderated discussion of advanced .NET topics. > [mailto:[EMAIL PROTECTED]] On Behalf Of Noam Arbel > Sent: Saturday, June 01, 2002 12:39 PM > To: [EMAIL PROTECTED] > Subject: Re: [ADVANCED-DOTNET] Singleton pattern > > > I think it is usefull to understand when SuppressFinalize() > should be used. If you look at code like this: > > public class UseResource > { > public void OpenResource() > { > // open a resource for use > } > > public void UseResource() > { > // Do some stuff with the resource > } > > public void CloseResource() > { > // close the resource > SuppressFinalize(); // <== make sure Finalize is not called > } > > ~UseResource() > { > // close the resource > } > > > A good coder will open the resource, use it multiple times > and call the > CloseResource() at the end (hopefully in a finally block). > This will call the SuppressFinalize() letting the GC know > that cleanup has been done. > > But if the user did not call the CloseResource explicitly, it > will get closed through the destructor and not left dangling. > > As to the public constructor on the Singelton class, it does > look strange. > > Noam > > You can read messages from the Advanced DOTNET archive, > unsubscribe from Advanced DOTNET, or subscribe to other > DevelopMentor lists at http://discuss.develop.com. > You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
