In article <01bbaae0$dfddc570$ba912499@bit-blitzer> "Larry Brasfield" <larrybr@earthlink.net> writes:

>     A Proposal Re virtual operator new and virtual ctors

> Of course, this is a bit late, but it's now or never.

No, it was now or never a year ago.  Now it's way too late.
--
    --Andrew Koenig
      ark@research.att.com


[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In article <DyCJ94.Ann@research.att.com> ark@research.att.com (Andrew
Koenig) writes:

|> In article <01bbaae0$dfddc570$ba912499@bit-blitzer> "Larry Brasfield" <larrybr@earthlink.net> writes:

|> >     A Proposal Re virtual operator new and virtual ctors

|> > Of course, this is a bit late, but it's now or never.

|> No, it was now or never a year ago.  Now it's way too late.

Or way too early.  I believe that the standard will be reviewed in 5 to
10 years time, and such extensions could be considered then.
--
James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils,    tudes et r   alisations en logiciel orient    objet --
                -- A la recherche d'une activit    dans une region francophone
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

    A Proposal Re virtual operator new and virtual ctors

Of course, this is a bit late, but it's now or never.

I propose that C++ be given better built in support for various
kinds of cloning operations, via these mechanisms:

1. Allow operator new, in its conventional and possibly overloaded
  forms, to be a virtual method.

2. Allow constructors to be declared virtual.  (These will be true
  virtual constructors, not the misnamed "virtual constructor" idiom.)

Here are some examples of proposed new syntax:
 // ordinary, static new, object-selected default ctor
 pAnotherOfSame = new typeid(oOriginal);

 // ordinary, static new, object-selected parameterized ctor
 pAnotherOfSame = new typeid(oOriginal)(usual, ctor, args);

 // ordinary, static array new, virtual default ctor
 pMoreOfSame = new typeid(oOriginal)[nHowMany];

 // virtual new, virtual ctor
 pAnotherOfSame = oOriginal.new typeid(oOriginal)(args);

 // virtual new, virtual default ctor
 pAnotherOfSame = pOriginal->new typeid(pOriginal);

 // virtual array new, virtual default ctor
 pMoreOfSame = oOriginal.new typeid(oOriginal)[nHowMany];

This proposal will require compile-time support as follows:

1. Parser must recognize . or -> qualified new in addition
 to the unqualified new now recognized.

2. Parser must allow a typeid expression in the same place that
 a typename is now required in new expressions.

3. Semantic analyzer must enforce that the typeid expression
 argument resolves to an object (or reference to one) of a
 class that has virtual ctor(s) matching the argument signature.
 (The usual match) (See runtime support for what this is for.)

4. Unlike ordinary virtual functions, virtual ctors must be
 overridden in derived classes.  (They could default to the
 overload-equivalent base ctor call followed by the default
 ctor for the class.  Mere base class behavior is not enough
 as is the assumed case for ordinary virtual methods.)

5. For scalar new, code generator must create an indirect ctor
 call thru the dtor/ctor table (described below) instead of
 creating inline ctor or calling known ctor.

6. For array new, code generator must arrange many such indirect
 ctor calls instead of running known ctor repeatedly, and, upon
 exception, it must undo using indirect dtor call.

7. (Perhaps?) Semantic analyzer should enforce type compatibility
 between qualifier for new and the typeid() argument.  (Or just
 let the programmer beware.  Why not?)

8. Virtual array and scalar new have the same signatures as
 static new, but do have a this pointer available.  This is for
 uniformity and allows useful allocation sub-pool strategies.

This requires various kinds of runtime implementation support.

1. v-tables must be allowed to have entries for whatever virtual
 operator new's might be defined.  (This is nearly costless.)

2. The RTTI for each class that has virtual ctor(s) must be augmented
 with a table of ctors that could be applied for that class.  The
 order of entries in the table would be determined in the same way
 that v-table entry order is determined now.  Each entry would
 point to code equivalent to a normal inline ctor call, followed
 by a subroutine return.  This new table would be accessed thru a
 pointer located the same way that RTTI is.

3. For classes that have no virtual dtor, the same table should
 have an entry for the class dtor.  For classes that do have a
 virtual dtor, it goes into the table.  This should probably
 always be the 0th entry.  The only use for this is to destruct
 partially constructed arrays in case of an exception.

4. Exception handling for array new calls would have to invoke dtor
 from the RTTI-bound ctor/dtor table the right number of times.

Arguments for This Built in Cloning Support

1. Certain useful patterns of instantiation are
 tedious and error prone without this feature.

 In C++ today, one can design and write polymorphic Clone() or
 CloneMany(n) methods which have much the same effect as using
 the proposed virtual new and virtual ctor features.  This will
 involve a virtual base class Clone(), and overriding Clone()
 methods in the derived classes.  The problem arises when such
 hierarchies have concrete classes at multiple levels.  Clone()
 is very much like the copy ctor in several respects.  It must
 be reimplemented in some fashion for each class.  It has an
 expected meaning that is rarely sensibly left to a base class.
 (non-data-adding derived being the exception)  And actually
 writing the Clone() bodies is work easily relegated to some
 drone or a machine, just as copy ctors could have been.

2. This feature gives clients of a class clone access to all
 the virtual ctors that a class may define, with overload
 resolution, without having to define Clone methods for them.

 For classes that were expected to be cloned, there would be
 no serious cost impact if all the ctors were made virtual.
 One can imagine adding enough Clone(initialValue) methods
 to allow clone objects to be flexibly initialized, but this
 creates one of those parallel maintenance nightmares and, for
 a class library writer, forces the compilation of Clone()
 methods that may not be used.  With the virtual ctor approach,
 due to reuse of ctor code sequences, (presuming implementation
 here), there is minimal added cost in space and a considerable
 savings in execution time by eliminating a call layer.

3. Virtual new/ctor will regularize a pattern of usage that
 is bound to become ubiquitous as we deal more and more with
 higher level abstractions.

Arguments against This Built in Cloning Support
1. Too late.  Maybe next time. (But C++++ is illegal!)
2. Equivalent behavior is possible without changes.
3. It is too much extra baggage for implementations.

Well, that's it.  Ready to be swept away in the march
toward the standard we so eagerly anticipate.

--
Larry Brasfield        My views are my own, at least.

In case anyone notices, I happen to work for Microsoft, but
this proposal is most definitely not made on behalf of my
employer and is not to be construed as reflecting the views
or wishes of Microsoft.  I advance it as an individual, not
as an agent for any other entity.
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]