Wednesday, April 13, 2005

C# Course day three


  • COM is done

  • Classic VB (6) is done

  • Big sell job on garbage collection. Commentary: It's good (I am a Java developer after all) and yes you can introduce bugs doing it manually but most of the time developers are quite capable of managing memory.

  • GC does heap compaction to deal with memory fragmentation

  • destructors/finalizers in C# look like ~ClassName(){} and are used for implicitly freeing resources. More important in C# than Java because of Windows' finite resource limitations (e.g., Fonts)

  • Unreachable objects with finalizers are moved to freachable queue & finalizers are not called on GC thread. Finalize thread comes along and calls finalizers and then on second GC run the object is collected. Which all means objects with finalizers stay around longer. Secondly their generational flags are bumped up meaning they're more expensive to clean up (i.e., more exhaustive GC search required). Don't use finalizers if possible.

  • C# idiom is to provide an explicit method for freeing finite resources as well as an implicit destructor. If using the explicit method then call GC.SuppressFinalize(object) to prevent the GC from duplicating the work. The explicit method should be an implementation of IDisposable. Eclipse's SWT suffers some of this same dispose problem because it uses native Windows resources. Ugh!

  • Finalizers are not guaranteed to run (like Java) so avoid them if possible.

  • A try-finally block for freeing allocated resources can be replaced with something like using(Resource r1 = new Resource()){}

  • WeakReference class allows an object to be collected if memory is low. Used for something like caching.

  • Can use the Windows Performance Monitor (i.e., perfmon) for viewing the CLR Memory. Pretty graphs... ;-)

  • There is multiprocessor support but uses a different CLR DLL (i.e., Workstation and Server). All console apps run using the Workstation VM unless you make some config changes.

  • An unsafe block is available for executing code and preventing the GC from moving objects around in memory. This is important for calling C DLLs for example. Looks like unsafe{}

  • IO Streams are very similar to Java. Functionality is added to the basic stream using the Decorator pattern. And there are Reader and Writer classes for dealing with text. C#'s one major difference is that there is just Stream not InputStream and OutputStream. Instead you define read or write using constructor parameters.

  • There is a File and a Directory class is C#. Java only has a File class with an isDirectory() method. The File class has some handy Factory methods for creating Streams.

  • There is a utility Path class for manipulating path strings.

  • FileSystemWatcher allows you to eliminate directory polling and receive events for things happening to a file or a directory.

  • IsolatedStorage is a handy class for providing 10MB of storage on the local file system for applications started from an http address. The data is stored in "c:\Documents & Settings\\LocalSettings\Application Data\Isolated Storage\". The only problem is that the directories in here are cryptically named.

  • CredentialCache class useful for getting the credentials of the current user.

No comments: