• Andrew (unregistered)

    I can see that this post has generated very interesting responses.

    Personaly I'm fun of if...else solution. I really doubt that parsing command line arguments is the real bottle neck of any application.  I would focuse on improving other parts of the application.

     

  • Crusty Parser (unregistered) in reply to manifoldronin
    manifoldronin:
    You can't really appreciate how much java sucks until you are obligated to write java code every god-damned day to feed your children.If you are obligated to write any thing every goddamned day to feed your children, that "any thing" inevitably sucks, java or non-java. Another (unrelated) point: IIRC, in Java 7, the switch statement will support string literals as cases.

    I hated java and perl so much, I moved just about everything over to python. Now I love what I do every day.

    Nothing is inevitable, every problem is not a nail, and every tool is not a hammer.

  • Koos (unregistered)

    all of this is probably inspired by MS' remarks on string-Hashcodes: For example, the implementation of GetHashCode provided by the String class returns unique hash codes for unique string values. (This obviously cannot be true because GetHashCode returns a 32-bit integer value and many more string values exist)

  • steve (unregistered)

    The real WTF is that the programmer went to all the trouble of converting the string "single" to an int and the user is still required to type out the entire word. Why solve the problem of needing 7 precious bytes to represent the constant "single\0" and not save the user a few keystrokes while you're at it?

    The obvious solution is to create an int based on the first two chars and simply ignore the rest of the chars in the parameter. Then document that all parameters may be shortened to two characters, and re-label it a "feature": The user need only type "si" when they mean "single".

    The program's behavior will also be well-defined for any conceivable input, since colliding parameters will be obvious and easy to find. Most of the time you want to avoid hash collisions, but in this case a definitive "yes, that will collide" is better than "I doubt it, but I'd need to compute its hash to be certain".

    The only catch is that if you want to map two chars directly to an int16 with no conversion (in an embedded system, that's probably the simplest and best way to do it), you have to know which byte order the system uses.

Leave a comment on “How Not to Parse Command Line Arguments”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article