[cxx-abi-dev] ABI for new inheriting constructor rules

[Richard Smith]

Per http://wg21.link/p0136r1 an inheriting constructor declaration no
longer results in the implicit synthesis of derived class constructors, and
instead the behavior of a call to an inherited constructor is that:

 1) the portion of a hypothetical defaulted default constructor prior to
the base constructor invocation is executed, then
 2) the inherited constructor is invoked, then
 3) the portion of a hypothetical defaulted default constructor after the
base constructor invocation is executed

There are a couple of obvious ways we could avoid emitting the code for (1)
and (3) in every inherited constructor call site:


Approach A: synthesize a fake constructor of the derived class

Strawman: add a new form of mangled name for a fake constructor that
forwards to a base class constructor, whose <encoding> is that of the base
class constructor, except that the <nested name> is that of the derived
class and the <unqualified-name> is

 <ctor-dtor-name> ::= CI <base class type>

 This would give code largely similar to what we generate with the C++11
inheriting constructor rules, except that the additional copy constructions
and destructions for parameters would be removed. The downsides are that
this only works if we can forward all the arguments (and in particular, we
can't do this for varargs constructors), and generates one additional copy
of the derived class default initialization code for each base class
constructor.


Approach B: factor out the duplicated portion of the construction

Strawman: add three new forms of mangled name for these constructor
fragments:

  <ctor-dtor-name> ::= CP [<seq-id>] _  # default constructor prefix
  <ctor-dtor-name> ::= CS [<seq-id>] _  # default constructor suffix
  <ctor-dtor-name> ::= DP [<seq-id>] _  # default constructor cleanup prefix

where in the first and third case the <seq-id> represents the position of
the last virtual or direct base class that is constructed or destroyed by
the function, and in the second case it represents the position of the last
virtual or direct base class that is not constructed by the function (where
in each case the base classes are enumerated in the order in which they
would be constructed).

The CS symbols would destroy the entire class object if an exception is
thrown. (I think it'd be fine except in pathological cases to provide only
the CS symbols; maybe we could drop the CP/DP ones.)


Or perhaps a hybrid of these (it may be reasonable for the constructors
from approach A to call the fragments from approach B, especially when
optimizing for code size). In any case, use of these new symbols would be
optional; implementations could instead choose to emit the code inline.
Thoughts?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sourcerytools.com/pipermail/cxx-abi-dev/attachments/20160506/ecf47d97/attachment.html>