> On May 6, 2016, at 2:29 PM, Richard Smith <[email protected]> wrote: > Per http://wg21.link/p0136r1 <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:
This only affects interoperation to the extent that it's done with vague linkage, since as far as I know there's no way to give an inherited constructor a strong definition. I think we should recommend using (A) in all cases where it's possible, which as far as I know is everything except variadic constructors, and then just inline all the appropriate initialization for variadics. (A) has to deal with both constructor variants, though. Is there a reason we can't just continue to mangle the symbol as a C1 or C2 in the derived class? Just concern about ODR differences when there happens to be a non-trivially-copyable type passed by value? John. > > > 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? > _______________________________________________ > cxx-abi-dev mailing list > [email protected] > http://sourcerytools.com/cgi-bin/mailman/listinfo/cxx-abi-dev
_______________________________________________ cxx-abi-dev mailing list [email protected] http://sourcerytools.com/cgi-bin/mailman/listinfo/cxx-abi-dev
