free geoip Jayson's Blog - jaysonKnight.com
jaysonKnight.com
A conduit to the voices inside my head.

Jayson's Blog

Sort by: Most Recent | Most Viewed | Most Commented

  • First thoughts on C# Generics...

    as i'm sure everyone has seen, the next version of C# will include compile time support for super late binding...also known in the OO world as Generics. since even the early VB days, in order to achieve this type of functionality (albeit at run-time), we would use variant types, or in the .NET world, object types...then just supply several overloaded methods based on the actual type of object passed in. not only does this lead to severely repetitious coding, there is a severe performance penalty involved w/ casting, and in a lot of cases, boxing/unboxing. there is a really cool tool dev'd by MS at this link: this will show you just where the perf penalties are. in most cases, next to casting from object types, string concat's are 2nd in the performance hit category (see my earlier post on the StringBuilder object). this tool is basically a query analyzer type tool, but for managed code.

    anyway, on to generics. it's quite the buzz in the managed world of .NET right now, and for good reason. instead of expensive runtime checks, and the associated non-type safety associated w/ those checks, we can now define methods that in effect supply the same runtime functionality of supplying object types and casting to the correct type...AT COMPILE TIME! this is a godsend to component developers, and the amount of redundant code this will save is pretty incredible, this will have a HUGE impact on polymorphism. i can think of literally hundreds of classes i've written that could benefit from generics, and code bloat would shrink dramatically.

    take for example the framework i wrote for tricking class libraries into thinking that they have a .config file. there are several way to let this class lib know where it lives so that it knows where to search for a .config file (path reference, assembly reference, etc), however each one of these requires a seperate cast from a type of object to the desired type. you can write overloaded methods for each type, or write a generic method accepting an object ref, then testing whatever is passed in to see exactly what the heck it is (and truth be told, there is probably some way that someone would want to pass a reference in that i haven't thought of), then perform the appropriate cast to the type you need. that is very tedious work, trying to predict what other coders are going to do...so why even attempt it? generics to the rescue! :-) in a future post i will re-write my .config class library to take full advantage of generics...it will have to wait for my copy of whidbey to get here though. i will also be posting soon on the other additions to the C# language...

    more to come...
    j

  • longhorn pt 2...

    I managed to dig up an old HDD, wiped it clean, and got longhorn installed on it. at an idle after a clean boot, it sits at over 600 mb of RAM (though i am sure there is plenty of debug code in this release). first impressions are pretty good, though i can't seem to find the option of having an address bar displayed in windows explorer, which is definitely NOT a good thing as i cut and paste path names on a very regular basis, especially when trying to use MSBuild. i successfully wrote and built my first XAML app (an obiquitous "Hello World" application), and then built it using MSBuild. at this point, one of the advantages i see to using MSBuild and external build configuration files is that it moves the AssemblyInfo class out of code and into a common XML format. other than that, it's just one more file i have to keep track of, though i am sure some more benefits will reveal themselves to me. i am not a huge fan of command line building, so i will hold off on more coding until i can get my hands on Whidbey. i am extremely excited about the "reclassing" of the Win32 API though, from what i can tell Longhorn will be one of the first truly OO OS's ever produced, the .NET framework will no longer be just a wrapper around the arcane Win32 API's, they will all be promoted to first hand .NET classes. i would expect that code performance will increase substantially b/c of this as well. a question i have is will further updates to the new .NET Win32 API be realeased as new versions of the .NET framework for backwards compatibility, and for code portability (MONO is becoming more and more of a reality every day, and MS isn't objecting to it at all). i have read that indigo will be released as a seperate download for prior OS's, which is a good thing, however will it just be a wrapper in itself? all in all, it seems pretty stable for a pre-alpha release...but i haven't really banged the OS too hard yet.

    so i sit here blogging on an OS that won't even be released for at least 3 more years (if it ships by 06 we will all be pleasantly surprised).

    more to come...

  • longhorn...

    So i've been attempting to get the pre-alpha longhorn installed to no avail. don't attempt to install it on virtual PC, it doesn't pick up any of the host's hardware.

    more to come...
    j

  • Late night ramblings...

    Been gone for a bit, very busy building some prototypes, mockups, etc. and trying to learn everything i can about longhorn. it's pretty amazing that this many people are this hyped up about technology that won't even be available for at least 2 years. a friend of mine is getting a pre-beta of longhorn, whidbey, and yukon. i cannot freakin' wait to take it for a test drive! apparently the push from the boys in seattle is going to be one markup language for any front end GUI...which sounds great and all, but i hate GUI stuff so i don't really know how much that will impact me. they call it XAML and it looks quite impressive. what is grabbing my attention more than that is WinFS and Indigo. more on that later...

    one of the things i have noticed in ASP.NET apps is a severe lack of intrinsic ability to provide users a look at what's going on for long running processes...status notifications, etc. given of course that anything over 30 seconds running shouldn't be GUI based, however the need will arise occasionally to do some sort of long running query or whatnot from an ASP.NET page. have a look at the prototype i am working on here: http://jaysonknight.com/asyncwaitstate

    it's 1AM, long day tomorrow. i am still fighting w/ autobell about them killing my porsche :-|

    cheerio

  • doh...

    So, there you are...sitting somewhere with the woman of your dreams...or perhaps about to win your the game you've been playing for 48 straight, whatever...just plug in your dream situation. then it hits you...FUCK, I WROTE THAT CLASS WRONG!!! that is just what happened to me, except i was in the middle of a seinfeld episode i had never seen before (yeah, i am lame)

    so, i wrote that singleton object that exposes all the elements of a config file via static properties...DOH! that was the wrong way to do it! erase all of the static keywords in AppConfiguration, and replace any calls to the singleton class w/ AppConfiguration.Getconfig (the previous way was simply AppConfiguration.[whatever]...

    live and die by the code
    j

  • Ramblings...

    how are we american programmers getting displaced by thousands by foreigners? if they program in VB, they almost have to learn the entire english language just to use it! ok, that was a cheap shot...but still...

    come on america...step it up! where else can you not work for pennies a day living in a shanty and be grateful for every second of it!

    whatever
    j
    Filed under:

  • T-SQL nightmares...

    So, i've been given the task of scrubbing some data for a group at my work. apparently they have about 50 records w/ either invalid zip codes or invalid SSN's. writing regular expressions in C# is a snap, however i have to load this data into an excel spreadsheet, so it would be a lot easier to try and validate the data on the server with T-SQL. have you ever tried to do string parsing with T-SQL? there is absolutely no way to check and see if it's going to work until you hit the little green play button in SQLQA...

    this is gonna be a fun one...
    j

  • Follow up for a previous post...

    I had previously posted a blog on 10/28 about how to get a class library to dynamically find it's own config file...then i realized that i didn't give any instructions on what to do next as far as loading that config file into some sort of object so that your application can use it!

    Personally, i would load the configuration file into a singleton object. per msdn documentation, the C# code for this would be:

    class Singleton
    {
    public static Singleton Instance() {
    if (_instance == null) {
    lock (typeof(Singleton)) {
    if (_instance == null) {
    _instance = new Singleton();
    }
    }
    }
    return _instance;
    }
    protected Singleton() {}
    private static volatile Singleton _instance = null;
    }

    i personally find this a bit wordy and complex for what we are really trying to accomplish here. we need one object to share common properties with any subscribing assemblies, for the most part this information isn't going to change, so why waste round trips instantiating a new object each time your assembly needs a property! then i remembered that static types are guaranteed to be type safe, so why go through all that tedious locking code when you can simply do it all in one line, like this:

    public sealed class AppConfiguration
    {
    public static readonly AppConfiguration GetConfig = new AppConfiguration();

    ...

    voila! it's as easy as that, you now have a shared instance of your object. bear in mind that all member vars and methods/props will need to be static as well. so now it's time to load our configuration settings. there are numerous ways to parse through an XML document, but again for simplicity (and avoiding looping through the document and storing values in arrays of strings), XPath queries seem to be the easiest way to query for your settings. We go on in our code to creat a *private* constructor (so no one can instantiate your singleton), this will only get called once for the lifetime of the object...

    private AppConfiguration()
    {
    ... [code to load the config file into memory, see my previous post on the 28th...

    XmlDocument getConfig = new XmlDocument();

    try
    {
    getConfig.Load(_configFileName);
    _someMemberVar = getConfig.SelectSingleNode(
    "configuration/appSettings/add[@key='ValueYouWantToLoad']/@value").Value;

    ...repeat for all elements
    }

    now simply expose the member vars as readonly properties, now all calling code can easily read configuration settings.

    more to come, it's 6:05PM and i am still at work :-( friggin' long running queries keeping me here late again.

    cheerio
    j

  • Bedtime thoughts...

    if you are going to concat more than 2 strings, consider using a StringBuilder object...or just use the code below to obtain a nicely formatted string:

    public static string BuildStrings(params string[] stringsToBuild)
    {
    string delimiter = " ";

    // this will be the return string
    string builtString;

    // use a StringBuilder as the internal mechanism to build the string
    StringBuilder localBuilder = new StringBuilder();

    // loop through each string passed in and add it to the string to build
    foreach(string stringToBuild in stringsToBuild)
    {
    localBuilder.Append(delimiter);
    localBuilder.Append(stringToBuild);
    }
    builtString = localBuilder.ToString();
    return builtString;
    }

  • Tip of the day...

    VB.NET supplies the "Optional" keyword for parameters in methods, if none is supplied you can explicitely define a default value in the parameter signature. C# doesn't supply this functionality (and for good reason, it leads to lazy coding). it's good coding practice to always check the values of parameters in your components, and either throw an assertion or an exception if it's not supplied, like so:

    void myMethod(type myType1, type myType2...)
    {
    // check here for params that cannot be null, or "" for strings
    if(myType == null) throw new ArgumentNullException([message], [inner exception]...);
    // now check for validity of the param using regex, etc, you can't count on client code doing these checks
    if(myType != [some sort of criteria]) throw new ArgumentException ([message], [inner exception]...);
    }

    that being said, if you wanted to provide a default value, you can use ternary syntax to provide one

    void myMethod(type myType1, type myType2...)
    {
    myType1 != null ? MyType1 : [your default value here];
    }

    of course if you want to allow null values, you won't need to test for param values. if you follow these guidelines, you will insure that your components get used in the correct way.

    Tip number 2:

    ALWAYS ALWAYS ALWAYS call either string.Trim().ToLower() or string.Trim().ToUpper if you are using/comparing string params in C#...i spent the better part of 2 hours trying to track down a subtle bug, and it turned out to be that i was comparing strings that were spelled the same, however their ASCII values were different. VB.NET of course doesn't care about case, but it's good coding style nonetheless.

    happy coding :-)
    j
« First ... < Previous 85 86 87 88 89 Next >

Copyright © :: JaysonKnight.com
External Content © :: Respective Authors

Terms of Service/Privacy Policy