Singletons / classes with only one member
W Karas
little reason to think it would ever make sense for the class to have
more than one instance. What are some criteria for deciding whether
it should even be a class? For example, does:
class A
{
private:
int a;
public:
void x();
void y();
};
A only_instance_of_a;
or
class A
{
private:
static int a;
public:
static void x();
static void y();
};
have major advantages over:
// Header file
namespace A
{
void x();
void y();
}
-------
// Implementation file.
namespace A
{
namespace Impl
{
int a;
}
using namespace Impl;
void x() { ... }
void y() { ... }
}
The one obvious advantage of a class is that privacy is strictly
enforced by the compiler (as opposed to putting private stuff in a sub-
namespace that is private by convention). The disadvantage of a class
is the classic problem of trying to minimize implementation details in
the header file for external code. I'm aware of the technique of
using a pointer or reference to class private data, but is it more
trouble than it's worth? It seem generally unintuitive to have a
class of objects with only one object in it.
Victor Bazarov
> Suppose you have a class that has only one instance,
You mean, "only one data member"?
> and there is
> little reason to think it would ever make sense for the class to have
> more than one instance. What are some criteria for deciding whether
> it should even be a class? [..]
Only make it a class if there is some *abstraction* you need to
represent in your program. For example (using your code), if you just
have an int somewhere, it's an int, and can be used anywhere the int can
be. If that int is wrapped in a class, the class instance (even if it's
only one per program) cannot be [easily] used where an int would go.
Another sentiment: it doesn't matter that your class has only one data
member. That's *implementation detail*, and it can change with time.
If you need a special type, have a special type. Don't design "from
bottom up", it's A BAD IDEA(tm). Design by describing your model. If
your model needs a class, have a class. How many data members it has is
of no consequence to the design itself.
V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
Walt
> W Karas wrote:
> > Suppose you have a class that has only one instance,
>
> You mean, "only one data member"?
No, I mean what I said.
>
> > and there is
>
> > little reason to think it would ever make sense for the class to have
> > more than one instance. What are some criteria for deciding whether
> > it should even be a class? [..]
>
> Only make it a class if there is some *abstraction* you need to
> represent in your program.
Part of my concern is whether a class abstraction is ever really
appropriate for one thing (considering the English meaning of the word
"class").
> For example (using your code)
The brevity of the example is for convenience, it is not germane. In
fact, the larger the example, the more relevant the question.
Immortal Nephi
> Suppose you have a class that has only one instance, and there is
> little reason to think it would ever make sense for the class to have
> more than one instance. What are some criteria for deciding whether
> it should even be a class? For example, does:
I ask myself the same question. You refer one instance. You mean one
variable per running program in memory. For example like procedural
programming.
// Header.h
int g_variable = 0; // Global Variable
void foo(int &g_v)
{
g_v++;
}
void foo2()
{
g_variable++;
}
// Main.cpp
#include "Header.h"
int main()
{
int var = 20;
foo(var); 1% slower
g_variable = var;
foo2(); // Faster
return 0;
}
According to my performance test. foo2() is faster than foo() because
it has fewer x86 instructions than foo() does. It looks like that 200
global functions do not have reference are able to modify g_variable
directly. One problem is that you don't know which global function
modify g_variable. It is a good design unless you wrap 200 global
functions and 10 global variables inside file scope. I am sure that
everyone agree to be a bad design, but critical performance is
important.
> class A
> {
> private:
> int a;
>
> public:
> void x();
> void y();
> };
You define A a; data member and function member are wrapped inside
class. It uses a pointer to access data member or function member
indirectly. It seems to be good performance. I don't recommend it
unless you create A array like A a[5] or A a1 and A a2.
> A only_instance_of_a;
>
> or
>
> class A
> {
> private:
> static int a;
>
> public:
> static void x();
> static void y();
> };
Class A with static on both data member and function member are better
because static causes them to become global variable and global
function like I described above. You should always use class because
you want encapsulation.
> have major advantages over:
>
> // Header file
>
> namespace A
> {
>
> void x();
> void y();
>
> }
>
> -------
>
> // Implementation file.
>
> namespace A
> {
>
> namespace Impl
> {
> int a;
>
> }
>
> using namespace Impl;
>
> void x() { ... }
> void y() { ... }
>
> }
I do not recommend namespace because it does not have encapsulation.
It has opened code, but class has closed code with encapsulation.
> The one obvious advantage of a class is that privacy is strictly
> enforced by the compiler (as opposed to putting private stuff in a sub-
> namespace that is private by convention). The disadvantage of a class
> is the classic problem of trying to minimize implementation details in
> the header file for external code. I'm aware of the technique of
> using a pointer or reference to class private data, but is it more
> trouble than it's worth? It seem generally unintuitive to have a
> class of objects with only one object in it.
Nephi
Walt
I think this could come out differently depending on the machine
architecture. Aren't there some architectures that are optimized for
the addressing mode of "register value + 16-bit immediate offset"?
...
Daniel T.
>
> Suppose you have a class that has only one instance, and
> there is little reason to think it would ever make sense
> for the class to have more than one instance. �What are
> some criteria for deciding whether it should even be a
> class?
The most important criteria is whether having more than one object of
the class would cause errors, or how important that constraint is.
Often I see programmers make a class a Singleton simply because they
cannot see any reason to have more than one object and want global
access to it. Rather than asking how likely it is that more than one
instance will exist, you should be asking if there would be any
problems with multiple instances existing.
> [examples snipped]
>
> The one obvious advantage of a class is that privacy is
> strictly enforced by the compiler (as opposed to putting
> private stuff in a sub-namespace that is private by
> convention).
Putting the private stuff in an unnamed namespace in the implimation
file is a pretty strict enforcement of privacy.
The obvious advantage of a class is that one can make multiple
instances at a later date, with little modification.
> The disadvantage of a class is the classic problem of
> trying to minimize implementation details in the header
> file for external code. �I'm aware of the technique of
> using a pointer or reference to class private data, but
> is it more trouble than it's worth? �It seem generally
> unintuitive to have a class of objects with only one
> object in it.
What you describe is often called the "pimpl" idiom. I suggest that it
only be used to provide compiler firewalls. I have had times when
modifying a header file meant a 30 minute recompile, and the class'
privates were still quite volitile. In those cases, the pimpl idiom
makes a lot of sinse, but not as a matter of course.
The keyword "class" is pretty overloaded in C++ code. It is often used
to express interfaces, namespaces, and clumps of pure data as well as
the classical notion of Class. I suggest that in those situations
where some other keyword would work just as well, maybe it's a good
idea to use it.
Walt
> On Feb 27, 12:30 pm, W Karas <wka...@yahoo.com> wrote:
>
>
>
> > Suppose you have a class that has only one instance, and
> > there is little reason to think it would ever make sense
> > for the class to have more than one instance. What are
> > some criteria for deciding whether it should even be a
> > class?
>
> The most important criteria is whether having more than one object of
> the class would cause errors, or how important that constraint is.
>
> Often I see programmers make a class a Singleton simply because they
> cannot see any reason to have more than one object and want global
> access to it. Rather than asking how likely it is that more than one
> instance will exist, you should be asking if there would be any
> problems with multiple instances existing.
>
> > [examples snipped]
>
> > The one obvious advantage of a class is that privacy is
> > strictly enforced by the compiler (as opposed to putting
> > private stuff in a sub-namespace that is private by
> > convention).
>
> Putting the private stuff in an unnamed namespace in the implimation
> file is a pretty strict enforcement of privacy.
Yes, that's the way to go if you're fairly sure the implementation
will never grow big enough so you'd want to break it up into multiple
implementation files. Then I don't see an alternate to a namespace
that's private by convention (except a class).
Puppet_Sock
[snip]
> The one obvious advantage of a class is that privacy is strictly
> enforced by the compiler (as opposed to putting private stuff in a sub-
> namespace that is private by convention). The disadvantage of a class
> is the classic problem of trying to minimize implementation details in
> the header file for external code. I'm aware of the technique of
> using a pointer or reference to class private data, but is it more
> trouble than it's worth? It seem generally unintuitive to have a
> class of objects with only one object in it.
Another possible advantage is that it can be a way to
document choices. Putting stuff in a class means you
have chosen to make things a particular way. Putting
stuff in a class means you get to document things through
the interface, maybe related types, the name of the class,
even related classes in a library or whatever other project
level grouping.
Socks
Walt
You can put related namespaces together in a libaray. But if by
"related classes" you mean classes in inheritance hierarchy, that's a
good point, you can't do that with namespaces.
Puppet_Sock
Not necessarily inheritance, though that is a possibility.
If there are no member functions, a namespace might do as
well as a class.
Maybe there is only one of the class in question. But maybe
there are other classes, not related through inheritance, but
related through some degree of similarity that does not work
well through inheritance. Maybe the only similarity is that
there is only one of each of them. Or they only have one member.
Or some other detail that is special to the context of the task
the program is written for.
Think of a class as an exporter of a service. Sometimes that
service is simply to hold some data. The POD notion. Sometimes
it's to provide a lot of functionality through member functions.
But another possible service is just to sit there and hold onto
some typing that documents some choices. And not always just
comments. But, as I said, for example the name of the class.
To make a silly example that probably wouldn't make it past any
serious code review, you could name the class something like
class OneDataMemberAndNothingElse
{
// stuff goes here
};
though that is intended to be obviously silly.
Depending on the context of the program, you coud do something
like a class called SingeltonThisHardwareStatus or some such
that held the status of a chunk of hardware that had a program
running on it.
I guess it's just that I've been reading a lot of "how to code"
books lately and I've got "make your code self documenting" on
the brain right now.
Socks
Walt
Sorry, I should have named this thread "Singletons / classes with only
one instance" (duh).
Another approach, allowing for true privacy:
// Header file
namespace A
{
void x();
void y();
}
-------
// Implementation file.
namespace A
{
class Impl
{
friend void x();
friend void y();
int a;
};
Impl impl;
void x() { ... impl.a ... }
void y() { ... impl.a ... }
}