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: gcc-help-owner@xxxxxxxxxxx [mailto:gcc-help-owner@xxxxxxxxxxx]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 order-of-destruction. 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!) Thanks, --Eljay 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.