Over the weekend I started Reading "
CLR Via C#
". I picked it up at Borders earlier this year with a certification book. I was trying to get more MCTS certs at the time and never ended up reading it. Also every time I look at it I feel like it's that black box I'll never be able to understand. I realized this is a bad attitude to have, so I opened it up and began reading. Instead of becoming lost, I feel like some things are becoming found.
I realize I should have read this book right away. So far nothing has been entirely over my head. I have had to reread some paragraphs due to sentences being heavy on the the terms. Also the author "Jeff Richter" tries to use the correct CLR terms and they sometimes clash with C# and general OO terms. An example is he uses "type" as the term for a static class.
I've made it 11 chapters in and so far it has been full of those "so thats how that works" and "thats good to know" moments. The biggest one so far has been the Events chapter. He covers a C# feature that has not been covered in any of the C# books I have read.
In C# you can declare Events like Properties. That is instead of using "get" and "set" blocks, one can use "add" and "remove" blocks. He covers this because the default implementation of events in the CLR is a bit flawed when it comes to thread safety. The CLR will lock the full object when adding and removing event delegates. He gives an example of overcoming these flaws by implementing manual locking in the "add" and "remove" blocks.
private event EventHandler<SomeEventArgs> somethingHappend;
private Object mLock = new Object();
public event EventHandler<SomeEventArgs> SomethingHappend
{
add
{
lock (mLock)
{
this.somethingHappend += value;
}
}
remove
{
lock (mLock)
{
this.somethingHappend -= value;
}
}
}As you can see it looks much like a C# property. It uses a private event that is exposed publically through two blocks. Other than the keywords the other major difference is you cannot set access modifers on the "add" and "remove" blocks. It would be very bad programming to let someone add an event delegate but not let them remove it.
I have one application that I maintain where this will come in very handy. Planning on testing out the difference very soon.
I highly recommend this book for any serious .NET developer. I kick myself for not learning more about the CLR in the first place. Visual Studio sometimes babies the programmer too much I think. That and many programmers are lazy and love to just know enough to get by. I find these kinds of programmers have a very hard time working at Sierra Bravo. We have such a large variety of projects that one must learn quickly and know enough to jump the entire gammut of .NET applications. As a .NET developer here it's impossible to just be an ASP.NET developer or WinForms developer. I like it that way, it ensures that I'm never board and am learning all the time.
In my tenure so far I have written, Winforms Applications, entire .NET CF warehouse management applications, fully globalized ASP.NET web sites, various web services, various windows services, System Tray utilities, a Vending Machine controller program (implementing various serial protocols), written TCP clients for propietary protocols and much more. I have also helped companies migrate to/from MSSQL databases with various front ends. Heck, I'm even working on a C++ Win32 mobile application this week. I have done more in 3 1/2 years than a typical programmer does in 10 years.
Understanding how something works makes it much easier to implement a project with it. I found when I was a PHP programmer that I really went from amatuer to professional when I studied how PHP parses the script, allocates memory for variables. This is not an easy thing to do without looking at the source code. There are no good books out there about the "PHP Runtime". Knowing the rammifications of taking advantage of variable variables and not unsetting after use helped me take one of my more complext php programs and reduce it's memory usage 3 fold.