• (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)

    Besides the weird way to initialise (I rather have a global reference than a pointer). A linter that doesn't know to look for side effects of instancing a variable in C++ is utter garbage. Get rid of it.

  • Farrah (unregistered)

    Just use Meyer's singleton:

    class SingletonClass {
    public:
    static SingletonClass& instance() {
        static SingletonClass x;
        return x;
    }
    ...
};

    It is simple to write, lazy initialized and thread safe (instantiation, not use).

  • (nodebb)

    To my knowledge .net is the only OO framework which guarantees that a static constructor is instanced only ONCE and BEFORE the type containing it is used which makes static member fields natural singletons.

    public sealed class Utitlities
{
    private Utilities() { }

    public static Utilities Instance { get; } = new();
}

    Now in C++ (and other languages like Java) you don't have this luxury. In fact in C++ it isn't even defined when static variables are instances, so you have to do something like this instead:

    public class CUtitlities
{
    public: 
        static Utilities Instance() 
        {
              static CUtilities instance;
              return instance;
        }

        Utilities(Utilities const&) = delete;
        void operator=(Utilities const&) = delete;

    private: 
        Utilities() { }    
}

    Addendum 2025-08-12 05:06: And then out of habit I put a public in front of class for C++ ... ah, it really shows that I'm mostly writing C# these days.

  • maurizio (unregistered)

    "Stop being clever and don't try and apply a design pattern for the sake of saying you used a design pattern." Yes, this is the point: i spent the last 15 years reading other people code (something around a few millions line of code each year) and i still haven't found code where the developers don't fall in this trap; i think that certain approaches to design pattern are the biggest plague in modern IT, because they teach to stop thinking, and blindly apply solutions that have been developed for problems that have nothing to do with the system at hand.

  • ProblematicLint (unregistered) in reply to jeremypnet

    In C++, static outside of any class/struct just makes the variable local to the file. In case of header, it means every file that includes it will get its own copy. Opposite of what you want for a singleton.

    It has a yet third unrelated meaning when used for a local variable in function, which basically makes variable "shared" between invocations of the function (which does happen to be a legit way to implement a singleton, i.e. Singleton* getInstance() { static Singleton instance; return &instance; })

Leave a comment on “A Single Lint Problem”

Log In or post as a guest

Replying to comment #683156:

Log Out

« Return to Article