Re: private constructors => singleton
godescbach <g.o.d.e.s.c.b.a.c.h@yahoo.com> writes:
On 20 Apr 2006 12:49:55 +0200, "Imre Palik"
<firstname.lastname.ext@automation.siemens.com> wrote:
"dan2online" <danielhe99@gmail.com> writes:
Hi,
Preets wrote:
Can anyone explain to me the exact use of private constructors in c++ ?
If you write a singleton class in C++. you will need to play some
tricks make all constructors private, including default, copy and
assignment operators.
Could you explain the reasons why would somebody write a singleton class in
C++ instead of using the good old C-style singleton pattern?
The advantages of the C-style singleton (file-local data with public
interface) are better information hiding, and built in compiler firewall.
But what are the advantages of the singleton class?
One reason you might want to use a singleton is to inherit behaviour
from another class.
I'm not sure if it is meaningful to apply the Liskov substitution principle
to singletons. But anyway, you can easily hide the singletonness behind an
ordinary class.
I mean something like this:
// singleton.H
// includes, no need to include the definition of foo here.
struct singleton_interface
{
singleton_interface();
~singleton interface();
void fiddle_with_it();
void set_fubar(fubar fb);
// ...
};
// singleton.C
// includes
static fubar fb_;
static foo bar_;
// other file-scope data
void
singleton_interface::fiddle_with_it()
{
// play with the file scope data
}
void
singleton_interface::set_fubar(fubar fb)
{
fb_ = fb;
}
// other methodes
In this case you have an ordinary C++ class (but w.o. data members), that
still behaves as if it would be a singleton. So if you need a class
because you have to implement a prescribed interface, that is no excuse for
those pesky get_instance() methods ;-)
Perhaps you want to group a one or more objects into one singleton to
ensure only one instance for a particular program. The classes that
define these objects are not singletons because they can have more
that one instance in other programs.
This is simple containment. You can easily take care of it with file scope
data
IMO, it is best to group data and the functions that operate on it in
a class. This takes information hiding a step further by putting the
data and its functionality into class. All access must go through the
class. Not sure what you mean by 'compiler firewall' or how using the
C-style has any advantage over a class singleton in terms of the
compiler.
Even better information hiding :-) That is, being polite, and not showing
the private parts of the class on the interface. With C-style singleton,
you only need the headers defining the types used by the implementation
(i.e., private data), to compile the implementation file. They are totally
unnecessary when compiling user code.
Clients of a singleton class don't really know or care if the class is
a singleton. It does not impact the interface.
You have to get a reference to the singleton from somewhere. This will
lead to lines like this:
newbar = foo:get_instance().fornicate(bar);
I would consider this as an impact on the interface.
Using the C-style
singleton your public interface doesn't need a reference to the object
passed in because you interface knows there's only one instance with
which to work.
This is not necessarily true. Especially if you have the class-like
interface described above, which could be abused to hold an instance ID,
that is used to as an index to e.g., some file local container.
So someone looking at youi code can tell if a group of
functions operating on some data are operating on only one instance of
that data. The class singleton is better at hiding this fact. But
this is rather subjective in any case.
Sorry, but I can't really get this part. Could you explain?
ImRe