 |
C++Talk.NET
C++ language newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
Larry Evans
Guest
|
 Posted: Wed Jul 14, 2004 10:31 pm Post subject: Re: Non-deducibility and specialization finalization |
 |
|
On 07/14/2004 11:40 AM, David B. Held wrote:
| Quote: | Alexey Sarytchev wrote:
|
[snip]
| Quote: | 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
struct container : public base
{
};
|
[snip]
| Quote: | 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?
| Quote: | 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.
| Quote: | 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 ]
|
|
| Back to top |
|
 |
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
