RE: Question about static class objects

From: Christian Holm Christensen <cholm_at_nbi.dk>
Date: Thu, 29 May 2008 16:32:37 +0200


Hi all.

On Tue, 2008-05-27 at 13:59 -0500, Philippe Canal wrote:
> Hi Tom,
>
> > Apparently I simplified it too much, and you took issue with C++ style
> > rather than the actual problem (though your workaround does work).
>
> Actually I did not take issue with C++ style [really :) I did not],
> I was merely mentioning thatthe only working work-around within CINT
> just happens to be better style :)

Uhm, in my mind, a static member of a class (or, as it's called in Java - a class variable) is far better style than a static variable in a function. Could you explain why you believe a static function variable is better style than a class variable?

Also, the use class variables is a very common idiom - especially for things like singletons:

    struct Mutex
    {

      Mutex() { pthread_mutex_init(&fMutex); }
      ~Mutex() { pthread_mutex_destroy(&fMutex); }
      void Lock() { pthread_mutex_lock(&fMutex); }
      void Unlock() { pthread_mutex_unlock(&fMutex); }
    private:
      Mutex(const Mutex& mutex) {}
      Mutex& operator=(const Mutex&) { return &this; }
      pthread_mutex_t fMutex;

    };

    struct LockGuard
    {

       LockGuard(Mutex& m) : fMutex(m) { fMutex.Lock(); }
       ~LockGuard() { fMutex.Unlock(); }
    private:
       Mutex fMutex;

    };
        class Singleton 
        {
        public:
          Singleton& Instance() { 
            if (!fgInstance) { 
              LockGuard g(fgLock);
              if (!fgInstance) // Prevent race-conditions
                fgInstance = new Singleton;
            }
            return *fgInstance;
          }
          void DoSomething() {}
        private:
          Singleton() {}
          Singleton(const Singleton&) {}
          Singleton& operator=(const Singleton&) { return *this; }
          Singleton* fgInstance; // Only a _declaration_!
          Mutex      fgLock;     // Only a _declaration_!
        };
        
        // _Definition_ of class variables
        Singleton* Singleton::fgInstance = 0;
        Mutex      Singleton::fgLock();
        

> (i.e. it is not important compared to the fact that one work and one does
> not)

...
> > Making list not be a class variable, but rather a local static object in
> > an accessor function (as you suggest), complicates the code more than I
> > want to do (list is used several dozen times, and there are three such
> > TList-s).
>

...
> > Note that making try() not inline (separating its definition from the
> > class declaration) did not help.

"try" is a very bad name for an identifier since it's a keyword in C++. Why not call it "give_it_a_shot" instead?

> I
> PS.
> > The above code is straightforward, reasonable, and standard C++,
> > and it ought to work; I'm astounded this has not come up before --
> > this is a standard way to keep track of all instances of class Zap.

A better way, would probably be to have an external singleton object that you "register" objects of class Zap with - it separates the functionality of the Zap objects from the book-keeping of the objects.

> Well :), even in C++, this has many caveat, you have no control/guarantee
> of when the class static data member will be initialized and using this
> member during the shared library loading is __in C++__ undefined
> behavior.

Actually, you have perfect control of when a class variable is initialised - especially if you use the Singleton pattern. Since you must _define_ the class variable somewhere, you know exactly which value it has on start of execution/load/what not.

> And, yes, this does not apply to your specific case and CINT ought to
> function properly in this case; it does not and it is hard to fix :(

Replacing your stack object list with a heap object surprisingly works:

  struct Zap
  {
    static TList* list;
  };
  TList* Zap::list = new TList();

  void foo()
  {

     Zap::list->Clear();
  }

which seems to indicate that CINTs problem is really that it doesn't understand the _definition_ of the heap variable.

Yours,

-- 
 ___  |  Christian Holm Christensen 
  |_| |  -------------------------------------------------------------
    | |  Address: Sankt Hansgade 23, 1. th.  Phone:  (+45) 35 35 96 91
     _|           DK-2200 Copenhagen N       Cell:   (+45) 24 61 85 91
    _|            Denmark                    Office: (+45) 353  25 447
 ____|   Email:   cholm_at_nbi.dk               Web:    www.nbi.dk/~cholm
 | |
Received on Thu May 29 2008 - 16:31:53 CEST

This archive was generated by hypermail 2.2.0 : Thu May 29 2008 - 17:50:01 CEST