• whicker (unregistered)

    The division algorithm is absolutely beautiful.

  • (cs)

    throw-ing has GOT to be faster than return-ing, right?

  • En3pY (unregistered)

    Well... I really miss ASM programming times :(

  • sobani (unregistered)

    Of course it's faster. For every method that gets called, you save a whole return operation.

    captcha: smaile :-)

  • Hit (unregistered)

    Egads!

    Nice work. Although not nearly enough exception abuse for my tastes.

    Given that C++ supports exceptions, I'd be surprised if there wasn't at least one entry that introduces the wonderful paradigm of "exceptional programming".

  • (cs) in reply to whicker
    whicker:
    The division algorithm is absolutely beautiful.
    Why thank you.

    I hope you guys enjoy reading my code as much as I enjoyed writing it. This contest is a lot of fun and I can't wait to see the rest of the entries.

  • Look at me! I'm on the internets (unregistered)

    Well, even if it doesn't win, It should get an honourable mention for Best Comment: This algorithm is pre-optimized so as to not confuse the compiler.

  • %USERNAME% (unregistered)

    That's the first of the entries which I'm looking at, and it's cute. I especially like the version number of the documentation. I am just wondering whether the next version will be "Err+1" or "Err^2".

  • Foobar (unregistered)

    CAPTCHA: tastey.

    It sucks to install a captcha remover that doesn't work.

  • Foobar (unregistered) in reply to Foobar

    CAPTCHA: Testing

    Ninjas?

  • Anonymus (unregistered)

    If the programmer was REALLY talented, he'd have used recursive exceptions!

    CAPTCHA: riaa. And I'm listening to Internet radio...

  • (cs)

    Ah! Returning values by throwing, that's clever. It also supports dynamic typing, unlike return! E.g. a function can have variant return types by throwing them instead of using the return keyword. Something like:

    try { GetValue(); } catch(int i) { /* int was returned / } catch(string s) { / string was returned */ } ...

    I will definitely start replacing all my returns with throws in my future projects.

  • SomeCoder (unregistered) in reply to vilcans
    vilcans:
    Ah! Returning values by throwing, that's clever. It also supports dynamic typing, unlike return! E.g. a function can have variant return types by throwing them instead of using the return keyword. Something like:

    try { GetValue(); } catch(int i) { /* int was returned / } catch(string s) { / string was returned */ } ...

    I will definitely start replacing all my returns with throws in my future projects.

    Oh dear god! The pain! My eyes! The goggles do nothing!

    :)

  • Klaus (unregistered)

    I love this so much! The savings of layerjumping and the namespace mumbo jumbo is encredible.

  • OMGWTF (unregistered)
    TerseCalc's innovative n-tiered architecture allows for the math tier to directly return values to the UI layer, without stopping in the middle parsing layer!

    Then i guess all those ExceptionHandlers (one for each function!) and stack unwinding are faster than returning.

    Come on! As everybody knows, you must pass the result via a global variable. You're encouraged to have a doeen an decide on which one should the result be stored based on a dice, you never know if the memory position where you store results get corrupted. Easier than adding mathematical coprocessors, computers should provide some fast-access memory for this variables, something called Earning Access Xpeed or abbreviated, EAX.

    Ah, and for unwiding, you simply set the stack to 0 and manually set EIP. Why throw something when you can JUMP?

  • dkf (unregistered) in reply to OMGWTF
    OMGWTF :
    Come on! As everybody knows, you must pass the result via a global variable.
    Only in threaded code...
  • bill (unregistered) in reply to whicker

    I especially like the last 4 lines of the division function:

    char buffer[25];
sprintf(buffer,(remainder!=0)?("%i.%i"):("%i"),quotient,remainder); // Reason why Numbers are stored as strings
throw new string(buffer);
throw new string(ERROR);

    a 25 char buffer because obviously a number cannot be more than 25 chars long;

    sprintf with a conditional statement inside it for the special case of having a remainder (and a remainder doesn't appear to actually be a remainder, but rather a fractional part; that, according to the comment documentation, can only be one digit long)

    throwing the return value

    unreachable code that would throw an ERROR.

  • (cs) in reply to bill

    The remainder can be more than one digit long if you use #define TEN 100 instead of #define TEN 10. The logarithm of TEN base 10 is the number of decimal places it can print. The trouble is #defining TEN to anything other than 10 results in incredibly slow division. It has the added bonus of giving a non-base-10 decimal result if you set it to something other than a power of 10.

    And I'm sad that, of all the entries currently presented, mine has the fewest comments. :(

  • miraculix.x (unregistered) in reply to lizardfoot

    throw-ing certainly is NOT faster than return-ing. Consider that for every throw-operation the compiler has to ensure the stack gets cleaned up. In fact, any code block with exception handling in it will cause additional epilog / prolog code to register/handle any throw and catch blocks. At the end that means more statements to execute, less efficiency.

    some stuff to read: http://blogs.msdn.com/ricom/archive/2003/12/19/44697.aspx http://www.nwcpp.org/Downloads/2006/ehc.ppt http://www.codeproject.com/cpp/exceptionhandler.asp

  • Mania (unregistered) in reply to miraculix.x

    Miraculix, apparently you missed some lectures on exceptions. Whilst it is not recommended to use as an alternative to returning in the general case, in exceptional cases it is recommended.

    Your links state this exactly.

    An exceptional circumstance would be for a function designed to be recursively called hundreds of levels deep, to actually return without calling itself again.

    Also, by the very fact that you've arrived at the end shows that an exception hasn't been raised recently. This is easily proved through mathematical induction.

    Now what's the quickest way to return from this deep nest, once you've got your result? To throw an exception clearly. Yes, more work has to be done then a simple ret and stackptr--, but if you can skip past hundreds of these simple rets by a throw, it's bound to be quicker.

    Your code becomes more readable, it's faster, and it employs generally accepted programming principles.

  • A-Nona-Mouse (unregistered) in reply to vilcans

    Actually I HAVE seen this in production code!!!!!

  • (cs) in reply to miraculix.x
    miraculix.x:
    throw-ing certainly is NOT faster than return-ing. Consider that for every throw-operation the compiler has to ensure the stack gets cleaned up. In fact, any code block with exception handling in it will cause additional epilog / prolog code to register/handle any throw and catch blocks. At the end that means more statements to execute, less efficiency.

    miraculix, i think you must be a newbie here.

Leave a comment on “OMGWTF Finalist #04: TerseCalc”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article