Untitled Coding Blog

This is the final part of the series about the C# code analyzer and interpreter that I created a while back. The actual execution and interpretation of the C# code are explained in this post. It is the last post in this series. To begin with, in very simple terms each word in the C# code can have an associated action that needs to be executed when the code is read by the analyzer in the proper order. For example, a word in the code might be a variable name. In this case, the reference corresponding to that variable is located and stored in a temporary buffer once the word is read. After that, it can be used from the buffer for another operation like invoking a method on the object/objects that the reference references. In case it has to call a method, it needs to locate the body of the method and jump to the method implementation and start reading it. With constructors, it is pretty much the same thing with the only difference being the fact that it always returns a single object and...

I had the chance to dig deeper into how C# handles members in general and came up with some really interesting conclusions. This post is mostly about how C# and the CLR resolves fields and methods calls with the corresponding implications. This is especially good to shut up someone if you do an interview with a know-it-all interviewer.. Actually is it pretty interesting because in C# you can actually have multiple fields with the same name in an object. But there is a small gotcha: you can't declare the duplicate fields in the same class definition. So how can you do this? Well you use inheritance. You can have a simple class that inherits from another base class declaring another field with the exact same name as field from the base class. They will look like this: In this case, what field will be accessed from these duplicate fields? It's actually pretty simple. It depends on how you reference the object. Each object has a type which can be a class, structure or some...

Most developers that have used Entity Framework will surely have noticed some special files in the project that end in ".tt". These files serve as blueprints for the code that is generated from the Entity Framework mappings which are stored in an xml file ending in ".edmx". A ".tt" template is similar to the ".cshtml" files used in Asp .Net MVC but instead of rendering html content it renders C# code. By editing these files we can customize how the generated code will look and behave. For example the partial ".tt" template bellow for each column in a table in the database it generates a property that implements the INotifyPropertyChanged interface to notify subscribers that the object has changed: This is applied for each column in every table. Using this code we can bind our objects directly to a Windows Presentation Foundation interface after fetching them from the database. We can also generated backing fields for that prop...

This is a continuation of my blog series about writing a hybrid C# code analyzer and interpreter. Compared to part one, I renamed the variable references from "TrackedVariableReference" to "EvaluatedObjectReference" and a variable is now known as an "EvalutedObject" or any subtypes derived from it. This part will focus on the simulation of the code execution. The core part is the object that stores the current execution state which is of type "CodeEvaluatorExecutionState". The most important things stored in this state object are the objects of the type "CodeEvaluatorExecutionFrame". These objects represent a method call and store all the local parameters corresponding to a method call. These parameters include the local "this" reference, the local objects created inside the method, the passed parameters from caller of the method and a special slot for a reference which contains the results of an expression. This last slot ...

The purpose of this C# analyzer is to see all possible execution paths from any entry point inside the code. Currently the entry point can be only a method. There are multiple ways to deal with this. The approach would be to rewrite all existing code and rewrite all conditional statement so that they are true all the time. This approach has numerous disadvantages. Firstly, it will actually execute the code and any calls to external resources such as databases will be executed. Since the code has been altered, there is also no guarantee that it won't produce exceptions at runtime. And for really big code bases, it will be incredibly slow and it will require actual compilation of the modified code which may take even more time. My approach is to write a C# interpreter with some special conditions that will go through all possible execution paths. In order to go through all the execution paths, our interpreter will need to ignore all the conditional statements and jump directly ...