> So the question is: after the *global* object is destroyed, will its
> memory get overwritten? Or can I still "play" with that memory?

> > Can I safely assume that, after the logger is destroyed, "is_destroyed
> > = true"?

> Absolutely not.

> > I want to *know* if a logger is used after it's been destroyed.

> > So the question is: after the *global* object is destroyed, will its
> > memory get overwritten? Or can I still "play" with that memory?

> You can't do anything to the object after you've deleted it. (I'm

> That doesn't work.
> The scenario is like this:
> - I have a global logger, defined in Translation Unit 1
> - I have another global object, defined in Translation Unit 2.

> Between translation units, it's unspecified which object is
> constructed first, thus, it's not sure which object will be destroyed
> first.

> Actually, with a slight modification this can be made to work. I have
> exactly the same problem with a logger of mine a few years ago. I
> provided an accessor routine to return the address of the logger
> object. This was done by having a pointer that was initialized to the
> address of the logger variable. Instead of setting destroyed to true I
> set this pointer to null. Access was always and only via the accessor
> method that returned the pointer so this enabled me to detect when the
> accessor was returning a pointer to a destroyed logger.

> I really don't like singletons and now handle logging differently
> using Parameterize From Above (TM). But for those that want to use
> singletons I recommend using a singleton manager. An example of one
> can be seen in ACE. These managers control creation of singletons so
> that they are destroyed in reverse order of their creation. Hopefully
> this will help.

> You just can't guard against this ;)

> Since each other global variable which
> uses logger needs to include your header,
> there will be one logger::init object
> *before* the user variable. Inside this
> translation unit the logger::init object
> will be constructed *before* the other
> global variable (if that does not use
> static initialization, but in this case,
> it will not use your logger), and due
> to the ref counter it will only be
> constructed *once*. The same logic
> applies to the d'tor, but reverse.

> Actually, now that I think about it, it's not as easy as I thought.
> TU = Translation Unit
> Assume we have

> TU1
> // this includes the header with the logger::init trick
> implementation of destructor for class A, which uses logger L

> TU2
> // this does not include the header with the logger::init trick
> static instance of class A

> TU3
> static instance of logger L

> So the solution should be: if in a translation unit you have a static
> instance of some class, and in its destructor you might end up doing
> logging, you should include the logging header (which will do the
> initialization trick)

> +: It doesn't require dynamic initialization
> -: It requires a base-derived relation.

> > The order of inialization between translation units is not defined,
> > thus the same applies
> > for destruction. The following can happen:
> > - a global object is constructed before a logger
> > - thus, it will be destroyed after the logger
> > - if in its destructor it tries to use the logger, there we go -
> > logger is used after it's been destroyed.

> > You just can't guard against this ;)

> You could use the approach that good ol'
> std::ios_base::Init has been invented for
> because the global IO inserter/extractors
> (cin, cout, ...) have essentially the same
> problem which you are describing.