Schrödinger's entity



  • void Entity::SetDeadState(const bool isDead)
    {
        m_bIsDead = isDead;

        if (m_bIsDead)
        {
            m_bIsDead = false;
            Kill();
        }
        else
        {
            m_bIsDead = true;
            Resurrect();
        }
    }

    Both the Kill and Resurrect functions set the m_bIsDead variable to either true or false, depending on if it was just killed or resurrected. So... yeah, not really sure what the person who did that was trying to accomplish. Apparently they were stress testing the bits?



  • So it does completely the opposite of what you tell it to do (after briefly, sort-of-but-not-quite doing what you told it to do)?



    What game are you making?


  • Considered Harmful

    @eViLegion said:

    So it does completely the opposite of what you tell it to do (after briefly, sort-of-but-not-quite doing what you told it to do)?

    Presumably it sets it to alive so Kill() will run, or dead so Resurrect() will work. It's OK to perturb invariants as long as you restore them by the time the method returns.



  • @eViLegion said:

    So it does completely the opposite of what you tell it to do (after briefly, sort-of-but-not-quite doing what you told it to do)?



    What game are you making?

    It's not a game, it's a simulator. Thankfully not a full motion rig, I'd hate to think we'd actually killed someone with a bug. It does actually do what you expect, Kill and Resurrect set the flag when they are complete to the correct state.



    @joe.edwards said:
    @eViLegion said:
    So it does completely the opposite of what you tell it to do (after briefly, sort-of-but-not-quite doing what you told it to do)?

    Presumably it sets it to alive so Kill() will run, or dead so Resurrect() will work. It's OK to perturb invariants as long as you restore them by the time the method returns.

    Pretty much this, although it was abusing that boolean pretty badly.


  • Oh I see. That really is horrible.



    Surely the "SetDeadState" should just ignore m_bIsDead completely, and simply do



    if (bDead) { Kill(); } else { Resurrect(); }



    with the Kill and Resurrect functions taking care to guard themselves with m_bIsDead, and set it when they're done.



    Seems an obvious candidate to be inline as well, since Anyone writing SetDeadState(true) would be better off just calling Kill() directly, and vice versa.



  • @eViLegion said:

    Oh I see. That really is horrible.



    Surely the "SetDeadState" should just ignore m_bIsDead completely, and simply do



    if (bDead) { Kill(); } else { Resurrect(); }



    with the Kill and Resurrect functions taking care to guard themselves with m_bIsDead, and set it when they're done.



    Seems an obvious candidate to be inline as well, since Anyone writing SetDeadState(true) would be better off just calling Kill() directly, and vice versa.

    That's what it does now. :)



  • @CodeNinja said:

    That's what it does now. :)

    Excellent work!



  • @eViLegion said:

    So it does completely the opposite of what you tell it to do (after briefly, sort-of-but-not-quite doing what you told it to do)?

    What game are you making?
    It's not a game.  It's a signup page for health insurance.



  • @CodeNinja said:


    void Entity::SetDeadState(const bool isDead)

    {

        m_bIsDead = isDead;



        if (m_bIsDead)

        {

            m_bIsDead = false;

            Kill();

        }

        else

        {

            m_bIsDead = true;

            Resurrect();

        }

    }

    Both the Kill and Resurrect functions set the m_bIsDead variable to either true or false, depending on if it was just killed or resurrected. So... yeah, not really sure what the person who did that was trying to accomplish. Apparently they were stress testing the bits?

    The m_ prefix suggests module-level scope to me, which means m_bisDead might be accessible to Kill() and Resurrect(), which means they might be testing it and doing nothing if it's already in the "correct" state (you can't kill the dead, etc). Forcing it before the call might be intended to ensure that Kill() and Resurrect() both run to completion when called via SetDeadState().

    Not particularly defensible; perhaps explanatory.



  • TRWTF: My boss wants me to put it back.


  • Discourse touched me in a no-no place

    @CodeNinja said:

    TRWTF: My boss wants me to put it back.
    Does he want to Kill() the already-dead? You cannot kill what does not live!



  • @CodeNinja said:

    TRWTF: My boss wants me to put it back.

    OH FFS. Can I give you my telephone number, and you get him to ring me, so I can tell him what a cunt he is?


  • Trolleybus Mechanic

    @dkf said:

    @CodeNinja said:

    TRWTF: My boss wants me to put it back.
    Does he want to Kill() the already-dead? You cannot kill what does not live!

     

    But you can chainsaw it into tiny peice to make it immobile and ineffective.

     


  • Considered Harmful

    @dkf said:

    @CodeNinja said:

    TRWTF: My boss wants me to put it back.
    Does he want to Kill() the already-dead? You cannot kill what does not live!


    That is not dead which can eternal lie. And with strange aeons even death may die.


Log in to reply