• Suomynona (unregistered) in reply to JamesCurran
    JamesCurran:
    Next is from Kyle, who found the root cause behind the failure of long-running daemons ... 

    TODAY = today()
    YESTERDAY = yesterday()
    Am I missing something here? I can see how it's a dumb thing to do, but I don't see the connection between that and the failure of long-running daemons.


    Well, taking a time value in several distinct calls is certainly a WTF. Imagine what happens when the clock crosses a minute/hour/day/month/year boundary just in between those calls. If you take a lesser portion before a higher portion, you can cause a mysterious "time warp" to the future, like January 31, 23:59 (thats 11:59 p.m. for our US readers) instead of January 1, 00:00 or December 31, 23:59. If you determine a higher portion before a lesser portion, you can likewise have the time warp back into the past.

    The funniest possible effect, though, is probably that you may even get an invalid date, like February 31 when the clock just switches from January 31 to February 1.

  • (cs) in reply to Brian
    Brian:
    On the Power PC (and maybe on x86 too) constants may have bad data locality and take two instructions to load.  Using gConsts.zero rather than 0.0 may end up taking half as many instructions if a bunch of constants are used in a function.  This is because it only has to load the address of gConsts once then it can just use offsets to get the other values.
     
    Brian: What about level 1 and level 2 cache, which most architectures have?  Don't fall into the trap of trying to optimize away ONE low-level instruction.
  • Munk Yee (unregistered)

    Yeah, you are "a bit disturbing", but that's why we come here.

    BTW, you mean I have to type "INT_ZERO" to get a gawldang 0?!  And who says my local version of zero has to be the same as your local version of zero.  You mind your business I'll mind mine.

  • (cs) in reply to Pax
    Anonymous:
    This goes back a looong way.  I beleive the original K&R suggested using the line
         #define PI 3.14159
    should "the value of PI change in future"


    Hey, with engineers, you can never be sure.  PI could be 3.14 one day, 3.14159 another day, and 3 the next. [:)]
  • (cs) in reply to mizhi
    mizhi:
    Anonymous:
    This goes back a looong way.  I beleive the original K&R suggested using the line
         #define PI 3.14159
    should "the value of PI change in future"


    Hey, with engineers, you can never be sure.  PI could be 3.14 one day, 3.14159 another day, and 3 the next. [:)]


    This is why we need a binary float literal syntax...
  • (cs) in reply to Maurits
    Maurits:
    mizhi:
    Anonymous:
    This goes back a looong way.  I beleive the original K&R suggested using the line
         #define PI 3.14159
    should "the value of PI change in future"


    Hey, with engineers, you can never be sure.  PI could be 3.14 one day, 3.14159 another day, and 3 the next. [:)]


    This is why we need a binary float literal syntax...


    The absolute best way to obtain pi that I've ever seen is this one:

    static const double pi = atan2(0.0, -1.0);

    You're guaranteed the most accurrate value no matter if your architecture is 16, 32, or 64 bit.

  • Ant (unregistered)

    What makes this worse than verbosity codified, is that fact that its plain wrong :

    <font>private const int </font>INT_TWENTY_SEVEN = 28;  //err, no it isn't

  • (cs) in reply to Ant

    /* minitru.h /
    const int TWO_PLUS_TWO = 5; /     Ignorance is Strength */

Leave a comment on “A Constant Barrage”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article