Singletons

[John W. Eaton]

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

| Well, as an example that I got curious about from your list further
| below, from reading the source of src/DLD-FUNCTIONS/fftw.cc and the
| associated liboctave/oct-fftw.* files, I see that initialisation is
| right now done at the moment when octave_fftw_planner::method() is
| first called (which calls instance_ok which in turn attempts the
| initialisation). 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).
| 
| [...]
| 
| Some of these shouldn't really exist for the entire execution, right?
| The fftw stuff should be deleted when Octave is done working with fft;
| same if all sparse matrices go out of scope, as well as graphical
| stuff. Is this correct?

Not necessarily.  For example, the fft planner holds state about how
to compute the next FFT calculation, right?  So it has to stay around
as long as there is some possibility that fftw will be called again.
Likewise for spparms and graphics state, fonts, command editor and
history, etc.  So as far as I can tell, these things never go out of
scope.

But again, if you think that something could be improved, propose a
patch.

jwe