global objects order-of-construction & order-of-destruction

Young, Michael
Thu Aug 17 15:02:00 GMT 2006

If there is not a switch for this, there may be other code analysis tools that can catch / flag / report on global objects.  By the way, when it is "not possible" to get away from global objects, the only way I know of dealing with OoC/OoD dependencies is to use Schwartz counters ("original" article can be found in "C++ Gems", but it is widely documented).  Everything else that I've seen is actually a variant on this technique.  If you know of anything else, I'd be interested in it...
  - Mike

-----Original Message-----
From: []On
Behalf Of John Love-Jensen
Sent: Thursday, August 17, 2006 10:04 AM
To: MSX to GCC
Subject: global objects order-of-construction & order-of-destruction

Hi everyone,

Is there any switch in GCC for C++ to disallow global objects (flag them as
an error), or at least a flag to point them out as a warning?

class Foo { };
Foo foo; // <-- I want this flagged!

I know, I know... C++ allows global objects, so it is not an error, let
alone a warning, type of situation.

In large projects (very, very large -- with many DLLs), I've run into
order-of-construction and order-of-destruction in every single project I
have worked on in the past 8 years.

The answer is "Well, don't do that.  Don't use global objects."

The lead engineer would like us to avoid OoC and OoD problems by nipping the
problem in the bud by fiat -- if there is some easy way to identify & excise
those objects from our code.

So the problem is identifying where those global objects are sneaking into
our application, and excising them.  Perhaps using one of the various
techniques mentioned by Scott Meyers, or one of the Design Patterns to
protect against OoC problems (and I hope, OoD as well).

Hence, compiler error flag on global object?  Or warning flag?  Or some
interesting use of nm and grep?

Any help will be appreciated.  Hmmm... I hope my inquiry isn't off topic for
this forum -- might be a peripherally related GCC question.  I'm
experiencing this problem using GCC due to unordered order-of-destruction,
and not with other compilers (knock on wood) which have LIFO

Oh, and the things that cause problems are usually "live objects" not "dead
structures".  (Although I have seen dead structures that reside in released
DLL's cause problems in a few cases, where another part of the code has a
dangling pointer to the unmapped DLL (DSO's, not SSO's).  But that's a
similar-but-different sort of problem.  And don't get me started on
allocating objects in one private heap, and trying to delete them in a
different heap -- ARRGH!)


PS:  please don't say "use Java".  I'm well aware that Java (or other
well-chosen select languages) don't suffer from this sort of predicament.
I'm already a Java SE 5 sympathizer.

More information about the Gcc-help mailing list