C++ PATCH for member template classes

Alexandre Oliva oliva@dcc.unicamp.br
Mon Oct 26 15:40:00 GMT 1998

Jason Merrill <jason@cygnus.com> writes:

>>>>>> Alexandre Oliva <oliva@dcc.unicamp.br> writes:
>> Note, however, that the testcase auto_ptr.C is broken, since direct
>> initialization cannot be used when conversion from auto_ptr<D> to
>> auto_ptr<B> muts be performed.

> That's where we differ; I think that the committee's intent was to allow
> direct-initialization.

It certainly was; see item (3) of
http://www.dejanews.com/getdoc.xp?AN=290018284 :

(3) Direct-initialization, base-from-derived, e.g.

          struct Base {};
          struct Derived : Base {};
          auto_ptr<Derived> source();
          auto_ptr<Base> p( source() );

  This is similar to (1); in this case, the viable constructor is:
  which is callable using the conversion
         auto_ptr<Derived>::operator auto_ptr_ref<Base>()
  which should be selected when operator overloading tries to
  convert type auto_ptr<Derived> to auto_ptr_ref<Base>.

  Overload resolution succeeds.  No additional copying is allowed,
  so the copy constructor need not be callable.

Unfortunately, this is just plain broken, since, as we agree,
auto_ptr<Base>::auto_ptr_ref<Base> and
auto_ptr<Derived>::auto_ptr_ref<Base> are unrelated types.  The
Standard is broken.  The issue is: should we provide a different
implementation with the expected behavior or stick with the broken
standard and allow only copy-initialization for different types?  The
Standard does not explicitly state that direct-initialization is to be
supported, this can only be (incorrectly) guessed from the

Alexandre Oliva
mailto:oliva@dcc.unicamp.br mailto:oliva@gnu.org mailto:aoliva@acm.org
Universidade Estadual de Campinas, SP, Brasil

More information about the Gcc-patches mailing list