Consider the following case:

    class A;

    template <class T>
    struct Holder
    {
        T*  mf(void* p)  { return new (p) T; }
    };

    struct User
    {
        Holder<A>   ha;
    };

Based on my reading of clause 17.4.1, it would appear that this is legal
code.  In fact, my compiler accepts it witout complaint.

However, when Holder<T>::mf() is made virtual, my compiler issues errors.
Presumably it is trying to instantiate Holder<A>::mf() and cannot because
type A has not been defined.

According to 17.4.1.9,

  It is unspecified whether or not an implementation implicitly
  instantiates a vritual member function of a class template if the
  virtual member function would not otherwise be instantiated.

Is this clause applicable to the situation described above?  If so, is my
compiler's issuance of an error conforming behavior?  Finally, for what
reason(s) is the implicit instantiation of virtual member functions treated
differently than non-virtual and static member functions?

Thanks,
--Bob

====================================================================
Bob Steagall                                 steagall@deltalogic.com
DeltaLogic, Inc.                           http://www.deltalogic.com
1537 Kew Road                                   Voice (216) 321-8200
Cleveland Hts, OH 44118-1204                    Fax   (216) 321-6976
---
[ 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
]

In article <3495a9ca.5935655@news.apk.net>, steagall@deltalogic.com (Bob
Steagall) wrote:

> Consider the following case:
>
>     class A;
>
>     template <class T>
>     struct Holder
>     {
>         T*  mf(void* p)  { return new (p) T; }
>     };
>
>     struct User
>     {
>         Holder<A>   ha;
>     };
>
> Based on my reading of clause 17.4.1, it would appear that this is legal
> code.  In fact, my compiler accepts it witout complaint.
>
> However, when Holder<T>::mf() is made virtual, my compiler issues errors.
> Presumably it is trying to instantiate Holder<A>::mf() and cannot because
> type A has not been defined.
>
> According to 17.4.1.9,
>
>   It is unspecified whether or not an implementation implicitly
>   instantiates a vritual member function of a class template if the
>   virtual member function would not otherwise be instantiated.
>
> Is this clause applicable to the situation described above?

Yes.

> If so, is my
> compiler's issuance of an error conforming behavior?

Yes.

> Finally, for what
> reason(s) is the implicit instantiation of virtual member functions treated
> differently than non-virtual and static member functions?

Most implementations handle virtual functions by creating "virtual function
tables" (also known as vtables or vftables) which contain pointers to the
virtual functions.  If there is a pointer to the function, there must be
a definition, so it must be instantiated.

Based mostly on this implementation technique, at one time the working paper
for the standard required that all virtual functions had to be defined and
so all virtual functions of a class template had to be instantiated.

But an implementation might determine through static analysis that the
virtual function can never be called (e.g. neither it nor any of the
functions it overrides is ever referenced) and omit the vtable entry.

Also, there are other implementations of virtual functions which do not
use vtables and do not require that unused virtual functions be defined.

Rather than constrain implementations in either direction, the draft
standard now makes it implementation-defined whether an otherwise unused
virtual function must be defined - or for templates, instantiated.

-- Bill Gibbons
   bill@gibbons.org
---
[ 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
]