Topic: Non-deducibility and specialization finalization
Author: Larry Evans <cppljevans@cox-internet.com>
Date: Wed, 14 Jul 2004 22:31:21 +0000 (UTC) Raw View
On 07/14/2004 11:40 AM, David B. Held wrote:
> Alexey Sarytchev wrote:
[snip]
> It depends on how the names are nested. If you look at Larry Evan's
> post, you see an example given by Dave Abrahams:
>
> struct base
> {
> template <typename T>
> struct impl
> { };
> }
>
> template <class Policy>
> struct container : public base
> {
> };
>
[snip]
> As far as specializations go, there may be some in which the nested
> impl<> template does not even exist, and they may not show up until
> after some template argument deduction process. That is the
Let me see if I understand. Given the primary or general template:
template <class Policy>
struct container
{
template <typename T>
struct impl
{ };
};
There could be specializations:
template <>
struct container<P1> : public base
{
};
template <>
struct container<P2> : public base
{
};
which would cause the problem Abrahams highlighted. However,
your "finalize" requirement would disallow these specializations.
Is that correct?
> motivation for my proposal to "finalize" specializations. However,
Isn't there something in the standard which limits the specializations
to only those that are visible during the instantiation? I remember
getting burned by not taking this into account and just had to make
it visible; otherwise, the compiler, IIUC, just didn't consider it.
If that's true, then I guess the template argument deduction doesn't
depend on specializations that may show up but only on those that
are actually visible at instantiation time. I could be wrong.
Hopefully someone will correct me.
> in the special case where the nested template is within the scope
> of the enclosing class' template parameters, then the nested
> template *is* logically deducible (given all specializations are
> visible), which is why I think the C++ template argument deduction
> rules should allow it for that case (which I argue is a common
> case, rather than an exception, as far as nested templates go).
I agree. Another alternative is to just specify that
container<P>::impl<T> means only "immediate nesting" of the
"general" template and not include "superclass nesting". But maybe
that's too restrictive. A third alternative is to allow a new
operator :0:, to mean this. IOW, even with the above container
specialziations on P1 and P2, only the general template would be
valid if container<P>:0:impl<T> were used.
I'm cross-posting this to comp.std.c++ since it seems relevant
there.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
[ 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 ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]