• some guy (unregistered)

    Frist of all, that's brillant, because you got rid of all those complicated fields in your class. An anti-struct, if you will. Secondly, all the unit tests with the single "instantiations" pass - seems like a you problem.

  • Industrial Automation Engineer (unregistered)

    The thought that scares me most is: how can the application even mimic something reasonable? How effed up must the application be to even remotely able to work with these anti-patterns? What architecture is robust enough to take this nonsense?

  • (nodebb) in reply to Industrial Automation Engineer

    The object might just be a "coincidental" singleton, that is, a thing there's only ever one of for practical purposes, but it's really meant to be a "true" singleton (with a static "get_instance()" method, and all the tra-la), and this is the other developer's way of achieving that without making it a real "true" singleton.

  • (nodebb)

    My guess is that someone couldn't figure out the syntax for a static member variable but knew how function-level static variables worked. Since the two get/set functions can't share the static variable, they created a common function to hold the static, but exposed two separate get/set functions for the interface.

  • (nodebb)

    getter/setters, or properties as they sometimes are called, are not an anti pattern, they are a concept from design by contract and are super valuable because they abstract contract from implementation. In all good languages they are a zero-cost feature do to inlining at a compile level (like C/C++/C#) and even on more meh languages like Java they still offer a very low overhead do to concepts like PGO.

    Now why is a contract relevant; well, it allows backwards compatibility and clarity of expression. So basically you can future proof code, which is not the case with (instance) member variables on types.

    That said, properties can be abused. Expected behaviors are as important to contracts as is the syntax. So if you actually turn a field into a property (or use getter/setters in language that don't have properties directly), you expect them to behave like properties. So no long running execution times or observable side effects especially when it comes to state or concurrency.

    Addendum 2025-04-17 12:08: For completion sake, yeah everything about setGetField is garbage - there's no way to sugarcoat it really.

  • Guessed (unregistered) in reply to davethepirate

    My guess is that someone couldn't figure out the syntax for a static member variable but knew how function-level static variables worked. Since the two get/set functions can't share the static variable, they created a common function to hold the static, but exposed two separate get/set functions for the interface.

    That is disturbingly plausible, but if you're willing to go full WTF (as the author of this code clearly is), you could just do:

    private:
int &fieldref() {
    static int s_val = 0;
    return s_val;
}

public:
void setField(int val) {
    fieldref() = val;
}

int getField() {
    return fieldref();
}

    Function-level static, but no weird boolean-controlled set/get logic.

  • (nodebb) in reply to davethepirate

    I can totally see this being the result of trying the proper way to do this, but continuously getting the syntax slightly wrong, and after a day of banging their head against the wall, settling on this because it worked. And then thinking that this must be the way to do it, due to what they believe are "idiosyncrasies of the language", and not due to them "being unable to read a manual".

  • (nodebb)

    These CSOD are amazing. Not in a million years would have I had been creative enough to think of such a twisted pattern.

    But there it is. Someone not only thought about it, they actually implemented it. It would almost be pure genius if it had been done in a cynical way, like some kind of obfuscated C contest. Sadly, it probably wasn't.

  • (nodebb)

    @prueg. Yeah, this.

Leave a comment on “Static State”

Log In or post as a guest

Replying to comment #678963:

Log Out

« Return to Article