Initialization priorities

[mendell at ca.ibm.com]

The compiler is not allowed to initialize t before s in the example below.
If you put a #pragma priority between the two, the values before and after
must be such that t is alwas initialized after s.

Mark

I've been thinking about this, and I think I'm leaning towards not
mandating this as part of the ABI. (*) I don't see that this feature
is that useful, and it's (almost) the only thing we're mandating
that's not part of standard C++.

One thing that worries me is this kind of code:

  struct S { S (); };
  struct T { T (); };

  S s;
  T t;

but where `t' gets initialized first.  It's very confusing to realize
that the T constructor can't rely on `s' being initialized; one of the
nice things about C++ is that lexical ordering implies initialization
ordering, which means that you can (usually) assume variables are in a
good state.  (For instance, with locals, the standard goes to
considerable effort to disallow any way of talking about an
uninitialized variable; code like:

   goto label;
   S s;
   label:

is illegal.)

So, I'm not even sure this is a great language feature, let alone
something that we should mandate support for in the ABI.  Furthermore,
we haven't provided a syntax for doing this, so programs using these
features will only be portable at the object-file level anyhow -- not
at the compiler level.  Vendors who do not support this feature in
their compilers may well "forget" to implement it in their linkers as
well, rendering it a non-standard anyhow.

--
Mark Mitchell                   mark at codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

(*) I admit to arguing against most extensions, whenever they are
    proposed, so you should bear that in mind.