Singletons

[John W. Eaton]

On 25-May-2011, Jordi Gutiérrez Hermoso wrote:

| Sorry for feeling argumentative today, but Octave activity has been a
| little low lately, so I don't feel too bad about livening it up.

I can be argumentative too, but I'd rather play nice and I'd rather
not waste what little time I have to work on Octave at the moment
arguing about these kinds of things unless you have patches that you'd
like to propose which will actually improve something.

| It would in fact be relatively easy to change this
| code to simply namespace the global octave_fftw_planner object; the
| calling code in fftw.cc is in fact only using the class aspects of the
| singleton as namespacing. And the dtor is never called; it's in fact
| protected and the class is never derived from (and you would probably
| run into problems if you tried to subclass it).

Yes, you could do this but you'd still have to initialize the global
object somewhere and it seems better to me to have a container of
sorts (the singleton) that manages that instead of having a separate
init function and requiring a user to call that.  But maybe I'm
missing some magic bullet here, and you could use this particular case
to show how we can do things better.  But in this case the destructor
will still never be called unless you want to create a mechanism for
things like this so that all these singleton objects will be cleaned
up in Octave's clean_up_and_exit function.  Of course we could do that
with the current singleton approach simply by adding a function like

  static void SINGLETON::cleanup (void)
  {
    delete instance;
  }

to every singleton class, then adding something like

  cleanup_functions::add (SINGLETON::cleanup);

to the SINGLETON::instance_ok function, in which
cleanup_functions::add places the SINGLETON::cleanup function in a list
of functions to be called just before Octave exits.  This might
be interesting to try and see what effect it has on the amount of lost
memory that valgrind reports.

(Look, cleanup_functions could itself be a singleton!)

OTOH, we do have other classes which do use static class members as a
way of implementing namespaces.  That was done because those things
were written before namespaces were universally supported by C++
compilers.  It would be nice to fix those to use namespaces instead,
but that fix should probably be done when we think about putting all
of Octave inside a (set of) namespace(s).

| The point is that a singleton is antithetical to OOP because it's not

OK, so it is not OOP.  There's nothing that says that a program has to
be slavishly OO, is there?  As I said, I see benefits to using the
singleton class when there is global data to manage.  I don't think we
have over used this idiom in a bad way.

jwe