Borland's Together Modeling tool for .Net

I've had the opportunity to use Borland's Together Control Center product a lot lately.

For those of you that are wondering "What the hell is Together?", the Borland web site defines it as:

"An integrated development platform designed to simplify and accelerate the analysis, design, development, and deployment of enterprise applications."

Translation... yet another UML case tool.

Initially, I found my self asking... Why would I use this when Visio Enterprise Architect does basically the same thing?

The answer lies in its simplicity.  I found the Together IDE easier to use than Visio and the code generation it produced from my models was just as good.  Plus it provides the ability to track requirements, test cases and generate excellent html documentation.

There were a few minor annoyances such as the way it produces nested namespaces and its Java style indentation, but all and all it is a fairly capable product, especially considering that it is the first version that offers C# and VB.Net support.

Although it does lack some of the extended UML elements that Visio provides as well as pre-built classes for the .Net framework, I expect these will be offered in future versions.

Backward compatability not Backwards compatability

I was at a client site the other day and one of the developers asked me if it was possible to get the name of the assembly that had made a call to a specific function within a class.

I told him to use the Assembly.GetCallingAssembly() static method in the System.Reflection namespace and pointed him to an example of it's use in one of our c# classes.

He then thanked me and went off to add the call to his code. 

I thought that the matter was done, but a little later he came back and told me that it didn't work. It seems that it was always returning the Microsoft.VisualBasic namespace.

Now I knew that he was writing the code in VB but I couldn't believe that there was a bug in this method... one that I'd used on several times before with no problems.

I rewrote his code in C# and sure enough... It worked!  But the VB code always returned Microsoft.VisualBasic....

Then I set about trying to figure out why.

After a lot of hair pulling and google-ing to no avail, I finally figured it out:

Consider the following class:

 using System.Reflection;

class MyClass

{

public string WhoCalledMe()

{

return Assembly.GetCallingAssembly().FullName;

}

}

 

And now the VB code that instantiates it and calls the WhoCalledMe method:

 ' VB source code

Dim x

Dim caller as string

x = New MyClass()

' This returns Microsoft.VisualBasic....!

caller = x.WhoCalledMe()

 

 

The reference to the object that contained the call to Assembly.GetCallingAssembly() was not properly declared.

Instead of strongly typing the reference variable, it was declared un-typed... and since the compiler option was not set to "Option Strict", this was allowed.

This means that there is some sort of Microsofty magic going on here to resolve the late bound call through... you guessed it... the Microsoft.VisualBasic assembly.

The moral of this story is:  Backward compatibility is great when you need it... but you have to be careful to make sure it doesn't turn into BACKWARDS compatibility.

 

 


 

Loop optimization and .Net JIT Compiler

The other day, a colleague asked me a performance question involving loops and optimization.

The question was as follows:

When looping thru an array in a for loop, should the array's upper bound calculation (array.length) be placed in a separate variable prior to the start of a loop so that the expression does not get evaluated each time thru the loop.

For example:

int l = theArray.length;
for(int i = 0; i < l; i++){
  …
}

vs.

for(int i = 0; i < theArray.length; i++){
  …
}

 

On the surface, this seems to make perfect sense; however, I seemed to remember reading something that suggested that the optimal solution was actually the second, because the compiler already has an algorithm for dealing with this. 

After several minutes of debate, we decided to check the web, and found this interesting article  by Emmanuel Schanzer of Microsoft which suggests that “optimizations like this haven't been helpful for nearly 10 years: modern compilers are more than capable of performing this optimization for you. In fact, sometimes things like this can actually hurt performance.”

Although this sounds counter-intuitive, it really makes sense once you read the article and think about it.

The moral of this story?  Don't try to out think the compiler.