Re: StateFull vs Stateless Singleton
On Jul 6, 1:21 am, =D6=F6 Tiib <oot...@hot.ee> wrote:
On 5 juuli, 21:06, James Kanze <james.ka...@gmail.com> wrote:
On Jul 5, 6:05 pm, =D6=F6 Tiib <oot...@hot.ee> wrote:
[...]
As is the code which captures the command line and its options.
Command line is passed to main() and so main() passes it to
some singleton? Why it should be a singleton?
Because there can't be more than one command line. Options have
to register before main is called (from the constructor of
a static object), so you need something to handle the order of
initialization issues.
These are command line arguments for something that will be
further called by main(). Why there must be a global singleton
that holds its options?
Because no one component is interested in all of the options.
OK, may be it is reasonable. However such options may be passed to
component run-time as well? What is the difference if the source is
command line or some user command to change them later, run-time?
If there is some user command to change them later, then they
aren't command line options. Long running programs don't
normally use command line options (other than the specify the
configuration files); they use configuration files, and if the
user can issue commands to modify the configuration on the fly,
they probably rewrite the configuration file as well. Command
line options are for short running programs, which do one thing
and exit (like a compiler). My options are variables at
namespace scope. Preferrably local to the module in which they
are used. The constructor calls a function in CommandLine which
enrols them.
While convenient at some levels, this solution isn't perfect.
You've still got to find all of those options when it comes to
writing the man page or help text. But globally, I've found it
very useful to be able to define an option in the module which
uses it, without having to modify any central code which "knows"
all of the options.
However that does not worry me, after all there are very few
things that directly depend on command line and that command
line does not likely change during program run.
Not once it has been parsed. But Option enroles with the
CommandLine class, so that it can correctly pick up options when
it parses the command line.
Ok, there is just one command line and pretending there may be
several is pointless when there are no other sources of
options.
Even when much of the configuration may come from
a configuration file, it's useful to access it through a single
co-ordinator. (I have, or maybe only had, code somewhere which
does this. It's a singleton which maintains a list of
configuration sources; when you ask it for a value, it goes
through the list, returning the first it finds. First in the
list is typically a collection of options, registered with the
command line, followed by an object which reads environment
variables, followed by one or more files, followed by an object
which returns the defaults.)
In a multithreaded application, the thread manager (which
ensures e.g. a clean shutdown) must be a singleton.
At the moment yes, application (or some framework that it
uses) has to orchestrate shutdown itself. Again, when i do not
get rid of single things then i do not like
"ShutDownManager::instance().doIt()". I prefer to have
shutDown() function. If nothing else then faking it for a unit
test is lot cheaper.
The main argument against this solution is that it doesn't work.
The task manager has to know about all of the tasks, so that it
can signal them in case of a shutdown request, then wait until
they've finished.
To expose something to a function is actually as hard as to expose it
to a class, isn't it? Ok, task manager. I do not still see why there
must be a class for it.
It needs to be a container, which can contain a variable number
of entries. Thus, a class. You can use std::vector<Thread*> if
you want, but in that case, you may still want to handle order
of initialization issues, in order to allow threads to be
started from the constructor of a static object. (Not usually
a good idea, but there are probably cases where it is
justified.)
namespace taskmanager {
void shutDown(); // shortest thing to say.
// other operations with task manager.
}
And where do you put the data that taskmanager::shutDown needs
to manipulate? Data which is also accessed each time you start
a thread, etc.
It might be feels like C way of information hiding, but
nameless namespaces are exactly for that ... like i understand
the standard. Sure, it may be a class too.
Unnamed namespaces are only accessible from the translation unit
in which they occur. Something like a thread probably has
a couple of different globally accessible functions; if it's in
library code, each will be in a separate file.
(Thinking about it, this seems to be a common theme of
singletons. The have to know about all of the instances of
something else: threads, temporary files, etc.)
Yes. For example factories. I prefer factory functions when
there are limits so creation (or destruction, or reusage) of
something should not be made in usual ways. How a factory
function achieves it is implementation detail. It may use real
singletons that are defined in (nameless namespace in)
translation unit that defines such factory function.
The classical singleton is nothing more than a factory function.
With the twist that it always returns the same instance, rather
than a new one each time.
Such design likely removes (or adds flexibility how to handle) the
issues that may be with construction/destruction order of singletons.
Namespace also naturally does not let any usual questions about
classes (like what if i copy or derive from or use as member or
delete) to be asked with straight face.
[...]
Yes. More generally, however, when single instances of data are
involved, I prefer to wrap in a class than in a namespace. Once
I've defined the class, no one else can get at the data.
I believe nameless namespace in a translation unit is deepest place
where single instance of data can be hidden with C++.
It's too deep, since only the functions in that one translation
unit can get too it. (Actually, it depends, and in cases where
a helper class or helper functions are only needed in a single
function, I'll put them in the unnamed namespace. I'm also
fairly fond of using namespaces named XxxPrivate, defined in
a local header which isn't exported.)
--
James Kanze