• (nodebb) 
    // Frist.h

class Frist
{
   /// Blah blah C++ stuf blah blah
}

static Frist* g_frist = Frist();

    That's got to work surely? I'll only get one in my program?

  • Anonymous Coward (unregistered)

    Obviously, the way to create singletons is to use pthread_once.

  • (nodebb)

    :%s/design pattern/bad programming/g

  • (author) in reply to Bananafish

    Most (but not all) uses of the singleton pattern are bad programming. It is almost always better to manage the lifecycle of a single instance through more conventional methods- like just creating one instance of it.

  • (nodebb)

    where, or where,

    Whether typo or eggcorn, that's really poetic! The more conventional phrase would be "where oh where".

  • (nodebb) in reply to jeremypnet

    What that will do is create a separate Frist instance for each compilation unit (.cpp file), not visible from other compilation units. To create a true program-wide singleton, you need to declare it as extern in the .h file, and have exactly one .cpp file defining the instance.

  • Duke of New York (unregistered)

    Singletons are not bad if you don't code singularity into the class. Then they're just classes that your application happens to have one of.

    What else are you going to do, create multiple resource pools and lose the benefit of pooling? Renegotiate a backend connection on each use? I've seen such things done in orgs that regarded application architecture as a nice-to-have-somewhere-else.

  • Klimax (unregistered)

    Pretty sure this is dual abuse. Abuse of singleton and abuse of OO aka classes. Was there any good reason why utils were class members instead of free-standing functions?

  • DoContra (unregistered) in reply to jeremypnet

    That code will get you one heap-allocated instance of Frist for every compilation unit that includes Frist.h. It is a bit of a pain to "properly" implement Singleton in C++ because initialization of global variables ("static initialization") before main() starts execution have no guarantees whatsoever. My aproximation for singletons in C++ is something like

    class mySingleInstance { //Class internals, everything marked static, private constructors //... static bool isInitialized; static void initialize() { if (isInitialized) { return; } //actual initialization code } } //... bool mySingleInstance::isInitialized = false;

    And then as near the top as possible in main() (or whatever is the very first bit of code that is guaranteed to need the class)

    mySingleInstance::initialize();

    (you could add mySingleInstance::initialize() to every class method for overly defensive coding with near assured side effects, or change the bool for a pointer to the class that has the actual implementations if you wish for everything to be heap allocated)

    "Fun" fact: The OG Singleton pattern worked due to a quirk/implementation detail of Sun's JVM at the time. Said quirk is now part of the Java/JVM specification.

  • xtal256 (unregistered)

    "g_Utility" kinda looks like "guilty", which nicely describes whoever wrote that code.

  • Your Name (unregistered)
    Comment held for moderation.
  • Farrah (unregistered)
    Comment held for moderation.

Leave a comment on “A Single Lint Problem”

Log In or post as a guest

Replying to comment #683140:

Log Out

« Return to Article