Wednesday, August 20, 2003

Does C# Measure Up? Google Search It There is an interesting article on the performance characteristics of C# here.  I include some quotes below: For myself, being one of those who may have had, as mentioned in the introduction, prejudices against C#, I confess I was surprised and occasionally impressed by its performance. This article looks at the “threat” to C++ and Java that C#/.NET may become. Overall the results were surprising, although perhaps unexciting, in showing that C# (and to a less extent Java) is, to a good degree, on a par in efficiency terms with its older and presumed to be) more efficient counterparts C and C++ at least as far as the basic language features compared in this analysis are concerned. The research has shown that C# provides very good overall performance —at least as far as with the scenarios we’ve examined—and could not fairly be labeled as a poor performer to the degree that Visual Basic, and to some extent Java, have been in the past. For my part, I was impressed with the performance; it certainly exceeded my expectations. Where I would make serious criticisms is from the perspective of language features and support for multiple programming paradigms. 11:42:09 AM   []    comment []

Custom Display of Variables in VS.NET Watch Windows Google Search It Have you ever wanted to customize how a variable appears in the debug window of Visual Studio.NET?  Take the simply case of a GUID for example.  When a GUID it displayed in the watch window it the value is simply {System.Guid}.  Perhaps this is helpful to some but I don't find this debug display particularly helpful especially when their is a third column identifying the type already.  Not to be frustrated too easily, however, you can click on the expansion button to drill into the details.  Again, lets consider the Guid:  At this point VS.NET displays the fields _a through _k on the left and then shows the values for each of these fields (random integers as far as I can tell) in the value column.  This is clearly more helpful because now you can at least compare two Guid to see if they are the same.  It turns out, however, that you can actually customize the display of types in the watch window.  For C# you need to open up the mcee_cs.dat (mcee_mc.dat for Managed C++ and autoexp.dat for native C++) file and add a custom autoexpansion rule for the type.  The files are located in ...Common7PackagesDebugger. For System.Guid I added the following line: <System.Guid>=<_a,h>-<_b,h>-<_c,h>-<_d,h><_e,h>-<_f,h><_g,h><_h,h><_i,h><_j,h><_k,h> As a result the watch windows now displays the following: {0x25551444-0xffffc219-0x4307-0x810xea-0x190xac0x110x630x170x77} This is clearly not ideal as I actually want it to display "25551444-c219-4307-81ea-19ac11631777" but what is does display is clearly better than {System.Guid}.  Below are the issues that I ran into: Issues You need to restart VS.NET to consume any change in the mcee_cs.dat file. There doesn't seem to be anyway to specify a method return be used.  :(  This is too bad... I really wanted to just use ToString() (or better yet GetHashCode()) and be done with this. The VS.NET team was kind enough to supply different numeric representations but with Hex they prefix (probably appropriate in most cases) with "0x" which doesn't work for displaying a GUID in the format I would like. System.Guid should have been displayed correctly without me going to have to futz with this. Perhaps the coolest is that you can enable this for any class including your own classes.  As a result, you can handle the second two issues by adding a property of your choosing to display what you need.  In other words, even though methods are not supported, both fields and properties are.  One additional item to mention is that you can enable or disable manual expansion which is nice if you are like me and keep clicking to expand the same type as though this time it might have some useful information even though it never has before. The only official documentation I could find on this was in the above link and then in the file itself. As a side note I find the implementation curious.  I would have expected some type of Attribute for this especially given the support for the System.Diagnostics.DebuggerStepThroughAttribute.  As a result, users of my class could capitalize on my decision on how to display the class in the watch window.  (Obviously the user could perhaps customize it using the method Microsoft actually implemented.) 1:33:25 AM   []    comment []

© Copyright 2004 Mark Michaelis.