Re: A few questions about singletons...
On Sep 24, 4:03 pm, "Somebody" <someb...@cox.net> wrote:
So, I've been programming for 16 yrs in C++ and it seems like all the OO
interviews these days think you need to know design patterns to be a good
(or even decent) programmer :p. What ya gonna do eh? :)...
Anyways, this is what I have for my singleton class.
class CSingleton
{
protected:
CSingleton()
{
printf("CSingleton()\n");
}
~CSingleton()
{
printf("~CSingleton()\n");
}
static CSingleton* m_pInst;
public:
static CSingleton* GetInstance()
{
if (m_pInst == NULL)
m_pInst = new CSingleton;
return m_pInst;
}
};
CSingleton* CSingleton::m_pInst = NULL;
int _tmain(int argc, _TCHAR* argv[])
{
CSingleton* p1 = CSingleton::GetInstance();
CSingleton* p2 = CSingleton::GetInstance();
printf("--> %x %x\n", p1, p2);
return 0;
}
Works fine... except...
1) what is the interview approved way to clean up the created object? Hav=
ing
a static "clean up" method that the user is responsible for calling seems
completely retarded and anti-encapsulation. I've seen some solutions that
create a second CSingletonDestroyer class as static and pass in the point=
er.
Then when the CSingletonDestroyer class is killed naturally, it kills the
CSingleton...
2) but the CSingletonDestroyer() class brings up thread safeness issues..=
..
if I wrap my GetInstance() in a critical section how does the critical
section get initialized and cleaned up? I guess I can use a mutex, which
will solve the init problem since that can be static init'ed, but wheres =
the
clean up?
Keep in mind, I'm doing this for Windows jobs, so no "linux only" solutio=
ns
:).
Some interviewers seem to like to puff themselves up with some
knowledge they read about, but don't understand the pitfalls of. I
wouldn't want to work with someone like that anyway. I've had several
leads that thought they were hot poopy because they read the gang of 4
and learned some new words like "singleton". Ends up those same guys
created 6 months worth of debugging for me, because they don't
understand the pitfalls. I myself, plainly do not use singletons
anymore. It does not mean I don't understand it, it means I've decided
passing a reference to an object that is clearly documented has been
less of a headache then debugging through global and static release at
program exit. There is always going to be some guy that creates an
unwanted dependency on a singleton and doesn't understand the mess
they are making. You cannot control the actions of others, but you can
try to minimize the mistakes they will make.
I have to date to see a singleton that did not involve a global or
static of some sort. The problem of another global or static depending
on it is unescapable without shockers tied to the entire companies
nipples. Release order of globals and statics is undefined. Sometimes
it will break, sometimes not, but it will always give you a massive
headache when you get to debugging this reappearing/disappearing
problem.
Design patterns are great. Knowing about them is also great. Knowing
about the pitfalls is better. Knowing that everyone that touches your
code probably won't is excellance.
Thus I think the answer to 1) is - There is no compeltely safe way to
cleanup. Everyone needs to be aware of that and the dependency problem
it creates.
2) why bother with a static destroyer? You are just moving the issue
to another place. Maybe I would need to see a specific example to
understand....