Cluebat-man to the rescue : C#

Using reflection to ease code maintenance

vanDooren — Tue, 02 Dec 2008 11:35:00 GMT

Currently I am programming an application for performing code analysis on the software that controls the production process. Apart from the parsing of the code, and iterating across a hierarchical representation of the expression tree, all these rules (verifications) have to be executed against all the code.

I could change the code verifier every time I implemented a new rule, but instead I used reflection to do this for me. Every verification that has to be done is represented by a class that implements the right interface. This interface defines the prototype of the method that performs the verification.

interface IActionVerification
{
void Verify(CodeContext context);
}

The context variable contains the complete context of the portion of the code that is being looked at: the current action, step, function block and phase.

When a new code verifier instance is create, it will use reflection to examine the current assembly, and extract all classes that implement this interface.

public CodeVerifier()
{
    actionVerifications = new List<IActionVerification>();
    var currAssembly = Assembly.GetExecutingAssembly();
    foreach(Type t in currAssembly.GetTypes())
    {
      if (null != t.GetInterface(typeof(IActionVerification).Name))
        actionVerifications.Add(
          (IActionVerification)
             currAssembly.CreateInstance(t.FullName));
    }
}

This way, it is very easy to populate the list of all verifications to do. The code verification itself is conceptually as simple as this:

foreach (var verification in actionVerifications)
verification.Verify(context);

Implementing a new verification is the as easy as creating a new class and implementing the interface. After that everything will be done automatically. Ading a new verification is as easy as this:

class ActionExpressionCount : IActionVerification
{
    public void Verify(CodeContext context)
    {
      if (context.Action.ParsedExpression.Count < 1)
        ActionExpressionCountInvalid.LogIssue(context);
    }
}

Hip hip hooray for the .NET framework!

Access != database

vanDooren — Mon, 14 Jul 2008 06:27:00 GMT

While working on a data application for the finance guys, I already discovered that Excel sucks when used with OleDb. It seems as if Excel was specifically designed to make your life as a programmer miserable.

Fair’s fair: Excel is not a database, so perhaps it is acceptable if the data link layer feels as if it has been thrown together by a vba hacker without a clear grasp of data types and interfaces. Probably they needed another handful of buzzwords on the Excel box, and decided to hire a high-school summer intern who installed basic once.

But I digress.

While I am willing to let Excel off the hook for not being something it was not supposed to be, I have a problem with extending the same courtesy to Access; an application specifically designed to be a database.

For the last couple of hours I have been debugging the finance app because some of the allocated items showed up as having cost nothing. This would have enjoyed the CFO immensely if it had been true, but since that wasn’t the case, they were wondering why my app insisted it. For some systems the totals and the details were correct. For others they were zero, or something far less that what they had cost in reality.

I examined a correct example, compared it with one of the problem cases, and found that all required data was there, in the correct tables. Then I debugged through the code, and the algorithm seemed to work just fine. Only for some systems it didn’t return any values. And since this was done via LINQ, debugging the actual SQL was difficult.

Then I decided to go spelunking in the raw data tables themselves. Again and again I checked, and nothing seemed to be wrong. But then it suddenly jumped at me:

tbl_keymstr -> row 1234 -> Alloc_key == ‘all’

tbl_alloc -> row 123456 -> Alloc_key == ‘All’

How could this be possible? I double checked, and verified that the links were all defined with the ‘Enforce referential integrity’ flag set.

After some testing, it seems that Access is pretty loose in its judgments. When it comes to comparing strings, ‘equals’ really means ‘kinda looks like’, so ‘All’, ‘all’ and ‘alL’ are all the same for access.

The LINQ queries in my app all use the C# ‘==’ to define joinings and equality operations, so if the rows in 1 table say ‘All’ and those in the other say ‘all’ the result of the joined set is empty of course.

Key definitions and cost allocations get uploaded separately, and my app doesn’t check whether the key fields are spelled the same. Everything gets uploaded, and the integrity is insured by the database itself, as it should be. If there is an upload error it gets reported and everything is rolled back. Unfortunately, key value comparison does not work that well.

The fix was very simple: I implemented a case insensitive comparison in my queries, and the problem was solved. Too bad Access is allowed by the Office team to let sloppy input through.

EDIT: I just checked, and by default, SQL server has the same behavior. But you can change it to case sensitive if you want, which is important in scenarios like these. Granted, I should have checked first before slagging off Access, but I still think that this should be an option in Access. The fact that it isn't is a severe shortcoming in my eyes, since lots of smaller databases use strings as keys. In case sensitive clients (like e.g. C# apps by default) this causes a lot of work to get correct results. And if you forget to case insensitivize (is that even a word?) your queries even once, you will get incorrect data.

