MethodBase Without Reflection

One of my friends early this morning (Too early if you ask me. It takes me a lil bit to get my engines going) asked me about getting presently executing method information. Well, that is pretty easy, right? We have System.Reflection that allows us to look into the current codebase for information like that, like getting the methods name as a string.
We just simply do a:
[csharp]
System.Reflection.MethodBase.GetCurrentMethod()
[/csharp]

Bam, we have the current method name. But, he wanted to do this sans Reflection.
Well, we have to make that one line of code a little bit longer taking into account that constraint, but it really isn’t that complex. We know that for each method that is executed in an arbitrary thread we get one of those StackFrame objects that is pushed onto the base dynamic stack data structure (i.e. We push a new StackFrame object onto the callstack). Those StackFrame objects contain all sorts of fun information, and that information can be extracted and used for whatever scheming purpose you have in mind. But remember, a lot of method information is contained in the debug file, so when you switch to release builds you might elude some data that you are interrogating for.
So firstly, let’s produce a new StackFrame object:

[csharp]
StackFrame stackFrame = new StackFrame();
[/csharp]

Now we have a StackFrame object, and we know that the StackFrame contains all sorts of MethodBase information that can be employed to garnish information from.
So, let’s do some MethodBase hydrating:
[csharp]

StackFrame stackFrame = new StackFrame();
MethodBase methodBase = stackFrame.GetMethod();
[/csharp]

Now that you got those to ready to go, you can start getting all the fun information!
For example:

[csharp]
StackFrame stackFrame = new StackFrame();
MethodBase methodBase = stackFrame.GetMethod();
string methodName = methodBase.Name;
bool isStaticMethod = methodBase.IsStatic;
bool isPublicMethod = methodBase.IsPublic;
[/csharp]

Ready to go! :)

Share

Generics And ArrayList (Object Array), Let’s Fight

I got in a fight, mentally. I love generics, but a lot of the times when I get my code review’s occur, people ask me why I didn’t use an object array when it would have sufficed?

So in this, I am talking about instead of using this:

[csharp]

ArrayList list = new ArrayList();

[/csharp]

Using this:

[csharp]

List list = new List();

[/csharp]

It’s a good question I suppose, but I gotta admit, I favor the use of generics heavily, and although there is a load of piddly crap that could be brought up between the two, I think that it all boils down to the performance differences, from both doing the development (since you don’t have to copy to an external collection to make freakin updates) to running the god damn application itself. I have heard in the past that there have been compiler problems with this generics. Is this true? I have no clue. I would be interested to know if it was though. Anyways, why do I think that generics are better then object arrays performance wise. It basically boils down to the heap. In the end, a generic from what I understand, there is no boxing and reference created to the boxed value, which is the case with an object array, and therefore, because of this lack of creating a piece of allocated memory on the heap instead just puts the god damn value in the array. That makes better sense to me.
I could point out more, but I want to leave work now.

Share