Re: Problems with -fno-implicit-templates

[Alexandre Oliva <oliva at dcc dot unicamp dot br>]

Carlo Wood <carlo@runaway.xs4all.nl> writes:

> template <class TYPE>
> dstream &operator<<(dstream &o, const TYPE &data) { return o; }

> dstream& operator<<(dstream& o, const char *data) { return o; }

>   d << "a string constant";

> it incorrectly(?) uses the template, and not the specialisation.

Strange.  On all tests I've done on sparc-sun-solaris2.5, the
non-template function is used.

The type of "a string constant" is `char const[17]', not `char const*'
nor `char*'.  Furthermore, `char const[N]'->`char const*' is an Lvalue
Transformation (array to pointer conversion: Exact Match), and binding
a reference to the array is an Identity conversion (Exact Match too).
[over.ics.rank]/3 seems a bit confusing about whether the first
alternative should be considered better than the second; it says:

3 Two implicit conversion sequences of the same form are  indistinguish-
  able conversion sequences unless one of the following rules apply:

  --Standard conversion sequence S1 is a better conversion sequence than
    standard conversion sequence S2 if

    --S1 is  a  proper  subsequence  of  S2  (comparing  the  conversion
      sequences in the canonical form defined by _over.ics.scs_,
-->   excluding any Lvalue Transformation; the identity conversion
-->   sequence is considered to be a subsequence of any non-identity
-->   conversion sequence) or, if not that,

[snip]

While it says that Lvalue Transformations should be disregarded, it
says that the Identity conversion is a subsequence of any other.
Which one is right?

If the Identity conversion *is* a subsequence of the Lvalue
Transformation, then the template function should be used, because of
the first bullet in [over.match.best]/1.  Otherwise, if they compare
equal, the second bullet says that a non-template function should be
preferred over a specialization of template function, so the
non-template function should be used.  Does any standard maker cares
to explain?

> Note that adding a -W option (which should never change the code imho)
> causes this to work:

Agreed

> It seems impossible to instantiate this template manually (using
> -fno-implicit-templates), while it DOES get instantiated automatically
> as we saw above (without -fno-implicit-templates).

How about:

template dstream& operator<<(dstream&, char const (&)[17]);

-- 
Alexandre Oliva
mailto:oliva@dcc.unicamp.br mailto:aoliva@acm.org
http://www.dcc.unicamp.br/~oliva
Universidade Estadual de Campinas, SP, Brasil