December 2009 Entries
The Gift That Keeps On Taking

It's the the gift giving season, which naturally has me thinking a lot about what makes a great gift. There's the ubiquitous gift card, which is almost always a safe bet, but can seem a bit impersonal in my opinion. Then there are gifts that aren't really gifts at all. Gifts like this seem like a great gift idea from the giver's perspective, but frequently end up having some real long term cost to the receiver. It's usually the big ticket items that fall under this category: cars, recreational vehicles, or anything with a lot of moving parts. Giving a gift like this to someone who doesn't have the means to easily keep up the maintenance is really not much of a gift. I've often wondered how people who are featured on reality and/or game shows end up once the cameras leave and they are left with their brand new $50,000 car or completely remodeled house. These things have real costs over their usable lifetime, and those costs can add up.

It's a bit like a company offering a very popular product for $20 and then charging $60 every time you need a new battery/refill/tune up. I've seen this same pattern in the IT world. A large vendor offers their products and/or services at a deep discount (up to and including 100%) but then eventually leaves the client high and dry with a bunch of hardware and/or software to maintain. It's easy for management to get wide-eyed at the slick demos, marketing propaganda and salespeople-speak and lose track of the really real cost of maintaining IT infrastructure and applications.

I think in most cases the vendor is hoping this investment will pay dividends in the form of creating case studies or selling support contracts, and the client sees it as a great opporitunity to upgrade. Let me tell you, though, the hangover from a venture like this isn't a pleasant one. I've been in the unfortunate situation of trying to maintain a massive collection of servers and applications that were built by outside vendors and ultimately abandoned. The client resources are too scarce to effectively maintain everything (which is why the initial pitch was so inviting), and things slowly begin to deteriorate. Servers need support contracts, they crash, hard drives fail, things go bad. Software rots, outlives its usefulness, and needs to be refactored and updated. These things cost real money and take real people hours and hours to keep going.

I've sat in too many meetings where a 4 year plan for the construction of a massive project is being laid out and hear the one or two people who ask, "What about year 5? Year 6? 7?" get quieted down. The gift is so enticing it's easy to get caught up in the excitement I suppose, but you really do need to ask yourself, "How can we maintain this?"

Posted On Monday, December 21, 2009 2:19 PM | Comments (1)
Differences between using the ‘Convert’ class vs. casting (Part 2 of 2)

In the last post I was puzzled by what I thought were some inconsistencies between using the cast operator and Convert.ToInt32 when trying to convert an object typed as a decimal to an int.

I had it tracked down at the ‘System.Convert’ class in the ‘mscorlib’ assembly we’ll find the following in the method definition for ‘ToInt32(object)’ using Reflector:


All that’s going on here is we’re using the underlying type’s implementation of the ‘IConvertible’ interface to perform the conversion. The System.Decimal class implements the ‘ToInt32’ method of ‘IConvertible’ like this:


There we finally see the heavy lifting that goes in to converting a decimal to an int. So why does the use of ‘Convert.ToInt32’ result in this method ultimately being called but performing the direct cast on an object doesn’t?

Let’s use that same code example from the previous post and crack it open with Reflector. In addition to displaying an approximation of what the original C# or VB .NET code might have looked like for a given assembly, Reflector also lets you peak at the intermediate language (MSIL). Looking at this intermediate language can sometimes give you a better feel for what’s really going on under the covers with a bit of code.

If we look at the IL for the code that failed with the InvalidCastException at runtime we can see what’s actually happening:


We can see the initial creation of the decimal variable (L_0008), boxing that value into an object (L_000f), and then the eventual attempt to unbox that value into an Int32 (L_0016). As I discovered previously, the C# spec explicitly disallows unboxing a type into something other than the the type that was initially boxed.

Let’s compare this with the code that (successfully) attempted to cast a decimal variable to an integer:


We can see the initial creation of the decimal variable (L_0013) and then a call to the ‘op_Explicit’ method of the System.Decimal type. This appears to be the difference between these two code snippets, so what is the ‘op_Explicit’ method?

This method defines an explicit cast operation that can be performed between the Decimal and Int32 types. This method gets treated just like the other defined operators (i.e. addition, subtraction, division, etc.). Just like the compiler gives us a nice readable syntax for dealing with these operators (i.e. using the ‘+’, ‘-‘, and ‘/’ characters to represent the operation), we also get a nice ‘( )’ operator as readable facade on top of the ‘op_Explicit’ method. If we use Reflector to take a look at the op_Explicit declaration we find the following:


All this is doing is calling out to the ‘ToInt32’ method that’s doing the real “heavy lifting” of performing this conversion.

So, after all of that I feel satisfied in understanding a bit more about the .NET framework, boxing, unboxing, and type conversion. Perhaps not immediately useful in my day to day life, but I’m a firm believer in understanding as much as I can about the tools that I use to do my job, whether it be the hardware, operating system, IDE, or development platform.

Posted On Saturday, December 5, 2009 5:42 PM | Comments (1)
Tag Cloud