Re: [ALACPP] Singleton clarification

[Christopher Smith <x@xxxxxxxx>]

On Thu, 2003-06-19 at 11:03, arlo@xxxxxxxxx wrote:
> Overall, I have to agree with Chris on the Singleton issue. This is especially
> the case in C++ in Windows. We had merry hell last winter because our system
> was divided into multiple DLLs. Static variables are one-per-PE-per-process,
> and wre the usual low-level implementation of singletons. Thus, what we though
> was one-per-process was actually one-per-DLL-per-process, and the sharing of
> data didn't work out well.

Egads! I remember having this problem as well. As I recall I ended up
some crazy stuff with Win32 synchronization objects & shared memory to
fix this problem. Much like the Java class-loader issue, it proves to be
quite difficult in various scenarios to actually achieve
one-per-process. Exposing every singleton access method through a DLL
interface the other approach that worked reasonably well, although it
obviously made encapsulation a fair bit of a pain.

> This is a common implementation of the Monostate pattern (see

Cool! I have new pattern name for a technique I use all the time!

> http://www.objectmentor.com/resources/articles/SingletonAndMonostate.pdf, by
> Robert Martin). It does have a number of advantages over Singleton, and there
> are more advanced implementations that get around some of its remaining
> problems. Still, it gets complex and shows issues when you dynamically load /
> unload PEs, or when you have mutually dependent monostates (and need to write
> phoenix-like behavior, or something).

I find "static locals" tend to avoid a lot of the mutual dependency
problems with just a small amount of design work. Definitely the big
thing with Singletons or Monostates is to decide what the scope of your
"only one" statement is, and then figure out how you are going to
guarantee it. Probably the right thing to do is take the notions from
the Loki library and then extend them so that another policy you have is
"singleton scope". Then implement the necessary hard work to do whatever
scopes you need.

> That said, there are still a few cases where singletons / monostates are the
> correct solution to a problem. One example is a dynamic registry of active
> object instances (map from some key to object). Eg, if you have several
> different groups of objects, one per network connection, and need to look up
> the correct set of objects to dispatch to based only on a string / numeric
> representation of the address / port.

While I'd agree that you'd want an object which manages this registry, I
can think of a number of "refactoring" exercises where you'd end up with
multiple registries (for example as a nice way to enforce per-user
namespaces where a given ID maps to a different port based on the user).

> However, as I work more and more, I find fewer and fewer reasons to use
> non-constant static variables, ad with them, fewer reasons to use singletons.

Hehe... I even do const static variables for singletons a lot of the
time. ;-)

> The real problem that I have with log4cpp isn't that they use singletons. It's
> that they think that they're using singletons, but don't. They just use a
> bunch of mutually-dependent global static variables. They don't control
> ccreation or destruction order, even though the destructors for some of them
> use others of them. If they at least stepped up to singletons, then they could
> fix a number of their crash on close or leak on close bugs.

GOD! These kinds of issues with log4cpp drive me to distraction. I
remember actually rewriting a good chunk of the log4cpp code base just
to avoid the really obvious crashes I was getting. One of these days
when I actually have nothing to do (probably 60 years from now), I'll
write my own logging library that does this stuff right. ;-)

--Chris
_______________________________________________
alacpp mailing list
alacpp@xxxxxxxxxxx
http://lists.ellipsis.cx/mailman/listinfo/alacpp