Differences between C++ and C#, part 3

vanDooren — Wed, 27 Feb 2008 11:52:00 GMT

One of the things that C# (and VB.NET) programmers have to live with is non-deterministic destruction of their objects.

The garbage collector was introduced in .NET to take care of memory leaks and remove the need for manual memory management. It does this by keeping track of references, and as soon as an object is no longer referenced, it ‘can’ be collected by the garbage collector.

The ‘can’ is important here, because cleanup happens only when the GC thinks is should happen. On systems with lots of memory, and few memory allocations and releases, it is possible that this takes minutes or hours, or even doesn’t happen at all.

This can be a real problem, because now you don’t have memory leaks anymore, but resource leaks.

Suppose your app opens a file for writing, and does not explicitly dispose of the stream reference.

FileStream stream =
new FileStream(Path.GetTempFileName(), FileMode.Open);
StreamWriter writer = new StreamWriter(stream);writer.WriteLine("Hello, world.");

writer.Close();

The file is written and flushed to disk, but as long as the garbage collector does not collect the ‘stream’ object, it will hold an open file handle that will prevent you or anyone else from accessing that file. To overcome this you have to make sure that the file is released. On way of doing that would be like this:

FileStream stream = new FileStream(Path.GetTempFileName(), FileMode.Open);
try
{
StreamWriter writer = new StreamWriter(stream);
writer.WriteLine("Hello, world.");
writer.Close();
}
finally
{
stream.Dispose();

}

You could also use the ‘using’ keyword, but the same holds true. It is easy to make mistakes, and if you have several of such objects in the same scope, then your code will become a convoluted mess of nested try/finally or using constructs.

In C++/CLI, this problem can be solved differently.

In native C++, they way you create an object determines whether it will live on the stack or in the heap. The location implies the way the object will be cleaned up. If it is on the stack, it will be released automatically when it goes out of scope.

C++/CLI does not have the ability to create managed objects on the stack, but it supports stack like semantics. I.e. even if you use the declaration that would put the object in the stack, it is still created in the managed heap. But the syntax and the semantics are stack based.

This means that in the following example, the stream object will automatically be released when it goes out of scope.

FileStream stream(Path::GetTempFileName(), FileMode::Open);
StreamWriter writer(%stream);
writer.WriteLine("Hello, world.");

writer.Close();

And regardless of how many such objects we need to create or use locally, they will all be cleaned up automatically without needing ugly nested structures, and without needing extra lines of code.

Of course, you still have to determine if this is something you want, because sometimes you need objects to live beyond the scope in which they were created. In that case you can use the gcnew operator to use heap semantics.

FileStream^ stream = gcnew FileStream(Path::GetTempFileName(), FileMode::Open);

C++ gives you the ability to choose the best approach, which is nice if you want to write correct code without wanting to increase the number of lines of code, and structural complexity.

Is C++ still a viable language?

vanDooren — Mon, 05 Feb 2007 08:02:00 GMT

Every so often someone in microsoft.public.dotnet.languages.vc asks about the future of C++, or if he should learn C# or VB.NET instead of C++. Some people are also confused if using C++ means they carry around C++ legacy code if they want to write pure .NET apps.

With C++ you can write pure .NET apps that have absolutely no legacy luggage whatsoever. On the contrary, you can write .NET apps and still use powerful features like templates. Another advantage is that the next version of VC++ will be able to compile for different .NET platforms (2.0 and higher).

You can also reuse native C++ code and libraries and create mixed mode applications. C++/CLI is the only language that allows you to do this.

But I have also learned C# and .NET, and I have used it since version 1.0 was released. I use it fairly often. In fact, at work I use it as much as possible.

C# comes with a lot of stuff that makes programming a lot easier and less time consuming. I love C++ but I admit that C++ does not hold a candle to C# when it comes to rapid application development.

But C++ is still the only viable option for scenarios where you need absolute control over memory and real-time performance. Interoperability with other code is also a strong area for C++ where C# wimps out. Raw performance also makes a difference when you are writing a piece of code that has to crunch through 300 MB of code to do some image processing for example. 95% of all large code bases are still native C++. Vista is completely native as well, so C++ is not going away anytime soon.

My reason for choosing C# for pure .NET applications is that it is easier to learn, easier to maintain, and less effort to create an application. And C# and VB will also have support for LINQ, and lots of other cool new features that are not planned for C++ at the moment. And by now there are more good C# programmers than C++ programmers. It is far easier to transfer ownership of a C# project.

I would not touch VB.NET with a 10 foot pole because I think VB is evil incarnate, and the syntax is too verbose and ugly as hell. But that is just my personal preference of course. Most people in the C++ forums would agree.

People in the VB forums may have a different opinion of course.

Anyway, if you want to do .NET programming, learn C#. If you want to do C++ programming, learn C# and C++ and the low level stuff like marshalling and interop. If you want to do C++ programming in the windows world, knowing only native C++ will not suffice anymore in most cases.

C++ is about power and flexibility. C# is about getting the job done with as little fuss and effort as possible. Both have their place.

Differences between C# and C++/CLI, part 2

vanDooren — Thu, 31 Aug 2006 20:58:00 GMT

One question that comes up from time to time in the C++ newsgroups is that functions or constants that exist in a C++/CLI class library are not accessible in a C# or VB.NET project.

The reason for this is nearly always that that constants or functions are defined outside of a class scope.

Consider the following - perfectly valid - C++/CLI:

namespace Bla

{

const int CONST = 42;

int func(void)

{

return CONST;

}

};

You can use CONST and func in other C++/CLI code.

What you can’t do is to use those symbols in other .NET languages. The reason is that those languages do not have a concept of things existing outside of a class or struct scope.

In other words, even though the CLR supports it, languages other than C++/CLI do not support free standing functions, variables and constants.

A simple workaround is to put them in a dummy class. For example, you could put all constants in a class called ‘Consts’, and functions in a class called ‘Functions’.

Differences between C# and C++/CLI, part 1

vanDooren — Thu, 31 Aug 2006 20:56:00 GMT

Learning C# if you already know C++ is relatively easy. The syntax is similar, and the semantics are definitely a lot easier to understand.

Since C# looks like C++, most of the concepts are easy to learn, but here and there are a few details that might cause problems later on.

On of these things is the difference between the meaning of classes and structures in C# and C++.

C++

With C++, a distinction needs to be made between native C++ and C++/CLI

Native C++

Classes and structures are virtually identical in native C++. Instances can be located on the stack or on the heap. It all depends on how they are instantiated.

The only difference between the two is that in a class, the default access of a class member is private, while the default access of a structure member is public.

That’s all there is to it.

C++/CLI

With the rise of C++/CLI, the compiler needs to know

a) whether a type is managed or unmanaged, and

b) whether the type (if managed) is a reference or value type.

To solve this, the new keywords ‘ref’ and ‘value’ are used. The term ‘ref type’ indicated a reference type. The type is managed, and is located on the managed heap. The term ‘value type’ indicates a managed value type. It is also managed, but located on the stack

Type can be either a class or a structure. As a result, it is possible for classes to be value types, and structures to be reference types in C++.

Semantics

In C++, the way in which you instantiate – and not the declaration – of a type determines whether it lives on the heap or on the stack.

2 important consequences of type location in C++ are that stack based instances are fixed in memory during their lifetime, and that stack based instances are guaranteed to be cleaned up when the go out of scope.

In reality, the C++ compiler is cheating you. It does some things behind your back to fool you into thinking that things live on the stack, while in reality they live on the managed heap.

Native types are either allocated on the stack or the native heap, based on whether you use stack semantics or operator new.
Value types can be created on the stack, on the native heap and on the managed heap, based on whether you instantiate them using stack semantics, operator new, or operator gcnew. But still, what you see is what you get.
Reference types are always created on the managed heap. Even if you use stack semantics for instantiating a reference type, the compiler still allocates the object on the managed heap. The compiler then takes care to insure that the object behavior (like deterministic cleanup etc…) mimics what you would expect of a stack based object.

If you are programming C++ in a mixed mode environment (both native and managed code in the same module) it is important to be aware of these possibilities and their impact.

C#

C# has a type system that is a lot easier to grasp.

Classes are reference types. They are always created on the managed heap.

Structures are value types. They are always created on the stack. C# -like C++/CLI- also supports the concept of boxing, where a copy of the value type is saved on the managed heap.

Conclusion

C# and C++/CLI share some type traits. The cases that are identical in C++/CLI and C# are in the following table:

	C#	C++/CLI
Value type	struct	value class
Reference type	class	ref struct

All other types in C++ and C++/CLI do not have a 100% equivalent in C#.

When building class libraries for use in other .NET enabled languages, you have to watch out for incompatibilities that can be caused by using C++/CLI specific types.